Banco MCP

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

The description transparently discloses behavioral details: it can be called with no args to get a login link, or with a token for session login. Annotations indicate idempotentHint=true, which aligns with the description's mention of non-expiring config. No contradictions, and the description adds context beyond annotations about the login flow and token usage.

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 packs multiple use cases into one paragraph. It is front-loaded with the tool's purpose and authentication methods. Every sentence adds value, but a slightly more structured layout could improve readability without losing detail.

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

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

Given the simple parameter and no output schema, the description covers the authentication process well: two login methods, token usage, and a persistent alternative. It does not describe the return value, but for an authentication tool the main concern is side effects. Overall, adequately complete for effective agent decision-making.

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 the sole optional 'token' parameter: it is a JWT from browser login, used for session-only login. This adds essential meaning beyond the schema's bare type definition, though it could be more precise about the expected format.

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

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

The description clearly states the tool is for authentication, with explicit instructions for two distinct methods: permanent config and session-based token. It differentiates from sibling tools by being the sole authentication tool, and the verb 'authenticate' plus detailed explanation leaves no ambiguity.

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

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

The description provides clear guidance on when to use each authentication method (permanent via config vs session via token) and what to do with the generated link. It lacks explicit 'when not to use' caveats, but the context is sufficiently clear for correct 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 readOnly, idempotent, not destructive. Description adds valuable behavioral context: different return outputs based on connection state, without contradicting annotations.

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

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

Two concise sentences front-loaded with purpose, followed by scenario details. No wasted words.

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

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

No output schema exists, so description must explain return values. It covers all relevant states (connected vs missing credentials) with sufficient detail for a simple status tool.

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

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

No parameters, so baseline is 4. Description adds nothing beyond schema but this is acceptable as there are no parameters to document.

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 connection status and URLs, distinguishing two scenarios (all connected vs missing credentials). Differentiates from siblings like 'authenticate' by focusing on status 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?

Implied usage for checking connection status but no explicit guidance on when to use vs alternatives or when not to use. Lacks explicit context for selection among sibling 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 adds substantial behavioral context beyond annotations: invoke works without installation, returns connect/checkout links for auth/payment, install makes permanent, writes require owner/admin, etc. It explains core flow and flagging of installation status. No contradiction with annotations (readOnlyHint=false, destructiveHint=false) as writes are not explicitly 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?

The description is lengthy and dense, mixing high-level purpose with operational details. It front-loads well but then becomes a stream of details without clear structure. While informative, it could be more concise and organized for easier parsing.

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 (15 parameters, complex flow, no output schema), the description lacks details on return values and most parameter semantics. It covers the overall behavior but leaves significant gaps that hinder full understanding 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 must compensate, but it only briefly mentions a few parameters (action, tool_id, arguments) in the context of the flow. Most of the 15 parameters (e.g., conversation, request_name, cancel_reason) are not described, leaving the agent to infer their purpose. The value added is partial.

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 defines the tool as the official MCP marketplace for discovering and running MCPs/tools. It specifies the core flow (search, describe, invoke, install) and distinguishes it from external registries. The verb 'marketplace' is specific, and the purpose is well explained, differentiating it from sibling openfinance 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 explicitly states to use this tool first before external registries, and provides guidance on when to use invoke vs install (prefer invoke for occasional use). It also mentions list_tools for currently callable tools. However, it does not directly compare to sibling tools like report_bug, but given the distinct domain, 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 destructiveHint=true; description adds that consent is revoked, data deleted, and no longer available. Also mentions return of re-connect URL. No contradiction.

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

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

Three concise sentences with core action upfront, no unnecessary words. Front-loads the primary effect.

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

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

Adequate for a simple destructive tool, but missing parameter clarification. No output schema, but description covers return value. Lacks detail on parameter semantics.

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

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

Single parameter 'item' has 0% schema description coverage. Description implies it identifies a bank but doesn't specify format (e.g., ID, name). Agent needs to infer from 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 revokes consent and deletes connection data for a specific bank. Distinct from sibling tools like list_connections or get_item_status. Verb and resource 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?

Implies usage when disconnecting a bank, but lacks explicit when-not-to-use or alternatives. Mentions re-connect URL but no guidance on selecting this over other tools.

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

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

