Banrisul MCP

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

Annotations indicate idempotentHint=true, which aligns with the description's indication of non-expiring connection. The description adds behavioral context about permanent vs session login and token handling.

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

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

Three concise sentences, front-loaded with purpose. Each sentence adds value without redundancy.

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

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

Covers the key authentication scenarios and token management. No output schema specified, but the description implies the expected return (link or success). Could mention return format explicitly.

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

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

Schema has 0% description coverage for the single optional token parameter, but the description fully explains its purpose (a JWT token) and the two calling modes (with or without token). This compensates completely.

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 handles authentication for MCP.AI IDE agents. It distinguishes from siblings like connect and openfinance tools by focusing on the authentication flow.

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 describes three usage scenarios: adding token to config for permanent login, passing token as argument for session-only, or calling with no arguments to get a login link. Provides clear guidance on when to use each.

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 and idempotentHint, and the description adds valuable behavioral detail about the two possible output states (authenticated vs pending). This goes beyond annotations without contradicting them.

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

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

The description is extremely concise with two sentences, front-loading the main purpose and immediately providing scenario-based detail. No wasted words.

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

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

Given zero parameters, clear annotations, and no output schema, the description fully covers the tool's behavior in its two expected states. It is complete for its simplicity.

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 no parameters, so schema coverage is 100%. The description does not need to add parameter information, and the baseline score applies.

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 scenarios for when providers are connected vs missing credentials. It distinguishes itself from sibling tools like 'authenticate' by focusing on status rather than initiating 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?

The description explains when to expect authenticated:true versus connect_url, providing clear usage context. However, it does not explicitly mention when not to use this tool or compare it to alternatives like 'authenticate' or 'openfinance_list_connections'.

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 significant behavioral context beyond annotations: explains that invoke works even if MCP not installed, returns connect or top-up links for auth/billing, and that writes require owner/admin. Annotations indicate non-read-only (readOnlyHint=false) and non-destructive (destructiveHint=false), and description aligns 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?

Long but well-structured, front-loading core purpose and flow. Some repetition (e.g., invoke vs install guidance appears twice), but overall each sentence contributes. Could be tightened without losing 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?

Given the tool's broad scope (15 params, multiple actions, no output schema), the description provides extensive context: core flow, key behaviors, and output hints (e.g., connect/top-up links, installed flags). Missing explicit description of return structures for actions like list_tools or subscribe, but adequate for an agent to use 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 has 0% description coverage for 15 parameters. The description explains key parameters (action, query, mcp_id, tool_id, arguments) and their roles in the flow, but leaves many others (limit, message, immediate, tier_slug, conversation, etc.) undocumented. Compensates somewhat but 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 it's the official mcp.ai marketplace, explaining its role as a catalog and execution platform for MCPs. It distinguishes from sibling tools by specifying it's the first tool to use for finding capabilities, contrasting with external registries and other tools like authenticate or openfinance functions.

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

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

Provides explicit guidance: use this tool first for capability discovery, prefer invoke for occasional use, install for permanent addition, and describes core flow (search→describe→invoke). Also specifies when to use alternatives like list_tools or request_mcp, and mentions permission requirements for write actions.

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 set destructiveHint=true, so the description adds value by explaining that data will no longer be available and that a re-connection URL is returned. This goes beyond the annotation, providing useful behavioral context.

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

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

Two concise sentences. The first sentence states the primary action, the second adds the return value. No unnecessary words, and key information is front-loaded.

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

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

For a simple tool with one parameter and no output schema, the description covers the main action and result. However, it lacks explanation of the parameter and does not mention any preconditions or side effects beyond what is annotated, 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?

The single parameter 'item' has no description in the schema and the description does not explain what it represents. Although 'specific bank' is mentioned, the parameter is not explicitly defined, leaving 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 the action (revokes consent and deletes connection data) and the result (data no longer available). It also mentions a return value, distinguishing it from sibling tools like list_connections or get_item_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?

No guidance on when to use this tool vs. alternatives like openfinance_list_connections. The description implies it is for disconnecting a bank, but does not explicitly state when it is appropriate or what prerequisites exist.

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?

Despite annotations being minimal (readOnlyHint false, destructiveHint false, etc.), the description thoroughly explains behavior: polling up to ~60s, possible final statuses (status, executionStatus, lastUpdatedAt, synced), needs_action with reconnect_url, and timed_out. No contradictions with annotations.

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

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

