Banco Digio MCP

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

Annotations include idempotentHint=true and destructiveHint=false. The description adds flow details (token handling, link generation) but does not elaborate on side effects like setting authentication state or error behavior.

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

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

The description is three sentences, front-loaded with the key purpose, and each sentence adds essential information without redundancy. 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?

While the description covers the authentication flow well, it lacks details on return values (e.g., what the tool returns beyond 'the link') and error handling. Given no output schema, 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 fully compensates by explaining the 'token' parameter: it is a JWT, optional, and its presence determines behavior (session login) or absence (return link).

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

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

The description clearly states the tool's purpose: to authenticate for MCP.AI IDE agents, with specific steps for login and token handling. It distinguishes from siblings like 'connect' by detailing the token-based authentication flow.

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

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

The description specifies when to use the tool (for IDE agents) and provides two methods (permanent config or session token). However, it does not explicitly mention when not to use it or compare with alternatives like 'connect'.

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 meaningful behavioral context beyond annotations by detailing the response structure for both connected and missing credentials scenarios. 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 two sentences with no fluff. It front-loads the core purpose and then elaborates with specific examples. Every sentence serves a clear function.

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

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

Given no parameters and no output schema, the description fully covers what the tool does, including both success and failure cases. It is complete enough for an agent to understand the tool's behavior without additional context.

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

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

There are zero parameters, so the baseline is 4. The description does not need to add parameter information; it correctly focuses on the function and output. Schema coverage is 100% with 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?

The description clearly states it returns connection status and URLs, and distinguishes two distinct states: all providers connected vs credentials missing. It uses specific language like 'returns', 'authenticated:true', and 'connect_url'. No confusion about what this tool 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 implies usage for checking overall connection status, but does not explicitly state when to use this tool versus sibling tools like 'authenticate' or 'openfinance_list_connections'. No when-not-to-use or alternative guidance 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?

The description goes well beyond the annotations by disclosing that invoke runs tools without installing, returns connect links for credentials and checkout links for payment, that interactive writes require owner/admin, and that search/describe flag installed status. It also details the prompt library's independent behavior. There is 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 lengthy but well-structured, front-loading the core purpose and then using labeled sections like 'Core flow:', 'KEY:', and 'If...' to organize guidance. Each sentence adds substantive value, though it could be slightly more concise without losing critical details.

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 (14 actions, 23 parameters, no output schema), the description covers the essential flows, permission requirements, and prompt library behavior. It explains key return artifacts like connect links, checkout links, and shareable prompt slugs. Some missing details remain, such as what 'resume' does and the exact return format of search results, but overall it is substantially complete.

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

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

With 0% schema description coverage, the description compensates by explaining the purpose of core parameters: action values (search, describe, install, invoke, list_tools, etc.), tool_id for selecting a tool, and mcp_id within the flow. It also implies prompt-related parameters such as prompt_body and prompt_vars. However, not all 23 parameters are explained (e.g., limit, immediate, tier_slug, cancel_reason), leaving some semantic 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 this tool is the official mcp.ai marketplace and catalog of MCPs/tools, also serving as the way to run them. It distinguishes itself from siblings by being a meta-tool for discovering, installing, and invoking MCPs, whereas siblings are domain-specific (e.g., OpenFinance).

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 each action: search for discovery, describe for profiles, invoke for one-off execution, install for permanent addition, and list_tools for currently callable tools. It also explicitly recommends 'prefer invoke for a single/occasional use' over install, and explains the auth/payment fallback flow.

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 provides behavioral context beyond annotations: it revokes consent, deletes data, makes data unavailable, and returns a reconnection URL. This complements the destructiveHint without contradicting it.

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: action, consequence, return value. No wasted words; information is front-loaded 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?

For a simple tool with one parameter, the description covers the action, side effects, and return value. The only gap is the lack of explicit parameter documentation, which is minor given the tool's low complexity.

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

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

The input schema has a single required parameter 'item' with zero description coverage. The description mentions 'for a specific bank' but does not map this to the parameter explicitly, leaving ambiguity.

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

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