Annotations are minimal (readOnlyHint=false, destructiveHint=false). The description adds critical behavioral context: polling up to 60s, return fields (status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out), and actions on specific statuses. 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 somewhat lengthy but well-structured and front-loaded with the core action. Every sentence adds value, but could be slightly trimmed without losing meaning. Still very 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 thoroughly covers return fields, error conditions, and follow-up steps. It lacks details on error handling for invalid items or permissions, but overall it is sufficiently complete for a sync 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 no descriptions (0% coverage). The description fully explains both parameters: items can be item_id, connector_id, connector_name, or omitted for all; wait=false gives fire-and-forget. 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 action (forces re-sync and waits), the resource (one or more connections), and distinguishes from alternatives by emphasizing 'fresh data without reconnecting.' It specifies when to use (stale balance/transaction list) and the exact mechanism (PATCH then poll).

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 ('balance or transaction list looks stale'), when-not-to (not needed for fresh data), and alternatives (re-check with openfinance_get_item_status). It also explains optional behavior (set wait: false for fire-and-forget) and distinguishes from other tools.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds rich behavioral context: CREDIT account error handling with warnings, degradation to last-synced balance with realtime:false for upstream failures or non-Open Finance connectors, and response shape. This significantly exceeds annotation-only information.

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, front-loaded with main purpose, each sentence adds unique value (error handling, degradation, response format). 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 only 1 parameter and no output schema, the description comprehensively covers behavior, error states, and response shape. Edge cases (CREDIT errors, upstream failures) are clearly 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 1 parameter with 0% coverage. Description compensates by specifying the array (1–50) and purpose ('per account id'), adding meaning beyond the schema type alone.

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

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

The description clearly states it returns real-time balance per account id, with specific verb 'Returns' and resource 'GET /accounts/:id/balance'. It distinguishes from sibling tools like list accounts by focusing on balance retrieval.

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

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

Provides explicit guideline to pass account_ids as an array of 1–50. However, it does not contrast with sibling tools like openfinance_get_accounts_detail or openfinance_list_accounts, leaving some ambiguity on when to use this tool over 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?

Beyond annotations (readOnly, idempotent), the description reveals batch results/errors shape and provider_incident block causing unreliable values, advising not to present them as real. 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 concise, front-loading the core functionality in the first sentence, and adds essential caveats without superfluous information.

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

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

Given no output schema and a single parameter with 0% coverage, the description covers the batch shape and a notable edge case (provider_incident), but does not fully describe the returned account object structure or error handling beyond the errors array.

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

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

With 0% schema coverage, the description explains the account_ids parameter as an array of strings with size 1-50, and notes the batch shape. It does not elaborate on valid account ID formats or other implicit constraints, 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 full account objects including extended creditData per ID, and specifies the batch shape. It differentiates from sibling tools like list_accounts by focusing on detail retrieval per ID.

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 usage guidance on passing account_ids as an array of 1-50, and warns about provider_incident scenarios. However, does not explicitly state when to use this tool over alternatives or provide when-not conditions.

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: warns about pluggy not returning a paid/status field, explains that payments[] may reflect previous bill payment, and mentions the batch shape { results, errors }. 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 and well-structured with clear sections, but slightly verbose. Every sentence adds value, but could be more concise without losing 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?

Very complete given the complexity: covers what the tool returns, what it doesn't, caveats about payments and billId, and references sibling tools. No output schema, but the description partially explains the return fields.

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

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

Only one parameter (bill_ids) with 0% schema description coverage, but the description fully explains it must be an array and how to obtain the ids via list_credit_card_bills, adding meaning beyond the schema.

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

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

The description clearly states it returns bill-level detail for credit card bills by id, and explicitly distinguishes it from openfinance_list_transactions which returns individual transactions. It also mentions what it does not return, making the purpose very 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?

Provides explicit when-to-use (get bill detail), when-not-to-use (for transactions), and alternatives (openfinance_list_transactions for itemized transactions). Also instructs to first use openfinance_list_credit_card_bills to discover ids.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds behavioral details: returns specific fields (status, executionStatus, connector metadata) and explains the return shape for both usage patterns. No contradictions.

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

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

Two sentences with no wasted words. The purpose is front-loaded, and the parameter behavior is clearly separated. 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 simplicity (1 optional parameter, no output schema), the description covers usage and return shape sufficiently. It doesn't explain error states or field types beyond the listed statuses, but that is acceptable for a read-only status tool.

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

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

