Omie

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

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

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

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

The description includes context ('MCP.AI for IDE agents') that is slightly extraneous and could be more concise. The core instructions are clear, but the first sentence could be trimmed without losing meaning.

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

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

Given a single optional parameter and no output schema, the description covers the main use cases (session and persistent login) adequately. It lacks details on error handling or token validation, but overall completeness is good for a simple authentication tool.

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

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

The input schema has 0% description coverage, but the description fully explains the 'token' parameter: it is a JWT obtained by the user, and calling without it returns a link. This adds critical meaning beyond the schema, compensating for the lack of schema descriptions.

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

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

The description clearly states the tool's function: authentication via browser login and token retrieval. It specifies exactly what the tool does (returns a link or accepts a token) and distinguishes between two usage modes, making the purpose unambiguous.

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

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

The description provides explicit guidance on when to use each method: best to add the token to config for permanent access, or paste it for session-only. It also explains calling with no args to get the link. However, it does not explicitly compare to sibling tools or state when not to use this tool.

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

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

Description adds valuable behavioral details beyond annotations, such as specific response fields (authenticated, pending, connect_url) and how they change based on connection state. No contradictions with annotations.

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

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

Two efficient sentences: first introduces purpose, second explains two key states. No wasted words, front-loaded.

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

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

For a simple status-check tool with no parameters and clear annotations, the description fully covers what the agent needs to know: return data structure and conditional behavior.

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

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

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

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

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

The description clearly states the tool returns connection status and URLs, with specific examples of response states (authenticated vs missing credentials). It effectively distinguishes from siblings like 'authenticate' which performs authentication initiation.

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

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

The description explains behavior under different conditions (all connected vs missing credentials), helping the agent decide when to call. It could explicitly state when to use instead of sibling tools, but the context is clear enough.

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

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

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

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

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

The description is a single dense paragraph without visual breaks or bullets, making it harder to scan. While every sentence adds substantive information, the sheer length (200+ words) and lack of structure detract from conciseness.

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

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

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

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

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

With 0% schema description coverage, the description carries the burden and does explain the central 'action' parameter and important fields (mcp_id, tool_id, arguments, prompt_slug). However, several parameters like limit, query, immediate, conversation, and prompt_targets remain undocumented in both schema and description, so it doesn't fully compensate for the low coverage.

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

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

The description clearly states the tool's purpose as 'the official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them,' and outlines a concrete core flow (search → describe → invoke). This distinguishes it from sibling tools like omie_* which are domain-specific data operations.

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

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

The description gives explicit guidance: 'Use install only to make an MCP PERMANENT in the active toolkit ... prefer invoke for a single/occasional use.' It also clarifies when to use list_tools, subscribe/cancel, report_bug, and request_mcp, and notes permission requirements for writes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description adds substantial behavioral context beyond the readOnly/idempotent/destructive annotations: it explains the default output (only balances), the effect of incluir_movimentos, the date range behavior, and the default date of today. No contradictions with annotations.

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

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

The description is dense yet well-organized, front-loading the primary purpose, then the distinction from siblings, then parameter guidance. Every sentence adds value without fluff, making it easy to parse despite its length.

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

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

For a read-only balance tool with 7 parameters and no output schema, the description covers the tool's purpose, alternatives, account identification methods, default behaviors, date formats, and optional flag for movements. It is complete enough for an agent to select and invoke the tool correctly without further 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?

With 0% schema description coverage, the description compensates well for 6 of 7 parameters: it explains conta, nCodCC, cCodCCInt, incluir_movimentos, data_inicial, and data_final with formats and defaults. However, the 'account' parameter is left unexplained, leaving a small gap.

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

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

The description clearly states it returns the 'SALDO ATUAL' (current balance) of a checking account, with a specific verb and resource. It also distinguishes itself from the sibling tool omie_list_checking_accounts by noting the difference between real/current balance and initial balance at a fixed date, eliminating ambiguity.

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 names the alternative omie_list_checking_accounts and explains why this tool should be used for real balance, stating 'ao contrário de omie_list_checking_accounts'. It also frames the tool as the basis for bank-to-Omie reconciliation, providing clear usage context.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description is concise (approximately 5 lines) and well-structured, starting with the core purpose and then detailing behavior and usage. Every sentence adds value without redundancy.

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

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

Given 11 parameters (6 required) and no output schema, the description covers key aspects: shortcut nature, error handling, date formats, and when to use alternatives. Could mention the return value, but not critical for a creation tool.

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

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

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

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

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

