Omie

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

Annotations indicate idempotent and non-destructive write. Description adds that calling with no args returns a link, and that config header gives permanent access, session-only otherwise. 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?

Description is moderately long but well-structured with purpose first, then two methods. Each sentence adds value; no redundancy. Could be slightly tighter but not wasteful.

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 all relevant aspects: how to obtain token, two usage modes, and call patterns. No output schema, so response handling is left implicit, but given the tool's simplicity, it's 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 has one parameter with 0% coverage, but description compensates by explaining the token is a JWT and when to include it vs omit. Adds concrete meaning and usage context.

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 is for authentication in IDE agents, explaining two methods: permanent config setup and session token paste. It distinguishes from siblings like 'connect' by specifying its role in token-based login.

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 guidance on when to use each mode (permanent config vs session paste) and how to call with or without token. Lacks explicit 'when not to use' but covers typical scenarios well.

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 readOnly, idempotent, non-destructive. The description adds valuable context about conditional return values (authenticated: true vs connect_url), going 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?

Two efficient sentences that front-load the main purpose and then detail behavioral cases. 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?

No output schema, so description must explain return values. It covers two main cases and mentions key fields. Could include more exhaustive list of fields, but adequate for a simple status 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?

Input schema has 0 parameters with 100% coverage, so baseline is 4. Description does not need to explain 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 returns connection status and URLs, with specific behavior for different states (all connected vs missing credentials). It distinguishes itself from siblings by explaining the output variations.

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 use for checking connection status but does not explicitly state when to use this tool vs alternatives like 'authenticate'. No guidance on when not to use.

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 reveals many behavioral traits beyond annotations. It explains that invoke works even when the MCP is not installed, returns connect/checkout links for auth/payment, and that writes behind invoke require owner/admin. Annotations declare readOnlyHint=false and openWorldHint=true; the description aligns and provides rich context, 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 a single, dense paragraph of over 250 words. It lacks formatting, bullet points, or clear separation of different workflow steps. While front-loaded with the primary purpose, it requires careful reading to extract all guidelines. Verbosity reduces quick readability, earning a low score for 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 tool's complexity (15 parameters, many actions), the description covers most aspects: search/describe/install/invoke flow, auth/payment handling, permissions, and relationships between actions. It does not explicitly describe return values (and there is no output schema), but mentions that invoke returns links, and search/describe flag installed status. A few minor omissions (e.g., behavior of list_tools, subscribe/cancel details) prevent 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?

With 0% schema description coverage, the description carries the burden. It explains the purpose of key parameters implicitly: action enum values like search, describe, invoke are listed and contextualized; mcp_id and tool_id are used in the flow; arguments is mentioned but not detailed. It adds significant meaning beyond the schema, though some parameters like tier_slug, cancel_reason are not explained.

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 the official in-platform catalog and execution system for MCPs and tools. It explains the core flow: search, describe, invoke, install, etc., and distinguishes itself from external registries by saying 'use THIS tool FIRST'. This provides a specific verb and resource, differentiating from sibling tools like omie_* or report_bug.

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 on when to use this tool vs. alternatives. It says to use it first before external registries, and explains when to use invoke vs. install: 'use install only to make an MCP PERMANENT... prefer invoke for a single/occasional use'. It also notes that writes require workspace owner/admin, providing clear usage context and 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?

The description reveals only that it creates an entity, which is a write operation. Annotations are all false, so the description carries full burden. No details on side effects, idempotency, or authorization needs are given.

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 that states the action, endpoint, parameter format, and links to documentation. It is efficient but could benefit from clearer separation of 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?

Given the tool's complexity and lack of output schema, the description provides essential information about the JSON structure and references official docs. However, it omits the 'account' parameter and any return value 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?

With schema coverage at 0%, the description compensates by explaining the 'data' parameter as a JSON string with common fields and enum values. However, the 'account' parameter is not mentioned at all, leaving incomplete 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 it creates a checking account (bank/cash/card) in the company, using the official endpoint name. This distinguishes it from siblings like list, update, or delete.

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 provide any guidance on when to use this tool versus alternatives such as omie_update_checking_account or omie_list_checking_accounts. It lacks explicit context on prerequisites or when not 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?