The description clearly states the tool revokes Open Finance consent and deletes connection data for a specific bank, using specific verbs and a clear resource. It distinguishes from sibling tools like connect or force_sync by focusing on disconnection.

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 when to use (to disconnect a bank) and notes a reconnection URL is returned, but does not explicitly contrast with alternatives or provide 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 annotations (readOnlyHint=false, etc.), description details the PATCH-then-poll behavior up to ~60s, return structure including status, executionStatus, lastUpdatedAt, synced, needs_action with reconnect_url, and timed_out behavior. Also explains wait parameter effect. 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?

Well-structured and front-loaded with core action. Every sentence adds value: use case, parameter details, error handling, alternative modes. Efficient use of text without redundancy.

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

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

Comprehensive for a tool with no output schema: explains return format, fields, error conditions (needs_action, timed_out), and references sibling tool for follow-up. Covers edge cases and provides complete context 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?

Despite 0% schema description coverage, description fully explains both parameters: items as array of selectors (item_id, connector_id, etc.) or omit for all; wait: false for fire-and-forget. Adds meaning beyond 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?

Clearly states the tool forces a re-sync of bank connections and waits for completion. Specific verb 'force_sync' and resource 'connections'. Distinguishes from siblings like openfinance_get_item_status by explaining it triggers a sync rather than just checking 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?

Explicitly says when to use: 'when a balance or transaction list looks stale'. Contrasts with alternatives: no need to disconnect/reconnect, and if timed_out, re-check with openfinance_get_item_status. Also explains fire-and-forget mode with wait:false.

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 mark as read-only and idempotent. Description adds crucial details: CREDIT accounts may return BALANCE_FETCH_ERROR with a structured warning, and upstream failures cause degradation to last-synced balance with realtime:false and a warning. 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?

Efficiently front-loaded with main function and endpoint. Every sentence adds value, though it could be slightly more structured with bullet points for edge cases.

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 error handling, degradation behavior, and response shape, but lacks detail on the balance fields within results and does not explain error status codes or messages. No output schema exists to supplement.

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

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

Schema has 0% coverage, so description compensates by explaining account_ids is an array of 1-50 strings. This adds meaning beyond the bare schema, but only one parameter is 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?

Clearly states 'Returns real-time balance payload per account id' and specifies the GET endpoint, distinguishing it from sibling tools like list_accounts or get_accounts_detail.

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

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

Explains when to call (for real-time balance) and input constraints (array of 1-50 account IDs), but does not explicitly contrast with alternatives like openfinance_list_accounts or openfinance_get_accounts_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?

Adds significant behavioral context beyond annotations: batch response shape `{ results, errors }`, provider_incident block with reliability warnings. Annotations already indicate readOnly, destructive=false, idempotent, and description aligns with them.

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

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

Efficiently structured: purpose first, then parameter details, then warning. No redundant information.

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

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

Covers the primary use case, parameter constraints, and unexpected behavior (provider_incident). Could benefit from mentioning what fields are in the full account objects beyond creditData.

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 parameter account_ids is described with range (1-50) and batch shape, adding meaning beyond the schema which only defines type array of strings.

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 'Returns full account objects including extended creditData', specifies the endpoint pattern, and distinguishes from sibling tools like openfinance_list_accounts which likely return 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?

Describes when to use (to get full details with creditData), parameter constraints (array of 1-50 ids), and warns about provider_incident conditions. Lacks explicit when-not-to-use or 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 indicate readOnly, idempotent, and non-destructive behavior. The description adds critical behavioral detail: batch results/errors shape, that payments[] reflects previous bill cycle payments, sparse billId metadata, and lack of paid/status field from Pluggy. 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 thorough and well-structured, starting with purpose, then what it does not do, usage instructions, and caveats. While verbose, every sentence adds value; slight conciseness loss but still 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 the tool's complexity (Brazilian Open Finance nuances, data quality warnings, payment interpretation), the description covers all necessary aspects: output shape, usage prerequisites, behavioral caveats, and cross-tool references. No output schema exists, but the description compensates fully.

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

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

