Mercado Pago MCP

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

Annotations indicate idempotentHint: true and readOnlyHint: false. The description adds behavioral context by explaining that calling with no args returns a link (non-destructive) and that adding token to config makes it permanent. It does not contradict annotations and provides useful insight into state changes.

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 three sentences long, front-loading the purpose, and every sentence adds value without unnecessary words. It is well-structured for quick comprehension.

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 authentication tool with one parameter and no output schema, the description covers all needed information: the two usage patterns, permanent vs session, and the effect of parameter. It is complete for an agent to invoke correctly.

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

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

Despite 0% schema coverage, the description fully explains the single optional parameter 'token': it should be a JWT for session login, or omitted to get the auth link. This provides complete semantic 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 is for authentication, detailing methods to log in and obtain an access token. It uses specific verbs like 'log in' and 'authenticate', and distinguishes itself from siblings by being the primary authentication tool.

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

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

The description provides explicit usage scenarios: adding token to config for permanent connection, passing token for session login, or calling with no args to get a link. However, it does not explicitly exclude alternatives or mention when not to use it, missing some comparative guidance.

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

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

The description adds behavioral context beyond annotations: it explains the output variations (authenticated:true/false, pending[], connect_url). Annotations already declare read-only and idempotent, so the description complements rather than contradicts.

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 effectively convey purpose and behavior. No wasted words; front-loaded with key return values.

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 no output schema, the description covers both possible states (all connected vs missing credentials) adequately for a simple status tool. No additional information 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?