The input schema has 0% description coverage, so the description fully compensates. It explains that omitting 'item' returns all banks with { count, items }, while providing it returns a single bank's status. 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 it returns the current status of a bank connection, listing possible values and included fields. It distinguishes behavior based on the 'item' parameter and contrasts with sibling tools like openfinance_list_connections which likely list connections rather than status.

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

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

The description provides explicit guidance on how to use the 'item' parameter: omit for all banks, pass for a single bank. It does not explicitly state when not to use or name alternatives, but the context is clear and differentiated from 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 and idempotentHint=true, so the description adds value by noting it's a GET endpoint and describing the batch response shape { results, errors }. It does not contradict annotations and provides additional behavioral context beyond what the structured fields offer.

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, efficient sentence front-loaded with the main action, followed by field details, usage guidance, and parameter specification. No wasted words, though it is dense. Structure is logical and easy to parse.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers purpose, usage sequence, parameter constraints, and response shape. It lacks error handling details but the batch shape implies error information. It is sufficient for an agent to understand and invoke correctly.

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

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

The description adds meaning to the only parameter: 'Pass loan_ids as an array (1-50)'. This specifies the type, cardinality constraint, and intent, which are not present in the input schema (0% coverage). It assumes the IDs come from list_loans, which is clear 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 it returns full loan contract details by ID, listing many fields. It explicitly distinguishes itself from the sibling openfinance_list_loans by positioning itself as a deep-dive after listing. The verb 'Returns' and resource 'loan detail by id' are specific and unambiguous.

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

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

The description explicitly says to use this tool after openfinance_list_loans, providing sequential usage context. It also specifies input constraints: loan_ids as an array of 1-50 strings. However, it does not mention when not to use it or provide alternative methods.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context: the credit card balance meaning varies by connector, the 'name' field is not the brand, and the presence of a provider_incident block may indicate unreliable data. This goes beyond the annotations to help the agent understand nuances.

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 densely packed with valuable information and is well-structured, starting with the core function then adding usage guidelines and warnings. It is slightly verbose but each sentence contributes meaning, so 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?

Given no output schema, the description explains many return fields (balance, number, type, subtype, bankData, creditData, bank, connector_id, item_id) and covers edge cases like provider incidents. However, it does not explicitly describe the response as a list or mention pagination/limits, which are minor omissions for a 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?

Schema description coverage is 0%, so the description must fully explain parameters. It explains the 'item' parameter well (omit vs pass) and mentions BANK/CREDIT types in the return context. However, it does not explicitly state that the 'type' parameter is used to filter results to only BANK or CREDIT accounts, leaving a gap in meaning.

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 accounts for a bank connection, listing types (BANK, CREDIT) and various data fields. It distinguishes from siblings like openfinance_list_credit_card_bills and openfinance_get_account_balance by specifying what this tool does differently, such as listing all accounts or filtering by item.

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' (list all accounts) vs when to pass 'item' (target a single bank). Also warns about the credit card balance being connector-dependent and directs to openfinance_list_credit_card_bills for standardized billing, providing clear when-not-to-use guidance.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description adds valuable behavioral insight: the result is cached for the adapter session, the response is a single aggregated set (no batch ids), and it details the structure of each entry. 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 concise, front-loads the main purpose, and every sentence adds necessary detail: caching, field descriptions, usage hint, and response behavior. No extraneous 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 no parameters, no output schema, and clear annotations, the description provides sufficient context for an agent. It explains what the tool returns, the structure, and a usage hint for a related tool. No gaps identified.

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 no parameters, and the schema coverage is 100%. The description adds meaning by explaining the output fields and how to use the categoryId, which helps an agent understand the tool's output even though the input schema is empty.

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 transaction category taxonomy from Pluggy, using a specific endpoint and caching. It lists the fields and differentiates from sibling list tools that return accounts or transactions rather than categories.

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 hints at usage by mentioning that the categoryId is used by openfinance_update_transaction_category, but it does not explicitly state when to use or not use this tool versus alternatives. The context is clear enough for an 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds specific return fields, but no additional behavioral context like rate limits or error conditions. 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 concise sentence with key action and return details front-loaded. 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 no output schema and no parameters, the description fully explains what the tool returns and includes the important add_connection_url field. Adequate for a simple list operation.

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 (0), so baseline 4. Schema coverage is 100% by default, and description adds no param info because none exist.

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

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