The description is a single, dense paragraph but every sentence adds value. It is front-loaded with the main action and timeout. Could be slightly more structured (e.g., bullet points), but not overly verbose.

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 (2 parameters, no output schema), the description covers purpose, usage, parameters, return format, error handling, and alternative tools. It is fully self-contained.

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 2 parameters with 0% coverage, but the description fully explains them: 'wait' boolean (fire-and-forget when false) and 'items' array (selectors or omit for all). This compensates completely for the schema's lack of 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 forces a bank to re-sync connections and waits for completion. It uses specific verbs like 'forces re-sync' and 'pulls fresh data', and distinguishes itself from siblings by indicating it is for stale data without disconnecting.

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

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

The description explicitly tells when to use the tool ('when a balance or transaction list looks stale'), how to sync all (omit items), and how to handle errors (needs_action with reconnect_url). It also mentions alternatives like openfinance_get_item_status for timeout cases.

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

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

Adds substantial behavioral details beyond annotations: explains BALANCE_FETCH_ERROR, degradation to last-synced balance, warning fields, and response shape. 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?

Dense information in a single paragraph. No wasted words, but could be improved with bullet points for error conditions. Still concise and well-structured.

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 and no output schema, the description covers all key aspects: real-time retrieval, error handling, degradation, and response structure. Complete for the tool's complexity.

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

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

Schema has 0% coverage for parameter descriptions, but the description compensates by explaining the array format and valid range (1-50). Could mention that items are string IDs, 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 real-time balance per account id with the endpoint path. It is specific and distinguishes this tool from siblings like openfinance_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?

Provides guidance on valid input range (1-50 account_ids), explains behavior for CREDIT accounts and upstream failures, and describes error handling. Lacks explicit when-to-use vs alternatives, but context is strong.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds crucial behavior: a potential provider_incident block when the Open Finance provider has an OPEN incident, warning that credit limits and balances may be unreliable. This goes beyond annotations and is valuable for agent decision-making. It could have mentioned rate limits or authentication, but overall good transparency.

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: first explains core function, second specifies usage and response shape, third warns about provider incident. It is front-loaded, avoids redundancy, and every sentence adds unique value. No wasted words.

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

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

Given the tool has one parameter, no output schema, and annotations cover safety, the description provides a clear response shape and a critical warning about data reliability. It does not mention error handling details or pagination (unlikely needed for batch max 50). The completeness is high for the tool's complexity, though a brief note on what errors field contains could improve 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% for the single parameter account_ids, so the description must compensate. It does: states it is an array, size limit 1–50, and implies it accepts string IDs via the endpoint path. This adds meaning beyond the schema's type definition. It would benefit from clarifying the ID format (e.g., string UUIDs), but the provided context is sufficient for basic usage.

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

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

The description clearly states it returns full account objects including extended creditData per ID, and references the specific endpoint (GET /accounts/:id). This distinguishes it from sibling tools like openfinance_list_accounts which lists all accounts, and openfinance_get_account_balance which retrieves only balance. The verb 'Returns' plus the specific resource 'account objects' makes the purpose precise.

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 how to use the tool: pass account_ids as an array (1–50) and notes the batch response shape { results, errors }. It implicitly suggests this tool is for getting details for specific account IDs, as opposed to list_accounts. However, it does not explicitly state when not to use it or provide alternatives, but the context is clear enough for an AI agent to infer.

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 value beyond annotations by disclosing batch shape, absence of paid/status field, payments[] referencing previous bill, and sparse billId metadata. 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?

Description is detailed but front-loaded with purpose. Every sentence adds value, though slightly verbose with context about Brazilian Open Finance and Pluggy specifics.

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

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

Given no output schema and one parameter, description covers parameter guidance, output shape, and critical behavioral caveats. Nearly complete for effective tool use.

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

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

With 0% schema coverage, description explains the array parameter usage, sourcing bill IDs from sibling tool, and batch shape. Provides clear guidance but could detail the parameter format slightly more.

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 returns bill-level detail including financeCharges and payments by ID. Distinguishes from sibling tools openfinance_list_credit_card_bills and openfinance_list_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?

Explicitly tells when to use (bill detail) and when not (itemized transactions), directs to sibling tool for discovery, warns not to sum transactions, and explains payment semantics.

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, destructiveHint) are already present and consistent. Description adds useful context: the reconnect_url for reauthentication without disconnecting, and the bulk behavior. No contradictions.

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

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