No parameters exist, so the baseline is 4. The description does not need to add param info as schema coverage is 100% (empty 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 returns connection status and URLs, and distinguishes itself from siblings like authenticate and openfinance_list_connections by specifying it checks overall connection state. The verb 'Returns' and resource 'connection status and URLs' are specific.

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 checking connection status, with explicit conditions for different states (all connected vs missing credentials). It does not provide explicit when-not-to-use or alternatives, but the context is clear for a simple status checker.

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?

Given annotations only provide high-level hints (readOnlyHint=false, etc.), the description carries the full burden and does so thoroughly. It explains that invoke runs one-off without installation, returns connect/checkout links when credentials or payment are needed, requires owner/admin for writes, and clarifies the difference between installed_in_toolkit and installed_in_workspace. 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 long, but the tool is exceptionally complex with 23 parameters and 14 actions. It is front-loaded with the primary purpose, then organized into sub-contexts (core flow, invoke vs install, permissions, prompt library). While it could benefit from bullet points, every sentence contributes meaningful 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?

For a tool of this complexity, the description is remarkably complete. It explains the end-to-end flow, edge cases (auth and payment requirements), the distinction between invoke and install, permission requirements, and the secondary prompt library feature. It also describes the return behavior of key actions (invoke returns links, get_prompt returns text). No output schema exists, so the description's coverage is 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?

The description provides semantic context for the crucial `action` parameter and the core flow (e.g., tool_id, arguments, prompt_vars), and mentions several prompt-related params. However, with 23 parameters and 0% schema description coverage, many parameters (immediate, tier_slug, cancel_reason, cancel_comment, request_name, etc.) are left unexplained, leaving the agent to guess their meaning from names alone.

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

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

The description clearly identifies the tool as the official mcp.ai marketplace and catalog, with a specific primary function of discovering and running MCPs. It details a concrete workflow (search → describe → invoke) and distinguishes itself from sibling tools by defining its role as the central hub for all MCP and prompt management.

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 offers explicit usage guidance: 'prefer invoke for a single/occasional use' and 'use install only to make an MCP PERMANENT'. It also contrasts list_tools as reporting what is callable right now, and distinguishes prompt-related actions. It additionally specifies prerequisite permissions for writes (workspace owner/admin), making when-to-use 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 destructiveHint=true. The description adds valuable context: consent revocation, data deletion, unavailability of data, and a reconnect URL. However, it could mention potential side effects (e.g., impact on shared accounts or historical data retention).

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 totaling ~69 words. It front-loads the main action and includes the return value. No 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?

For a destructive action with one parameter and no output schema, the description covers the action and return value but misses a critical parameter explanation. It also lacks details on reversibility (though implies via reconnect URL) and any confirmation steps.

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 parameter 'item' with 0% coverage (no description). The description does not explain what 'item' is (e.g., bank ID, connection ID). With low schema coverage, the description must compensate, but it fails to do so.

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 revokes consent and deletes connection data for a specific bank, making data unavailable. It also mentions the return of a reconnect URL, adding specificity. This distinguishes it from sibling tools like openfinance_list_connections or openfinance_force_sync.

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 disconnecting a bank but does not explicitly state when to use it versus alternatives (e.g., pausing without deleting). No contraindications or prerequisites are provided.

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 fully discloses the behavioral traits: it waits up to ~60s, polls for completion, and provides timed_out flag. It explains what happens on needs_action (reconnect_url for re-authentication). Annotations are minimal (only readOnlyHint=false), so the description carries the full burden and meets it comprehensively.

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 thorough but not overly verbose. It is well-structured: main action, usage, parameters, return fields, edge cases. It could be slightly more concise, but every sentence adds value.

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

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

Given no output schema, the description explains the full return format including status, executionStatus, lastUpdatedAt, synced, needs_action, reconnect_url, and timed_out. It covers the polling behavior and error cases. This is complete for a tool with 2 parameters and no output schema.

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

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

With 0% schema description coverage, the description compensates fully. It explains `items` as an array of selectors (item_id, connector_id, etc.) and that omitting it syncs all. For `wait`, it explains that setting it to false gives fire-and-forget behavior. This adds essential 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 that the tool forces a bank to re-sync connections and waits for completion. It explicitly differentiates from sibling tools like openfinance_get_item_status by explaining when to use each. The verb 'forces' and resource 'connections' are specific.

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 when-to-use guidance ('Use this when a balance or transaction list looks stale') and when-not-to-use (e.g., re-check with openfinance_get_item_status if timed_out). It explains the implications of omitting `items` (sync all) and setting `wait: false` (fire-and-forget).

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

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

The description discloses degradation behavior when the institution is unavailable, structured warnings for CREDIT accounts, and non-throwing error handling. This adds significant value beyond the annotations.

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

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

While lengthy, the description is well-structured and front-loaded with purpose. Every sentence adds value and there is no 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?

The description thoroughly covers the tool's behavior, error handling, and response shape, making it complete despite the absence of an output schema.

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

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

Schema coverage is 0%, but the description compensates by specifying account_ids as an array of 1-50 strings, which adds necessary constraints 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 returns real-time balance for account IDs, specifying the HTTP method and path. It distinguishes itself from sibling tools by focusing on balance retrieval.

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 passing account_ids as an array of 1-50 and details error handling. However, it does not explicitly state when 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 already mark readOnlyHint=true and idempotentHint=true. The description adds crucial context about provider_incident blocks and unreliable data, which is 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 sentences plus a warning: each sentence is purposeful, front-loaded with the primary action, and no redundant information.

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

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

Given no output schema, the description adequately explains the return shape (results, errors) and a critical edge case (provider_incident). Covers main usage aspects.

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?

Only one parameter is present with 0% schema coverage. The description adds constraints (array size 1–50) and batch shape, providing meaningful guidance 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 it returns full account objects with extended creditData per ID, and distinguishes from sibling tools like list_accounts by emphasizing batch retrieval of detailed objects.

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 specifies the batch shape and array size (1–50), guiding usage. While it doesn't explicitly list when not to use, the context and sibling names imply alternatives for listing or balances.

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 transparently discloses behavioral details beyond the annotations, including the batch response shape ({ results, errors }), the absence of a paid/status field in Pluggy, and the nuanced meaning of payments[]. This complements the readOnlyHint and idempotentHint annotations effectively.

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 detailed and front-loaded with the main purpose, but it is somewhat lengthy. However, every sentence adds value by clarifying usage, limitations, and warnings, so it remains acceptable.

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

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

Given the simple input schema (one parameter) and no output schema, the description is remarkably complete. It covers the return structure, caveats about payments and status, and how to proceed for itemized transactions. No gaps remain.

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 only parameter, bill_ids, is an array of strings. The description explains how to use it: pass bill IDs discovered via the list tool. This adds meaningful context beyond the schema, though the parameter is simple.

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 returns bill-level details for credit card bills by ID, specifying the returned fields (financeCharges, payments). It also explicitly differentiates from openfinance_list_transactions, which retrieves individual transactions, 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 this tool: after discovering bill IDs via openfinance_list_credit_card_bills. It warns against using it for individual transactions and explains the limitations of payments[] in Brazilian Open Finance, including the appropriate alternative for checking paid status.

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 show readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context (e.g., reconnect_url reopens widget in UPDATE mode without disconnecting), but does not mention authentication 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 and front-loaded with the main purpose. While it contains necessary details, it is slightly lengthy but well-structured with clear sections for parameters.

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 (bulk support, optional parameters, and reconnect_url behavior), the description provides sufficient context. No output schema exists, but the description covers return structures adequately.

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 fully explains the semantics: omitting 'item' returns all banks ('{ count, items }'), passing 'item' returns a single bank, and 'item_ids' supports bulk execution. This compensates 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 it returns the current status of a bank connection, including executionStatus, connector metadata, and reconnect_url. It distinguishes itself from sibling tools like openfinance_list_connections by specifying it's for status retrieval, not listing all connections.

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 when to omit the 'item' parameter for all banks, pass it for a single bank, and use 'item_ids' for bulk execution. However, it does not explicitly state when not to use this tool or compare directly with alternatives like openfinance_force_sync.

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 readOnlyHint, destructiveHint, idempotentHint. Description adds batch shape { results, errors } and array size limit, providing additional behavioral context like error handling and pagination.

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 a single paragraph that front-loads purpose, then lists fields, then gives usage guidance. Could be more structured (e.g., bullet points for fields) but is 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?

With only one parameter and no output schema, the description covers the tool's usage completely: field list, batch shape, size limit, and use case. No gaps remain.

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 loan_ids with no description. Description adds that it is an array of loan IDs with a size constraint (1-50), which is essential for correct usage. Could be more explicit about ID format, but sufficient.

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 full loan contract detail by ID, enumerating many specific fields. It differentiates from sibling tool openfinance_list_loans by indicating this is for deep-diving into a specific contract.

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

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

Explicitly says 'Use after openfinance_list_loans to deep-dive on a specific contract.' Provides batch shape and array size limit (1-50). Lacks explicit when-not-to-use, but context is clear.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description discloses that credit balance meaning is connector-dependent, that provider_incident and identity_notice blocks may appear, and that values may be unreliable during incidents. 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?

Detailed and informative, but could be more structured (e.g., bullet points) for easier parsing. Despite length, every sentence adds value, and core purpose is front-loaded.

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

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

Given the tool's complexity (multiple account types, returned fields, edge cases, warnings), the description is remarkably complete. It covers provider incidents, identity notices, credit balance nuances, and references related tools. No output schema exists, but description sufficiently explains return structure.

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 compensates well by explaining 'item' vs. omitting it, 'type' as filter, and 'item_ids' for bulk. However, 'item_id' (singular) vs 'item_ids' (plural) is not differentiated, leaving slight ambiguity.

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 'Returns accounts for a bank connection' and distinguishes between BANK and CREDIT types. It explains the returned fields and differentiates from sibling tools like openfinance_list_credit_card_bills.

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 omit 'item' (to list all accounts across connections) vs. pass 'item' (to target a single bank). Includes warnings about credit balance interpretation, provider incidents, and identity notices, and references alternative tools.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint without contradiction. The description adds caching behavior and field structure, which is helpful but not exhaustive (e.g., no mention of rate limits or error behavior).

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

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

The description is two sentences, front-loaded with the core action, and every sentence adds value. No redundancy or wasted words.

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

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

Given no parameters or output schema, the description covers the tool's purpose, cache behavior, return fields, and relationship to a sibling tool. No gaps remain.

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; schema coverage is 100% (empty). The description does not need to add param info, and it provides sufficient context about the output fields. Baseline 4 is appropriate.

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 the transaction category taxonomy via GET /categories, cached per session. It specifies the fields (id, description, etc.) and mentions usage by sibling tool openfinance_update_transaction_category, distinguishing it from 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 explains it is a cached single-response tool with no batch ids, implying low overhead. It does not explicitly state when not to use, but the context (cached taxonomy) and sibling names make appropriate scenarios 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 indicate readOnlyHint: true and destructiveHint: false, which the description reinforces by stating it returns data. The description adds context about reconnect_url behavior (UPDATE mode, no slot consumption). 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 a single paragraph of three sentences, front-loaded with the main purpose. While it could be slightly more concise by omitting obvious field names, it is not overly verbose and every sentence contributes value.

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

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

Given the tool is a simple list with no parameters, the description completely covers its functionality. It explains all key return values and the special URLs, leaving no ambiguity for an AI agent.

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

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

No input parameters, so schema coverage is 100%. The description adds meaning by explaining the return fields (connector_id, item_id, bank name, reconnect_url, add_connection_url) and their behavioral significance, compensating for the lack of an output 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 returns saved bank connections with specific fields (connector_id, item_id, bank name, reconnect_url, add_connection_url). It distinguishes from sibling tools like openfinance_disconnect_bank and openfinance_force_sync by focusing on listing and providing URLs for reconnection.

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 the reconnect_url (for re-authentication, LOGIN_ERROR, stale data) and what it does (opens widget in UPDATE mode). It also notes that reconnect does not consume a connection slot. However, it does not explicitly state when not to use this tool versus alternatives like openfinance_disconnect_bank.

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. The description adds critical behavioral context: the complex payment_status derivation logic, payment cycle semantics, connector asymmetry (open_bill not always available), bill_grouping_reliability warnings, and the fact that it returns a warning instead of failing if CREDIT_CARDS product is not enabled.

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 quite long but well-structured with paragraph breaks and backtick emphasis for key terms. Every sentence adds important context given the complexity of Brazilian Open Finance. However, some redundancy could be trimmed; it is slightly verbose but justified.

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 thoroughly covers all aspects of the output, including the account echo block, payment_status derivation, open_bill structure and limitations, future_bills projections, connector asymmetry, bill grouping warnings, and the authoritative nature of totalAmount. It also handles edge cases like missing open bill and product not enabled. Given no output schema, the description is complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains include_open_bill in detail and mentions account_ids for bulk. However, it does not describe page and page_size parameters at all, which are standard but still undocumented. The description adds value for the most critical parameters but misses pagination.

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 CLOSED credit card bills for a CREDIT-type account, listing specific fields (dueDate, totalAmount, etc.) and distinguishing itself from individual transaction tools like openfinance_list_transactions. It also explains the scope and derived fields like payment_status.

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 when-to-use and when-not-to-use guidance: it says to use openfinance_list_transactions for itemized purchases, warns against reconstructing bill totals from transactions, explains the opt-in open_bill feature with its limitations and connector asymmetry, and advises cross-checking the account echo when multiple banks are connected.

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 annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds crucial behavioral details: error handling (returns a warning object instead of throwing 403), and a detailed data integrity mechanism with flags like 'suspect_zeroed'. This transparency helps agents handle edge cases correctly.

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 well-structured with a clear front-loaded purpose, followed by field details, error handling, and a data integrity section. While slightly verbose, each sentence adds value and the bulk support note is useful. It is efficient for the complexity involved.

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 lack of output schema and schema descriptions, the description provides a solid overview of return structure (total, results, warning), error handling, and data integrity warnings. It misses explicit explanations for parameters like page and page_size, but overall it sufficiently equips an agent to use 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?

With 0% schema coverage, the description adds minimal parameter guidance. It mentions bulk support for item_ids and implies item is a connection ID, but does not explain page, page_size, or type filtering. The enum for type is listed but not linked to the parameter, leaving agents to infer functionality.

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 returns the investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.) and fields (balance, amount, rates). It distinguishes from siblings like 'openfinance_list_investment_transactions' by focusing on holdings/positions rather than transactions.

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 investment portfolio data and mentions bulk support via item_ids, but does not explicitly contrast with alternative tools like list_investment_transactions. The context is clear enough for an agent to infer when 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by listing specific returned fields (quantity, value, netAmount, expenses) and confirming batch support via investment_ids, which is beyond annotation info.

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 plus a line for bulk support, front-loaded with the core purpose. No unnecessary words; each sentence adds value.

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

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