The description clearly states it is a shortcut to launch a payable or receivable in one call, naming the verb 'lança' and the resources 'conta a PAGAR ou a RECEBER'. It distinguishes itself from sibling tools like omie_create_payable/receivable by emphasizing it resolves codes by name.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by stating the list is not paginated and is fixed/short, which is behavioral context beyond the annotations. No contradiction 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 extremely concise with two sentences. It front-loads the core purpose and key behavioral traits (no pagination, code usage), with 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 list's purpose and behavioral traits, but the lack of explanation for the 'account' parameter leaves a significant gap. An agent cannot know what value to provide for that parameter. The absence of output schema is acceptable per rules, but the parameter omission 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?

The input schema has one parameter 'account' with no description, and schema description coverage is 0%. The description does not mention or explain this parameter, failing to add meaning beyond the schema. Given the low coverage, the description should compensate but does not.

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 action ('Lista') and resource ('tipos de documento'), including specific examples (dinheiro, boleto, cartão, cheque). It also distinguishes the tool from siblings by noting it is not paginated and provides a fixed, short list, which helps agents understand its scope.

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 usage context by explaining the list is not paginated and that each type's 'codigo' is used in other operations (baixas and lançamentos). However, it does not explicitly state when to use this tool versus alternatives 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 already declare readOnlyHint, idempotentHint, destructiveHint, so safe behavior is known. Description adds value by noting pagination and providing filter naming conventions, which go beyond annotations.

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

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

Description is concise and front-loaded with the main purpose. However, it could be better structured by separating parameter explanations for clarity.

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

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

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

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

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

Schema coverage is 0%, so description must compensate. It explains the filters parameter with field names and examples, but page, account, and page_size remain undocumented. Partial compensation.

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

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

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

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

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

Mentions reconciliation context and filter hints, but no explicit guidance on when to use this vs. more specific list tools (e.g., omie_list_payables). Usage is implied rather than stated.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value beyond these by disclosing pagination behavior and the use of a JSON filter object with specific keys (e.g., filtrar_por_data_de/ate, status). This informs the agent of behavioral traits not covered by annotations, such as pagination and filter format.

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 first sentence states the core purpose and method, and the second covers pagination and filtering. Information is front-loaded and every sentence serves a purpose, making it efficient for an AI agent to parse.

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

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

Given the tool's simplicity (4 params, no output schema, safe annotations), the description covers the key aspects: pagination and filter usage with sample keys. It does not explain the 'account' parameter or output format, but for a listing tool, these are minor omissions. The agent can infer page/page_size from 'Paginado' and account from 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?

With 0% schema description coverage, the description partially compensates by explaining the `filters` parameter (JSON format, example filter keys). However, it does not describe the `page`, `page_size`, or `account` parameters, leaving half of the parameters without semantic enrichment. The filter hints are useful but 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 the tool's purpose: 'Lista contas a pagar' (list payables), identifies the underlying method 'ListarContasPagar', and distinguishes it from sibling CRUD tools (e.g., omie_get_payable, omie_create_payable). The verb 'list' and resource 'payables' are explicit, providing a specific and unambiguous purpose.

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

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

The description explains that it is paginated and how to filter by date, status, client, etc., but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. It implies listing use cases but lacks direct guidance on when to choose omie_list_payables over omie_get_payable or other 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 indicate read-only, idempotent, non-destructive behavior. The description adds that it is paginated and each project links 'codigo' to financial entries, which provides minor behavioral context beyond annotations.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds that the tool is paginated and accepts filters, but does not disclose rate limits, return format, or other behavioral traits beyond the schema. Given the annotations, the description adds moderate value.

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

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

The description is concise, using one sentence and a bullet-like list of filter fields. It front-loads the main purpose and pagination, but the structure could be improved by separating the filter list into clearer formatting. Every sentence earns its place.

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

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

With 4 parameters, 0% schema coverage, and no output schema, the description should provide more context. It covers the main purpose and filter details but lacks explanation of pagination behavior, required vs optional parameters, and return value information. The tool is moderately complex due to the JSON filter, so more completeness is needed.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that the 'filters' parameter accepts specific fields like filtrar_por_data_de/ate, etc., but it does not describe 'page', 'account', or 'page_size' parameters. This leaves significant gaps for the agent to understand all 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, uses the verb 'Lista', and specifies the resource 'contas a receber'. It also mentions pagination and filter options, distinguishing it from sibling tools like omie_list_payables 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 indicates the tool is paginated and supports filters, implying its use for listing receivables with optional filtering. However, it does not explicitly state when to use this tool versus alternatives, nor does it 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 indicate non-destructive mutation; the description adds context about the JSON structure and required keys. It does not contradict annotations and provides behavioral details beyond the structured fields.

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

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