Very concise: two sentences and a short bullet for bulk support. Front-loaded with the core action and return types. Every sentence is informative and necessary.

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 enumerates what is returned (status, executionStatus, connector metadata, reconnect_url). Covers both single and bulk modes. No missing information for typical 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 has 0% coverage, but description adds meaning: 'item' for single bank, 'item_ids' for batch. However, it does not explain 'item_id' vs 'item', leaving some ambiguity. Still adds significant value over 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?

Description clearly states it returns the current status of a bank connection, lists example statuses, and distinguishes from sibling tools like authenticate and connect. It covers single and bulk 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?

Explicitly explains when to omit 'item' for all banks and when to pass 'item' for a single bank. Also mentions bulk support with 'item_ids'. Could be improved by clarifying the difference between 'item' and 'item_id' parameters.

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, and idempotentHint=true, so the description's burden is lower. The description adds useful behavioral context: the batch shape '{ results, errors }', parameter size limit (1-50), and the specific fields returned. 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 two sentences, front-loaded with the main purpose, then usage guidance, then batch format. Every sentence earns its place with no wasted words.

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

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

Given the tool has only one parameter and no output schema, the description covers the essential aspects: what it returns, when to use it, parameter constraints, and result shape. It could mention error handling for invalid IDs, but the batch shape implies that. Adequate for this complexity.

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

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

Schema coverage is 0%, so the description must compensate. The description adds that `loan_ids` is an array with size limit 1-50 and that it returns a batch shape. However, it does not explain the format of each item in the array beyond what the schema already provides (strings). This adds some value but not full compensation for the lack of schema documentation.

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 'Returns' and the resource 'full loan contract detail by id', and explicitly distinguishes from sibling tool openfinance_list_loans by advising to use it after that tool for deep-diving. This meets the criteria of specific verb+resource and sibling differentiation.

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

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

The description explicitly says 'Use after openfinance_list_loans to deep-dive on a specific contract', providing clear when-to-use guidance and naming the alternative tool. This is exemplary usage guidance.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description discloses critical traits: credit balance meaning depends on the connector, provider incidents may cause unreliable data, and identity notices require deduplication. It also mentions bulk support via item_ids.

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 front-loaded with the core purpose. While detailed, all information is relevant and well-organized. Slightly verbose, but the complexity justifies the length.

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

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

Covers all parameters, return fields, edge cases (provider incidents, identity notices), and bulk support. References sibling tool for credit card bills, providing a complete picture despite 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 coverage, the description fully compensates by explaining each parameter's purpose: 'item' to target a single bank, 'type' to filter, and 'item_ids' for bulk execution. It adds context missing from 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 accounts for bank connections with specific data fields (balance, number, type, etc.) and distinguishes between BANK and CREDIT types. It also highlights when to use this tool vs. openfinance_list_credit_card_bills by noting that this tool's credit balance is connector-dependent.

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: omit 'item' to list all accounts across banks, pass 'item' for a single bank, and warns about credit balance interpretation. It also advises using openfinance_list_credit_card_bills for standardized billing amounts and explains provider_incident and identity_notice handling.

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 and idempotentHint=true. Description adds valuable behavioral traits: caching (lasts for session), single aggregated response (no batch IDs), and that entries include id, description, and parent info. 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?

Three sentences, no wasted words. Front-loaded with purpose, then details on cached nature and entry structure. Excellent conciseness.

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

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

With no output schema, the description fully explains what the response contains (id, description, translated description, parentId, parentDescription) and notes caching. Complete for a simple list 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?

No parameters exist, so baseline 4 applies. The description adds no parameter details but none are needed.

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

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

The description uses specific verb 'returns' and resource 'transaction category taxonomy', clearly distinguishing it from siblings like openfinance_list_transactions or openfinance_get_accounts_detail. It specifies the API endpoint (GET /categories) and connects it to the update 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?

States the tool is for retrieving categories used with openfinance_update_transaction_category and mentions it is cached (so repeated calls are unnecessary). Context for when to use is clear, though without 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?

The description adds significant behavioral context beyond annotations, such as the reconnect_url behavior, no connection slot consumption, and no need to disconnect first. Annotations indicate readOnlyHint, idempotentHint, and destructiveHint are all true/false appropriately, and the description aligns with them.

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 key information. It could be slightly shorter, but it provides essential details without unnecessary verbosity.

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 exists, but the description enumerates the fields returned. For a listing tool with no complex output, this is sufficiently complete. The context around reconnect_url adds 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?