Given 4 parameters and no output schema, the description covers return fields, prerequisite, and batch support. Missing pagination details, but overall sufficient for tool selection and 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% (no parameter descriptions). The description indirectly explains investment_id as the identifier from the prerequisite tool and mentions batch support for investment_ids, but does not explain page/page_size parameters. Adequate but not comprehensive.

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 movement history for a specific investment position' and lists transaction types (BUY/SELL/TAX/etc.), distinguishing it from sibling tools like openfinance_list_transactions by specifying the context after openfinance_list_investments.

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 to 'Use after openfinance_list_investments to get the investment_id,' indicating prerequisite and typical workflow. Does not explicitly state when not to use, but the context is clear.

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

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

Adds behavioral context beyond annotations: sequential per-connection querying with rate-limit spacing, and return format `{ results, errors }`. Annotations already declare readOnly and idempotent, so description complements without contradiction.

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

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

Three sentences with front-loaded purpose. Concise yet complete for the tool's simplicity. No redundant information.

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

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

Given one optional parameter and no output schema, the description covers input usage, behavior, and return structure. Adequate for a list operation with clear 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?

Input schema provides only a generic array of strings with 0% coverage. Description fully explains the `items` parameter: it accepts connection selectors (item_id, connector_id, or connector_name) and describes the different behavior when absent. This compensates for the bare schema.

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

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