Clearly states it returns saved bank connections with specific fields (connector_id, item_id, bank name, add_connection_url). Distinguishes from sibling tools like openfinance_disconnect_bank 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?

Implied usage via name and description, but no explicit guidance on when to use vs alternatives (e.g., openfinance_list_accounts) or when not to use.

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

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

Annotations declare it's a read-only, idempotent tool. The description adds rich behavioral context: derived payment_status logic, cross-bill payment matching, open bill availability conditions, and warnings for unreconciled data. 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 very long (600+ words) and verbose, containing repetitive explanations. While well-structured with sections, it could be significantly trimmed without losing 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?

Given no output schema, the description thoroughly documents returned fields (payments[], payment_status, open_bill structure), behaviors (connector asymmetry, reliability warnings), and edge cases. Covers all critical aspects for correct usage.

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

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

Schema description coverage is 0%. The description explains include_open_bill in detail and implies account_id usage, but does not describe page, page_size, or account_ids (though account_ids is mentioned in 'bulk support'). Only 2 of 5 parameters get meaningful explanation.

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

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

The description clearly states it returns 'CLOSED credit card bills for a CREDIT-type account' and details the fields. It distinguishes from siblings like openfinance_get_credit_card_bill (single bill) and openfinance_list_transactions (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?

Provides extensive guidance on when to use this tool vs alternatives (e.g., use openfinance_list_transactions for itemized purchases), how to interpret payment_status, when to trust totalAmount over billId grouping, and connector asymmetry. Explicitly warns against common misinterpretations.

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, idempotentHint, and non-destructive. Description adds value by detailing return fields (balance, amount, rates, dueDate, issuer, ISIN) and error handling pattern, which 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?

Description is information-dense, front-loaded with purpose, then lists types and output fields. No redundant sentences, though it could be more 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?

With no output schema, description covers return structure partially (lists many fields and error response). However, does not document pagination parameters or behavior, nor all possible fields. Adequate but not fully complete for a tool with 4 params.

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

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

Schema description coverage is 0% and the description does not explain any of the 4 parameters (item, page, type, page_size). It only indirectly mentions type enum values. This fails to compensate for missing 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?

Description explicitly states the tool returns the investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.). It clearly distinguishes from sibling tools focused on accounts or transactions by specifying the resource (portfolio) and action (list).

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?

Indicates it should be used for connections with INVESTMENTS product enabled and describes graceful error handling when the product is not enabled (returns warning instead of throwing). However, lacks explicit comparison to alternatives like openfinance_list_investment_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 declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to reiterate safety. It adds value by listing the types of transactions returned (BUY/SELL/TAX etc.) and key fields (expenses breakdown), which go beyond the annotation scope. No contradictions.

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

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

The description is relatively concise, with two main sentences plus additional guidance. It front-loads the purpose and key details. However, the structure could be improved by separating the parameter list and usage note more clearly, 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 the parameter count (4), no output schema, and annotations present, the description covers the core purpose and highlights the investment_id parameter and bulk support. However, it omits details on pagination (page, page_size) and does not describe the return format or limit explanations. It is adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explicitly mentions investment_id and investment_ids for bulk support, adding meaning to those parameters. However, page and page_size parameters are not described, leaving their semantics unclear. The description partially compensates but misses two 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 returns movement history for a specific investment position, listing transaction types (BUY/SELL/TAX etc.) and fields (quantity, value, netAmount, expenses). It distinguishes from sibling tools by explicitly referencing openfinance_list_investments as a prerequisite, differentiating from other listing 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 guidance to use after openfinance_list_investments to obtain investment_id. It also mentions bulk support via investment_ids. However, it does not explicitly state when not to use this tool or list specific alternatives, though sibling context provides implicit differentiation.

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 safe behavior. The description adds behavioral details such as sequential processing with rate-limit spacing and the return format `{ results, errors }` per connection, which 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 concise, using three sentences to convey purpose, parameter usage, and return format. It is front-loaded with the main action and contains no extraneous information.

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

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

Given the tool has only one optional parameter and no output schema, the description covers usage, return structure, and behavioral context. The annotations further fill in safety traits. It is adequately complete for an agent to select and invoke the tool correctly.

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

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

The schema only defines `items` as an array of strings with no description. The description compensates by specifying that each string is a connection selector of type item_id uuid, connector_id, or connector_name. This adds significant 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 lists loan contracts per bank connection via GET /loans. It identifies the resource and action, and while it does not explicitly differentiate from sibling list tools, the specific mention of loans makes the purpose clear.

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

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