There are no parameters, and schema coverage is 100% (empty properties). The description clearly explains what the tool returns, adding value beyond schema. There is no need for parameter details.

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 saved bank connections for the install, listing specific fields like connector_id, item_id, bank name, and URLs. It distinguishes itself from sibling tools by focusing on connection listing and providing detailed usage of reconnect_url.

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 use the reconnect_url (for re-authentication, MFA errors, LOGIN_ERROR, stale data) and that it does not consume a connection slot. However, it does not explicitly state when to use this tool versus other listing tools among siblings, though the context is clear enough.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds extensive behavioral context: payment cycle semantics, derived payment_status logic, open bill derivation from pending transactions, connector asymmetry, bill_grouping_reliability, warnings instead of failure, and balance meaning variance. 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 front-loaded with the core function and key semantics. It is logically structured: output description, payment semantics, open bill details, connector asymmetry, bulk support. While verbose, every section adds critical value for a complex domain. Could be tightened but remains 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, the description provides a detailed account of response fields: payments array, aggregates, derived payment_status, open bill structure, future_bills, account echo block. It covers warnings, bulk support, and non-availability scenarios. Minor lack of explicit root response structure (e.g., top-level keys) but sufficiently complete for a read tool.

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

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

Schema description coverage is 0%, so the description must compensate. It explains account_id, account_ids (bulk), and include_open_bill (opt-in, derivation, confidence) in detail. However, pagination parameters (page, page_size) are not mentioned, leaving a gap for 2 of 5 parameters. The explanation of covered parameters is thorough, but the omission reduces the score.

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

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

The description opens with a specific verb-resource pair ('Returns CLOSED credit card bills for a CREDIT-type account'), clearly distinguishing the tool from siblings like openfinance_list_transactions (itemized purchases) and openfinance_get_credit_card_bill (singular). It explicitly states scope (closed bills, CREDIT account) and differentiates from transaction-level 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 explicit when-to-use guidance: refers to openfinance_list_transactions for itemized purchases, explains when to use include_open_bill, warns against assuming payment status from payments array, provides logic for derived payment_status, and includes a stern directive ('NEVER call such a bill vencida categorically'). It also addresses connector asymmetry and bulk support.

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 significant behavioral context beyond annotations: details error handling (returns warning object instead of throwing for INVESTMENTS disabled), data integrity checks with cross-referencing transaction history, and mass zeroing detection. 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, clear sections for error handling and data integrity. Slightly verbose in listing return fields, but every sentence adds value. Conciseness is good but not perfect.

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

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

Provides comprehensive behavioral details and error scenarios, compensating for no output schema by describing return fields and warning objects. Lacks explicit pagination description and connection sourcing context, but overall adequate for read-only tool with annotations.

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

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

With 0% schema coverage, description partially compensates by explaining bulk support via item_ids and implying item refers to connection ID. However, it does not describe page, type, item_id, or page_size, 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 returns an investment portfolio for a connection, listing specific asset types. It distinguishes from siblings like list_investment_transactions by focusing on portfolio snapshot rather than transaction history, but does not explicitly differentiate.

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 explicit guidance on when to use this tool vs siblings (e.g., list_investment_transactions). Provides context on bulk support and error handling but no alternatives or when-not-to-use criteria.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context beyond annotations by listing return fields and bulk support (investment_ids), enhancing transparency.

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 paragraphs, front-loaded with purpose and key details. Every sentence adds value; 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?

Given no output schema, the description richly details return fields and types. It also mentions prerequisites and bulk support. However, missing pagination explanation and error handling limit completeness slightly.

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 adds meaning for investment_id and investment_ids (via 'Bulk support: accepts investment_ids for batched execution') but does not explain page or page_size parameters, leaving some 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 'returns the movement history for a specific investment position' and enumerates transaction types (BUY, SELL, TAX, etc.) and output fields, distinguishing it from sibling tools like openfinance_list_investments or openfinance_list_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?

Provides explicit usage guidance: 'Use after openfinance_list_investments to get the investment_id.' This tells the agent when to invoke it, though it does not explicitly mention when or when not to use alternatives.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds key behavioral traits: sequential querying with rate-limit spacing and return format '{ results, errors }' per connection. 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?

Three sentences front-loaded with purpose, followed by parameter semantics and omission behavior. Every sentence adds unique value; no redundancy or filler.

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

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

Covers purpose, parameter usage, return format, and behavior for multiple connections. Minor gap: does not specify behavior for an empty 'items' array (likely equivalent to omission). Still adequate for a simple list tool with no output schema.

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

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

