Omie

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

Annotations indicate idempotent and non-destructive write. Description adds that calling with no args returns a link, and that config header gives permanent access, session-only otherwise. No contradictions.

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

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

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

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

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

Covers all relevant aspects: how to obtain token, two usage modes, and call patterns. No output schema, so response handling is left implicit, but given the tool's simplicity, it's adequate.

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

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

Schema has one parameter with 0% coverage, but description compensates by explaining the token is a JWT and when to include it vs omit. Adds concrete meaning and usage context.

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

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

The description clearly states the tool is for authentication in IDE agents, explaining two methods: permanent config setup and session token paste. It distinguishes from siblings like 'connect' by specifying its role in token-based login.

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

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

Provides explicit guidance on when to use each mode (permanent config vs session paste) and how to call with or without token. Lacks explicit 'when not to use' but covers typical scenarios well.

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

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

Annotations already declare readOnly, idempotent, non-destructive. The description adds valuable context about conditional return values (authenticated: true vs connect_url), going beyond annotations.

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

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

Two efficient sentences that front-load the main purpose and then detail behavioral cases. No wasted words.

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

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

No output schema, so description must explain return values. It covers two main cases and mentions key fields. Could include more exhaustive list of fields, but adequate for a simple status tool.

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

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

Input schema has 0 parameters with 100% coverage, so baseline is 4. Description does not need to explain parameters.

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

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

The description clearly states the tool returns connection status and URLs, with specific behavior for different states (all connected vs missing credentials). It distinguishes itself from siblings by explaining the output variations.

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

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

The description implies use for checking connection status but does not explicitly state when to use this tool vs alternatives like 'authenticate'. No guidance on when not to use.

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

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

Disclosure goes well beyond annotations: describes write operations (install/uninstall), one-off invocation without installation, auth requirements (owner/admin), and behavior when credentials or payment are needed. No contradictions with annotations (readOnlyHint=false, etc.).

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

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

The description is long and somewhat verbose, but the complexity of the tool (13 actions) justifies the length. It is front-loaded with the main purpose and flow, but could be more concise by summarizing actions in a table or bullet points.

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

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

Given the tool's complexity, the description covers most aspects: core flow, selection of actions, auth, payment interactions, and relationships between invoke/install. Missing parameter details for some fields and lack of output schema info are minor gaps.

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

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

With 0% schema coverage, the description compensates by explaining key parameters (action, query, mcp_id, tool_id, arguments, etc.) and their roles in the flow. A few parameters like 'limit' and 'message' are not explicitly mentioned, but the core semantics are well covered.

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

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

The description clearly states it is the official marketplace for MCPs and tools, with a specific verb-resource combination. It distinguishes itself from sibling tools like authenticate or omie_* by being the primary entry point for discovering and running 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?

Explicitly states when to use this tool first before external registries, and provides detailed guidance on choosing between invoke, install, list_tools, subscribe, etc. It includes when to use alternatives and prerequisites like owner/admin for writes.

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

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

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

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

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

The description is two sentences long, front-loads the purpose, and contains no superfluous words. It is optimally concise.

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

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

Despite lacking an output schema, the description does not hint at the return value. The 'account' parameter is unexplained. For a retrieval tool with 3 params and no output schema, some additional context on return format would improve completeness.

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

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

With 0% schema coverage, the description explains the two identifier parameters (Omie ID and integration key) but does not mention the 'account' parameter, leaving it ambiguous. This partial explanation adds some value but is incomplete.

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

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

The description clearly states 'Detalha um cliente/fornecedor' (details a customer/supplier) and provides the API method name, distinguishing it from sibling tools like omie_list_customers.

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

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

It specifies that the user must provide either 'codigo_cliente_omie' or 'codigo_cliente_integracao', indicating when to use this tool. However, it does not explicitly contrast with list or mention when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers safety. The description adds that the tool returns id and label, but does not disclose any additional behavioral traits (e.g., pagination, authentication requirements). It neither contradicts nor significantly expands on annotations.

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

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

The description is a single sentence with no wasted words, directly stating the tool's purpose and output. It is appropriately brief for a simple list tool.

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

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

