C6 Bank MCP

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

Annotations indicate idempotentHint=true, readOnlyHint=false, destructiveHint=false. Description adds context: explains that calling with no args returns a link, and with token it authenticates. Mentions permanence of config vs. session, which is useful 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?

Two sentences, front-loaded with key purpose and usage. Every word earns its place; no fluff.

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 two main use cases (permanent config and session token) and the no-args link generation. No output schema, but description implies the tool returns a link or authentication status. Adequate for a simple auth tool.

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

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

Schema has one optional 'token' param with 0% coverage. Description explains it is a JWT token for session login, and no-args returns a link. 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 the tool handles authentication for MCP AI, explaining two login methods (permanent config vs. session token). It distinguishes itself from unrelated siblings like 'connect' or 'report_bug' by its unique purpose.

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

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

Provides explicit guidance on when to use: 'log in in the browser, copy the access token' and recommends the permanent config method. Advises calling with token for session login or no args to get the link. No mention of when not to use among siblings, but siblings are unrelated.

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

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

The description adds value beyond annotations by detailing the return values in different states (authenticated vs missing credentials). Annotations already indicate readOnly and idempotent, and the description reinforces this with specific behavior.

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

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

Two sentences, well-structured, no fluff. Every sentence adds meaningful information about the tool's output in different conditions.

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 two main states (all connected vs missing credentials) but does not mention other possible states like partial connections. However, for a status tool, it is fairly complete and useful.

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 schema coverage is 100%. The description naturally doesn't need to add parameter info, and with 0 parameters, baseline 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 tool returns connection status and URLs, distinguishing it from siblings like authenticate (which does authentication) and openfinance_list_connections (which lists connections). 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 implicitly tells when to use: to check connection status, especially when all providers connected or credentials missing. However, it does not explicitly mention when not to use or alternatives like authenticate for performing authentication.

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 are minimal (readOnlyHint false, etc.), so the description carries the burden. It adds important behavioral context: 'invoke works even when the MCP is NOT installed' and 'Writes ... require workspace owner/admin.' It also explains return behaviors like connect/checkout links. 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 dense wall of text, though front-loaded with the main purpose. It uses arrows and semicolons but could be better structured with bullets. Every sentence adds information, but the length makes it harder to scan 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?

Given the tool's complexity (23 params, 14 actions, no output schema), the description covers the core flow, permissions, and prompt library, but leaves gaps: 'resume' action isn't explained, parameter-specific behavior is missing, and return formats for search/list_tools are not described. It is complete enough for basic use 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 coverage is 0% across 23 parameters, and the description only implicitly explains a few (e.g., tool_id via 'pick the right tool_id', action via the action list). It does not clarify key parameters like 'immediate', 'conversation', 'tier_slug', or 'cancel_reason'. The description does not compensate sufficiently for the schema's lack of coverage.

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

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

The description clearly states the tool is the marketplace catalog and executor: 'the in-platform catalog of every MCP/tool, AND the way to run them.' It details the core search→describe→invoke flow, making the purpose unambiguous. It also distinguishes from sibling openfinance tools by focusing on cross-MCP discovery and execution.

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 for actions: 'prefer invoke for a single/occasional use' and 'Use install only to make an MCP PERMANENT'. It also explains fallback links for credentials/payment. However, it doesn't explicitly name external alternatives or when not to use the marketplace itself, only internal action 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?

The description adds behavioral context beyond annotations: it explicitly states that data is deleted and will no longer be available, and that a reconnection URL is returned. This reinforces the destructiveHint annotation and provides useful details about the tool's effects.

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, each serving a distinct purpose: action, consequence, and return value. No redundant or filler words. Highly efficient and 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?

The description covers the core action and outcome but leaves a critical gap: the meaning of the 'item' parameter is not explained. Given the tool has only one required parameter and no output schema, the description should explicitly map 'item' to a bank identifier. This omission reduces completeness.

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

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

Schema coverage is 0%, and the description only says 'for a specific bank', weakly implying the 'item' parameter is a bank identifier. It does not specify what value the parameter expects (e.g., bank ID, connection ID), leaving ambiguity. The description fails to add sufficient meaning to the parameter.

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

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

The description clearly states the action 'Revokes the Open Finance consent for a specific bank and deletes the connection data', which is a specific verb-resource pair. It is distinct from sibling tools like openfinance_force_sync or openfinance_list_connections, as none other mention disconnecting a bank.

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 versus alternatives. It does not mention when not to use it, nor does it provide context for choosing among sibling tools. The usage context is implied but not stated.

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

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