Annotations (readOnlyHint=false, destructiveHint=false) are consistent. The description adds value by disclosing that customer and supplier are the same cadastre, required fields, and tag usage. However, it lacks details on return values 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?

The description is moderately dense but front-loaded with the primary action. Every sentence adds value, though it could be slightly more structured (e.g., bullet lists) for readability. 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?

Given the complexity (many fields, no output schema), the description covers input requirements, classification, and a reference to official docs. It does not describe output or error handling, but those are secondary 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?

Schema coverage is 0%, but the description thoroughly explains the 'data' parameter: format (JSON string), required and common fields. This fully compensates for the missing schema documentation. The 'account' parameter is not explained, but the main parameter is well-covered.

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 creates a customer or supplier, and distinguishes from siblings by clarifying that the same function handles both types, with classification via tags. This is 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?

The description clearly indicates when to use (creating customers/suppliers) and how to differentiate them (tags). It does not explicitly state when not to use (e.g., updates), but the sibling list implies other tools for updates.

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 a write operation (readOnlyHint: false). The description adds context about the data parameter format and required fields but does not disclose side effects, error behavior, or return value. This is adequate but not comprehensive.

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, focused sentence with no filler. It front-loads the purpose and efficiently conveys necessary details about required fields and references.

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 complexity (create operation, multiple required fields, dependencies), the description provides critical context like required fields and cross-tool references. However, it lacks details on return value, error handling, and omits the 'account' parameter, leaving gaps for an AI 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 description coverage is 0%, so the description must compensate. It explains the 'data' parameter in detail (JSON string with required fields and references). However, it provides no information about the 'account' parameter, leaving one of two 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 clearly states that the tool creates an account payable (conta a pagar). It lists required fields and references official documentation, distinguishing it from the sibling 'omie_create_receivable' tool which handles receivables.

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 by listing required fields and referring to other tools for prerequisites (supplier id, checking account). However, it does not explicitly state when to use this tool versus alternatives or provide conditions or 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 indicate it's not read-only or destructive, and the description correctly identifies it as a creation operation. No additional behavioral traits (e.g., side effects, auth needs) are disclosed, but no contradictions exist.

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 somewhat verbose. It front-loads the purpose effectively, but could be more concise while retaining essential 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?

With no output schema, the description should explain return values or success indicators. It does not mention what the tool returns, error handling, or post-creation behavior, leaving 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 description coverage is 0%, so the description must compensate. It specifies required fields and formats for the 'data' parameter, but does not describe the 'account' parameter. Adds partial 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 the tool creates a receivable account (IncluirContaReceber). The verb 'cria' and resource 'conta a receber' are specific, and it distinguishes from sibling tools like 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?

It lists required fields and references sibling tools for looking up customers and checking accounts, providing clear context. However, it lacks explicit when-not-to-use instructions or 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?

The description states 'Ação IRREVERSÍVEL' (irreversible) and warns of destructive nature, but the annotations set destructiveHint: false, contradicting the description. This is a clear annotation contradiction that fundamentally misinforms the agent about the tool's safety.

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 efficiently convey purpose, distinction from siblings, usage hints (irreversible, user confirmation), and parameter guidance. Includes a doc link. No unnecessary words, though the parenthetical API name could be omitted.

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 return value details (no output schema), does not explain the 'account' parameter, and does not clarify behavior on success or failure. While it provides a documentation link, the description itself is not fully self-contained for a tool with 3 undocumented parameters and 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?