Given the tool's simplicity (one optional parameter, no output schema) and good annotation coverage, the description covers the core functionality. However, it omits any explanation of the parameter and provides no details about the return format beyond field names. A bit more context would improve completeness.

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

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

Schema description coverage is 0%, and the description does not explain the single optional parameter 'account'. The parameter is left entirely to the schema, which lacks a description. This fails to add meaning beyond the raw schema definition.

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

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

The description clearly states the verb 'Lista' (lists) and the resource 'empresas (CNPJ) Omie' (Omie companies/accounts) connected to the install, and specifies the returned fields (id, label). This distinguishes it from sibling tools like omie_list_customers or omie_list_invoices.

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

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

The description implies usage for retrieving connected Omie accounts, but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The context is clear enough for a simple list tool.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it lists company-registered accounts and hints at a mapping use case, but does not disclose pagination, error handling, or other behaviors beyond annotations.

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

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

Efficient two-sentence description. First sentence immediately states the action, second adds valuable context. No unnecessary words.

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

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

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

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

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

Schema description coverage is 0%, so the description must compensate for parameter meanings. It does not explain any of the four parameters (page, account, filters, page_size), leaving the agent without guidance on how to use them.

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

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

Description clearly states the tool lists checking accounts (banks/cash) registered in the company, specifying the API function name. It effectively distinguishes from sibling list tools by the resource type (checking accounts vs. customers, invoices, etc.).

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

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

The description provides a concrete use case: mapping Omie accounts to bank accounts in reconciliation. While it doesn't explicitly state when not to use or list alternatives, this context helps an agent decide applicability.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds pagination and filter behavior. No contradictions; adds modest context beyond annotations.

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

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

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

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

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

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

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

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

Schema coverage is 0% so description must compensate. It explains 'filters' parameter (JSON from Omie API) but provides no extra info on 'page', 'account', or 'page_size'. Only 1 of 4 parameters gets meaningful description.

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

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

Description clearly states it lists clients/suppliers/carriers (specific resources) and indicates it's paginated. The verb 'list' and resource types distinguish it from siblings like omie_get_customer (single) or omie_list_accounts.

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

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

No guidance on when to use this tool vs alternatives like omie_get_customer or other list tools. Does not specify scenarios for filtering or pagination versus other methods.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds that it is paginated and lists specific Hungarian filter names, which offers additional behavioral context beyond annotations. No contradictions.

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

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

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

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

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

Given 4 parameters with 0% schema coverage and no output schema, the description should fully explain parameters and usage. It partially covers filters but omits page, account, and page_size. It also does not describe output, errors, or limits. Incomplete for a comprehensive tool context.

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

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

The schema has 0% description coverage, so the description must compensate. It explains the `filters` parameter in detail with Hungarian names and values, but does not explain `page`, `account`, or `page_size` parameters, leaving gaps.

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

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

The description clearly states it lists financial movements (accounts payable, receivable, checking account) and mentions reconciliation. It implicitly distinguishes from siblings like omie_list_payables and omie_list_receivables by covering both AR/AP plus checking account, but does not explicitly contrast them.

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

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

The description indicates it is the basis for reconciliation with a Bank MCP, providing context for when to use it. However, it does not explicitly state when not to use it or mention alternative tools like omie_list_payables or omie_list_receivables for more specific queries.

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

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

Annotations (readOnlyHint, idempotentHint) already indicate a safe read operation. The description adds valuable behavioral details: pagination support and the structure of the filters parameter (date range, status, type). No contradictions.

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

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

The description is a single sentence that efficiently conveys key information. The use of backticks and structured list for filter fields aids readability, though the 'etc.' is vague.

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

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

While the description covers pagination and filter capabilities, it omits explanations for three of four parameters (page, account, page_size) and does not describe the output format. Given the lack of output schema, additional detail would improve completeness.

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

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

Schema description coverage is 0%, so the description must explain all parameters. It partially describes the `filters` parameter (lists some accepted keys but ends with 'etc.'), but does not explain `page`, `account`, or `page_size`. This leaves significant gaps for an agent.

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

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

The description clearly states the tool lists fiscal invoices (notas fiscais) emitted, with pagination. The name and description together effectively distinguish it from sibling tools like omie_list_customers or omie_list_accounts.

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

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