Discloses critical behavioral details: waits up to ~60s, returns results with final status, handles errors like MFA_REINTERACTION with reconnect_url. It also explains the timed_out scenario and suggests a sibling tool. Annotations indicate read-only is false, consistent with a write operation. 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 detailed but each sentence adds value, covering usage, parameters, return values, error states, and alternatives. It is well-structured with examples and edge cases. A minor improvement would be to trim some redundant phrasing, but overall it is efficient.

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

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

Given no output schema and annotations providing limited behavioral info, the description is comprehensive. It covers the sync process, timeout behavior, return format (results/errors, status fields), error handling with reconnect_url, and fallback instructions. It fully enables correct agent 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 has 0% description coverage, but the description thoroughly explains both parameters: items can be selectors (item_id, connector_id, etc.) or omitted for all connections; wait defaults to true (implied by 'WAITS') and setting false makes it fire-and-forget. This fully 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 the tool forces a bank to re-sync connections and waits for completion. It distinguishes from sibling tools like openfinance_get_item_status by specifying that this tool triggers a sync, while the sibling is for re-checking status. The verb 'force sync' and the target 'connections' 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 states when to use ('when a balance or transaction list looks stale') and what it achieves ('pulls fresh data WITHOUT disconnecting/reconnecting'). It also provides guidance on alternatives: if sync times out, re-check with openfinance_get_item_status. Additionally, it explains optional parameters like omitting items to sync all and setting wait: false for 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?

Discloses important behavior beyond annotations: real-time vs degraded responses, warnings instead of errors for CREDIT accounts and upstream failures, and the 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?

Concise yet informative: 4 sentences covering endpoint, parameter, error handling, degradation, and response shape. No unnecessary words.

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

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

Covers main behavior, edge cases, and response structure. Lacks details on empty/invalid input handling, but sufficient for a simple read-only tool with clear error reporting.

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

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

Schema has 0% description coverage; description compensates by specifying 'account_ids' as an array (1-50) and implying these are account IDs from the system. Adds constraint and context.

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

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

Clearly states it returns real-time balance per account ID, with the specific endpoint '/accounts/:id/balance'. Distinguishes from siblings like 'openfinance_get_accounts_detail' and '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?

Describes when to use (to get balance), parameter constraints (1-50 account_ids), and error handling. Does not explicitly list alternatives or when not to use, but the context of sibling tools makes its purpose 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 declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context: batch shape {results, errors}, array size limit 1-50, and a provider_incident warning that certain values may be unreliable until recovery. This goes well 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 well-structured: purpose first, then batch shape, then caveat. It is slightly verbose due to the incident warning, 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 one parameter and no output schema, the description covers purpose, parameters, response shape, and special behavior. Missing authentication prerequisites, but overall sufficient for a read-only detail tool.

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

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

Schema coverage is 0%, so description carries the burden. It explains 'Pass account_ids as an array (1–50)', which adds meaning beyond the schema. It does not specify ID format but is sufficient for 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 with extended creditData per ID. It distinguishes from siblings like openfinance_list_accounts (list all) and openfinance_get_account_balance (single balance). The verb 'get' and resource 'accounts detail' 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 use when needing detailed account objects by ID, but does not explicitly state when not to use or mention alternatives. However, the context and sibling names suggest appropriate use cases.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds critical behavioral context: the batch shape {results, errors}, missing paid/status field in Pluggy, and the nuance that payments[] in Brazilian Open Finance represent the previous bill's payments, not necessarily this bill's payment status.

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

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

The description is dense with useful information and well front-loaded with the main purpose. Every sentence adds value, but it could be slightly more concise (e.g., combining some warnings). Overall it is well-structured and 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 simple input schema (one parameter) and no output schema, the description covers all necessary aspects: what the tool returns, what it does not return, how to use it, behavioral caveats (paid status, payment interpretation), and the batch response shape. It is sufficiently complete 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?