Although schema provides 0% parameter descriptions, the description fully explains the 'items' array: each element is a connection selector (item_id uuid, connector_id, or connector_name), and omitting the parameter lists all loans. This adds complete 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?

Clearly states verb 'Lists', resource 'loan contracts', scope 'per bank connection', and HTTP method 'GET /loans'. Differentiates from sibling 'openfinance_get_loan_detail' by specifying listing vs. detail 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?

Provides explicit guidance on using the 'items' parameter for specific connections or omitting it for all banks. Mentions rate-limit spacing for sequential queries. Does not explicitly state alternatives, but sibling names make differentiation 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 key behaviors: auto-pagination with truncation, manual pagination behavior, error handling (returns error block), detail levels and their trade-offs, credit card pending/posted behavior per connector, provider incidents, and cross-reference to other tools. Annotations (readOnly, idempotent) are consistent and the description adds substantial context beyond them.

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 well-structured with paragraphs separating pagination, detail levels, credit card nuances, and provider incidents. While not as concise as some examples, the content is valuable and each section serves a purpose. Minor redundancy in credit card metadata warnings could be tightened, but overall efficient for the complexity.

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 (8 params, no output schema, multiple edge cases), the description covers all necessary aspects: pagination modes, truncation, error handling, detail levels, credit card bill relationship, provider incidents, bulk support, and cross-references to sibling tools. No gaps remain for effective agent use.

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

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

Despite 0% schema description coverage, the description thoroughly explains every parameter: account_id (required), from/to (ISO dates), page/page_size (pagination modes with defaults and limits), detail (enum with explanations for compact, rich, raw), search_queries (case- and accent-insensitive substring match with OR semantics), and account_ids (bulk). The description adds meaning and usage rules 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 transactions for bank accounts, distinguishing between BANK and CREDIT types. It specifies that for CREDIT accounts, it is the only way to get itemized transactions, and contrasts with other 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?

Extensive usage guidance is provided: when to use this vs. alternatives (e.g., for credit card bills), not to sum by billId, explanation of pagination modes (auto vs manual), when to narrow date ranges, and when to check item status. It explicitly tells when not to use it for bill totals.

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?

Provides significant behavioral context beyond annotations: caps at 5000/account with truncated flag, provider_incident block, performance implications of raw granularity, and that reconnecting doesn't fix provider incidents. Annotations already indicate read-only and idempotent, which description supports and expands.

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 lengthy. It uses bold and structure to highlight key points, though some details could be condensed. Still, it remains readable and front-loaded with the core value proposition.

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, description explains the return shape (total, por_mes, top_despesas, by_account) and edge cases (truncated, provider_incident). For 9 parameters, it covers most behavior, but lacks explicit output field types or example response.

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

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

Schema has 0% description coverage, so description carries full burden. It explains all key parameters: item (accepting multiple identifier types), from/to (ISO dates), granularity (monthly/raw with defaults), detail (rich/raw), type (BANK/CREDIT), top_n (implied), item_ids (bulk). Adds meaning beyond schema's enum values.

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 consolidates cash-flow for a bank connection in one call, avoiding the need for multiple calls like openfinance_list_accounts. It distinguishes from siblings by emphasizing the unified analysis over individual account listing.

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 when to use (e.g., 'análise anual/mensal', 'fluxo de caixa') and when to omit item for all banks. Mentions granularity options for raw rows. However, does not directly compare to similar sibling tools like openfinance_list_transactions.

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, idempotentHint=true, destructiveHint=false. The description adds behavioral details: reveals upstream outage, returns global indicator, degraded components, open incidents, and flags incidents affecting connected banks. This goes beyond annotations.

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

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

The description is front-loaded with purpose, then usage guidance, then return details. Every sentence adds value without redundancy. It is appropriately sized for the complexity.

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 context, and return value structure. It is complete for a status check 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?

Tool has no parameters (baseline 4), so no additional parameter semantics needed. The description does not waste space on 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 checks the LIVE operational status of the Open Finance provider, distinguishing it from the sibling tool `openfinance_get_item_status` which checks the user's connection. The verb 'checks' and resource 'provider status' 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 describes when to use: when data looks incomplete or stale despite a connection showing UPDATED. It also clarifies that it helps differentiate provider-side problems from connection issues. While it doesn't explicitly say when not to use, the context is clear.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds: it never dumps the whole catalog, returns caveats for non-auto-update connectors, and explains plan-based filtering. 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 information-dense but not overly long. It front-loads the core action and follows with important details. A bit lengthy but justified by complexity.

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 fully details what is returned (fields, connect_url, caveats) and how the tool behaves under different inputs (keywords, plan type). It covers all necessary context for an agent to use it correctly.

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

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