The description is a single paragraph that efficiently conveys essential information without wordiness. Could benefit from clearer separation of parameter details.

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

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

The description lacks information about return values, error behavior, and fails to explain the 'account' parameter. Given no output schema, this leaves gaps for an agent invoking the 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 has 0% description coverage. The description thoroughly explains the 'data' parameter structure but does not address the 'account' parameter, leaving it 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 the verb 'Dá baixa' (settle/pay) and the resource 'conta a pagar' (payable account), distinguishing it from siblings 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 detailed guidance on the required JSON fields, references omie_list_checking_accounts for the checking account, and notes the counterpart relation with Banco MCP. However, it lacks explicit when-not-to-use instructions or alternatives for edge cases.

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

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

Annotations indicate non-read-only and non-destructive, but the description adds no further behavioral context (e.g., side effects, permissions, or reversibility). 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 that efficiently conveys the purpose and key parameter details without redundancy. It is front-loaded with the main action.

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 main parameter is well-documented, but the optional 'account' parameter is unexplained, and there is no description of the return value or output format. For a mutation tool, this leaves gaps.

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

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

The description explains the 'data' parameter in detail, listing its required subfields (codigo_lancamento, codigo_baixa_integracao, valor, etc.) and their meanings, compensating for the schema's 0% coverage. However, the 'account' parameter is not described.

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 settles a receivable ("Dá baixa (liquida/recebe) uma conta a receber") and names the API method. It differentiates from siblings like 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 references omie_list_checking_accounts for the checking account code and mentions reconciliation with Banco MCP, implying when to use it. However, it does not explicitly state when not to use this tool or provide alternatives beyond the bank context.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds no further behavioral traits beyond the edit action. It does not disclose side effects, permissions, or error conditions, but it does not contradict the annotations either.

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

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

The description is two concise sentences. The first sentence states purpose and technical detail (API method), and the second explains the key parameter and provides a usage hint. No words are wasted.

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

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

Given the two parameters and no output schema, the description covers the main parameter well and advises pre-consultation. However, it omits explanation of the account parameter and does not describe the return value or success/failure behavior, leaving some gaps for a complete understanding.

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

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

The description explains that the data parameter is a JSON string containing the account key and fields to alter, adding meaning beyond the schema's plain string type. However, the optional account parameter is not described, leaving a small gap.

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

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

The description clearly states the tool edits an existing checking account (Edita uma conta corrente existente) and provides the API method name. It distinguishes from sibling tools like omie_create_checking_account and omie_list_checking_accounts.

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

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

The description advises users to consult omie_list_checking_accounts first to obtain the account key, which is a clear contextual guideline. It does not explicitly state when not to use the tool, but the advice is actionable and specific.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, which are consistent with an update operation. The description adds that the data parameter must contain the customer key and fields to change, but does not disclose potential side effects or error behavior.

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

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

Two sentences, no wasted words. Front-loaded with the action and essential format requirements, followed by a practical usage hint.

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

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

Given no output schema, the description does not specify return values, but it adequately describes input requirements and provides a prerequisite suggestion. Slightly incomplete for a complete understanding.

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

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

Schema description coverage is 0%, but the description fully explains the data parameter: it must be a JSON string containing the customer key (codigo_cliente_omie or codigo_cliente_integracao) and fields to alter, with examples. This adds significant meaning beyond the schema.

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

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

The description clearly states the tool edits an existing customer/supplier ('Edita um cliente/fornecedor existente'), specifies the underlying API endpoint ('AlterarCliente'), and distinguishes from sibling tools by advising to use omie_get_customer first.

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

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

The description explicitly advises to consult omie_get_customer before using this tool, providing clear context for correct usage. It does not explicitly state when not to use it, but the guidance is sufficient.

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

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

The description adds value beyond the annotations by detailing that the 'data' parameter is a JSON string with mandatory keys and examples of editable fields. The annotations already indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false), and the description aligns with that. No contradictions.

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

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

The description is relatively concise with three sentences, each providing distinct information: action, parameter requirements, and usage advice. It avoids redundancy and is front-loaded with the main purpose. However, breaking the parameter explanation into a separate, more structured format could improve clarity.

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

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

The description lacks important details: it does not mention return values or success/failure indicators, nor does it cover the 'account' parameter. For an update operation with no output schema, the description should explain what the tool returns (e.g., the updated record or a status). The guidance to consult with 'omie_get_payable' hints at a workflow but leaves gaps.

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

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