The only parameter bill_ids is an array of strings with 0% schema description coverage. The description adds minimal guidance to pass an array and use openfinance_list_credit_card_bills to discover IDs, but does not elaborate on ID format or constraints. While the parameter is simple, the description could provide more detail given 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 it returns bill-level detail for credit card bills by ID, listing specific fields like financeCharges and payments. It explicitly distinguishes itself from openfinance_list_transactions by stating what it does NOT return (individual 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 provides explicit guidance on when to use this tool (to get bill detail) and when to use alternatives (openfinance_list_transactions for itemized transactions). It also instructs to discover bill IDs first using openfinance_list_credit_card_bills and warns against reconstructing totals from 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 already indicate read-only and idempotent. The description adds valuable behavioral details: the returned data includes status types, executionStatus, connector metadata, reconnect_url, and the ability to get all banks vs single. It also explains bulk support. 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 two sentences covering multiple aspects efficiently. It is front-loaded with the main purpose. Could be slightly more structured (e.g., separate bullet for bulk support) 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?

The description covers the return data (status, executionStatus, metadata, reconnect_url), the two modes (single/all), and bulk support. No output schema exists, so the agent relies on the description to understand the response. Error handling and edge cases are not mentioned, but the core functionality is well-documented.

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

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

Input schema has three parameters (item, item_id, item_ids) with zero description coverage. The description explains the role of 'item' and 'item_ids' but does not mention 'item_id'. Thus, it partially compensates for the schema gap but is incomplete.

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

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

The description clearly states the tool returns the current status of a bank connection, listing possible statuses, executionStatus, metadata, and reconnect_url. It distinguishes from siblings by specifying behavior for single item vs all banks, and bulk support. The verb 'get' and resource 'item status' 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 clear context for usage: omit 'item' for all banks, pass 'item' for single, and 'item_ids' for bulk. It implies when to use this tool (check status) but does not explicitly compare to alternatives like list_connections. However, the context is sufficient for an agent to infer appropriate use.

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

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

Annotations already declare read-only and idempotent, so description credit is for adding the batch processing behavior, the specific fields returned, and the array input constraint. 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 paragraph that front-loads the main purpose, then lists return fields, then usage guidance, parameter detail, and response shape. Every sentence adds value; no wasted words.

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

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

For a simple read-only tool with one parameter and no output schema, the description fully covers the return fields, usage pattern, input constraints, and response format. 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?

Schema coverage is 0%, but description compensates by describing the single parameter loan_ids as an array with length limit 1-50 and the batch response shape. This adds 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?

Description clearly states it returns full loan contract detail by ID using GET /loans/:loanId. It lists specific fields returned, and distinguishes itself from the sibling tool openfinance_list_loans by advising to use it after listing loans for a deep-dive.

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?

Explicit guidance to use after openfinance_list_loans for deep-diving on a specific contract. Also mentions batch limit of 1-50 loan_ids and the batch shape { results, errors }. No exclusion criteria provided, 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?

Adds significant context beyond annotations: explains connector-dependent balance meaning, provider_incident blocks affecting reliability, identity_notice requiring deduplication, and bulk support. Annotations already indicate read-only and idempotent nature, and description does not contradict.

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 lengthy (~300 words) but well-structured with sections for core functionality, usage patterns, warnings, and bulk support. All information is valuable given tool complexity, though could be slightly more concise.

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

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

Comprehensive coverage of main use cases, edge cases (provider_incident, identity_notice), and response fields (bank, connector_id, creditData details). Without output schema, description adequately describes return structure. Missing note on no required parameters is minor and covered by 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, description compensates by explaining usage patterns for item, type, and item_ids. However, it doesn't fully differentiate between item and item_id, which could cause confusion. Overall, it provides sufficient context for an AI agent to use parameters correctly.

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 accounts for bank connections with detailed fields, distinguishes between listing all accounts (omit item) and targeting a specific bank (pass item). Differentiated from sibling tools like openfinance_get_account_balance and 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 use each parameter (omit item for 'my accounts/cards', pass item for specific bank), recommends alternative tool for standardized bill amounts, and warns about connector-dependent behavior of credit card balance.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral details: it is cached for the adapter session, returns a single aggregated response, and has no batch IDs. This fully informs the agent of the tool's behavior 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?

The description is two sentences: the first front-loads the main purpose and source, the second details the returned fields and usage hint. Every sentence adds value, with no redundancy or waste.

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?

Considering the tool has no parameters and no output schema, the description covers the source, caching, field list, and usage guidance. It is largely complete, though a brief mention of the return format (array of objects) would be ideal for full completeness.

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

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

The tool has zero parameters, and the schema coverage is 100%. The description adds no parameter details since none exist, achieving the baseline. It does not need to compensate further.

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 from Pluggy, explicitly mentioning it provides the category IDs used by the sibling tool openfinance_update_transaction_category. It fully distinguishes itself from other listing tools by specifying its unique data and purpose.

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

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

The description gives language preference guidance ('prefer this for pt-BR users') and implies the tool is for retrieving reference data to categorize transactions. However, it does not explicitly state when not to use this tool or mention alternatives, though no direct alternative exists among siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral details about the reconnect_url behavior and the nature of the return data, which goes beyond annotations. No contradictions.

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

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

The description is informative but slightly verbose. It front-loads the purpose and return fields, then explains the reconnect_url. Could be trimmed slightly without losing 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 and no parameters, the description adequately explains what the tool returns and the key behaviors. It lacks mention of pagination or limits, but for a simple list tool, it is fairly 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?

The input schema has no parameters, so baseline is 4. The description does not need to add parameter semantics, and it correctly omits any param info.

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 saved bank connections with specific fields (connector_id, item_id, bank name, reconnect_url, add_connection_url). It distinguishes itself from sibling tools by focusing on listing connections, which no other sibling does.

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 guidance on when to use reconnect_url (re-authentication, MFA, LOGIN_ERROR, stale data) and what it does not do (doesn't consume connection slot, doesn't require disconnecting). It could be more explicit about when to use this tool over alternatives, but given no direct sibling for listing connections, it's 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?

Discloses complex derivation of payment_status, bill-to-payment mapping, connector asymmetry, and bill_grouping_reliability warnings. Adds behavioral context beyond annotations (readOnlyHint, idempotentHint) by explaining edge cases and limitations.

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 very long and dense, with multiple sections. While comprehensive, it could be more concise. However, the complexity of the tool justifies some 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?

Given the complexity (5 parameters, no output schema), the description is exhaustive: covers return fields, derived statuses, open_bill feature, connector asymmetry, warnings, and cross-references to sibling tools.

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?

Explains account_id, account_ids, and include_open_bill in detail, adding meaning beyond the schema. However, page and page_size are not described, leaving a minor gap despite self-explanatory names.

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 CLOSED credit card bills for CREDIT-type accounts, listing specific fields. It distinguishes from siblings like openfinance_list_transactions and openfinance_get_credit_card_bill by specifying it provides bill-level summaries.

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

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

Provides explicit guidance on when to use include_open_bill (opt-in), warns against common misinterpretations (e.g., not assuming payment based on payments array), and advises to use openfinance_list_transactions for itemized charges.

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 goes beyond annotations by detailing error handling (returns instead of throwing on 403), data integrity warnings for mass zeroing and suspect_zeroed rows, and bulk support. No contradiction with annotations (readOnlyHint, etc.).

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

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

The description is front-loaded with the main purpose, but the data integrity section is lengthy. Overall, it is reasonably concise for the complexity, though some sentences could be streamlined.

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 error handling and edge cases well, but lacks parameter documentation and does not describe the output format beyond mentioning total, results, warning. Given no output schema and 6 parameters, this is a notable gap.

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

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

With 0% schema description coverage, the description only adds a brief mention of 'item_ids for batched execution'. Other parameters (item, page, type, page_size) are not explained, leaving the agent with minimal 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 it returns the investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, fixed income, etc.) and mentions bulk support. This is a specific verb+resource that distinguishes it from siblings like openfinance_list_investment_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?