Despite 0% schema coverage, the description comprehensively explains the bill_ids parameter: it is an array, discovered via list bills, and the response includes results/errors, financeCharges, payments, totalAmount. This adds significant meaning beyond the bare schema.

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

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

The description clearly states it returns bill-level detail for credit card bills by ID, and distinguishes itself from sibling tools by specifying it does not return individual transactions, directing to openfinance_list_transactions for that 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 provides explicit guidance: use openfinance_list_credit_card_bills to discover IDs before calling this tool, and use openfinance_list_transactions for itemized transactions. It also warns about payment semantics and not 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 declare read-only and idempotent hints. Description adds detailed behavioral traits: returns reconnect_url that reopens widget in UPDATE mode without disconnecting, and describes return structure. 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 concise paragraphs with no fluff. First paragraph explains core functionality and return values; second adds bulk support. Could be more structured but 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?

Describes return fields well but covers only one of two result shapes (all returns {count, items}, single not specified). No output schema, so missing detail on single-mode response. Annotations cover safety, but behavioral context is good.

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

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

With 0% schema description coverage, the description must compensate. It explains 'item' (omit for all, pass for single) and 'item_ids' (bulk support), but 'item_id' is not mentioned, leaving ambiguity. Meaning is added for two out of three 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?

Clearly states it returns the current status of a bank connection with specific fields (status, executionStatus, metadata, reconnect_url). Distinguishes between single and all banks, and is distinct from sibling tools like openfinance_list_connections which list connections without 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?

Explains how to use for single vs. all banks (omit item for all, pass item for single) and mentions bulk support with item_ids. Provides clear context but does not explicitly exclude alternatives or state 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 already declare readOnlyHint=true and idempotentHint=true, so the tool is safe and idempotent. The description adds the batch size limit (1-50) and the error handling shape, 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 a single, focused paragraph. It lists key returned fields without excessive detail, and every sentence adds value. Slightly longer due to field enumeration but still 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?

No output schema exists, so the description lists contract detail fields, batch shape, and parameter constraints. For a simple one-parameter tool, this covers the essential information needed 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?

Schema has 100% required parameters but 0% description coverage. The description compensates by specifying 'Pass `loan_ids` as an array (1-50)' and mentions batch behavior, adding meaning beyond what the schema provides.

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 full loan contract detail by ID, lists specific fields returned (interestRates, charges, etc.), and explicitly distinguishes its use from sibling openfinance_list_loans via 'Use after... to 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?

Provides explicit when-to-use: 'Use after openfinance_list_loans to deep-dive on a specific contract.' Also specifies parameter constraints (array of 1-50 IDs) and result shape ({results, errors}).

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 important behavioral traits: CREDIT balance is connector-dependent, provider_incident may indicate unreliable data, and identity_notice handles joint accounts. It also explains deduplication and ownership attribution issues. 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 comprehensive but somewhat lengthy, covering many edge cases and details. It is well-structured with clear paragraphs and front-loaded with the main functionality. While every sentence adds value, a slightly more condensed version could improve conciseness without losing clarity.

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

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

Given the tool has no output schema, the description thoroughly explains all returned fields and their meanings, including specialized notes on CREDIT balance, provider_incident, and identity_notice. It also advises on deduplication and aggregate usage. This provides complete context for an AI agent 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?

With 0% schema description coverage, the description compensates by explaining the 'item' and 'item_ids' parameters well. However, it does not explicitly explain the 'type' or 'item_id' parameters (though 'type' enum is self-explanatory and 'item_id' might be inferred from context). It adds significant meaning overall, but leaves minor gaps for 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 that the tool returns a list of accounts for bank connections, distinguishing between BANK and CREDIT types. It details the exact fields returned (balance, number, type, subtype, bankData, creditData, bank, connector_id) and explains how to use the 'item' parameter to target all banks or a single one, effectively differentiating it from sibling tools like openfinance_get_account_balance.

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: omit 'item' to list across all banks, or pass 'item' for a single bank. It references a sibling tool (openfinance_list_credit_card_bills) for standardized billing information, and explains the 'provider_incident' and 'identity_notice' handling. It also mentions bulk support with 'item_ids', giving clear context for usage scenarios.

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 false. The description adds behavioral details: caching for the adapter session, single aggregated response with no batch ids, which goes beyond the annotations.

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

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