The description explains that either nCodLanc (Omie ID) or cCodIntLanc (integration key) should be provided, adding meaning beyond the schema. However, the 'account' parameter is not explained, and schema coverage is 0%, so some burden remains unmet. The explanation of the two alternative IDs is useful.

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 a checking account entry ('APAGA/estorna um LANÇAMENTO de conta corrente') and explicitly distinguishes it from payable/receivable tools by referencing sibling tools omie_delete_payable and omie_delete_receivable.

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 tells when to use this tool (for checking account movements) and when not to (for payable/receivable titles, directing to siblings). It also warns that the action is irreversible and advises user confirmation.

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 critical behavioral context by labeling the action as IRREVERSÍVEL, which contradicts the annotations (destructiveHint=false). It provides useful warning but lacks details on authentication, rate limits, or side effects beyond deletion.

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 two sentences, front-loading the core purpose and then adding critical warnings. No redundant or 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 delete operation, the description covers the essential aspects: purpose, identifier options, irreversibility, and a pre-call verification suggestion. Missing details include return values, error handling, and permission requirements.

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 explains two of the three parameters (codigo_lancamento_omie and codigo_lancamento_integracao) and notes that one must be provided. The 'account' parameter is left unexplained, 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 the tool deletes a payable account and references the specific Omie API function (ExcluirContaPagar). It identifies the required identifiers, but does not explicitly differentiate from sibling delete tools like omie_delete_receivable, leaving room for confusion.

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 warns about irreversibility and instructs to confirm with the user before calling. It also recommends consulting omie_get_payable first. However, it does not specify when not to use this tool or list alternatives beyond the consultation suggestion.

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 states the action is irreversible and destructive, while annotations have destructiveHint: false. This is a direct contradiction, so score is 1 per guidelines.

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 with no wasted words. Essential information is 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 3 parameters and no output schema, description provides purpose, params, and usage guidance. Missing explanation for 'account' parameter, but otherwise 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?

Description covers two of three parameters (codigo_lancamento_omie and codigo_lancamento_integracao) and explains their OR relationship. However, 'account' parameter is not mentioned, and schema coverage is 0%, so description partially compensates but leaves a 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?

Description clearly states the tool deletes (APAGA) a receivable account. It specifies the exact verb and resource, and distinguishes from siblings like omie_get_receivable and omie_create_receivable.

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 tells when to use: provide either codigo_lancamento_omie or codigo_lancamento_integracao. Warns that action is irreversible and advises to confirm with user and consult omie_get_receivable first, providing clear 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's value is marginal. It adds no further behavioral context beyond the API method name.

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 long, front-loads the purpose, and contains no superfluous words. It is optimally concise.

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?

Despite lacking an output schema, the description does not hint at the return value. The 'account' parameter is unexplained. For a retrieval tool with 3 params and no output schema, some additional context on return format 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?

With 0% schema coverage, the description explains the two identifier parameters (Omie ID and integration key) but does not mention the 'account' parameter, leaving it ambiguous. This partial explanation adds some value but 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 'Detalha um cliente/fornecedor' (details a customer/supplier) and provides the API method name, distinguishing it from sibling tools like 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?