Usage is implied by the description (to get investment portfolio), but no explicit guidance on when to use it vs alternatives (e.g., investment transactions) or when not to use it 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 provide readOnlyHint and idempotentHint; description adds detail on returned fields (quantity, value, expenses, etc.). No contradictions, but no mention of pagination behavior despite page parameters.

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 short, front-loaded paragraphs with no wasted words. Efficiently presents key 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?

Good coverage of return fields despite missing output schema, but pagination parameters are unexplained. Lacks error handling or rate limit info. Adequate but not exhaustive.

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%. Description mentions investment_id as required and investment_ids for bulk, but does not explain page and page_size parameters. Adds some meaning but leaves significant gaps.

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

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

The description clearly states the verb 'Returns' and the resource 'movement history for a specific investment position', listing specific transaction types. It distinguishes from siblings by referencing 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?

Explicitly says to use after openfinance_list_investments to get investment_id, and mentions bulk support. Does not explicitly state when not to use or name alternatives, but provides clear context.

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

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

Annotations already declare read-only and idempotent behavior. Description adds useful details: sequential per-connection fetching with rate-limit spacing, and return format { results, errors } per connection.

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 no waste. Front-loaded purpose, then parameter usage, then return format. Every sentence adds essential 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?

Covers purpose, parameter usage, return format, and rate-limiting behavior. Lacks error case details (e.g., invalid selectors), but given the simple schema and annotations, it is largely sufficient.

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

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