The description is concise and well-structured, front-loading the purpose and listing key fields. It could be slightly more terse but remains effective.

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

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

Given no output schema, the description adequately explains the return value (fields and their meanings) and important behavior (caching, aggregation). It is complete for a zero-parameter, read-only tool.

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

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

There are no parameters, so the baseline of 4 applies. The description does not need to add parameter semantics.

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 Pluggy's transaction category taxonomy, specifying the endpoint and caching behavior. It differentiates from siblings by being the only tool returning category taxonomy, with explicit mention of fields like 'id', 'description', and 'parentId'.

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 guides usage by noting that the 'id' field is used by 'openfinance_update_transaction_category', indicating a common workflow. However, it does not explicitly contrast with siblings or state when not to use it.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context about the reconnect_url behavior and that it does not consume connection slots. This adds value beyond annotations, though no inherent 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 three sentences, efficiently packed with relevant information. It front-loads the primary purpose and includes details on the special URLs. Slightly verbose in the reconnect_url explanation but overall 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?

Given no output schema, the description adequately covers the return structure and key nuances (reconnect_url behavior). It lacks pagination or ordering details, but for a listing tool with readOnlyHint, this is acceptable 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 input schema has no parameters, so schema coverage is 100%. The description does not need to explain parameters but instead adds value by describing the output fields in detail, compensating for the lack of an output schema.

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

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

The description clearly states it returns saved bank connections with specific fields (connector_id, item_id, bank name, reconnect_url, add_connection_url). The verb 'Returns' and the resource 'saved bank connections' are well-defined. It distinguishes from sibling tools by detailing the unique output and URLs.

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 context on using the reconnect_url for re-authentication scenarios (MFA connectors, LOGIN_ERROR, stale data). It clarifies what the tool does NOT do (consume a connection slot or require disconnecting). However, it does not explicitly state when to use this tool over siblings like '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?

Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context: payment status derivation logic, cross-bill payment matching, open bill availability asymmetry, and warning about not assuming payment from non-empty payments array. 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 long but well-packed with necessary details and front-loaded with main functionality. Could be more structured, but every sentence adds value given the complexity.

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

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

With no output schema, the description compensates by listing all returned fields, the derived payment_status, and the optional open_bill structure. It covers edge cases, warnings, and connector asymmetry. Very 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 coverage is 0%, so description must compensate. It explains include_open_bill in detail and mentions account_ids for bulk. It does not explicitly explain page and page_size, but they are standard pagination parameters. Overall, adds meaningful parameter 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 closed credit card bills for a CREDIT-type account and lists specific fields (dueDate, totalAmount, etc.). It distinguishes from sibling tools like openfinance_list_transactions which returns 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?

Extensive when-to-use and when-not-to-use guidance: explains that it's for closed bills, that individual transactions are in another tool, that open bill is opt-in, and includes warnings about payment status interpretation and bill grouping reliability.

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, non-destructive. The description adds critical behavioral details: graceful error handling for disabled products (403), and a sophisticated data integrity warning mechanism for mass zeroing, including how to treat suspect balances. This goes well beyond the annotations.

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

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

The description is relatively long but well-organized, with a clear front-loading of purpose and a separate paragraph for data integrity. Every part adds value, though it 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?

Given the tool's complexity (portfolio with many fields, error handling, data integrity) and the absence of an output schema, the description provides comprehensive context. It explains return structure, error behavior, and a detailed edge case handling, leaving few unanswered questions.

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 6 parameters and 0% schema coverage, the description only partially compensates by explaining item_ids for batched execution. It does not describe item, page, type, or page_size, leaving the agent without sufficient guidance on how to use these fields.

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 investment portfolio data for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.). It distinguishes itself from sibling tools like openfinance_list_investment_transactions by focusing on the full portfolio.

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 portfolio retrieval and mentions error handling (returns empty instead of throwing). It does not explicitly state when to use alternatives like openfinance_list_investment_transactions, but the purpose 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, idempotentHint=true, destructiveHint=false, so safety profile is clear. The description adds moderate context about what transactions are returned and bulk support, but does not disclose pagination behavior or rate limits. 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?