The description provides explicit guidance on using the `items` parameter to select specific connections or omitting it for all connections. It also explains the sequential querying with rate-limit spacing, which informs usage behavior.

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 readOnly and idempotent hints. Description adds extensive behavioral details: per-connector variation in credit card metadata, auto-pagination with 5000 cap, error handling returning structured errors, detail levels, provider incidents, and warnings about not summing by billId. 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?

Description is long but well-structured with clear sections. Every sentence adds value; slight verbosity is justified given tool complexity. Front-loaded with primary purpose and key caveats.

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

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

Covers all relevant aspects: CREDIT vs BANK differences, pagination, error handling, detail levels, provider incidents, bulk execution, and connection health checks. No output schema but hints at response structure are 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 0% description coverage, but description fully compensates by explaining each parameter: from/to as ISO dates, page behavior, page_size max, detail levels with use cases, search_queries semantics, and bulk support via account_ids.

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 transactions for bank or credit accounts, and distinguishes from siblings like openfinance_list_credit_card_bills and openfinance_list_transactions_by_item, avoiding ambiguity.

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

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

Provides explicit guidance on when to use this tool versus alternatives (e.g., for bill totals use openfinance_list_credit_card_bills, for closing dates use openfinance_list_accounts, for connection health use openfinance_get_item_status).

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses critical behaviors: internal account resolution, 5000/account scan cap with truncation flag, provider_incident block when Open Finance provider has open incident affecting totals. These go well beyond annotations and inform the agent of potential data quality issues.

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: first sentence states purpose, followed by how it works, parameter details, and caveats. Every sentence adds value. It could be slightly more concise, but the detail is necessary given the tool's 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 thoroughly explains return fields (totals, monthly evolution, top expenses, per-account breakdown, transaction rows with optional enrichment). It also covers edge cases like provider incidents and truncation. Complete for the tool's functionality.

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 fully compensates. It explains 'item' (connector_id, connector_name, or item_id), 'from'/'to' (ISO dates), 'granularity' (monthly summary vs raw rows), 'detail' (compact, rich, raw with enrichment details), 'type' (BANK or CREDIT), and 'top_n' (implicitly as N for top expenses). Every parameter is meaningfully described.

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

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

The description clearly states it provides consolidated cash-flow analysis for a whole bank connection, resolving accounts internally. It distinguishes itself from sibling tools like openfinance_list_accounts (no need to call separately) and gives specific use cases (annual/monthly analysis, cash flow). The verb 'list' with the context of cash-flow analysis makes the purpose unmistakable.

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

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

The description gives explicit usage scenarios (use for 'análise anual/mensal', etc.), explains when to omit 'item' (all banks), and mentions granularity options for raw data. It does not explicitly state when NOT to use or provide alternatives like openfinance_list_transactions, but the context strongly implies the 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, idempotentHint, destructiveHint=false. The description adds value by detailing the return fields (global indicator, degraded components, open incidents, your_banks_affected), providing beyond-annotation 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?

Every sentence serves a purpose: purpose, usage scenario, output details. No wasted words, well-structured with front-loaded key info.

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

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

Given zero parameters and no output schema, the description covers all necessary aspects: what it does, when to use, what it returns. Completely sufficient for an agent to select and invoke correctly.

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

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

No parameters exist, and schema coverage is 100%. The description explains the output meaning comprehensively, which adds value for an agent. Baseline for 0 params is 4, and the description meets that.

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

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

The description clearly states the tool checks the LIVE operational status of the Open Finance provider, distinguishing it from openfinance_get_item_status. It specifies the resource (provider status) and the verb (checks).

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 data looks incomplete or stale despite updated connections. Differentiates from reconnecting connections and provides clear context for diagnosing upstream outages.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable context: non-Open-Finance connectors have a caveat about manual reconnection, and results are filtered by the user's plan. This goes beyond annotations 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 detailed but every sentence adds value. It is front-loaded with the main purpose and specific return fields. A minor redundancy is the repeated emphasis on calling before connecting, but 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 no output schema, the description thoroughly explains all return values including caveats and plan filtering. It also covers edge cases (missing keywords). This makes the tool's behavior and usage fully understandable for an AI agent.

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

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