Schema has no description for the only parameter (0% coverage). Description fully compensates by explaining items expects an array of connection selectors (item_id, connector_id, connector_name), one per connection, and that omitting fetches all.

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

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

The description explicitly states the tool lists loan contracts per bank connection, includes the endpoint (GET /loans), and differs from sibling tools like openfinance_get_loan_detail (which gets a single loan).

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 pass 'items' (for specific connections) and when to omit (list all). Mentions sequential querying with rate-limit spacing. However, doesn't explicitly compare to alternatives like openfinance_get_loan_detail.

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 (readOnly, idempotent, non-destructive), the description extensively details behavioral traits: per-connector variations in credit card pending/posted status, pagination auto-pagination behavior, error return format, detail level impacts, provider incident blocks, and the need to cross-check account echo. 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?

Though lengthy, every sentence adds value. Well-structured with clear sections on credit card behavior, pagination, detail levels, and cross-tool references. No superfluous content.

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 8 parameters, no output schema, and many siblings, the description is exceptionally thorough: covers input, behavior, edge cases, error handling, and referrals to other tools. Provides actionable guidance for a complex API.

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 compensates: explains each parameter (account_id required, from/to ISO format, search_queries case-insensitive substring match, page/page_size modes, detail enum options, account_ids for bulk). Adds meaning beyond raw schema types.

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

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

The description clearly states it returns transactions for a bank account (BANK or CREDIT type), distinguishing its purpose from siblings like openfinance_list_credit_card_bills. It explicitly covers credit card itemized transactions and contrasts with bill 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: for CREDIT accounts it's the only way to get itemized transactions; warns against reconstructing bill totals using billId; directs users to openfinance_list_credit_card_bills for standardized totals and to openfinance_list_accounts for closing/due dates; explains when to use auto vs manual pagination and detail levels.

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 it as read-only, idempotent, non-destructive. The description adds critical behavioral traits: truncation at 5000/account with truncated:true flag, provider_incident block for affected banks, and bulk support via item_ids. 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 front-loaded with core purpose and then details options. It is quite long but justified by the tool's complexity (9 params). Some redundancy could be trimmed, but structure is logical and 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 the tool's complexity, no output schema, and 0% schema coverage, the description provides full context: return format (compact summary fields like total entradas, saídas, por_mes), error conditions (provider incident), truncation, batch support. It equips an agent to use the tool correctly and interpret results.

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

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

Schema description coverage is 0%, so the description fully compensates. It explains each parameter: item accepts connector_id/name or item_id; from/to as ISO dates; granularity options (monthly vs raw) with their consequences; detail options (compact/rich/raw); type filter; top_n; and item_ids for batch. The description adds meaning well 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 provides 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call.' It specifies the resource (bank connection) and action (analysis with fan-out), and distinguishes from siblings by noting it avoids needing to call openfinance_list_accounts first.

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

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

Explicitly says when to use this tool vs alternatives: 'you do NOT need to call openfinance_list_accounts first nor carry account_id uuids between calls.' Provides usage examples like 'análise anual/mensal' and explains how to target one bank or all. Also explains granularity and detail options, giving clear context for invocation.

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. The description adds value by explaining it checks a public status page, returns a global indicator, degraded components, open incidents, and flags affecting user's banks, providing behavioral context beyond annotations.

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

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

Description is front-loaded with the primary purpose, and each sentence adds value (purpose, usage guidance, return details). While somewhat long, it is efficient for 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?

For a zero-parameter tool with annotations, the description is fairly complete: it explains when to use it, what it returns, and differentiates from siblings. However, it lacks explicit return format details, but overall adequate.

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

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

No parameters exist, so description doesn't need to add param info. Schema coverage is 100% trivially. Baseline for 0 params is 4, and description adds return value context.

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

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

The description clearly states the tool checks the LIVE operational status of the Open Finance provider's health, distinguishing it from the sibling tool openfinance_get_item_status which checks the user's own connection.

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

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

Provides explicit guidance on when to use this tool (when data looks incomplete/stale despite updated connection) and how it helps differentiate provider-side problems from connection issues, explicitly naming the alternative 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?

Beyond annotations (readOnlyHint, idempotentHint), the description adds context about plan handling (PF vs PJ), caveat warnings for credential connectors, and the fact that keywords are required. 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 comprehensive but slightly verbose. Every sentence adds value, though it could be tightened without losing information. Still well-structured and front-loaded with key action.

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

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