Two short paragraphs, front-loaded with purpose, then return field details, then usage note. Every sentence adds value without redundancy or 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?

Explains return fields well despite no output schema, provides prerequisite and bulk note. However, missing description for pagination parameters (page, page_size) and lack of error/limit information make it incomplete for full practical use.

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

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

Schema description coverage is 0%, so description must compensate. It implicitly explains investment_id (required, obtained from prior call) and investment_ids (for bulk). However, page and page_size are not described at all, leaving a significant gap for a list tool that likely supports pagination.

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

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

The description clearly states it returns movement history for a specific investment position with explicit transaction types (BUY/SELL/TAX/INTEREST/AMORTIZATION/TRANSFER) and lists many returned fields. It effectively distinguishes from sibling tools like openfinance_list_investments (which lists investments) and openfinance_list_transactions (general 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 clear prerequisite: 'Use after openfinance_list_investments to get the investment_id.' Also mentions bulk support with investment_ids. However, does not explicitly state when not to use or mention alternatives, but the context with sibling tools provides indirect guidance.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, but the description adds important behavioral details: sequential querying with rate-limit spacing and the return format of {results, errors} per connection. 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 with two sentences, front-loading the main purpose and then providing essential details. No redundant or 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?

Despite no output schema, the description explains the return format and rate-limit behavior. For a list tool with a single optional parameter, the description covers all necessary context for an agent to invoke it correctly.

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

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

The input schema has only one parameter 'items' with no description and 0% coverage. The description compensates fully by explaining that each array entry is a connection selector (item_id uuid, connector_id, or connector_name) and that one entry corresponds to one connection to fetch. This adds significant meaning beyond the schema.

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

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

The description clearly states that the tool lists loan contracts per bank connection, specifies the HTTP endpoint (GET /loans), and distinguishes two modes (with or without the 'items' parameter). This makes the purpose specific and differentiates it from siblings like openfinance_get_loan_detail.

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 explains when to use the 'items' parameter (for specific connections) and when to omit it (for all linked banks), and mentions sequential querying with rate-limit spacing. It does not explicitly mention when not to use the tool or suggest alternatives, but the context is clear enough.

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

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

The description discloses numerous behavioral traits beyond the annotations (which are readOnlyHint: true, destructiveHint: false): auto-pagination vs manual, truncation at 5000, error handling (returns warning instead of throwing), detail modes (compact, rich, raw) with cost implications, account echo block, provider incidents, and inconsistent billId population. All traits are clearly explained, adding substantial value over the minimal annotation set.

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

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

Despite its length, the description is well-structured and front-loaded: the first sentence states the core purpose. Subsequent paragraphs are logically organized by feature (date filter, pagination, detail, troubleshooting). Every sentence provides necessary information for this complex tool; there is no redundancy or filler. The bulk support note at the end is appropriate.

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 (8 parameters, no output schema, multiple sibling tools), the description is remarkably complete. It describes the output shape (account echo block, transaction fields by detail level, truncation warning, provider incident block), addresses edge cases (credit sync failures, sparse billId, varying coverage per bank), and covers all documented behavior. An agent can fully understand and use the tool without ambiguity.

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 carries the full burden. It explains all 8 parameters: from/to as ISO date filters, search_queries as case-insensitive substring OR logic, detail with three modes and their behaviors, page/page_size for pagination with defaults and limits, account_id and account_ids for identification. Each parameter is given rich semantic context that the schema lacks.

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

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

The description clearly states the tool returns transactions for a bank account (BANK or CREDIT type). It distinguishes from sibling tools like openfinance_list_credit_card_bills by noting that this is the only way to get itemized transactions for credit accounts, and it contrasts its purpose for bill totals. The verb 'Returns transactions' and resource 'bank account' are specific and unambiguous.

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

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

The description provides explicit guidance on when to use this tool vs alternatives: for CREDIT accounts, it is the only way to get itemized transactions, while for standardized bill totals one should use openfinance_list_credit_card_bills. It also advises on date filters, keyword filtering, pagination modes, detail levels, and even when to check connection health or force sync. This exhaustive guidance helps the agent choose and use the tool correctly.

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), description adds critical behaviors: 5000-transaction cap per account with truncation flag, provider_incident block for incomplete data, bulk support via item_ids, and detailed response structure. This is comprehensive for a read-only tool.

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 well-structured: main purpose, alternative uses, parameter details, edge cases. Though somewhat verbose, each sentence adds necessary detail. Some repetition (e.g., compact summary mentioned twice) but not excessive.

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 9 parameters, no output schema, and moderate complexity, the description covers key aspects: input parameters, default behaviors, truncation, provider incidents, and response structure for both granularities. Missing minor details like pagination for raw mode but the caps and truncation flag mitigate this.

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 most parameters: item, from/to, granularity, detail, type, and item_ids. However, the 'top_n' parameter is only implied in 'largest N each' and the interplay between granularity and detail could be clearer (e.g., compact as a detail value vs. output description).

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

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