The description implies usage for listing invoices with filters and pagination. While it doesn't explicitly state when not to use or name alternatives, the context from sibling names makes the tool's purpose clear. Lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context: paginated operation and use of filters. No contradictions, but does not disclose additional traits beyond what annotations provide.

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

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

The description is a single sentence that efficiently conveys purpose and filter usage. It is brief and front-loaded but could be structured with bullet points for clarity.

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

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

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

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

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

Schema coverage is 0%. The description only explains the 'filters' parameter with examples (date format, fields) but leaves 'page', 'account', and 'page_size' undocumented. Does not add meaning for three of four parameters.

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

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

The description clearly states it lists payables (contas a pagar) and mentions pagination and filter capabilities. It distinguishes from sibling tools like 'omie_list_receivables' by specifying 'payables' but does not explicitly contrast with other list tools.

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

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

The description provides examples of filters (date, status, cliente, conta corrente) but no guidance on when to use this tool versus alternatives (e.g., 'omie_list_receivables'). No explicit when-not or alternative tool references.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the behavioral detail that the tool is paginated ('Paginado'), which is not covered by annotations. However, it does not disclose potential side effects, authentication requirements, rate limits, or performance characteristics beyond pagination, so value is moderate.

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

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

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

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

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

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

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

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

Schema description coverage is 0%, so the description must compensate for parameters. It partially explains the 'filters' parameter by listing accepted JSON keys (e.g., filtrar_cliente, filtrar_por_status), but it does not describe the other three parameters ('page', 'account', 'page_size'). The format of the filters JSON (string) is implied but not explicitly stated. Thus, the description adds only minimal meaning for one of four parameters.

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

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

The description clearly states it lists accounts receivable ('Lista contas a receber') with the function name 'ListarContasReceber', and mentions pagination and filter options. This distinguishes it from sibling list tools like omie_list_payables (accounts payable) and omie_list_invoices (invoices), making the tool's specific resource clear.

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

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

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

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

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

Annotations indicate idempotentHint=true and readOnlyHint=false, but the description does not elaborate on behavioral traits such as whether reports are persisted, if duplicate submissions are handled, or any side effects. The description adds minimal transparency beyond the schema and annotations.

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

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

Two sentences convey the purpose and a key usage hint without any redundant information. Every word earns its place.

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

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

Given the tool's simplicity (3 params, no output schema), the description covers the essential action and one parameter hint. However, it fails to specify return behavior or confirm what happens upon success, leaving some gaps.

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

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

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

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

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

Description clearly states the tool reports bugs, missing features, or feedback. The verb 'report' and resource types are explicit, making the purpose easy to understand. However, it could be more specific about the exact action (e.g., creating a support ticket).

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

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

The description advises including the conversation array for reproduction, providing one usage hint. However, it lacks explicit guidance on when to use this tool versus alternatives (no siblings for reporting) and does not specify prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it shows versions, but no additional behavioral traits (e.g., side effects, rate limits, or data scope) are disclosed. It does not contradict annotations.

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

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

The description is a single sentence with no fluff. It is front-loaded and efficiently conveys the tool's purpose. Every word earns its place.

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

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

Given the tool's simplicity (no parameters, no output schema, straightforward behavior), the description is sufficiently complete. It tells the agent what the tool does without needing extra details about return values or side effects.

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

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

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

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

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

The description clearly states the tool shows current MCP platform and adapter versions. It uses a specific verb ('show') and identifies the resource, distinguishing it from sibling tools that perform actions like authentication, connection, or OMIE operations.

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

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

No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or context. For a simple info tool this is a minor gap, but still lacks explicit guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds detail on the specific data returned (MCPs, connection status, catalog tool counts), which adds value beyond annotations.

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

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

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

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

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

Given zero parameters, rich annotations, and no output schema, the description adequately explains the return content. Could mention if always synchronous or potential error cases, but sufficient for a simple info tool.

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

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

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

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

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

The description specifically states it returns 'installed MCPs, their connection status, and how many catalog tools each exposes'. This is a specific verb+resource combination and clearly distinguishes from sibling tools like 'authenticate' or 'omie_list_customers'.

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

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

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

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