Description clearly states 'Lists loan contracts per bank connection' with the HTTP method and resource, distinguishing it from sibling tools like openfinance_get_loan_detail. The verb 'List' and resource 'loan contracts' 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?

Explains when to pass `items` (array of connection selectors) and when to omit it (list across all banks), including sequential rate-limit behavior. However, no explicit mention of when not to use it or reference to alternative tools.

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

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

The description discloses numerous behavioral traits beyond annotations: pagination behavior (auto vs manual), error handling (returns {total:0,...} on upstream errors), detail levels with token cost and coverage variability, provider incidents affecting data quality, credit card metadata inconsistencies (billId as hint, sparse population), pending vs posted variation by connector, and truncation warnings. No contradiction with annotations (readOnlyHint=true).

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?

Despite its length, the description is well-structured and efficient. It starts with purpose, then covers credit card specifics, pagination, detail levels, error handling, and bulk support. Every sentence adds necessary nuance; there is no repetition or filler. The information is dense but clearly organized.

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

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

With no output schema, the description fully explains the response structure: account echo block, provider_incident block, pagination behavior, truncation, and error returns. It covers edge cases like credit card sync failures and connector-specific metadata. For a tool with 8 parameters and complex bank-dependent behavior, the description is remarkably complete.

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

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

Schema_description_coverage is 0%, so the description carries full burden. Every parameter is explained in detail: account_id and account_ids for bulk, from/to as ISO dates, page/page_size with pagination modes, detail enum with behavior of each option, search_queries with substring matching and OR semantics. The description adds essential meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Returns transactions for a bank account (BANK or CREDIT type).' It distinguishes from sibling tools like openfinance_list_credit_card_bills, explicitly noting that tool as the source of truth for bill totals, and mentions bulk support. The verb 'returns' and resource 'transactions' 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 extensive guidance on when to use this tool vs alternatives. For credit card accounts, it states 'this is the ONLY way to get itemized transactions.' It warns against using this tool to reconstruct bill totals, directing to openfinance_list_credit_card_bills. It also advises checking openfinance_get_item_status if total is 0 and sync may have failed. Explicit exclusions and alternatives are given.

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 important behaviors beyond annotations: transaction caps at 5000/account with truncation flag, provider_incident block, bulk support, and default granularity behavior. All consistent with readOnlyHint and idempotentHint.

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?