Clearly states 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call.' Distinguishes from siblings like openfinance_list_transactions by highlighting that it internally resolves accounts, eliminating the need for separate calls, and allows analysis of all connected banks in one go.

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

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

Explicitly tells when to use this tool: 'Use this for 'análise anual/mensal', 'fluxo de caixa', 'entradas e saídas', 'maiores gastos/recebimentos'.' Also advises against using openfinance_list_accounts first, and explains scenarios for different granularities 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?

Beyond annotations (readOnly, idempotent), the description adds rich behavioral details: live check, returns global indicator, degraded components, incidents, and flags affected banks. 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 well-structured and front-loaded, but slightly verbose. Every sentence adds value, though minor trimming could improve conciseness.

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

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

Despite no output schema, the description thoroughly explains return values (global indicator, components, incidents, affected banks) and usage context, making it complete for a zero-parameter live health check tool.

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

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

No parameters are defined, so schema coverage is 100%. The description adds context about what the tool queries and returns, satisfying the baseline of 4 for zero-parameter tools.

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

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

The description clearly states the tool checks the LIVE operational status of the Open Finance provider, distinguishing it from the related sibling openfinance_get_item_status by emphasizing provider health vs. connection health.

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 specifies when to use: when data appears incomplete or stale despite an updated connection, to differentiate upstream outages from connection issues. Provides actionable scenario.

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

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

The description adds significant behavioral details beyond the annotations: it never dumps full catalog without keywords, returns a hint when keywords empty, honors user's plan (PF hides PJ banks, PJ covers both), and surfaces caveat warnings for non-Open-Finance connectors. This complements the readOnlyHint and idempotentHint 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 a single dense paragraph containing all necessary information. It front-loads the main purpose and key returned fields. While slightly long, every sentence adds value, and the density is justified by the tool's complexity. Could be broken into bullet points for easier scanning.

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 2 parameters and no output schema, the description covers everything needed: purpose, when to call, required parameters, return content, plan behavior, and caveat handling. It enables an AI agent to use the tool correctly without relying on external documentation.

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

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

Schema coverage is 0%, but the description fully explains both parameters: keywords[] is required (returns hint if empty), and include_accounts controls whether linked accounts are returned. It adds real-world meaning (pass bank names as keywords) that goes beyond the type definitions, fully compensating 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 searches bank connectors by name, lists the returned fields (id, access, audience, linked connections, connect_url), and distinguishes itself from siblings by specifying its role in the connection workflow. It uses a specific verb ('searches') and resource ('bank connectors'), 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 call this BEFORE connecting, and provides context on plan behavior and caveat handling. While it doesn't name alternative tools for when not to use it, the sibling list and the focus on pre-connection search make the usage clear. The instruction that keywords[] is REQUIRED also guides proper 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?

Discloses the key side effect of creating a Category Rule that affects future transactions, which goes beyond annotations. Also explains error handling for batch operations, providing essential behavioral context.

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

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

