Omie

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

The description discloses key behaviors: the token can be set permanently via config or temporarily via parameter. It correctly indicates idempotency (idempotentHint=true) and does not contradict annotations. However, it does not mention potential failure modes or what happens on invalid tokens.

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 includes context ('MCP.AI for IDE agents') that is slightly extraneous and could be more concise. The core instructions are clear, but the first sentence could be trimmed without losing meaning.

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 a single optional parameter and no output schema, the description covers the main use cases (session and persistent login) adequately. It lacks details on error handling or token validation, but overall completeness is good for a simple authentication 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 input schema has 0% description coverage, but the description fully explains the 'token' parameter: it is a JWT obtained by the user, and calling without it returns a link. This adds critical meaning beyond the schema, compensating for 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 function: authentication via browser login and token retrieval. It specifies exactly what the tool does (returns a link or accepts a token) and distinguishes between two usage modes, 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 provides explicit guidance on when to use each method: best to add the token to config for permanent access, or paste it for session-only. It also explains calling with no args to get the link. However, it does not explicitly compare to sibling tools or state when not to use this 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?

Description adds valuable behavioral details beyond annotations, such as specific response fields (authenticated, pending, connect_url) and how they change based on connection state. No contradictions with 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 efficient sentences: first introduces purpose, second explains two key states. No wasted words, 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?

For a simple status-check tool with no parameters and clear annotations, the description fully covers what the agent needs to know: return data structure and conditional 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?

No parameters exist, and schema coverage is 100% trivially. Baseline 4 applies; description adds no parameter info but none is needed.

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 returns connection status and URLs, with specific examples of response states (authenticated vs missing credentials). It effectively distinguishes from siblings like 'authenticate' which performs authentication initiation.

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 explains behavior under different conditions (all connected vs missing credentials), helping the agent decide when to call. It could explicitly state when to use instead of sibling tools, but the context 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?

Beyond the annotations, the description discloses key behaviors: invoke works even when the MCP is NOT installed, returns connect links for credentials, returns checkout links for empty wallets, and 'Writes (install/uninstall/subscribe/cancel and the one-off install behind invoke) require workspace owner/admin.' These details add valuable context about side effects and prerequisites.

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 dense paragraph without visual breaks or bullets, making it harder to scan. While every sentence adds substantive information, the sheer length (200+ words) and lack of structure detract from conciseness.

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 complexity (23 parameters, 14 actions) and absence of an output schema, the description provides a thorough overview of the tool's functionality, flow, permissions, payment handling, and the separate prompt library. It omits details on some secondary parameters, but the overall context is rich enough for an agent to understand when and how to use it.

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 does explain the central 'action' parameter and important fields (mcp_id, tool_id, arguments, prompt_slug). However, several parameters like limit, query, immediate, conversation, and prompt_targets remain undocumented in both schema and description, so it doesn't fully compensate for the low 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's purpose as 'the official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them,' and outlines a concrete core flow (search → describe → invoke). This distinguishes it from sibling tools like omie_* which are domain-specific data operations.

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 guidance: 'Use install only to make an MCP PERMANENT in the active toolkit ... prefer invoke for a single/occasional use.' It also clarifies when to use list_tools, subscribe/cancel, report_bug, and request_mcp, and notes permission requirements for writes.

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?

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?

Beyond the annotations already stating readOnly and idempotent, the description adds meaningful behavioral details: the default response returns only balances, `incluir_movimentos:true` changes the response to include the movements, `data_inicial/data_final` default to today, and the tool returns the current real balance rather than the fixed-date initial balance. It does not contradict 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 core is front-loaded: first the operation and resource, then the distinction from siblings, then the parameters. It is slightly long and repeats the idea of `incluir_movimentos` more than once, but each informative portion stays relevant, so the length does not hurt.

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 no parameter descriptions in the schema, the description is strong: it names the returned balance fields, explains how to add movements, and gives the date defaults. A minor unaddressed point is that all parameters are optional and the description incorporates a different identifier but does not say what happens if no account identifier is supplied.

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 most of the parameter burden and does well: it explains `conta`, `nCodCC`, `cCodCCInt`, `data_inicial`, `data_final`, and `incluir_movimentos`, including date formats and default behavior. However, the schema property `account` is not described, so about one parameter remains undocumented in both the schema and description.

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?

A description is explicitly says 'EXTRATO BANCÁRIO and SALDO ATUAL de uma conta account (ListarExtrato)' and immediately distinguishes it from omie_list_checking_accounts, which only gives `saldo_inicial` in a fixed date. An agent can know exactly what resource and operation this tool represents and can tell it apart 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 names the alternative when it is supposed to be used: use this tool with `incluir_movimentos:true` to match the bank statement to Omie entries, and use omie_list_checking_accounts when only the accounting starting balance is needed. That is an explicit when/when-not without relying on 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?

Discloses that it creates records (mutation), resolves names server-side, accepts name or code, and returns errors with options for ambiguous inputs. No contradiction with annotations (readOnlyHint:false, destructiveHint:false). Could mention that it does not guess but returns errors.

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 (approximately 5 lines) and well-structured, starting with the core purpose and then detailing behavior and usage. Every sentence adds value 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 11 parameters (6 required) and no output schema, the description covers key aspects: shortcut nature, error handling, date formats, and when to use alternatives. Could mention the return value, but not critical 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?

With 0% schema description coverage, the description compensates by explaining that fields accept name or code, and dates accept two formats. It covers key parameters (fornecedor, categoria, conta_corrente) but not all 11 (e.g., observacao, numero_documento). Still adds significant value.

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 is a shortcut to launch a payable or receivable in one call, naming the verb 'lança' and the resources 'conta a PAGAR ou a RECEBER'. It distinguishes itself from sibling tools like omie_create_payable/receivable by emphasizing it resolves codes by name.

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 advises 'Use isto por padrão pra lançar' and specifies when to use alternatives (omie_create_*) for those who already have codes. Also notes that ambiguous names return errors with options, guiding proper usage.

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 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, idempotentHint, destructiveHint, so safe behavior is known. Description adds value by noting pagination and providing filter naming conventions, which go 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?