Well-structured with front-loaded purpose and logical flow, but slightly verbose due to detailed parameter explanations. Still, every sentence adds essential context.

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 parameters, output structure (summary fields), edge cases (truncation, provider incidents), and offers practical usage guidance, making it fully self-contained despite lacking an output schema.

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

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

Despite 0% schema description coverage, the description comprehensively explains each parameter's meaning, types, and effects on output (e.g., granularity, detail, item, type), adding significant value over the bare schema.

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

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

The description clearly states it provides consolidated cash-flow analysis for a whole bank connection in one call, distinguishing it from sibling tools like openfinance_list_accounts and openfinance_list_transactions by handling account resolution internally.

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 explains that you do not need to call openfinance_list_accounts first and provides typical use cases (fluxo de caixa, maiores gastos), but lacks explicit 'when not to use' guidance for alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds context: it checks a public status page, is independent of user connections, and details the output (global indicator, components, incidents, your_banks_affected). No contradiction.

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

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

The description is a single dense paragraph but effectively front-loads the main action and provides all necessary details. It could be slightly more structured, but it is concise relative to the information conveyed.

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 parameters and no output schema, the description fully covers the tool's purpose, usage triggers, and output types (global indicator, degraded components, incidents, your_banks_affected). No 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 input schema has no parameters (0 params, 100% coverage), so the description does not need to add parameter info. Baseline for 0 params is 4, and no additional parameter semantics are required or missing.

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 'checks the LIVE operational status of the Open Finance provider', distinguishing it from the user's own connection status via sibling tool 'openfinance_get_item_status'. Verb and resource are specific and unambiguous.

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

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