The description explains the 'data' parameter in detail, specifying required keys and example fields. However, it completely ignores the 'account' parameter, which is in the schema but not described. With 0% schema description coverage, the description should cover all parameters to compensate, but it fails to do so for one of the two.

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

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

The description clearly states that the tool edits an existing payable account ('Edita uma conta a pagar existente') and names the underlying API method ('AlterarContaPagar'). It distinguishes itself from siblings like 'omie_create_payable' and 'omie_get_payable' by focusing on the update action.

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

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

The description provides explicit guidance on how to use the tool: it requires a JSON string with the record key and fields to change. It also advises consulting 'omie_get_payable' first, implying a prerequisite and aiding proper usage. However, it does not explicitly state when not to use this tool versus alternatives.

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

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

Annotations indicate the tool is not read-only and not destructive. The description adds that the data parameter must contain keys and fields to change, implying a partial update, and suggests prior consultation. It does not detail permissions, idempotency (hinted false), or error behavior, so transparency is adequate but not extensive.

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

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

The description is extremely concise: two sentences that front-load the purpose and API function, then provide essential parameter guidance and a usage recommendation. No word is wasted.

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

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

Given the tool has two parameters, no output schema, and moderate annotations, the description covers the 'data' parameter well and recommends prior consultation, but it omits the 'account' parameter and does not describe return values or success indicators. This leaves gaps for a mutation tool.

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

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

Schema coverage is 0%, so the description must explain all parameters. It thoroughly explains the 'data' parameter, including required keys and example fields, but it does not mention the 'account' parameter at all, leaving its purpose ambiguous.

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

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

The description clearly states it edits an existing receivable (Edita uma conta a receber existente), providing a specific verb and resource. It references the API function AlterarContaReceber and distinguishes from sibling tools like create, delete, get, and list by naming the update operation.

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

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

The description explicitly recommends consulting omie_get_receivable before using this tool, providing clear context for when to invoke it. However, it does not mention alternatives like omie_settle_receivable or omie_delete_receivable, nor does it specify when not to use the tool.

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

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

Annotations already indicate it is not read-only (readOnlyHint=false), not destructive (destructiveHint=false), and idempotent (idempotentHint=true). The description does not elaborate on these traits or add behavioral context beyond the obvious creation of a report. It neither contradicts nor enhances the annotations.

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

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

The description is extremely concise (two sentences), front-loaded with the tool's purpose, and every sentence provides essential information without redundancy.

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

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

Given the tool's simplicity (3 params, no output schema), the description covers the core purpose and hints at the conversation parameter. However, it omits details about the 'context' parameter, the required 'message' format, and any return value or confirmation after reporting.

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

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

The description explains that the 'conversation' parameter should contain recent messages for reproduction, adding meaning not in the schema (which has 0% description coverage). However, it does not clarify the purpose of 'context' or the required 'message' parameter, leaving gaps.

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

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

The description clearly states the tool reports bugs, missing features, or feedback, with a specific verb ('report') and resource categories. It is distinctly different from all sibling tools, which are financial and system utilities.

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

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

It advises including the conversation array for reproduction, providing direct usage guidance. However, it does not explicitly state when to avoid this tool or mention alternatives, but since it is the only feedback tool, it is still clear.

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

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

The description adds minimal behavioral context beyond annotations. Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, signaling safe read-only behavior. The description simply restates the purpose. It does not contradict annotations, but also does not enrich them with details like potential performance impact or response structure.

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

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

The description is a single sentence that immediately conveys the tool's purpose. There is no wasted text, and it is appropriately front-loaded. Every word earns its place.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read. The description adds valuable context about what state is returned (installed MCPs, connection status, accounts, catalog tool counts), which goes beyond annotation coverage. No contradictions.

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

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

Exactly one sentence, front-loaded with the action 'Returns', and richly informative without any fluff. Every clause earns its place.

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

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

For a zero-parameter, read-only info tool with strong annotations, the description fully conveys what the agent will get. No output schema exists, but the description lists the key content categories, making it sufficient for correct invocation.

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

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

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

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

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

The description clearly states a specific verb ('Returns') and resource ('current toolkit state'), enumerating the exact contents: installed MCPs, connection status, connected accounts, and catalog tool counts. This is distinct from sibling tools like show_version or connect, making its purpose unambiguous.

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

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

The description clearly implies the tool's usage context: whenever the agent needs the current toolkit state, including MCP connections and account bindings. It does not explicitly name alternatives or exclusions, but the scope is sufficiently clear to guide selection among siblings.

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