Description is concise and front-loaded with the main purpose. However, it could be better structured by separating parameter explanations for 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?

No output schema and missing explanations for three parameters (page, account, page_size). The description heavily focuses on filters but leaves significant gaps about response format and other inputs.

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 compensate. It explains the filters parameter with field names and examples, but page, account, and page_size remain undocumented. Partial 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?

Description clearly states the tool lists financial movements (payables, receivables, checking account entries) and is the basis for reconciliation. It distinguishes from sibling list tools by covering a broader scope of movements.

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?

Mentions reconciliation context and filter hints, but no explicit guidance on when to use this vs. more specific list tools (e.g., omie_list_payables). Usage is implied rather than 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 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?

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?

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?

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.

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

Annotations are all false (readOnly, destructive, idempotent), so the description carries the burden. It discloses the upsert semantics ('é UPSERT (mande os campos a preservar)') and the integration key, which is critical behavioral info. It doesn't cover error handling or partial failures, but the given detail is valuable 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?

Three sentences, no fluff. Purpose is front-loaded, and the cross-reference to a sibling tool avoids repeating shared rules. The JSON example is compact and directly actionable.

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 batch write operation with no output schema and sparse annotations, the description should cover more: the account parameter, the full payload shape beyond the top-level, required fields per item, and any response/error behavior. It also leaves the data-type mismatch unresolved. It's adequate for a basic call but not complete for robust agent 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?

Schema has 0% description coverage, so the description must explain parameters. It explains the 'data' parameter with an example JSON structure and the key field, which is helpful. However, it never explains the 'account' parameter, and the schema says data is a string while the description shows an object—a mismatch that could confuse agents. Partial compensation 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?

The description clearly states a specific verb (creates or updates) and resource (múltiplas contas a receber) in a batch, and explicitly distinguishes itself from the sibling omie_upsert_payables_batch by referencing it. This makes the tool's scope 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 tells the agent this is a batch upsert and where to find the exact rules (omie_upsert_payables_batch). It also clarifies the UPSERT behavior and the key field. However, it doesn't explicitly state when to prefer this over the single-create/update receivables tools, though the batch nature is implicit.

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 it is not read-only (readOnlyHint=false), not destructive (destructiveHint=false), and idempotent (idempotentHint=true). The description does not elaborate on these traits or add behavioral context beyond the obvious creation of a report. It neither contradicts nor enhances 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 extremely concise (two sentences), front-loaded with the tool's purpose, and every sentence provides essential information 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 tool's simplicity (3 params, no output schema), the description covers the core purpose and hints at the conversation parameter. However, it omits details about the 'context' parameter, the required 'message' format, and any return value or confirmation after reporting.

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 'conversation' parameter should contain recent messages for reproduction, adding meaning not in the schema (which has 0% description coverage). However, it does not clarify the purpose of 'context' or the required 'message' parameter, leaving gaps.

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 reports bugs, missing features, or feedback, with a specific verb ('report') and resource categories. It is distinctly different from all sibling tools, which are financial and system utilities.

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 advises including the conversation array for reproduction, providing direct usage guidance. However, it does not explicitly state when to avoid this tool or mention alternatives, but since it is the only feedback tool, it is still 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 adds minimal behavioral context beyond annotations. Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, signaling safe read-only behavior. The description simply restates the purpose. It does not contradict annotations, but also does not enrich them with details like potential performance impact or response structure.

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 immediately conveys the tool's purpose. There is no wasted text, and it is appropriately front-loaded. 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?

Given the tool's simplicity (no parameters, no output schema), the description is mostly complete. It tells the agent what the tool returns (version information). However, it could be more explicit about the exact format or scope of the output, such as listing which versions are shown (MCP platform, adapter). Still, it is adequate for a straightforward version check.

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 input schema has zero parameters, so schema_description_coverage is 100%. With no parameters to document, the description incurs no responsibility for parameter semantics. The baseline for 0 params is 4, and the description adds no extra parameter information, which is acceptable.

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 shows current MCP platform and adapter versions. It specifies a verb ('show') and resource ('versions'). While it doesn't explicitly differentiate from siblings, the sibling tools are mostly OMIE-specific CRUD tools, so uniqueness is implied. A slightly more precise description of what 'platform and adapter versions' entails would improve it.

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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or context. For a simple info tool, guidelines may not be critical, but their absence leaves the agent with zero context on when this tool is appropriate.

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, so the agent knows this is a safe read. The description adds valuable context about what state is returned (installed MCPs, connection status, accounts, catalog tool counts), which goes beyond annotation coverage. 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?

Exactly one sentence, front-loaded with the action 'Returns', and richly informative without any fluff. Every clause 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 zero-parameter, read-only info tool with strong annotations, the description fully conveys what the agent will get. No output schema exists, but the description lists the key content categories, making it sufficient 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?

There are zero parameters, and schema coverage is trivially 100%. The baseline for zero parameters is 4, and the description needs no parameter explanation.

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 a specific verb ('Returns') and resource ('current toolkit state'), enumerating the exact contents: installed MCPs, connection status, connected accounts, and catalog tool counts. This is distinct from sibling tools like show_version or connect, making its 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 clearly implies the tool's usage context: whenever the agent needs the current toolkit state, including MCP connections and account bindings. It does not explicitly name alternatives or exclusions, but the scope is sufficiently clear to guide selection among siblings.

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