Description is comprehensive but slightly verbose. It front-loads the main action and follows with important details, but could be tightened without losing meaning.

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?

Completely addresses complexity: no output schema, yet describes return shape; covers prerequisites, side effects, and batch behavior. Leaves no gaps for effective tool 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 description coverage, the description fully compensates by explaining the structure of the 'items' parameter, required fields, and how to obtain the IDs from other tools.

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 the tool corrects transaction categories, specifies HTTP method and endpoint, and distinguishes from sibling tools like openfinance_list_transactions and openfinance_list_categories by referencing them as sources for IDs.

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

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

Provides clear context on when to use (fix miscategorized transactions, improve future accuracy) and prerequisites (IDs from specific sibling tools). Lacks explicit exclusion criteria but offers sufficient guidance.

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

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

The description lacks behavioral disclosure beyond the obvious write operation. Annotations set idempotentHint=true, which contradicts the implied non-idempotent nature of reporting a bug (multiple reports create multiple entries). No discussion of side effects, permissions, or response behavior.

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

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

The description is concise, consisting of two sentences. It front-loads the purpose and then gives specific guidance. 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?

Given the low complexity (3 parameters, no output schema), the description is minimally adequate. However, it does not cover potential contradictions (idempotentHint) or provide enough detail for the agent to confidently invoke the tool (e.g., format of conversation, expected response).

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

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

Schema description coverage is 0%, so the description must compensate. It explains that 'conversation' should contain recent messages for reproduction, giving it meaning. However, 'message' and 'context' are not described beyond their names, leaving the agent to infer usage from the tool's purpose.

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

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

The description clearly states the tool's purpose: reporting a bug, missing feature, or sending feedback. It specifies to include a conversation array, which distinguishes it from sibling tools that are primarily finance-related and do not involve feedback.

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 when to use this tool (for bugs, features, feedback) and implies the need to include a conversation array. However, it does not mention when not to use it or provide alternatives, but the sibling set makes the context clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds minimal behavioral context. It specifies what versions are shown (platform and adapter), which is useful but not extensive.

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, concise sentence that directly states the tool's purpose without any extraneous information. Every word earns its place.

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

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

Given the tool's simplicity (no parameters, no output schema, and annotations covering safety), the description is complete. It sufficiently explains what the tool does and what information it provides.

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 (0 params), so the baseline is 4. The description does not need to add parameter information since the schema is empty and fully covered.

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

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

The description clearly states the tool shows 'current MCP platform and adapter versions', specifying both the action and the resource. It distinguishes itself from sibling tools, which are primarily about authentication, finance operations, etc.

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

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

The description does not explicitly state when to use this tool vs alternatives, but given its simple nature and clear separation from sibling tools, the context is clear. There are no exclusions needed.

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=false. The description adds valuable context beyond annotations by specifying exactly what the tool reports (installed MCPs, connection status, accounts, catalog tool counts). This enriches the agent's understanding without contradicting any annotations.

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

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

The description is a single, well-structured sentence that front-loads the key purpose ('Returns the current toolkit state') and enumerates the specific data returned. Every word adds value with no redundancy or filler.

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

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

For a zero-parameter tool with no output schema, the description is fully complete. It tells the agent what the tool returns, which is sufficient given the tool's simplicity and the annotated safety characteristics.

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

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

The tool takes no parameters, and the input schema is an empty object with 100% coverage. Per the rubric, the baseline for 0 parameters is 4. The description doesn't need to explain parameters, and it doesn't, so the score is appropriate.

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

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

The description clearly states the tool returns the current toolkit state, listing specific data points (installed MCPs, connection status, connected accounts, catalog tool counts). This makes its purpose explicit and distinct from sibling tools like connect or openfinance_list_accounts, which perform actions or list domain-specific items.

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 cases: when you need an overview of the toolkit's overall status and health. It doesn't explicitly mention alternatives or when not to use, but the context of sibling tools (connect, authenticate, etc.) makes it clear this is the diagnostic/status tool. The lack of explicit exclusions is a minor gap.

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