Explicitly tells when to use: 'whenever data looks incomplete or stale even though a connection shows UPDATED' and how it helps differentiate provider-side problems from connection issues. Includes what is returned, providing clear 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 safe (readOnly, idempotent, non-destructive). Description adds key behaviors: plan handling (PF hides PJ), caveat warning for non-Open-Finance connectors, and never dumps full catalog.

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 comprehensive but slightly long; each sentence adds value. Front-loaded with purpose. Could trim minor redundancy but overall effective.

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

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

Given no output schema, description covers return fields, edge cases (caveat, plan, missing keywords). Provides complete guidance for agent to select and invoke correctly.

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

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

Description explains both parameters well despite 0% schema coverage. Notes keywords[] is required (mismatch with schema but adds meaning). Include_accounts usage is clear.

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?

Clearly states it searches bank connectors by name keywords, returns specific fields (connector id, access type, audience, linked connections, connect_url), and distinguishes from sibling tools by being a pre-connection search.

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 'Call this BEFORE connecting', notes that keywords[] is required and missing it returns a hint. Missing explicit when-not-to-use but context is clear.

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

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

The description discloses important behavioral traits beyond the annotations: it overrides automatic categorization, teaches the system by creating a Category Rule, and explains batch behavior with per-item errors. Annotations provide no hints (readOnlyHint=false, destructiveHint=false), so the description carries full burden and does so thoroughly.

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, well-structured paragraph. It front-loads the purpose, then details parameters, side effects, and return shape. While dense, it remains clear and each sentence adds value; minor redundancy could be trimmed.

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 (batch update, side effect, error handling) and lack of output schema, the description covers the return shape, parameter provenance, and behavioral implications. It is complete enough for an AI agent to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, but the description compensates fully by explaining the items array structure: 'Pass `items` as an array of { transaction_id, category_id }' and specifies where to obtain each ID. It also outlines the return shape, adding 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's purpose: 'Corrects the category of one or more transactions (PATCH /transactions/:id).' It uses specific verb-resource phrasing and distinguishes from sibling tools like openfinance_list_transactions and openfinance_list_categories by mentioning where to obtain the IDs.

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

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

The description provides clear context for when to use the tool: 'use this to fix miscategorized transactions and improve categorization accuracy going forward.' It also implies when not to use it by warning about the side effect of creating a category rule, but does not explicitly list alternatives 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 indicate idempotency and non-destructiveness; the description adds that the conversation array should be included for reproduction, which is a useful behavioral detail.

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

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

The description is a single, focused sentence that conveys the tool's purpose and key usage instruction without wordiness.

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 feedback tool with no output schema, the description adequately covers purpose and a key input instruction, though it doesn't explain the 'context' parameter or post-submission 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?

With 0% schema description coverage, the description partially compensates by explaining the 'conversation' parameter's purpose, but 'context' and 'message' are not elaborated.

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 reporting bugs, missing features, or feedback, which distinguishes it from sibling tools focused on financial operations and authentication.

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 explicit guidance to include the conversation array for reproduction, but does not mention when not to use or alternative tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. Description adds specificity by naming the exact version info (platform + adapter), which is helpful.

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, focused sentence with no waste. Front-loads the key action and output.

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 and no output schema, the description fully captures the tool's purpose and 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; baseline score is 4 as per evaluation rules.

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 'Show' and specific resources 'MCP platform and adapter versions', distinguishing it from siblings which cover authentication, connections, and Open Finance 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?

Usage is implied for retrieving version information, but no explicit guidance on when to use vs alternatives is provided.

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, destructiveHint=false, and idempotentHint=true; the description adds useful behavioral context by specifying exactly what state is returned (connections, accounts, tool counts), going beyond the annotation signals.

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?

A single, well-structured sentence that front-loads the action and enumerates the key contents of the response without extraneous detail.

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 parameterless, read-only informational tool, the description fully captures what the agent needs to know: it explains the output categories (MCPs, connections, accounts, tool counts). No output schema exists, but the description covers the essential return semantics.

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

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

The tool has zero parameters, so there are no parameter semantics to explain; the description appropriately focuses on the return value, and the empty schema is fully covered by the description's implicit handling of no inputs.

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 uses a clear verb ('Returns') and specifies the resource ('current toolkit state') with concrete details (installed MCPs, connection status, accounts, tool counts), clearly distinguishing it from financial-operation siblings like openfinance_list_accounts or authenticate.

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?

Although it doesn't name alternatives, the description makes it clear this is the tool for checking the toolkit's installed MCPs and connections; the read-only and idempotent annotations reinforce that it's a status check, providing enough contextual guidance for when to use it.

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