It specifies that the user must provide either 'codigo_cliente_omie' or 'codigo_cliente_integracao', indicating when to use this tool. However, it does not explicitly contrast with list or mention when not 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds no contradictions and provides minimal extra behavioral context (e.g., that it accepts two identifiers). No mention of authentication, rate limits, or return behavior. A 3 is appropriate 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 filler. Purpose is front-loaded, and every sentence adds value. Extremely concise.

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 tool with 3 parameters and no output schema, the description covers the primary use case. However, it fails to explain the 'account' parameter or describe the return value, leaving minor gaps. Annotations and schema do not fully 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%. Description explains two of three parameters (codigo_lancamento_omie and codigo_lancamento_integracao) and notes that either can be used. However, the 'account' parameter is left unexplained. This partial coverage raises the score above 1 but still lacks full clarity.

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's purpose: 'Detalha uma conta a pagar' (details a payable). It specifies input fields and distinguishes itself from siblings like omie_list_payables and omie_update_payable by stating 'Use antes de editar (omie_update_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?

Provides explicit guidance: 'Use before editing (omie_update_payable)' and explains how to identify the record via either codigo_lancamento_omie or codigo_lancamento_integracao. While it doesn't explicitly state when not to use, the context 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the main behavioral traits. The description adds no further details beyond 'Detalha', which is consistent. No extra context about side effects or restrictions is provided.

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 with no wasted words. The main action and key usage note are front-loaded, making it quickly scannable.

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 read operation with no output schema, the description does not explain what data is returned (e.g., fields of the receivable). While annotations cover safety, the agent lacks information on the structure of the response.

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 partially compensates by explaining two parameters (codigo_lancamento_omie and codigo_lancamento_integracao) as alternatives. However, the third parameter 'account' is not mentioned, 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 'Detalha uma conta a receber' (details a receivable), and mentions the specific operation code. It distinguishes from the update sibling by saying 'Use antes de editar', but does not explicitly differentiate from other get tools like omie_get_customer or omie_get_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?

The description provides explicit guidance on parameter usage: 'Informe codigo_lancamento_omie (id Omie) OU codigo_lancamento_integracao', indicating they are alternatives. It also suggests the tool should be used before editing (omie_update_receivable). No guidance on when not to use or alternatives to other 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?

Describes name resolution on server, error handling (returns options before creating if ambiguous), and accepted date formats. Adds context beyond annotations, though no mention of output or side effects beyond creation.

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 paragraph front-loading the tool's purpose. Every sentence adds value; 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?

Covers purpose, usage, key parameter behavior, and error handling. Missing details on output or return value, but for a tool with 11 parameters and no output schema, it is adequately 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 coverage, the description adds meaning to key parameters (tipo, fornecedor, categoria, conta_corrente, vencimento) but does not cover all optional parameters (e.g., account, observacao, numero_documento, codigo_lancamento_integracao).

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 creates a payable or receivable entry in one call by resolving names to codes. Distinguishes from omie_create_* sibling tools, which require codes already known.

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 'Use isto por padrão pra lançar; as tools omie_create_* continuam pra quem já tem os códigos.' Provides clear when-to-use and 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers safety. The description adds that the tool returns id and label, but does not disclose any additional behavioral traits (e.g., pagination, authentication requirements). It neither contradicts nor significantly expands on 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 a single sentence with no wasted words, directly stating the tool's purpose and output. It is appropriately brief for a simple list tool.

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 (one optional parameter, no output schema) and good annotation coverage, the description covers the core functionality. However, it omits any explanation of the parameter and provides no details about the return format beyond field names. A bit more context 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?

Schema description coverage is 0%, and the description does not explain the single optional parameter 'account'. The parameter is left entirely to the schema, which lacks a description. This fails to add meaning beyond the raw 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 the verb 'Lista' (lists) and the resource 'empresas (CNPJ) Omie' (Omie companies/accounts) connected to the install, and specifies the returned fields (id, label). This distinguishes it from sibling tools like omie_list_customers or omie_list_invoices.

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 retrieving connected Omie accounts, but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The context is clear enough for a simple list 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 declare readOnlyHint=true and destructiveHint=false, signaling safe read behavior. The description adds pagination info but no other behavioral details. This is adequate given 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 only three sentences, front-loads the purpose, and avoids unnecessary fluff. Every word 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?

The description explains the key output field (codigo_categoria) and mentions pagination, which is sufficient for a simple list tool. However, it lacks details on pagination limits or other fields, but the output schema absence makes this acceptable.

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 mentions pagination (implying page and page_size exist) but does not explain account or filters parameters. This is insufficient for the four 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 categories/chart of accounts with a specific verb ('Lista') and resource. It also distinguishes from sibling tools (e.g., omie_list_accounts) by focusing on categories needed for payables/receivables.

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 that this tool is used to get category codes required for creating payables/receivables, implying when to use it. However, it does not explicitly state when not to use it or mention 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 already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it lists company-registered accounts and hints at a mapping use case, but does not disclose pagination, error handling, or other behaviors 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?

Efficient two-sentence description. First sentence immediately states the action, second adds valuable context. 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?

Despite clear purpose, the tool has 4 undocumented parameters and no output schema. Description omits critical details like parameter usage, pagination behavior, response format, making it incomplete for effective agent usage.

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 for parameter meanings. It does not explain any of the four parameters (page, account, filters, page_size), leaving the agent without guidance on how to use them.

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 checking accounts (banks/cash) registered in the company, specifying the API function name. It effectively distinguishes from sibling list tools by the resource type (checking accounts vs. customers, invoices, etc.).

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 a concrete use case: mapping Omie accounts to bank accounts in reconciliation. While it doesn't explicitly state when not to use or list alternatives, this context helps an agent decide applicability.

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. Description adds pagination and filter behavior. No contradictions; adds modest 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?

Two concise sentences with key info front-loaded. No redundancy, but could be more structured (e.g., bullet parameter details). Still efficient and clear.

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?

Lacks details on return data fields, pagination limits, default values, account context, and max page size. As a list tool without output schema, description should cover more behavioral and output characteristics.

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 'filters' parameter (JSON from Omie API) but provides no extra info on 'page', 'account', or 'page_size'. Only 1 of 4 parameters gets meaningful 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?

Description clearly states it lists clients/suppliers/carriers (specific resources) and indicates it's paginated. The verb 'list' and resource types distinguish it from siblings like omie_get_customer (single) 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 vs alternatives like omie_get_customer or other list tools. Does not specify scenarios for filtering or pagination versus other methods.

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 readOnly and idempotent. The description adds pagination context and the role of codigo, which goes beyond the 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?

The description is relatively short (two sentences) and front-loads purpose. However, it omits parameter details, making it less efficient. It could be more concise while adding necessary info.

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 4 undocumented parameters and no output schema, the description fails to provide complete guidance. It mentions codigo but not return structure. Sibling tools are many list tools, but this description is incomplete for parameter usage.

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%. The description does not explain any of the 4 parameters (page, account, filters, page_size). It mentions paginated but provides no details on parameter usage or types.

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 departments/cost centers, is paginated, and each item has a 'codigo' for rateio. This distinguishes it from other list tools for different entities (e.g., accounts, 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?

The description implies pagination usage and the purpose of the codigo for rateio, but does not explicitly state when to use or not use this tool versus alternatives. Context is clear 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, idempotentHint, and destructiveHint, so the description adds value by stating the tool is not paginated and returns a fixed short list. 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 concise sentences, front-loaded with the main action and followed by key behavioral details. 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?

The description covers the return value (each type has a code used in write-offs) but lacks explanation of the 'account' parameter and does not fully specify output structure in absence of an output schema. Adequate but 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?

The single parameter 'account' is left completely undocumented in both schema and description. With 0% schema coverage, the description fails to explain its purpose or effect, leaving agents confused.

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 with examples (cash, slip, card, check) and distinguishes it by noting it is not paginated and returns a fixed short list, differentiating it from potential sibling list 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 does not provide explicit when-to-use or alternatives guidance. It implies usage for retrieving document types and mentions the code's use in other operations, but lacks comparison with 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 already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds that it is paginated and lists specific Hungarian filter names, which offers additional behavioral context beyond 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?

The description is a single paragraph that front-loads the main action but is dense with Portuguese and technical terms. It could benefit from better structure, especially for parameter explanations.

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 4 parameters with 0% schema coverage and no output schema, the description should fully explain parameters and usage. It partially covers filters but omits page, account, and page_size. It also does not describe output, errors, or limits. Incomplete for a comprehensive tool 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?

The schema has 0% description coverage, so the description must compensate. It explains the `filters` parameter in detail with Hungarian names and values, but does not explain `page`, `account`, or `page_size` parameters, 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 it lists financial movements (accounts payable, receivable, checking account) and mentions reconciliation. It implicitly distinguishes from siblings like omie_list_payables and omie_list_receivables by covering both AR/AP plus checking account, but does not explicitly contrast 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 indicates it is the basis for reconciliation with a Bank MCP, providing context for when to use it. However, it does not explicitly state when not to use it or mention alternative tools like omie_list_payables or omie_list_receivables for more specific queries.

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 (readOnlyHint, idempotentHint) already indicate a safe read operation. The description adds valuable behavioral details: pagination support and the structure of the filters parameter (date range, status, type). 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 a single sentence that efficiently conveys key information. The use of backticks and structured list for filter fields aids readability, though the 'etc.' is vague.

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?

While the description covers pagination and filter capabilities, it omits explanations for three of four parameters (page, account, page_size) and does not describe the output format. Given the lack of output schema, additional detail 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?

Schema description coverage is 0%, so the description must explain all parameters. It partially describes the `filters` parameter (lists some accepted keys but ends with 'etc.'), but does not explain `page`, `account`, or `page_size`. This leaves significant gaps 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 clearly states the tool lists fiscal invoices (notas fiscais) emitted, with pagination. The name and description together effectively distinguish it from sibling 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?

The description implies usage for listing invoices with filters and pagination. While it doesn't explicitly state when not to use or name alternatives, the context from sibling names makes the tool's purpose clear. Lacks explicit 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 idempotentHint=true. The description adds behavioral context: paginated operation and use of filters. No contradictions, but does not disclose additional traits beyond what 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 a single sentence that efficiently conveys purpose and filter usage. It is brief and front-loaded but could be structured with bullet points 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?

The tool has 4 parameters, no output schema, and moderate annotations. The description omits semantics for 'page', 'account', 'page_size', and does not describe the return value or pagination behavior beyond the word 'paginado'. Incomplete for confident usage.

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%. The description only explains the 'filters' parameter with examples (date format, fields) but leaves 'page', 'account', and 'page_size' undocumented. Does not add meaning for three of four 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 payables (contas a pagar) and mentions pagination and filter capabilities. It distinguishes from sibling tools like 'omie_list_receivables' by specifying 'payables' but does not explicitly contrast with other list 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 provides examples of filters (date, status, cliente, conta corrente) but no guidance on when to use this tool versus alternatives (e.g., 'omie_list_receivables'). No explicit when-not or alternative tool references.

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 non-destructive behavior. The description adds that the tool is paginated and that each project has a codigo linkable to financial transactions. However, it does not disclose rate limits, authorization needs, or other behavioral nuances.

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 brief (two sentences) and front-loaded with the main purpose. However, it is too concise, omitting necessary parameter explanations. It earns a middle score for being efficient yet incomplete.

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, four unexplained parameters, and a paginated list, the description lacks sufficient context. It fails to clarify pagination defaults, filtering capability, or the role of the 'account' parameter. The mention of 'codigo' is useful but not enough 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%, and the description does not explain any of the parameters (page, account, filters, page_size). It adds no meaning beyond the schema's type definitions, which is insufficient for correct usage.

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 company projects and includes pagination. The parenthetical 'ListarProjetos' confirms the API method. It differentiates from sibling list tools by specifying 'projetos' (projects). However, it does not explicitly contrast with other list 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?

No guidance on when to use this tool vs. alternatives. It does not mention when to prefer this over other list tools like omie_list_accounts or omie_list_customers. Usage context is implied but not 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the behavioral detail that the tool is paginated ('Paginado'), which is not covered by annotations. However, it does not disclose potential side effects, authentication requirements, rate limits, or performance characteristics beyond pagination, so value is moderate.

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 brief (approximately 3 lines) and front-loads the tool's primary purpose. However, it mixes Portuguese and English ('aceita' in Portuguese) and could be more structured (e.g., listing parameters explicitly). No extraneous content, but the use of 'etc.' adds vagueness.

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 four parameters, no output schema, and no required parameters. The description does not explain the 'page', 'account', or 'page_size' parameters, nor does it describe the return format or pagination behavior. For a listing tool with multiple parameters and no schema descriptions, the description is incomplete and leaves the agent uncertain how to properly invoke 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?

Schema description coverage is 0%, so the description must compensate for parameters. It partially explains the 'filters' parameter by listing accepted JSON keys (e.g., filtrar_cliente, filtrar_por_status), but it does not describe the other three parameters ('page', 'account', 'page_size'). The format of the filters JSON (string) is implied but not explicitly stated. Thus, the description adds only minimal meaning for one of four 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 accounts receivable ('Lista contas a receber') with the function name 'ListarContasReceber', and mentions pagination and filter options. This distinguishes it from sibling list tools like omie_list_payables (accounts payable) and omie_list_invoices (invoices), making the tool's specific resource clear.

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 given on when to use this tool versus its siblings (e.g., omie_list_payables, omie_list_invoices). The description does not mention prerequisites, contexts where this tool is appropriate, or when to avoid it. A statement like 'Use this for accounts receivable; use omie_list_payables for accounts payable' would improve this.

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, so the tool is a non-destructive mutation. The description adds that it settles a payable, but does not disclose other behavioral traits like confirmation responses, reversibility, or side effects beyond the mutation.

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 that front-loads the main action and provides essential details without excessive verbosity. It mixes Portuguese and English, but remains efficient and scannable.

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 complexity (mutating a financial record), no output schema, and 0% schema coverage, the description should cover all parameters and explain return values or confirmations. The 'account' parameter is missing entirely, and there is no mention of what the tool returns upon success or error.

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 for its parameters (data and account). The description compensates partially by detailing the JSON keys expected in the 'data' parameter (e.g., codigo_lancamento, codigo_baixa_integracao, valor, data, codigo_conta_corrente, observacao) and referencing 'omie_list_checking_accounts' for the account code. However, the 'account' parameter is not explained at all.

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

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

The description clearly states the tool's purpose: 'Dá baixa (liquida/paga) uma conta a pagar', which translates to settling/paying a payable. It also mentions the API method 'LancarPagamento', distinguishing it from sibling tools like 'omie_settle_receivable' 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?

The description provides some context: 'É o par pra conciliar com o Banco MCP' (it's the pair to reconcile with the Bank MCP), implying a specific use case. However, it does not explicitly state when to use this tool over alternatives, nor does it mention prerequisites or when not 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?

Annotations declare non-readOnly and non-destructive; the description adds details about the settlement action, required fields, and the need for codigo_conta_corrente from another tool. This provides context beyond annotations, though side effects (e.g., duplicate settlement) are not mentioned.

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 moderately concise, packing essential information in a few sentences. It front-loads the action. Could be slightly more streamlined but is effective.

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 2 parameters (1 required) and no output schema, the description explains the main parameter well and references integration context. However, it omits explanation of the 'account' parameter and does not describe the return value, making it somewhat 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 coverage is 0%, so the description must compensate. It thoroughly explains the 'data' parameter as a JSON string with specific fields and their purposes. However, the 'account' parameter is not described, leaving a gap. Overall, it adds value but 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?

Description clearly states the action: settling a receivable (Dá baixa ... uma conta a receber). It identifies the specific resource and distinguishes from the sibling tool omie_settle_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?

The description provides context for use ('É o par pra conciliar com o Banco MCP') and explains how to identify the receivable via codigo_lancamento or integracao. It does not explicitly state when not to use, but the sibling list provides differentiation.

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 non-read-only and non-destructive nature. Description adds that data must be a JSON with key and fields, but doesn't disclose error behavior or side effects beyond that. Adequate given 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-loaded with the action. Could omit the API method name for brevity, 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?

No output schema, so no return value explanation needed. Covers required input format and prerequisite, but misses the account parameter and error/state change details. Adequate for an update tool with annotations.

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 that data is a JSON string containing the key and fields to update, but the optional account parameter is completely undocumented. Insufficient for a 0% coverage scenario.

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 edits an existing checking account, using the specific API method name. It differentiates 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?

Explicitly advises to consult omie_list_checking_accounts before use, providing clear context. No exclusions or alternatives stated, but the guidance is sufficient for a mutation 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 readOnlyHint=false and destructiveHint=false, but the description reveals it is a mutation. It provides some behavioral context by requiring specific fields in data, but does not disclose potential side effects (e.g., what happens to omitted fields), error handling, or permission requirements. The description does not contradict 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 short, with the purpose in the first sentence and a useful note afterward. It is concise but could be slightly more structured (e.g., separate line for the note). 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?

Given no output schema, the description does not explain return values or error conditions. It relies on the user knowing valid fields via omie_get_customer. The required parameter is covered, but overall completeness for a mutation tool is moderate.

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 adds significant meaning to the 'data' parameter beyond the schema (which only says 'string'), specifying it must be a JSON string containing the key and fields to update. However, it does not explain the 'account' parameter. With schema coverage at 0%, the description compensates well for 'data' but not fully.

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 (AlterarCliente). It uses a specific verb (Edita) and resource (cliente/fornecedor existente), distinguishing it from omie_create_customer and omie_get_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?

The description advises to consult omie_get_customer before updating, hinting at a prerequisite workflow. It specifies that the data parameter must contain the customer key and fields to change. However, it does not explicitly state when not to use the tool or alternative 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 provide no extra behavioral info (readOnlyHint false indicates mutation). The description only states it edits, lacking details on partial vs full updates, idempotency, or side effects. It does not go beyond the basic verb.

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 efficiently convey purpose and usage. No superfluous text, though more structured formatting (e.g., listing required keys) could improve scannability.

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

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

As a mutation tool with no output schema, the description should indicate return values or error handling. It does not mention idempotency, partial updates, or what happens if the record doesn't exist. The undocumented `account` parameter also reduces 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?

Schema has 0% description coverage. The description explains the `data` parameter as a JSON string with required keys and example fields, adding value. However, the `account` parameter is entirely undocumented in both schema and description, leaving a 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 'Edita uma conta a pagar existente' (edits an existing payable account) and specifies that `data` is a JSON string containing the record key and fields to change. This distinguishes it from create and read counterparts.

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 'Consulte antes com omie_get_payable' (consult before with omie_get_payable), implying this tool is for updating after retrieval. No explicit when-not-to-use, but the guidance 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?

Annotations already indicate the tool is not read-only and not destructive. The description adds context about the data format and required keys, but does not disclose additional behavioral traits such as permissions, idempotency (already hinted false), or error behavior. The description aligns 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?

The description is concise, front-loaded with the primary action, and contains no redundant words. It efficiently conveys key requirements for the data parameter. Could be slightly more structured, but overall well-sized.

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 main data parameter well and references a sibling tool for consultation. However, it omits the optional `account` parameter entirely, does not specify return values or error conditions, and lacks details on required permissions. For a mutation tool with no output schema, this is a moderate gap.

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

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

Schema coverage is 0%, but the description compensates by explaining that the `data` parameter is a JSON string requiring a key (codigo_lancamento_omie or codigo_lancamento_integracao) and enumerates example fields to update. This adds significant meaning beyond the plain schema type.

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 receivable account ("Edita uma conta a receber existente") and references the specific API method. It distinguishes from sibling tools like omie_create_receivable and omie_delete_receivable, and even suggests consulting omie_get_receivable beforehand.

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 instructs users to consult omie_get_receivable first, providing a usage prerequisite. It implies when to use (for updating a receivable) and what the data parameter must contain. However, it does not explicitly state when not to use or list alternatives beyond omie_get_receivable.

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 idempotentHint=true and readOnlyHint=false, but the description does not elaborate on behavioral traits such as whether reports are persisted, if duplicate submissions are handled, or any side effects. The description adds minimal transparency beyond the schema and 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 convey the purpose and a key usage hint without any redundant 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?

Given the tool's simplicity (3 params, no output schema), the description covers the essential action and one parameter hint. However, it fails to specify return behavior or confirm what happens upon success, leaving some 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?

With 0% schema description coverage, the description must compensate. It only mentions the 'conversation' parameter, ignoring 'context' and 'message' (required). This is insufficient for an agent to correctly populate parameters without additional inference.

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 reports bugs, missing features, or feedback. The verb 'report' and resource types are explicit, making the purpose easy to understand. However, it could be more specific about the exact action (e.g., creating a support ticket).

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 including the conversation array for reproduction, providing one usage hint. However, it lacks explicit guidance on when to use this tool versus alternatives (no siblings for reporting) and does not specify prerequisites or 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, idempotentHint=true, and destructiveHint=false. The description adds that it shows versions, but no additional behavioral traits (e.g., side effects, rate limits, or data scope) are disclosed. It does not contradict 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 a single sentence with no fluff. It is front-loaded and efficiently conveys the tool's purpose. 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, straightforward behavior), the description is sufficiently complete. It tells the agent what the tool does without needing extra details about return values or side effects.

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

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

The tool has zero parameters and 100% schema coverage. With no parameters, the baseline is 4. The description does not need to add parameter meaning since none exist.

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 uses a specific verb ('show') and identifies the resource, distinguishing it from sibling tools that perform actions like authentication, connection, or OMIE 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?

No usage guidelines are 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 this is a minor gap, but still lacks explicit 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds detail on the specific data returned (MCPs, connection status, catalog tool counts), which adds value 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?

Single sentence with no wasted words. Information is front-loaded and easily scannable.

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 zero parameters, rich annotations, and no output schema, the description adequately explains the return content. Could mention if always synchronous or potential error cases, but sufficient for a simple info 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?

There are 0 parameters, so baseline is 4. The description does not need to explain parameters, and schema coverage is 100%.

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 specifically states it returns 'installed MCPs, their connection status, and how many catalog tools each exposes'. This is a specific verb+resource combination and clearly distinguishes from sibling tools like 'authenticate' or '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?

The description implies the tool is for checking toolkit state, but does not explicitly state when to use it over alternatives or provide any usage exclusions. Context is clear but lacks explicit guidance.

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