Given no output schema, the description thoroughly covers return fields (id, access, audience, connections, accounts, connect_url) and edge cases (missing keywords, caveat, plan handling). Sufficient for correct invocation.

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

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

With 0% schema coverage, the description fully explains both parameters: keywords (array of strings, required for search) and include_accounts (boolean). Adds 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 searches bank connectors by name and returns specific fields including a connect URL. It distinguishes from siblings like 'connect' by explicitly saying 'Call this BEFORE connecting.'

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 when-to-use guidance ('Call this BEFORE connecting'), explains behavior when keywords are missing, and advises preferring Open Finance connectors due to caveats. Effectively differentiates from 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 goes well beyond annotations by disclosing that recategorizing automatically creates a Category Rule (teaching Pluggy), that per-item errors do not fail the batch, and the exact response shape. This provides deep behavioral insight essential for correct invocation.

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 but packs all necessary information without redundancy. It is front-loaded with the core action. Slightly verbose in explaining side effects, but every sentence earns its place for the depth of context provided.

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

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

Given the complexity (batch update with side effects and error handling), the description covers input structure, response format, and behavioral implications. No output schema exists, so the description adequately compensates. An agent has sufficient information to use 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 coverage is 0%, but the description explains the items parameter as an array of objects with transaction_id and category_id, and crucially tells the agent where to obtain these IDs (from list_transactions and list_categories). This adds essential semantic 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 via PATCH /transactions/:id, specifies input structure (items array with transaction_id and category_id), and distinguishes from sibling tools by explaining the source of IDs and the side effect of creating category rules, 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 explicitly says to 'use this to fix miscategorized transactions and improve categorization accuracy going forward,' providing clear context. It does not mention when not to use or alternatives, but the usage scenario is well-defined.

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

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

Description advises including conversation data for reproduction, adding behavioral context beyond annotations. However, it doesn't disclose potential side effects or confirmation of submission. Annotations already mark it as idempotent and non-destructive.

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

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

Two sentences, front-loaded with purpose and essential usage instruction. No extraneous 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 3-parameter tool with no output schema, the description covers the main purpose and one key parameter. The 'context' parameter is left undocumented, slightly reducing completeness.

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

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

With 0% schema parameter descriptions, the description partially compensates by explaining the 'conversation' parameter. 'message' is implied as the main content, but 'context' remains unexplained. Added value is moderate.

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, using specific verbs and resources. It distinguishes from siblings, none of which serve this purpose.

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

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

No explicit when-to-use or alternatives are provided, but the purpose is implied by the tool name and description. Since no sibling tool overlaps, specific exclusions are less critical.

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

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

Description adds context beyond annotations by specifying what versions are shown (platform and adapter). Annotations already indicate read-only, idempotent, and non-destructive behavior, so the description provides additional value without contradicting.

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, no filler, front-loaded with the action and subject. Every word is 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?

For a simple, parameterless, safe tool with clear annotations, the description is complete. No output schema is needed for version display.

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

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

No parameters exist, and schema coverage is 100%. Baseline for zero-parameter tools is 4, and the description does not need to add parameter information.

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 'Show' and the resource 'current MCP platform and adapter versions'. This is specific and distinct from all sibling tools, which focus on authentication, OpenFinance operations, or bug reporting.

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

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

No guidance on when to use this tool versus alternatives. For example, 'toolkit_info' might also provide version information, but no differentiation is 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by specifying what the state includes, but it does not discuss potential edge cases like empty accounts or connection status nuances. With annotations providing the safety context, a score of 3 is appropriate.

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 that uses a specific verb ('Returns') and lists the exact contents of the response. Every word earns its place with no redundancy, making it highly 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 that the tool has no parameters and no output schema, the description carries the full burden of explaining return values. It lists all major categories of information (installed MCPs, connection status, accounts, catalog tool counts), making it complete for an agent to understand what it will receive.

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 the schema description coverage is trivially 100%. No parameter documentation is needed, and the baseline for zero-parameter tools is 4. The description does not need to add anything for parameters.

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

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

The description clearly states the tool returns the current toolkit state, enumerating specific data elements: installed MCPs, connection status, connected accounts, and catalog tool counts. This distinguishes it from sibling tools like show_version or marketplace, 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 clearly implies when to use this tool (to get a snapshot of the toolkit state), but does not explicitly name alternatives or exclusions. Since no sibling provides the same aggregated state, the context is sufficient for an agent to select it appropriately.

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