Omie

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds useful behavior beyond the annotations: config header yields a permanent connection, while passing a token yields a session-only login, and no args returns a link. It does not fully spell out side effects or success/failure return values, but annotations already cover idempotency and non-destructiveness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loaded, with no fluff, but the long single sentence with parenthetical clauses and multiple alternatives could be structured into clearer separate instructions. Still, every part adds necessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter auth tool with no output schema, it covers the no-arg return (the link), the token-paste path, and the persistent-config alternative. It doesn't state the response on a token success/failure, but the invocation guidance is sufficient for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description carries the full burden for the optional `token` parameter. It explains that token is a JWT/access token pasted by the user and how to pass it, compensating well for the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as MCP.AI authentication for IDE agents, with a concrete browser-login + access-token flow and two invocation paths (no args for a link, token for login). This specific verb+resource is unambiguous and easily distinguished from the unrelated calculo_* sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly differentiates the persistent config-header approach ('best... permanent, non-expiring') from the session-only paste/login path, and states exactly when to call with no args versus with { token }. This gives the agent clear selection criteria for both setup and invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish this is read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond that by specifying the two main response states: authenticated:true with empty pending[] when all providers are connected, and connect_url plus per-install URLs when credentials are missing. This helps an agent predict what to expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loads the core purpose, and then adds only the essential conditional details. Every sentence contributes meaningful information, and there is no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only status tool with no output schema, the description is complete enough. It tells the agent what information will be returned, what the success condition looks like, and what happens when credentials are missing. The low complexity means no additional guidance is required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description does not need to explain any input semantics. The baseline of 4 applies because there is no parameter burden at all.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: returning connection status and URLs. It distinguishes connect from its sibling authenticate by framing it as a status/read operation rather than an action, and the conditional output descriptions reinforce this.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes clear that this is the tool to call when checking connection state or getting URLs. It does not explicitly mention alternatives like authenticate, but the context strongly implies connect is for status checking rather than initiating authentication, so usage is clear without being fully explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses important behaviors: invoke runs an MCP even when it is not installed, does a one-off run without adding the MCP to the toolkit, returns a connect link when credentials are needed, returns a checkout/top-up link when payment is needed, and requires workspace owner/admin for write operations. The description enriches the annotations and does not contradict them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with identity and the core flow, and nearly every sentence carries useful guidance. However, it is one dense, wall-of-text paragraph with mixed language ("pontualmente") and heavy inline emphasis, which makes the many action alternatives hard to scan and parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 23-parameter, 14-action facade with no output schema, the description is remarkably complete: it covers the core flow, one-off invoke semantics, auth/credential/payment behavior, permission requirements, installed flags, the prompt library, and most action outcomes. The main gaps are the resume action and return-shape details for a few actions, but the overall guidance is sufficient for correct invocation in most cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description does a lot of compensating work: it maps action values such as search, describe, invoke, install, list_tools, publish_prompt, and explains tool_id, arguments, and prompt-related intent. However, several parameters and enum actions remain unexplained, including resume, limit, immediate, tier_slug, cancel_reason, report_context, conversation, request_name, and request_details, leaving agents under-specified for those paths.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as the official mcp.ai marketplace: the in-platform catalog of MCPs/tools and the way to run them. It states the core discovery→describe→invoke flow, distinguishes the prompt-library subdomain from the MCP flow, and makes it clear this is a marketplace orchestrator rather than one of the sibling calculator/authenticate tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: use install only to make an MCP permanent, prefer invoke for one-off use, use list_tools to see what is callable now, use subscribe/cancel for billing, and use request_mcp when nothing fits. It also explains what to do when invoke returns a connect link or checkout link, including retry behavior.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds a lot beyond the thin annotations: dedup behavior when the CNPJ already exists, precedence of user-supplied fields over the registry lookup, and that the situacao cadastral appears in the response with a warning if not ATIVA. Does not cover auth/account requirement or any rate/limit behavior, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the shortcut and the key behavior in a compact block of sentences; every clause carries information. Slightly dense with stacked clauses, but no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the workflow, dedup, precedence and response signal well, which matters for a create tool with no output schema. However, for a 17-parameter tool it leaves most parameters undescribed, so it is adequate but with a clear gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 17 params and 0% schema description coverage, the description carries the full burden, yet it explains only the main ones (documento/CNPJ, razao_social, nome_fantasia, endereco, email, telefone). It leaves cep, bairro, cidade, estado, complemento, endereco_numero, observacao, inscricao_estadual, codigo_cliente_integracao, account, and the 'tipo' enum (fornecedor/cliente/ambos) unexplained, with no format hints such as CNPJ formatting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb plus resource ('cadastra um FORNECEDOR (ou cliente) na Omie a partir do CNPJ'), lists the fields it auto-populates from the Receita Federal query, and names the sibling to use for CPF (omie_create_customer). An agent can distinguish it from omie_create_customer without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use (CNPJ, no manual typing) and an explicit exclusion with the alternative ('Só CNPJ: pra CPF use omie_create_customer'). It also states the de-duplication condition up front.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint=false and destructiveHint=false. The description adds behavioral context beyond that: it states the title reopens and is not deleted, and that it's the way to correct errors. No contradiction with annotations, and it adds value by clarifying the mutation's scope and reversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the main action, then adds key differentiations and parameter guidance. Every sentence carries meaning with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Core usage is well covered, but the 'account' parameter is left unexplained and there is no hint about the response or side effects. For a mutation with no output schema, this is a noticeable gap, though the primary guidance is solid.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It explains codigo_baixa and codigo_baixa_integracao clearly, but omits the 'account' parameter entirely. This partial coverage is helpful but leaves one of three parameters unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it cancels a payment (baixa) of an accounts payable and clarifies it does not delete the title, distinguishing it from omie_delete_payable. The verb 'CANCELA' and resource are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit usage guidance: cancels a payment and corrects a wrong write-off, and tells when to use alternatives (omie_delete_payable for deletion, omie_settle_payable for re-issuing). It also specifies which parameter to provide (codigo_baixa or codigo_baixa_integracao), leaving no ambiguity about when and how to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since annotations only indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false), the description adds valuable context: the title returns to open and is not deleted. This goes beyond the annotations, explaining the state change and the non-destructive nature. It is sufficient for a simple cancellation, though it does not mention idempotency or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, using one sentence plus a key note. The action is front-loaded (CANCELA) and the core behavior is stated clearly. It is efficiently written, though the parameter key note could be formatted as a separate line for better clarity—but overall it is appropriately sized with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple mutation tool with 3 parameters and no output schema, the description covers the primary purpose and the key selection, but it omits the account parameter entirely and does not mention edge cases (e.g., what happens if the receipt is already cancelled or reconciled). The description is adequate for basic usage but incomplete for full operational confidence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must explain parameters. It mentions that codigo_baixa or codigo_baixa_integracao act as keys, but it does not clarify their meaning (internal ID vs integration ID) or the role of the 'account' parameter. This is a significant gap; an agent cannot determine how to populate 'account' or the exact semantics of the key fields from the description alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the function: cancel the receipt of an accounts receivable, returning the title to open status. It explicitly distinguishes from deletion (não apaga o título) and matches the sibling omie_cancel_payment but for receipts. The action verb and resource are precise, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description identifies the target operation (canceling a receipt) and provides the key selection (codigo_baixa OR codigo_baixa_integracao), which implies usage context. However, it does not explicitly contrast with siblings like omie_cancel_payment or omie_unreconcile_receipt, so there is no explicit when-not guidance, though the purpose is clear enough for most cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this is a non-read-only, non-idempotent, non-destructive write. The description adds a real precondition beyond that: the parent `grupo` must be a totalizer group. It does not describe auth requirements or whether a duplicate description causes an error, but the added constraint is genuine value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose, then branches into the two modes in compact clauses; the examples ('2.01', 'Despesas Administrativas') are load-bearing. The nested parentheticals make it dense but nearly every token earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-param write tool with no output schema, the description covers mode selection, required vs optional fields, enum meanings, and a cross-reference to omie_list_category_types. The two undocumented params (`account`, `natureza`) are the remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage the description must carry the load, and it documents 5 of 7 params with meaning and mutual exclusivity: `descricao`, `grupo` (name OR code, with examples), `tipo_grupo` (R/D decoded), `tipo_categoria`, `codigo_dre`. It leaves `account` and `natureza` entirely unexplained, which keeps it out of the top band.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Cria uma categoria no plano de contas') and further distinguishes the two creation modes by their API operations (IncluirCategoria vs IncluirGrupoCategoria). An agent can differentiate this from omie_update_category and omie_get_category without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit conditional rules for each mode: category requires `descricao` + `grupo`; new group requires `descricao` + `tipo_grupo` and no `grupo`. It also points to omie_list_category_types for the `tipo_categoria` value. It doesn't state when to prefer creating a group vs a category in business terms, so it falls short of a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description indicates it's a creation operation, which aligns with annotations (readOnlyHint=false). It adds context about the integration key and official documentation. However, it does not disclose potential side effects, required permissions, rate limits, or consequences of creating a duplicate account.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is informative but slightly verbose, including Portuguese text and a link. It could be shortened without losing essential information, but most sentences provide value (operation, parameter hints, doc reference).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should clarify return values or confirmation behavior. It provides a parameter hint but omits the 'account' parameter. The link to official docs partially compensates, but for a creation tool, more detail about success/failure responses would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains that 'data' is a JSON string containing specific fields (like cCodCCInt, tipo_conta_corrente) and links to official documentation, adding significant meaning beyond the bare schema. However, the optional 'account' parameter is not described, leaving its purpose unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a checking account (conta corrente) in the company, with specific types (bank/cash/card). It includes the exact API operation name and details about the primary parameter 'data', ensuring unambiguous identification of the action and resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus its siblings (e.g., omie_update_checking_account, omie_list_checking_accounts). There is no mention of prerequisites, alternative tools for different scenarios, or situations where this tool should be avoided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=false, so the agent knows it's a mutation. The description adds context by specifying the types of entries it creates and the structure of the data payload. It doesn't discuss potential side effects, reversibility, or error behavior, but given the annotations cover the basic mutation nature, the description adds sufficient value beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and efficient; every sentence provides actionable information. It opens with the purpose, quickly lists what it's not, then dives into the data structure, and closes with a pointer for the account code. No wasted words, and the structure logically flows from purpose to usage to details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description should cover return values, but it doesn't. However, it thoroughly explains the input structure, clarifies the distinction from related tools, and references how to obtain the required account code. The only significant gap is the unexplained optional 'account' parameter and the lack of return value details. With no output schema, a note on what the tool returns would improve completeness, but the description is still quite comprehensive for a creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides no descriptions (coverage 0%), so the description must compensate. It thoroughly documents the required 'data' parameter, breaking down the JSON structure into cabecalho and detalhes blocks with field-level detail, including date format. However, it does not explain the optional 'account' parameter, leaving a gap. Given the core parameter is well-explained, this is a significant but not complete compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a specific type of checking account entry (LANÇAMENTO avulso) and lists the types it supports (tarifa, rendimento, aplicação, resgate, ajuste). It also explicitly distinguishes it from check/payable tools (omie_lancar) and transfers (omie_transfer_between_accounts), making the purpose unambiguous and differentiating it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states what this tool is NOT (conta a pagar/receber and transferência) and names the correct alternatives for those cases (omie_lancar and omie_transfer_between_accounts). It also provides guidance on obtaining the required account code (omie_list_checking_accounts), giving the agent clear direction on when and how to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate it's a write operation (readOnlyHint=false) and not destructive. The description adds context about data format and tagging, but no additional behavioral traits like idempotency or authentication needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is informative and front-loaded, but could be slightly more concise. It uses bold markers for emphasis and references external docs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The input is well-described, but there is no output schema and the description does not explain what the tool returns (e.g., created entity ID). References to official docs partially compensate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description carries full burden. It explains the data parameter thoroughly with required and common fields, but does not mention the account parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates customers/suppliers (Cadastra um cliente ou fornecedor) and clarifies that in Omie they are the same record with different classification, distinguishing it from sibling tools like omie_update_customer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides guidance on marking as supplier using tags and lists required fields, but does not explicitly state when to use this tool vs alternatives like update or delete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide basic information (not read-only, not destructive). The description adds that the tool creates a record and specifies required fields, but does not disclose additional behavioral details such as authentication needs, error responses, idempotency, or side effects beyond creation. Given the annotations, the description adds modest context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: two sentences front-loading the action and then detailing the main parameter. Every sentence adds essential information without redundancy. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a creation tool with no output schema, the description covers input in detail but omits return value information (e.g., whether it returns the created payable ID). It references external documentation but does not summarize error handling or idempotency (idempotentHint is false). The description is adequate for input but incomplete for full agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 2 parameters with 0% description coverage. The description explains the 'data' parameter in detail (JSON string with required fields and references to other tools) but does not mention the 'account' parameter. This partial coverage adds value for the main parameter but leaves one parameter undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a payable account ('Lança (cria) uma conta a pagar') and references the specific API endpoint (IncluirContaPagar). It distinguishes from siblings like omie_create_receivable and omie_create_customer by explicitly naming the resource type, though it does not directly contrast with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: when creating a payable. It references helper tools like omie_list_customers and omie_list_checking_accounts for prerequisite IDs, but does not explicitly state when not to use it or name alternatives (e.g., omie_update_payable for modifications). Guidance is implicit rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=false (write operation) and destructiveHint=false. The description adds context about the required fields and references to official docs, but does not disclose additional behavioral traits beyond what annotations provide, such as idempotency implications or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three sentences, each adding value: the action, the parameter details, and a reference to documentation. No redundant or unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description should at least hint at what the tool returns (e.g., created receivable ID). It provides good input context but omits return value information, making it somewhat incomplete for an agent to fully understand the tool's behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains the 'data' parameter as a JSON string with specific required fields, adding meaning beyond the schema's type-only definition. However, the 'account' parameter is not described, leaving a gap in coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a receivable account ('conta a receber') using the API endpoint 'IncluirContaReceber'. This distinguishes it from sibling tools like omie_create_payable and omie_create_customer, which handle different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context by listing required fields and referencing sibling tools for customer IDs and checking accounts, implying when this tool is appropriate. However, it does not explicitly state when to use it versus alternatives or include any when-not scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description states 'IRREVERSÍVEL' (irreversible), but the annotation destructiveHint is false, creating a direct contradiction. Additionally, no other side effects or permissions are mentioned. This is a significant transparency failure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, using two sentences to convey the action, identifiers, irreversibility, and bulk support. No unnecessary information or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description does not mention the required parameters 'tabela' and 'id' from the schema, nor does it clarify the role of 'account'. Since the schema lists these as required, the description is incomplete and could mislead an agent into thinking only the optional identifiers are needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains the purpose of id_anexo, codigo_integracao, and file_name as identifiers, and hints at 'ids' for bulk. However, it does not explain 'tabela' or 'account', which are part of the schema and required for the operation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool removes an attachment from a document, identifies it by id_anexo, codigo_integracao, or file_name, and mentions bulk support. This differentiates it from sibling tools like omie_upload_attachment and omie_get_attachment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides guidance on how to specify the attachment (via id_anexo, codigo_integracao, or file_name) and notes bulk execution with 'ids'. However, it does not explicitly contrast with list or get operations, though the deletion intent is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description states 'Ação IRREVERSÍVEL' (irreversible action), which implies destructive behavior. However, annotations declare destructiveHint: false. This is a clear contradiction, violating the rule that description should not contradict structured metadata. Despite adding useful context, the contradiction forces a score of 1.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at four sentences, front-loading the purpose and key distinction from siblings. Each sentence adds essential information (what it does, when to use, parameters, warning, documentation reference) without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high-risk nature (irreversible action) and lack of output schema, the description adequately covers purpose, usage boundaries, parameter choice, and a critical safety warning. It references documentation for more details. Missing a brief note on expected outcome (e.g., success/failure behavior), but overall sufficient for an informed call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the two identifier parameters (nCodLanc and cCodIntLanc) well, including their meaning and usage (provide one or the other). However, the 'account' parameter is not mentioned, leaving its purpose unclear. Overall, adds significant value for 2 out of 3 parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool deletes/stornos a checking account entry, gives examples of movement types, and explicitly distinguishes from sibling tools omie_delete_payable and omie_delete_receivable. The verb 'APAGA/estorna' and resource 'LANÇAMENTO de conta corrente' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool (for checking account movements like transfers, applications, withdrawals, fees) and when not to (for payable/receivable titles, directing to alternatives). It also warns that the action is irreversible and advises user confirmation before calling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description states the action is irreversible, implying destructiveness, but annotations set destructiveHint to false. This contradiction misleads an AI agent about the tool's safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, no wasted words. Purpose stated first, then critical usage notes. Every sentence adds necessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Provides essential steps (confirm, consult) but lacks details on return values, error cases, or what happens after deletion. However, for a deletion tool with no output schema, this is largely adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description adds meaning for codigo_lancamento_omie and codigo_lancamento_integracao by explaining mutual exclusivity. However, the 'account' parameter is not mentioned, leaving it undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it deletes (excludes) a payable account using either Omie ID or integration code. It distinguishes from siblings like omie_get_payable and omie_create_payable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to confirm with user before calling since action is irreversible, and advises consulting omie_get_payable first to verify the payable. Provides clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description claims the action is irreversible and destructive ('Ação IRREVERSÍVEL'), but annotations set destructiveHint to false, a direct contradiction. Flagged as 'Annotation Contradiction'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first states purpose and key parameters, second warns about irreversibility and gives usage guidance. No redundant information, perfectly front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple delete operation with no output schema, the description covers action, parameters, irreversibility, and prerequisite consultation. Minor gap: no mention of return value or error handling, but adequate for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description explains that 'codigo_lancamento_omie' or 'codigo_lancamento_integracao' must be provided, adding meaning beyond the schema. However, the 'account' parameter is not described, leaving 1 of 3 parameters unexplained. Schema coverage is 0%, so description partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool deletes a receivable (conta a receber) using either Omie ID or integration code. It distinguishes from siblings by advising to consult omie_get_receivable first.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the action is irreversible and requires user confirmation before calling. Advises to check with omie_get_receivable first, providing clear when-to-use and when-not-to-use context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the returned link expires at dDtExpiracao and bulk execution via ids is supported.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: the first sentence states the core behavior and return value, and the second adds bulk support. Every sentence earns its place with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the return value, expiration, identification options, and bulk support, which is good for a simple read operation. However, with 7 parameters, 0% schema coverage, and no output schema, the unexplained required parameters and the ambiguity around 'id' vs 'id_anexo' leave the description incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains id_anexo, codigo_integracao, file_name, and ids, but it leaves the required 'tabela' and 'id' parameters unexplained and does not clarify the relationship between 'id' and 'id_anexo'. This is a meaningful gap given the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's specific function: returning a download link for an attachment, including the exact response fields (cLinkDownload, dDtExpiracao). It also names three identification methods, which distinguishes it from sibling tools like omie_list_attachments, omie_upload_attachment, and omie_delete_attachment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context by telling the agent how to identify the attachment (by id_anexo, codigo_integracao, or file_name) and explicitly points to omie_list_attachments as the way to find the id. It does not explicitly state when not to use this tool versus upload/delete siblings, but the context is sufficient for correct selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare a safe, read-only, idempotent operation. The description adds the example code format, but does not clarify what the account parameter is or how returns are shaped.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single compact sentence with a concrete example; front-loaded and free of filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with 0% schema documentation and no output schema, the description omits what account means and provides no behavioral details beyond annotations, leaving gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so both parameters are undocumented. The description only illustrates the codigo format ('2.01.02') and gives no meaning for account, failing to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Detalha/retrieves) and resource (categoria do plano de contas) with an example code value. Distinguishable from omie_list_categories, but sibling differentiation is not explicitly stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus omie_list_categories or when not to. Usage must be inferred from the name and description alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, idempotent, non-destructive), so the description adds value by disclosing return-field composition (nSaldoAtual, nSaldoAnterior, nSaldoDisponivel, nSaldoConciliado, nSaldoProvisorio) and the default-today period behavior. It does not disclose pagination limits on the movement list or maximum period length, which would matter for reconciliation. Still, well above what annotations alone provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core capability, then differentiates from the sibling, then parameter details. Dense but each sentence carries information. The all-caps Portuguese emphasis and parenthetical tool name are slightly noisy but serve scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-param, no-annotation-gap read tool whose safety profile is covered elsewhere, the description provides identity, defaults, return field composition, and sibling routing. Missing coverage of account and apenas_nao_conciliados and any pagination guidance keeps it from being complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate: it explains conta (name OR id), nCodCC (Omie id), cCodCCInt (integration key), the date format (AAAA-MM-DD or DD/MM/AAAA), and the incluir_movimentos toggle's effect. This meaningfully covers 5 of 8 params. It does not mention account or apenas_nao_conciliados, leaving two undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('EXTRATO BANCÁRIO e SALDO ATUAL de uma conta corrente') and explicitly differentiates from siblings: contrasts with omie_list_checking_accounts (saldo_inicial at a fixed date vs. real current balance) and clarifies that with incluir_movimentos:true it acts as the movement lister, related to omie_list_checking_account_entries. An agent can select between account-related siblings without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use branching: default returns balances, set incluir_movimentos:true to get the statement entries for reconciliation. Names the alternative (omie_list_checking_accounts) and the exact condition that selects it (fixed saldo_inicial vs. real current balance). Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the identifier constraint ('Informe nCodLanc OU cCodIntLanc') but does not elaborate on behaviors like handling of both/neither identifiers or return format. Given annotations cover the safety profile, the description adds modest value without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no fluff. The primary action is front-loaded, and the critical parameter instruction follows immediately. It efficiently conveys purpose and essential usage in minimal words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with no output schema, the description covers the main identifiers but omits the 'account' parameter entirely. It also does not specify behavior when both identifiers are supplied or what happens if neither is provided. While the tool is straightforward, the missing account parameter and lack of edge-case guidance leave gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions are absent (0% coverage), so the description must clarify parameters. It explains nCodLanc as the Omie id and cCodIntLanc as an internal code, and specifies that one must be provided. However, the 'account' parameter is not mentioned at all, leaving its semantics unclear. It compensates for two of three parameters, which is significant.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Detalha um lançamento de conta corrente' (details a checking account entry) and identifies the specific API method. It distinguishes itself from siblings like omie_get_checking_account_balance (balance) and omie_list_checking_account_entries (list) by indicating it retrieves a single detailed entry. The verb 'detalha' and resource are explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear parameter requirements: must inform nCodLanc OR cCodIntLanc. This guides the agent on what to supply. It does not explicitly compare to alternatives, but the context implies this tool is for retrieving a specific entry versus listing. No exclusions are stated, but the 'OU' (or) clarifies an essential usage rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. Description adds minor context (function name) but lacks details on error behavior or what happens when parameters are combined.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single, well-structured sentence in Portuguese that conveys essential information without redundancy. Front-loaded purpose before parameter instructions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers identification parameters and purpose, but fails to explain the 'account' parameter or describe the output format (no output schema). For a read tool, output expectations are important but omitted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so description must compensate. It explains two key parameters (codigo_cliente_omie and codigo_cliente_integracao) as alternatives, adding meaning beyond the schema. However, it omits the 'account' parameter entirely.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it details a customer/supplier, mentions the API function 'ConsultarCliente', and specifies the two alternative identifiers. It distinguishes from sibling tools like omie_create_customer and omie_list_customers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit instruction to use either codigo_cliente_omie or codigo_cliente_integracao, guiding when to use this tool for retrieving a single customer detail. Doesn't explicitly state when not to use or mention alternatives, but the constraint is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint as safe. The description adds useful behavioral context: what data is returned (items, taxes, totals) and the critical caveat that invoices are not found by their 44-digit access key in this query. It doesn't cover error scenarios, but it goes beyond annotations and contains no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose, then adds differentiation, identification rules, and a warning in a logical order. The tax list is lengthy but directly tells the agent what will be returned. Each sentence serves a clear function, though the enumeration could be tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no param descriptions, the description covers the main behavior, sibling differentiation, identification, and a key limitation. It still leaves the account and data_emissao parameters undocumented and does not describe the response shape in detail, which prevents a perfect score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description is the only source of parameter meaning. It clearly explains codigo_nf and the numero+serie pair, but it does not explain account or data_emissao. It also lacks type or format details for the parameters, so compensation is only partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Detalhe COMPLETO de UMA nota fiscal (ConsultarNF)', clearly indicating it retrieves detailed data of one invoice. It explicitly distinguishes itself from omie_list_invoices (header only) and omie_get_invoice_xml (XML). The purpose is specific, actionable, and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states when to use this tool: when you need full itemized tax details beyond the header from omie_list_invoices. It gives a clear exclusion: if you need the XML, use omie_get_invoice_xml. It also explains how to identify the invoice (by codigo_nf or by numero+serie) and warns against the 44-digit access key.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds significant behavioral detail: it returns the exact PDF document authorized by SEFAZ (not a proxy or summary) or representation, the specific return components, the only-for-self-issued restriction, and the nIdNF naming quirk. This gives an agent more than enough context about the tool's actual behavior and limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and return values, then gives context, data-provenance, and a warning. Every sentence carries relevant information and the warning is signaling. It is slightly longer than strictly necessary, mainly due to the explanatory closure that SEFAZ is not an alternative source, but this is still acceptable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one required parameter and no output schema, the description fully covers what is returned, how to identify the resource, and when the call is valid. It does not explain the account parameter and does not mention possible error conditions, but these are minor gaps. The description is complete enough for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains the key required parameter id_nfe very well: where it comes from, how it appears in omie_get_invoice (compl.nIdNF), and how it can be named differently (nIdNfe). However, the optional account parameter is never mentioned and schema description coverage is 0%, so the agent gets good guidance for the main parameter but no an explanation for the secondary one.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the operation (obtaining the fiscal XML of an emitted NF-e), names the underlying service (ObterNfe, dfedocs), and specifies what is returned: the SEFAZ-authorized XML itself, access key, DANFE PDF, and status. It distinguishes itself from sibling omie_get_invoice by targeting the audit/fiscal-document use case rather than general invoice data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly routes the agent to the audit workflow: get the XML here and send it to auditor_fiscal_auditar_nota. It also gives a clear when-not: only works for invoices emitted by the user, because SEFAZ does not provide the emitter's own XML. It further explains how to obtain the required identifier through omie_get_invoice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so description adds minimal behavioral insight beyond the API operation name ('ConsultarContaPagar') and the identifier constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose, second provides parameter guidance and usage hint. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple read tool: explains what it does, which parameters to use, and in what context (before editing). Lacks return value description, but that is partially mitigated by the tool name and purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by explaining the two key parameters and their mutual exclusivity, but fails to mention the 'account' parameter, leaving its meaning unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Detalha uma conta a pagar' (details a payable account) and distinguishes from sibling 'omie_update_payable' by advising use before editing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use before editing (omie_update_payable) and specifies that either codigo_lancamento_omie or codigo_lancamento_integracao should be provided. Lacks explicit when-not-to-use guidance but is clear enough given context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds that the tool details a receivable and is a pre-edit step, but does not elaborate on return format or other behaviors. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with purpose, no redundant words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with good annotations, the description covers the main purpose and parameter usage. Missing explanation for the 'account' parameter, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description carries burden. It explains that 'codigo_lancamento_omie' is the Omie ID and 'codigo_lancamento_integracao' is an alternative, and that either can be used. The 'account' parameter is not mentioned, leaving a minor gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Detalha uma conta a receber' (details an account receivable), specifies the API function 'ConsultarContaReceber', and distinguishes from sibling 'omie_update_receivable' by noting 'Use antes de editar'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to provide either 'codigo_lancamento_omie' or 'codigo_lancamento_integracao', and indicates to use before editing. This provides clear when-to-use and alternative options.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare it is a write operation (readOnlyHint=false) and non-idempotent, but the description adds substantial behavior the annotations cannot: pre-creation duplicate detection with an override flag, ambiguity returns alternatives instead of guessing, date format acceptance, and — importantly — that parcelamento issues each parcela as a separate Omie call with per-parcela errors. It does not state auth/permission requirements, but disclosure is well above the annotation baseline.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded single-paragraph summary followed by three dense bullets (DUPLICIDADE, RATEIO, PARCELAMENTO) and a closing routing sentence. Everything earns its place; the opening paragraph is long but packs distinct facts rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter composite write tool with nested objects and no output schema, the description covers the failure modes an agent needs (duplication guard, ambiguity error, per-parcela partial failure) and what the response lists. A few simple fields and any permission prerequisites remain unaddressed, keeping it short of 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and 16 parameters, so the description must compensate. It does for the complex ones: nome-OU-código acceptance, categorias/departamentos rateio with percentual-ou-valor and the 100% sum rule, parcelamento fields (quantidade/periodicidade/valor_por_parcela) and whether valor is per-parcela, plus date formats. It leaves account, observacao, numero_documento, codigo_lancamento_integracao and data_previsao unexplained, but most are self-naming.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (lança/cria) and resource (conta a PAGAR ou a RECEBER), and goes further by naming the workflow it replaces (list_customers + list_categories + list_checking_accounts + create). An agent can distinguish it from omie_create_payable/omie_create_receivable immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing: "Use isto por padrão pra lançar; as tools omie_create_* continuam pra quem já tem o payload completo." This states both the default condition and the alternative with the condition that selects it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds that it returns id and label for connected companies, but does not elaborate on other behaviors like pagination or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the core purpose without any unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (1 optional parameter, no output schema), the description covers the basic purpose. However, it omits the parameter explanation, leaving a gap in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one optional 'account' parameter with 0% coverage. The description does not mention this parameter at all, providing no meaning beyond the schema definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists Omie companies (CNPJ) connected to the install, with id and label. The verb 'List' and resource 'empresas (CNPJ) Omie' are specific. This distinguishes it from sibling tools like omie_list_customers or omie_list_projects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing accounts but does not specify when to use it versus alternatives, nor does it provide exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by disclosing that the endpoint is paginated and supports bulk execution via ids, and that the response contains a listaAnexos array with nIdAnexo fields. This is useful behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two compact sentences with no filler. It front-loads the core purpose, then covers pagination, the return field, routing to dependent tools, and bulk support — every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with no output schema, the description is incomplete. It does not explain how to specify the document type via 'tabela', what filters/account mean, or how pagination parameters work. The routing to get/delete is helpful, but the agent lacks enough information to call the tool correctly in varied scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only clarifies the ids parameter ('Bulk support: accepts ids') and vaguely references pagination ('Paginado'). The required 'tabela' parameter and others such as account, filters, page, and page_size are left unexplained, leaving significant ambiguity for an agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Lista os anexos de um documento' (lists attachments of a document), and names the underlying API operation 'ListarAnexo'. It clearly distinguishes itself from sibling attachment tools by directing the agent to use the returned nIdAnexo with omie_get_attachment or omie_delete_attachment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly tells the agent what to do with the result: use omie_get_attachment (download) or omie_delete_attachment. It also notes bulk support for ids, signaling when batched execution is possible. It does not explicitly state when not to use this tool, but the list operation is clearly distinct from the get/delete/upload attachment siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate safe read-only behavior (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds value by noting pagination and the key field's role, without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences front-load the purpose and key detail (codigo_categoria role). No extraneous information; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the output's importance but omits parameter details. For a list tool with no output schema and 4 undocumented parameters, more guidance is needed for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The four parameters (page, account, filters, page_size) have zero schema description coverage, and the description provides no explanation of their meaning, format, or default values. The agent has no guidance on how to use 'account' or 'filters'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists categories/chart of accounts, specifies pagination, and explains the exact use case (providing codigo_categoria for payable/receivable creation). It distinguishes itself from sibling tools by linking to specific create tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use: when you need category codes for omie_create_payable/receivable. It does not explicitly state when not to use or list alternatives, but the connection to sibling create tools provides clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety and idempotency are covered. The description adds domain context (each type is expense 'P' or revenue 'R'), but it omits any pagination behavior, account selection semantics, or rate-limit information beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly written sentences that front-load the core purpose and then explain the payload meaning. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with strong annotations and no output schema, the description explains what is returned but leaves the three input parameters completely undocumented. This is a significant gap for correct invocation, especially for `account` and pagination parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description says nothing about the three input parameters (`page`, `account`, `page_size`). With no documentation in either the schema or the description, an agent has no guidance on how to control pagination or select an account.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Lista') and resource ('TIPOS de categoria'), and explicitly frames it as the source of the `tipo_categoria` (cCodigo) required when creating or altering a category. This clearly distinguishes it from the sibling `omie_list_categories`, which lists categories rather than category types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context: the returned `tipo_categoria` code is needed before creating or altering a category, implying when to call it. It does not name an alternative tool or state when not to use it, so it falls short of the explicit when/when-not/alternatives bar.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description is not required to restate those. It adds valuable behavioral context: pagination behavior, specific filter fields with date format (DD/MM/AAAA), and the origin codes for transfers (TRAP/TRAR). This goes beyond the schema and provides useful operational details without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise – a single sentence plus a note. It front-loads the primary purpose and then adds filter and transfer details. The structure is efficient, with no filler words. It loses a point because the filter fields are listed compactly without capitalization or escaping, which slightly reduces readability, but overall it's well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no parameter descriptions, the description must carry more weight. It explains the purpose, filters, and transfer origins, but it omits the shape of the response, how pagination works (e.g., page size limits), the meaning of 'account' (likely the account ID), and the exact format of the filters JSON (e.g., exact key names and how to pass multiple filters). While the tool is relatively simple, the lack of parameter documentation for three of four parameters and lack of return format make it incomplete for an agent to call correctly without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% – none of the parameters have descriptions in the schema. The description only partially compensates: it details the 'filters' parameter (listing accepted fields and date format) but does not explain 'page', 'account', or 'page_size'. Even 'filters' is not fully specified (e.g., whether all fields are optional or how to combine them). For a tool with zero schema coverage, the description must pay more attention to parameter documentation; it fails to do so for the majority of parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists checking account entries ('Lista lançamentos de conta corrente') and specifies the API method (ListarLancCC). It distinguishes from sibling tools like omie_list_accounts and omie_list_checking_accounts by focusing on entries rather than accounts. It does not explicitly name an alternative, but the resource and action are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (to list checking account entries) and provides filter guidance, but it does not explicitly state when NOT to use it or name alternative tools. The pagination and filter details give context, but there's no direct comparison with other sibling list tools. Usage is inferred rather than explicitly guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds no new behavioral details (e.g., pagination, sorting, rate limits), but does not contradict annotations. Meets minimum expectations given annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no waste. The main action is front-loaded. Could be slightly improved by structuring parameter info, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 4 parameters but no output schema. Description does not explain pagination, filtering syntax, or output format. Incomplete for a list operation; agent cannot infer how to build a request or interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% (no parameter descriptions in schema or description). The description fails to explain any of the 4 parameters (page, account, filters, page_size), leaving the agent without guidance on how to use them. This severely impairs effective invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb ('lista') and resource ('contas correntes'), and distinguishes from sibling tools like omie_list_accounts by specifying checking accounts. Also adds a specific use case (mapping for reconciliation), making purpose highly specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description gives context by mentioning a typical use case (reconciliation mapping), implying when to use. However, it does not explicitly exclude alternatives or state when not to use (e.g., when a broader list is needed). Provides clear context but lacks exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. Description adds pagination and filter format details, which are behavioral traits not in annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise (two short fragments), front-loads purpose and key features (paginated, filters). Could be slightly more structured by listing parameters, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a list tool with no output schema and few parameters, the description lacks details on how to use page/account/page_size, defaults, and result format. The filter reference is vague (external structure not defined). Not enough to ensure correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must explain parameters. Only 'filters' is described (JSON format referencing Omie API). 'page', 'account', and 'page_size' are not explained at all, leaving the agent with insufficient guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it lists customers/suppliers/carriers (specific resource) and mentions pagination and JSON filters. It distinguishes from siblings like omie_get_customer (single) and omie_create_customer (create). However, the description is only in Portuguese, which may reduce clarity for non-Portuguese speakers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage for listing multiple entities, no explicit when-to-use or when-not-to-use compared to alternatives. The description does not mention exclusions or alternative tools, but purpose indirectly gives context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context beyond annotations: it is paginated and each department has a 'codigo' for allocation. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. Front-loaded with the core action, followed by a concise detail. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 4 parameters, no output schema, and no required fields, the description partially covers output shape (each item has a 'codigo') and pagination. However, it lacks details on default page size, other fields, and how filters work. Adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only implicitly explains page and page_size via 'Paginado', but does not describe 'account' or 'filters'. The 'codigo' mentioned is a data field, not a parameter. Minimal added value for parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'lista' (lists) and the resource 'departamentos/centros de custo', with additional detail about pagination and the 'codigo' field used for allocation. It is distinct from sibling list tools like omie_list_accounts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., other list tools) or prerequisites. The description only states what it does without context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description does not contradict them. It adds that the operation is not paginated and explains how the 'codigo' values are used elsewhere, providing useful behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences with no fluff. The essential information is front-loaded: what it lists, that it's not paginated, and the codigo usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with two optional parameters, the description covers the main behavior, non-pagination, and one parameter thoroughly. Missing the 'account' parameter explanation, but overall it is adequate for a straightforward read-only operation with no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It thoroughly explains 'codigo' with examples and usage, but does not mention the 'account' parameter at all, leaving it unexplained. Thus it only partially compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists document types (dinheiro, boleto, cartão, transferência etc.) and even names the internal method PesquisarTipoDocumento. This distinguishes it from other list tools like omie_list_accounts or omie_list_categories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains the use case for the codes ('usado em baixas e lançamentos de conta corrente') and how to filter by 'codigo', giving clear context for when to use this tool. It does not explicitly name alternatives, but the purpose is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail: pagination ('Paginado') and the meaning of detalhes.dDtConcilia (empty = pending). However it doesn't explain pagination limits or default page size.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and use case, but the dense parenthetical enumeration of filter keys mixes reference documentation into the description. It is information-dense but somewhat crammed into a single block without clear separation between purpose, parameters, and response notes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, key filters, reconciliation semantics, and the dDtConcilia response field, which is substantial for a no-output-schema, 0%-coverage tool. Still missing what page/page_size/account do and any expected result shape, leaving gaps for an agent configuring the call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate and largely does. It documents filters JSON keys with Hungarian naming conventions (dDtPagtoDe/Ate, cTpLancamento with enum-like values 'CP','CR','BX', cStatus, nCodCC, nCodCliente), explains apenas_nao_conciliados semantics, and mentions the dDtConcilia field in responses. Page, page_size, and account parameters remain undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Lista movimentos financeiros — lançamentos/baixas de contas a pagar, a receber e conta corrente') and references the underlying API method ListarMovimentos. It distinguishes from omie_list_payables/omie_list_receivables by covering both plus checking account movements in a single unified listing, though it does not explicitly name the siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Establishes clear context: this tool is 'a base da CONCILIAÇÃO (pareia com o Banco MCP)', positioning it as the data source for reconciliation workflows. It also differentiates the apenas_nao_conciliados flag as a filter for unreconciled items. Lacks explicit when-not-to-use guidance versus omie_list_payables or omie_list_checking_account_entries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnly, idempotent, and not destructive. The description adds that the tool is paginated and specifies filter structure, providing valuable behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the purpose, and provides key filter details without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description lacks information about return values. It covers main purpose and filter options but omits details on pagination parameters and output format, making it adequate but not fully comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description partially compensates by detailing the filters JSON parameter (date range, status, type). However, it does not explain page, account, or page_size parameters, missing an opportunity to add full semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists issued fiscal notes (NF-e) in Portuguese, with pagination and filter details, making the purpose unambiguous and distinct from sibling tools that list other resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives like omie_list_receivables or omie_list_payables. However, the tool name and description imply it is for invoices, and sibling tools cover different resources.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, and non-destructive behavior, and the description adds a specific behavioral quirk: the raw Omie filter erroneously includes CANCELADO alongside PAGO/LIQUIDADO, so `status` should be preferred. It also discloses pagination. It does not describe the response format, but no output schema is present and the safety profile is already established.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and well-organized: the first sentence states the core purpose and pagination; the second gives the most important parameter guidance. It is dense but not bloated, though the caveat about Omie's raw filter is somewhat packed into the middle of the sentence flow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an optional-parameter, read-only list tool, the description covers the main aspects an agent needs: what it lists, that it paginates, and how to filter reliably. The main gaps are the specific shapes of the checks `filters` JSON and the pagination parameters themselves, but given the low stakes of a list call and the sibling-tool context, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate, and it does add meaning for `status` (menu, values, reliability caveat) and `filters` (JSON with date-from/to, client, checking-account keys). However, `page`, `page_size`, and `account` are left undocumented, so the compensation is only partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action and resource directly ('Lista contas a pagar' — lists accounts payable) and notes that it is paginated. This is immediately distinct from sibling tools such as omie_get_payable (single record), omie_create_payable (write), and omie_list_receivables (receivables), so no schema inspection is needed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a concrete, actionable guideline: use `status` for the situation (aberto/pago/cancelado/todos) because Omie's raw filter is less reliable and mixes CANCELADO with PAGO/LIQUIDADO, and use `filters` (JSON) for everything else (date/customer/account). It does not explicitly state when-not-to-use this tool or name alternatives, but the context makes the selection clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that it is paginated and each project links 'codigo' to financial entries, which provides minor behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only two sentences, direct and without unnecessary words. It front-loads the core action and key details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and 4 undocumented parameters, the description omits critical context about input formats, return structure, and usage scenarios. Pagination and 'codigo' are mentioned but not enough to make the tool fully understandable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description provides no explanation for any of the four parameters (page, account, filters, page_size). The mention of pagination is vague and not tied to parameters. No semantic value added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists the company's projects, provides the API method name (ListarProjetos), and notes pagination and the 'codigo' field. This distinguishes it from sibling list tools like omie_list_customers or omie_list_accounts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, no mention of prerequisites or exclusions. The description only states what it does, not when to invoke it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the read-only/idempotent annotations, the description reveals two concrete behavioral traits: the tool is paginated, and Omie's raw filter conflates status values, which is why the `status` parameter should be used. This is genuine context about how the API behaves and why the wrapper shaped that way.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded: the core action of the tool, the pagination hint, then the important status warning and filter examples. Every sentence has purpose, but the text is dense and not broken out into clear sections.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers pagination and the status vs filters decision, but most of the five parameters are five parameters with zero schema documentation. It leaves some params intentionally vague, and even the `filters` examples are 'etc.'. With no output schema, it offers minimal return/format context; an agent would need to infer outcome or rely on examples.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does for `status` (though the schema already has an enum) and for `filters` by showing JSON keys like filtrar_por_data_de/ate and filtrar_por_emissao_de/ate. However, `page`, `page_size`, and `account` are not semantically explained; the only hint for them is 'Paginado', which is thin for three optional parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Lista contas a receber (ListarContasReceber)', which clearly identifies the verb and resource: listing receivables. It also names the underlying Omie API endpoint. It does not explicitly differentiate from sibling tools like omie_list_payables, but the resource name is unambiguous enough for an agent to know this is the receivables list tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs the agent to use the `status` parameter for situation filtering, warning that Omie's raw filter mixes CANCELADO with PAGO/LIQUIDADO, and then to use `filters` for all other filtering. This is clear, actionable guidance for parameter usage. It does not, however, say when to choose this tool over sibling list tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are all false, so the description must carry the full behavioral burden. It mentions the action and the key parameter, but does not disclose side effects, reversibility, error behavior, or prerequisites (e.g., receipt must exist). The description adds little beyond what the name conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (two sentences) and front-loads the action and key information. It lacks explanation of the account parameter, but the structure is efficient and no filler is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema and empty annotations, this description is incomplete. It fails to explain the account parameter, prerequisites, or expected outcomes (e.g., success/failure signals). An agent would need to guess at required context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain the parameters. It mentions codigo_baixa and codigo_baixa_integracao as alternative keys, but entirely omits the 'account' parameter and provides no type/format details. This is a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action: marking a receipt as CONCILIADA (ConciliarRecebimento). It also includes the specific use context (matching bank statement with Omie title) and differentiates from siblings like omie_unreconcile_receipt by the explicit reconcile-purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states explicitly when to use the tool: 'Use ao casar o extrato do banco com o título na Omie.' This provides clear context. It does not explicitly mention alternatives or when NOT to use it, but the primary use case is well-defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are minimal and do not contradict the description. The description adds important behavioral context beyond those annotations: reconciliation cannot be done after the fact as a separate call, and clearly warns that the only way to reconcile already-settled payments is to cancel and re-launch. This is genuinely useful and non-obvious behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loaded with the core purpose before moving into parameter details. Most sentences add genuinely useful information, especially the reconciliation warning and the helper reference to omie_list_checking_accounts. It is longer than average but justified by the nontrivial JSON structure it documents.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and sparse annotations, the description covers the operation's intent, the required data payload, optional fields, date format, helper tool lookup, and the reconciliation-specific behavior. The main missing piece is documentation of the top-level 'account' parameter; otherwise the agent has enough context to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the burden. It does so well for the main 'data' parameter, explaining it is a JSON string with the settlement fields and their formats, including codigo_lancamento_omie vs codigo_lancamento_integracao, date format, and the optional observacao. However, the top-level 'account' parameter is not explained at all, leaving a small but real semantic gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb and resource: 'Dá baixa (liquida/paga) uma conta a pagar', and ties it to the Omie operation 'LancarPagamento'. It clearly differentiates this from the reconciliation-only behavior and from related sibling flows by explaining that reconciliation happens through this settlement action, not through a separate call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: it is for settling payables and is the only way to reconcile a payment via the API. It also gives a concrete when-not/alternative path: for an already-settled payment, use omie_cancel_payment and re-launch the settlement with concatenation. This routes an agent to the right sibling without ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) by disclosing partial-failure semantics (an error in one title does not abort the rest), the response shape (`baixas` ok vs `erros` per title), and a hard cap of 50 items per call. It also notes `conciliar:true` is the only API path to reconcile — valuable behavioral context an agent cannot infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose and the batch-vs-single distinction, then layers identification, reconciliation, error handling, and the cap. Dense but every sentence adds operative detail; slight verbosity in the identification clause keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, the description supplies what the schema cannot: the return contract (`baixas` with codigo_baixa, `erros` with Omie messages) and the 50-item limit. Nothing essential to calling it correctly is missing, aside from the minor undocumented fields noted above.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage the description must carry the burden, and it documents the key fields: `baixas` item identification via codigo_lancamento (aliased to codigo_lancamento_omie from get/list) or codigo_lancamento_integracao, plus valor, and that `data`/`conta_corrente` accept item-level or batch-default values. It leaves juros, multa, desconto, observacao, codigo_baixa_integracao and top-level `account` unexplained, so some params remain opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (dá baixa/settle) and resource (VÁRIAS contas a pagar), and explicitly frames it as the batch path ('numa chamada', 'sem uma chamada por título'), which distinguishes it from the single-title omie_settle_payable sibling. An agent can identify the tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete usage scenario ('conciliar um mês inteiro contra o extrato do banco') and a conditional rule for `conciliar:true` ('use quando a baixa vem do extrato do banco'). It implies when to prefer batch over single calls but never names the single-title alternative explicitly, so it stops short of full when/when-not routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the annotations by exposing non-obvious behavior: conciliation via this API only happens at settlement time, there is no separate ConciliarPagamento operation, and already-settled items need cancellation and re-submission. These are exactly the behavioral details that an agent cannot infer from the schema or annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is dense and front-loaded with the core purpose, but the conciliar_documento point is repeated about twice, and the guidance would be easier to scan if the reconciliation instructions were consolidated. Still, nearly every sentence adds meaningful information, so it is not padded fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with a bare schema and no output schema, the description effectively provides everything an agent needs to construct a valid call: the JSON payload shape, date format, account reference, related tools, and failure/recovery guidance. It reads like a complete operational spec.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 0%, the description compensates strongly by explaining the JSON structure of data, including codigo_lancamento, codigo_lancamento_integracao, codigo_baixa_integracao, valor, date format, codigo_conta_corrente, and optional observacao. However, the second parameter account is never described or even mentioned, which prevents a perfect score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description leads with a precise operation: 'Dá baixa (liquida/recebe) uma conta a receber (LancarRecebimento)', pairing a clear verb with the resource it acts on. It also differentiates from the sibling omie_reconcile_receipt by explaining the difference between settling with immediate reconciliation and reconciling later.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit guidance: pass conciliar_documento: 'S' for immediate reconciliation, use omie_reconcile_receipt when reconciliation should happen afterward, and if the item is already settled, cancel with omie_cancel_payment and relance. This clearly tells an agent when to use this tool versus the alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations (which only flag it as a non-read-only, non-destructive, non-idempotent write). It discloses partial-failure semantics ('erro em um título NÃO derruba os demais'), the response envelope (`baixas`/`erros`), the 50-item cap, and that `conciliar` is the only API path to reconciliation — exactly the behavioral detail an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: purpose first, then the identifier semantics, then the flags and failure mode, then the limit. Every clause adds distinct operational value with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description describes the return structure (ok entries with codigo_baixa, plus per-title errors), the batch limit, identifier resolution, and default inheritance. Given the complexity of a batch write tool, this is complete enough to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description carries the burden and delivers: it explains `codigo_lancamento` (= Omie id, matching codigo_lancamento_omie in get/list), the `codigo_lancamento_integracao` alternative, the item-level vs batch-default semantics of `data` and `conta_corrente`, and the meaning of `conciliar`. It omits the numeric fields (juros, multa, desconto) and codigo_baixa_integracao, so not exhaustive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('dá baixa em VÁRIAS contas a receber numa chamada') and immediately clarifies the mechanism (LancarRecebimento por título, loop interno). An agent can distinguish this batch tool from the singular omie_settle_receivable and from omie_reconcile_receipt without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context ('o caminho pra conciliar um mês inteiro contra o extrato do banco sem uma chamada por título') and a conditional rule for `conciliar:true` when the baixa comes from a bank statement. It stops short of explicitly naming the single-title sibling as the alternative for small workloads, leaving that to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (which indicate mutation but no destructiveness), the description discloses that both sides of the transfer are generated and linked (origens TRAP/TRAR), and that incorrect simulation pollutes reconciliation. This adds meaningful behavioral context that annotations do not cover, though it stays focused on the core operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph with high information density, front-loaded with the purpose and a clear directive. It uses emphasis (ALL CAPS) effectively and avoids redundant wording, though it is slightly verbose for its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a financial mutation tool with no output schema and low parameter coverage, the description covers the essential behavioral facts (two linked entries, reconciliation impact) and input nuances. It omits details about return values and error handling, but these are less critical for an agent correctly selecting and invoking the tool given the description's strengths.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It does so for `conta_origem`/`conta_destino` (accepts name or id, resolved server-side) and `data` (format flexibility), but leaves the other six parameters unexplained. This is a partial compensation for the coverage gap, not a full one.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it transfers money between two company checking accounts, specifies the internal operation (IncluirLancCC with `transferencia` block), and explicitly warns against simulating with separate entries. This distinguishes it from other financial tools without needing to open schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly declares this is the right operation for transfers and provides a strong when-not-to-use instruction ('não faça uma saída + uma entrada separadas'). It also gives practical input guidance (account name/id, date formats), leaving no ambiguity about when to choose this tool over siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false and destructiveHint=false, so the agent knows this mutates but is not destructive. The description adds no further behavior details: no mention of reversibility, effect on related records, permission requirements, or response format. With the full burden on the description (since annotations are generic), the description offers minimal behavioral context beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that leads with the purpose and then immediately provides the essential key requirement. Every word earns its place; there's no fluff or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating tool with 3 parameters, no output schema, and zero param documentation, the description is too sparse. It doesn't explain the 'account' param, describe side effects, or mention error conditions or data integrity implications. The alternative-key note is helpful but far from sufficient for an agent to safely invoke the operation in all cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no param descriptions). The description compensates partially by stating 'Chave: codigo_baixa OU codigo_baixa_integracao', clarifying that one of these two keys must be provided as an alternative. However, it does not explain the 'account' parameter at all, and it doesn't complete the picture (e.g., format expectations, which key to prefer). It adds some value beyond the bare schema but leaves a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Desfaz a conciliação' = undoes reconciliation) and a clear resource ('baixa de recebimento' = receipt write-off), and gives the API operation name (DesconciliarRecebimento). It clearly implies the inverse of omie_reconcile_receipt among siblings, though it doesn't explicitly name the sibling. This is a clear, distinguishable purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives, no prerequisites (e.g., that the receipt must already be reconciled), and no conditions that should prevent usage. The only hint is the key requirement, which is more about parameter usage than when to invoke the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes beyond the annotations by disclosing the parameter-driven direction of the mutation (inativar:true deactivates, inativar:false reactivates) and the underlying API method mapping, which is non-obvious behavior. It does not, however, discuss permissions, side effects on child categories, or reversibility beyond the reactivation flag.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences, front-loaded with the core action and followed by the identifier and flag semantics. Every sentence carries content, though the parenthetical API method names add slight noise for an agent that only needs the outcome.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter mutation tool with no output schema and 0% schema description coverage, the description covers the critical routing (group vs category) and the two key parameters but omits the semantics of five parameters, leaving real gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and there are 7 parameters, yet the description only explains `categoria` (exact code/name with example) and `inativar`. It leaves `account`, `natureza`, `descricao`, `codigo_dre` and `tipo_categoria` completely undefined, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States specific verbs and resource (rename/adjust/deactivate a chart-of-accounts category) and explicitly distinguishes itself from siblings omie_create_category, omie_get_category and omie_list_categories. It even clarifies that Omie has no delete-category operation and that inactivating is the substitute, which pins down the operation's scope precisely.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use vs. alternatives: there is no 'excluir categoria', so inactivation is the path, and it instructs the agent to look up the category first to decide between AlterarCategoria and AlterarGrupoCategoria. Both the trigger condition and the prerequisite lookup are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds no further behavioral traits beyond the edit action. It does not disclose side effects, permissions, or error conditions, but it does not contradict the annotations either.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences. The first sentence states purpose and technical detail (API method), and the second explains the key parameter and provides a usage hint. No words are wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the two parameters and no output schema, the description covers the main parameter well and advises pre-consultation. However, it omits explanation of the account parameter and does not describe the return value or success/failure behavior, leaving some gaps for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains that the data parameter is a JSON string containing the account key and fields to alter, adding meaning beyond the schema's plain string type. However, the optional account parameter is not described, leaving a small gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool edits an existing checking account (Edita uma conta corrente existente) and provides the API method name. It distinguishes from sibling tools like omie_create_checking_account and omie_list_checking_accounts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises users to consult omie_list_checking_accounts first to obtain the account key, which is a clear contextual guideline. It does not explicitly state when not to use the tool, but the advice is actionable and specific.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=false (modifies data) and destructiveHint=false. The description adds the behavioral trait that it updates specific blocks ('os blocos a alterar'), implying a targeted partial update. It also implies a prerequisite of fetching the existing entry. But it does not disclose potential failure modes, idempotency (though annotations say false), or whether the operation is reversible. Given annotations exist, this is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no fluff. The purpose is front-loaded, and the critical input requirement is stated right after. It's appropriately sized for a tool with moderate complexity, though it could have used the second sentence to also clarify the 'account' parameter without adding much length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema and two parameters, the description covers the main 'data' parameter thoroughly and the prerequisite consultation. However, it omits the 'account' parameter entirely, which could affect the request if used. It also lacks any comment on return values or error handling, though output schema absence makes that less critical. The gaps around 'account' and potential error conditions make it incomplete enough to not be a 4.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% for the 'data' parameter, so the description carries the burden. It explains that 'data' is a JSON string that must contain a key (nCodLanc or cCodIntLanc) and the blocks to change, which is meaningfully beyond mere type. However, the optional 'account' parameter is completely unmentioned in the description, leaving the agent without explanation for when to use it (e.g., filtering by account). This gap prevents a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Edita' (edits) and the resource 'lançamento de conta corrente' (checking account entry), with the API operation name in parentheses. This distinguishes it from other entry tools (create/delete/get) because the verb and resource are explicit. It doesn't explicitly name sibling alternatives, but the meaning is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit guidance: 'Consulte antes com omie_get_checking_account_entry' (consult first with the get tool), which tells the agent when to use this tool relative to fetching data. It also specifies the required input structure (must contain nCodLanc or cCodIntLanc). However, it does not explicitly state when to avoid this tool (e.g., for creating or deleting entries), leaving some inference to the agent, so not a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=false, which are consistent with an update operation. The description adds that the data parameter must contain the customer key and fields to change, but does not disclose potential side effects or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. Front-loaded with the action and essential format requirements, followed by a practical usage hint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description does not specify return values, but it adequately describes input requirements and provides a prerequisite suggestion. Slightly incomplete for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully explains the data parameter: it must be a JSON string containing the customer key (codigo_cliente_omie or codigo_cliente_integracao) and fields to alter, with examples. This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool edits an existing customer/supplier ('Edita um cliente/fornecedor existente'), specifies the underlying API endpoint ('AlterarCliente'), and distinguishes from sibling tools by advising to use omie_get_customer first.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises to consult omie_get_customer before using this tool, providing clear context for correct usage. It does not explicitly state when not to use it, but the guidance is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds value beyond the annotations by detailing that the 'data' parameter is a JSON string with mandatory keys and examples of editable fields. The annotations already indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false), and the description aligns with that. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively concise with three sentences, each providing distinct information: action, parameter requirements, and usage advice. It avoids redundancy and is front-loaded with the main purpose. However, breaking the parameter explanation into a separate, more structured format could improve clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks important details: it does not mention return values or success/failure indicators, nor does it cover the 'account' parameter. For an update operation with no output schema, the description should explain what the tool returns (e.g., the updated record or a status). The guidance to consult with 'omie_get_payable' hints at a workflow but leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains the 'data' parameter in detail, specifying required keys and example fields. However, it completely ignores the 'account' parameter, which is in the schema but not described. With 0% schema description coverage, the description should cover all parameters to compensate, but it fails to do so for one of the two.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool edits an existing payable account ('Edita uma conta a pagar existente') and names the underlying API method ('AlterarContaPagar'). It distinguishes itself from siblings like 'omie_create_payable' and 'omie_get_payable' by focusing on the update action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on how to use the tool: it requires a JSON string with the record key and fields to change. It also advises consulting 'omie_get_payable' first, implying a prerequisite and aiding proper usage. However, it does not explicitly state when not to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate the tool is not read-only and not destructive. The description adds that the data parameter must contain keys and fields to change, implying a partial update, and suggests prior consultation. It does not detail permissions, idempotency (hinted false), or error behavior, so transparency is adequate but not extensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences that front-load the purpose and API function, then provide essential parameter guidance and a usage recommendation. No word is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has two parameters, no output schema, and moderate annotations, the description covers the 'data' parameter well and recommends prior consultation, but it omits the 'account' parameter and does not describe return values or success indicators. This leaves gaps for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain all parameters. It thoroughly explains the 'data' parameter, including required keys and example fields, but it does not mention the 'account' parameter at all, leaving its purpose ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it edits an existing receivable (Edita uma conta a receber existente), providing a specific verb and resource. It references the API function AlterarContaReceber and distinguishes from sibling tools like create, delete, get, and list by naming the update operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly recommends consulting omie_get_receivable before using this tool, providing clear context for when to invoke it. However, it does not mention alternatives like omie_settle_receivable or omie_delete_receivable, nor does it specify when not to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only provide simple flags (readOnlyHint=false, destructiveHint=false), leaving the description to carry the behavioral burden. It does so thoroughly: it discloses that the temporary file copy is deleted after attachment, that the file is compressed and sent by the platform, that file names with more than one dot are rejected, and warns against using file_base64 for conversation attachments. This is far beyond annotations and gives the agent full behavioral expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but information-dense, organized into paragraphs and dash-lists. It front-loads the core purpose and then details the critical usage caveats. While it is not overly verbose, the density requires careful reading; a more structured breakdown (e.g., bulleted parameter usage) could improve scanning, but it remains efficient for the complexity it addresses.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool complexity (12 parameters, bulk support, no output schema, and nuanced upload workflow), the description is remarkably complete. It covers the two-step upload for conversation/computer attachments, bulk support, constraints, cleanup behavior, and the relationship to sibling tools. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must explain all parameters. It does this comprehensively: 'tabela' is explained with examples, 'id' is tied to the specific document table and references 'codigo_lancamento_omie' for payables, and 'arquivo' is explained with the three submission methods including conditions and restrictions. It also covers 'file_name', 'file_path', 'upload_id', and 'upload_ids'. The description adds immense meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: attaching a file (receipt, boleto, invoice) to an Omie document, and explicitly names the underlying API operation 'IncluirAnexo'. It also distinguishes itself from siblings by positioning it as the pair to 'omie_lancar/omie_settle_payable', so an agent can immediately know when this tool is relevant.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description goes beyond a simple 'when to use' by providing detailed guidance: it explains the appropriate context (after launching or settling a payable/receivable), how to handle attachments from conversation or computer (do not read content, call without file, execute upload command, then re-call with upload_id and file_name), and the three ways to supply the file (file_url, upload_id, file_base64) with explicit constraints. This is exemplary usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the critical behavioral trait: this is an UPSERT, not a patch, so the record is written with exactly what is sent and fields meant to be preserved must be included. It also explains the important ability to modify already-settled/paid titles without canceling the payment, which goes well beyond what the annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loaded: the first sentence states core purpose, and each following line adds operationally important context. The warnings about upsert semantics, preserving fields, and settled-title behavior are all necessary; there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex batch upsert with no output schema, the description covers the key aspects: purpose, payload shape, read-first instruction, partition keys, and behavior on paid titles. The main gaps are the meaning of the optional `account` parameter, a more complete nested item structure, and expected response/error details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description compensates by explaining that `data` is a JSON string with the shape `{"lote": 1, "conta_pagar_cadastro": [...]}` and by naming the key fields `codigo_lancamento_integracao` / `codigo_lancamento_omie`. However, it does not explain the `account` parameter or the nested item fields, so parameter guidance is incomplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: 'Cria OU atualiza VÁRIAS contas a pagar numa chamada' and names the underlying operation (UpsertContaPagarPorLote). It also distinguishes itself by saying it is the path for mass changes rather than one call per title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly describes when to use it: for batch/mass changes such as changing categories or checking accounts, and tells the agent to read data first with omie_list_payables/omie_get_payable. It does not explicitly name the single-item alternatives or state when not to use it, so some exclusion guidance is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.