Schema coverage is 0%, but the description fully explains both parameters: keywords[] is an array of bank names (required for meaningful results) and include_accounts is a boolean to include accounts. It adds semantics 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 it searches bank connectors by name, returns details like connector id, access type, connect_url, and explicitly says to call this before connecting. This distinguishes it from siblings like 'marketplace' or 'connect'.

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

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

It explicitly says 'Call this BEFORE connecting' and notes that keywords[] is required (otherwise returns a hint). It explains plan behavior (PF hides PJ) but doesn't explicitly state when not to use it, though 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?

The description fully discloses the side effect: overriding automatic categorization and creating Category Rules for future matching. It also explains batch error handling. Annotations are minimal, so the description carries the burden and succeeds.

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 dense paragraph that efficiently conveys behavior, batch details, and side effects. While comprehensive, it could be slightly more structured (e.g., bullet points for response fields) to improve scanability.

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

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

The description covers all necessary aspects: purpose, parameter semantics, side effects, error handling, and output shape. Given no output schema and a complex tool, it 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?

With 0% schema description coverage, the description compensates by specifying that `transaction_id` comes from `openfinance_list_transactions` and `category_id` from `openfinance_list_categories`, and details the response shape. This adds essential meaning beyond the raw 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 corrects transaction categories, specifies the HTTP method and endpoint, and lists the required ID sources. It leaves no ambiguity about the verb and resource.

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

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

The description explains when to use (fix miscategorized transactions, improve accuracy) and how IDs are sourced from sibling tools, but does not explicitly state when not to use or contrast with alternatives.

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

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

Annotations already provide safety traits (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds minor context by mentioning the conversation array, but does not disclose any additional behavioral details beyond what the annotations indicate.

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 consists of two concise sentences with no wasted words. The key action and required data are front-loaded, making it easy for an agent to understand quickly.

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, the description covers the basic purpose and a required element (conversation). However, there is no output schema or explanation of the response, which is a gap. It is minimally adequate but not fully comprehensive.

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

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

Schema description coverage is 0%. The description only explains the 'conversation' parameter ('Include the conversation array'), leaving 'context' and 'message' unexplained. While 'message' is somewhat self-evident, 'context' lacks any description, resulting in incomplete parameter guidance.

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

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

The description clearly states the tool's purpose: 'Report a bug, missing feature, or send feedback.' It uses specific verbs and resources, and it distinguishes itself from sibling tools (which are mostly openfinance or authentication) by being a general feedback mechanism.

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

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

The description explicitly instructs to 'Include the conversation array with recent messages for reproduction,' providing clear guidance on when to use the tool and what data to include. It lacks explicit when-not-to-use guidance, but the context is clear enough.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds no new behavioral details beyond those already captured, which is acceptable but does not earn a higher score.

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, front-loaded sentence with no unnecessary words. Every part 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, clear purpose), the description is fully sufficient. No additional context 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?

The tool has zero parameters and schema coverage is 100% (empty schema). The description correctly does not attempt to document parameters, and the baseline for zero parameters is 4.

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 'show' and the resource 'versions', specifying both MCP platform and adapter versions. This distinguishes it from siblings, as no other tool claims to show version info.

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 tool is simple and has no parameters or side effects, so explicit usage guidelines are less critical. The description implies it's for checking current versions, and there is no mention of alternatives, but none are needed given the unique purpose.

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. The description adds specific context about what is returned (installed MCPs, connection status, catalog tool counts), which is valuable 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?

Single sentence, perfectly front-loaded with the core purpose, 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?

For a zero-parameter tool with no output schema, the description sufficiently explains what is returned. Tool is simple and 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?

No parameters, so baseline 4 applies per rules. Description adds meaning about the output, not parameters, which is 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?

Description clearly states the verb 'returns' and the resource 'current toolkit state', listing specific data points (installed MCPs, connection status, catalog tool counts). It is distinct from all sibling tools which are primarily for authentication, connections, and financial data operations.

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

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

No explicit guidance on when to use this tool vs alternatives, but the tool is a zero-parameter info query with no side effects, so usage is implied. However, it doesn't mention scenarios where it should be used or avoided.

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