With 0% schema description coverage, the description fully compensates by explaining keywords[] as array of bank names (with example) and include_accounts as a boolean for fetching accounts. It also clarifies the behavior when keywords is missing (returns a hint, not an error), adding meaning beyond the schema.

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

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

The description clearly states the tool searches bank connectors by name, lists specific return fields (connector id, access, audience, etc.), and distinguishes from siblings by positioning it as a pre-connect search tool. The verb 'searches' is specific and matches the tool's function.

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 call this 'BEFORE connecting' to provide a one-click link, and warns that without keywords it returns a hint instead of dumping the catalog. However, it does not directly name alternative tools for different scenarios (e.g., listing all connections). The context is clear enough for the agent.

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 far beyond the limited annotations (readOnlyHint: false, etc.) by detailing important behavioral traits: the override of automatic categorization, automatic creation of Category Rules affecting future transactions, and the batch error handling where per-item errors do not fail the whole batch.

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-organized and front-loaded with the main action. While it contains multiple sentences, each serves a purpose (syntax, side effects, response shape). It could be slightly more concise but is 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 no output schema, the description fully explains the return shape ('{ updated, results: [{ transaction_id, category, categoryId }], errors: [...] }') and covers all essential aspects: input structure, side effects, and error handling. It is complete for an AI 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?

Despite the schema having 0% description coverage, the description fully compensates by explaining the 'items' parameter structure, the meaning of transaction_id and category_id, and where they originate (sibling tools). This adds crucial 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 verb 'Corrects' and the resource 'category of one or more transactions'. It explicitly differentiates from sibling tools like openfinance_list_transactions and openfinance_list_categories by specifying its unique role as an update/mutation tool with side effects.

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 ('to fix miscategorized transactions and improve categorization accuracy going forward') and how to obtain the required IDs from sibling tools. While it doesn't list alternatives for when not to use, the context and side-effect explanation are sufficient.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false, which the description does not contradict. The description lacks details on side effects or server behavior, but the annotation covers safety profile.

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

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

The description is very concise with two sentences, no redundant information. It could be improved by adding more detail without significant bloat, but 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?

The description does not explain what happens after reporting (e.g., response or confirmation). With no output schema and undocumented parameters, it is incomplete for effective tool usage.

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

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

Schema coverage is 0%, and the description only explains the 'conversation' parameter (as a JSON array). Parameters 'context' and 'message' are not described at all, leaving ambiguity about their purpose and accepted format.

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

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

The description clearly states the tool reports bugs, missing features, or feedback, with a specific verb and object. Sibling tools are mostly openfinance banking tools, so the purpose is clearly distinct.

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

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

The description advises including the conversation array for reproduction, which is helpful. However, it does not specify when not to use this tool or mention any 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 readOnlyHint, idempotentHint, and destructiveHint. The description adds specific context about what versions are shown (platform and adapter), adding value beyond annotations.

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

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

A single, clear sentence with no wasted words, front-loading the purpose.

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, parameter-less tool with no output schema, the description sufficiently covers its functionality. It states exactly what versions are shown.

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 the baseline is 4. The description does not need to add 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 uses a specific verb ('Show') and clearly identifies the resource ('MCP platform and adapter versions'), distinguishing it from sibling tools like authenticate and report_bug.

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

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

The description implies usage for retrieving version info, but does not explicitly state when to use vs alternatives. However, given the tool's simplicity, it 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, idempotentHint=true, and destructiveHint=false, indicating a safe, non-destructive read operation. The description adds specifics on the output content but does not disclose any additional behavioral traits beyond what annotations cover.

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

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

The description is a single sentence with zero wasted words. It immediately states the purpose and specifics, making it efficient 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 tool's simplicity (no parameters, clear annotations, straightforward purpose), the description is sufficiently complete. It covers what the tool returns without needing an output schema.

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

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

The tool has 0 parameters, so baseline is 4 per the rubric. The schema coverage is 100% (nonexistent parameters fully documented), 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?

The description clearly states the verb 'Returns' and the resource 'current toolkit state', with specific details on what is included (installed MCPs, connection status, catalog tools count). It uniquely identifies this tool among siblings, all of which are openfinance or other specific actions.

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

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

The description implies usage via 'Returns the current toolkit state' but does not explicitly mention when to use or alternatives. However, for a simple read-only state retrieval tool with no parameters, context is clear and no exclusions are needed.

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