Nubank MCP

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

Discloses key behaviors: permanent vs session-only authentication, and that calling without args returns a link. Annotations already indicate idempotency, but description adds context on token handling.

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

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

Two sentences covering both methods. Dense but not overly long. Minor improvement could be clearer separation of the two use 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?

For a simple authentication tool, the description covers login process, token usage, and session persistence. No output schema needed as it's a setup action.

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

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

The single 'token' parameter is fully explained: its content (JWT) and the two invocation patterns (with/without token). This compensates for the 0% schema coverage.

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

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

The description clearly states the tool's purpose: authentication via browser login and token management. It distinguishes from sibling tools like 'connect' by focusing on credential provisioning.

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

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

Explicitly describes two usage modes (permanent config vs session token) and when to call with or without arguments. However, lacks explicit alternatives or when-not-to-use 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?

Adds context beyond annotations by describing specific response scenarios (all connected vs missing credentials), aiding agent understanding of behavior.

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

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

Two sentences, front-loaded with purpose, 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?

Sufficient for a simple tool with no parameters; explains key return scenarios, though exact URL format is omitted.

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; baseline 4 applies as description doesn't need to add param info.

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

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

Description clearly states the tool returns connection status and URLs, with specific examples distinguishing it from sibling tools like authenticate and marketplace.

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?

Implicitly suggests use for checking connection status but lacks explicit when-to-use or alternative 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 discloses important behavioral details beyond annotations: invoke runs tools without installing them, install makes MCPs permanent, auth failures return connect links, and payment failures return checkout links. This adds substantial transparency 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 long but information-dense; every sentence adds value. It is logically organized from core flow to install vs invoke to prompt library, though a single dense paragraph could benefit from bullet points or more distinct sections.

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 complex tool with many actions, the description covers the core flow, billing, admin requirements, and prompt library well. It misses a few details like the resume action, the immediate parameter, and the full set of return values, but overall it is quite 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 23 parameters and 0% schema coverage, the description carries a heavy burden. It does explain the action parameter and implies tool_id and prompt variables, but many parameters (limit, query, arguments, immediate, prompt_*, cancel_reason) are not described. The core flow is clarified, but not every parameter's 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 identifies the tool as the official mcp.ai marketplace and explains its dual role as a catalog and execution engine. It explicitly distinguishes this tool from sibling openfinance and auth tools by describing the core flow of search → describe → invoke.

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

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

The description provides explicit when-to-use guidance: prefer invoke for one-off runs, use install for permanent toolkit additions, and use search/describe for discovery. It also notes that writes require workspace owner/admin and explains the retry flow for connect/checkout links.

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 destructive nature (deleting data) and provides useful info beyond annotations: returns reconnection URL. 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?

Two sentences, no fluff. Front-loaded with the main action, succinctly covers purpose and outcome.

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 tool simplicity (1 param, no output schema), description covers what happens and return value. Missing parameter description prevents a 5.

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 description does not explain the 'item' parameter. The description says 'for a specific bank' but does not link it to the parameter, 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?

Description clearly states the action: revokes consent and deletes connection data. It specifies the resource (specific bank) and distinguishes from sibling tools like 'connect' or 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?

Implies when to use (to disconnect a bank) but no explicit guidance on when not to use or prerequisites (e.g., connection must exist). Alternatives like 'connect' are implied but not stated.

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

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

Describes polling behavior up to ~60s, return format with fields like status, executionStatus, lastUpdatedAt, synced, needs_action, reconnect_url, timed_out. Also explains fire-and-forget mode via wait:false. Annotations are minimal, so description fully carries behavioral disclosure.

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 somewhat lengthy but every sentence adds value. Front-loaded with main action. Could be slightly more concise, but overall 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?

No output schema, but description details return structure with results and errors, key fields, and error scenarios. Covers all behaviors for a complex mutation tool with polling, error handling, and multiple modes.

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

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

Schema coverage is 0%, but description fully explains both parameters: 'wait' (boolean, fire-and-forget mode) and 'items' (array of strings as selectors: item_id, connector_id, connector_name, custom_label; omitting syncs all). No 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?

Clearly states the tool forces a re-sync of connections and waits for completion. Verb 'force sync' and resource 'connections' are explicit. Distinguishes from alternatives by noting it does not disconnect/reconnect.

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 balance or transaction list looks stale') and how to use ('OMIT items to sync ALL linked banks'). Provides guidance on handling 'needs_action' results and mentions re-checking with sibling tool 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?

Goes beyond annotations by detailing real-time vs last-synced balance, error handling for credit accounts, degradation behavior with warnings, and response shape. 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?

Concise yet comprehensive: front-loaded main purpose, then covers array usage, errors, degradation, and response structure 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?

Given the tool's complexity and no output schema, the description provides complete behavioral context, including error patterns, degradation conditions, and response shape, enabling effective agent invocation.

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

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

Schema has 0% description coverage; the description fully compensates by explaining the parameter is an array of account IDs with a size constraint (1–50), which is critical for correct usage.

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

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

Clearly states the verb 'Returns', resource 'balance payload per account id', and the endpoint. Distinguishes from sibling tools like openfinance_list_accounts by specifying real-time 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 context for using the tool (pass account_ids array, size limit) and describes edge cases. Lacks explicit when-to-use vs alternatives but is clear enough for selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds significant context: the provider_incident block, unreliable limits during provider incidents, and extended creditData. 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 (3 sentences) with no redundancy. It front-loads the primary purpose, then parameter details, then behavioral warnings. Every sentence provides necessary information.

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

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

For a 1-parameter tool with no output schema, the description covers the key aspects: purpose, parameter usage, response shape, and an important edge case (provider incident). It could be more detailed about the full return fields, but given the simplicity, it is fairly complete.

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

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

Schema coverage is 0%, so description must compensate. It specifies the array length constraint (1-50) and the batch response shape ($results, errors$), which are not in the schema. It also implies each item is an account ID. This adds meaningful guidance, though the exact meaning of each element could be more explicit.

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 specifies the verb 'Returns' and the resource 'full account objects including extended creditData'. It also mentions the HTTP endpoint and the batch shape, clearly distinguishing it from similar tools like openfinance_list_accounts.

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

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

The description explains how to pass account_ids (array, 1-50) and the response shape, but does not explicitly state when to use this tool over alternatives like openfinance_list_accounts or openfinance_get_account_balance. Usage context is implied but not consolidated.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds critical behavior: payments[] may reflect previous bill payment, billId is sparse/inconsistent, and Pluggy does not return paid/status. No annotation 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 long but comprehensive; every sentence adds value. It front-loads the main purpose and then covers caveats and usage details. Could be slightly more concise, but not overly verbose.

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

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

With no output schema, the description explains the return shape (batch with results/errors), listed fields, and what is NOT returned (individual transactions). It addresses connector-specific behaviors and edge cases, making it complete 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 coverage is 0%, so description carries full burden. It explains the parameter (array of bill_ids) and suggests how to get valid ids using sibling tool. It does not specify formatting or constraints, but guidance is sufficient for correct use.

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'), the resource ('bill-level detail for one or more credit card bills by id'), and specifies returned fields (financeCharges, payments). It explicitly distinguishes from the sibling openfinance_list_transactions for itemized transactions.

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

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

The description provides explicit when-to-use (get bill-level detail) and when-not (do not use for itemized transactions; use openfinance_list_transactions). It advises using openfinance_list_credit_card_bills first to discover ids and suggests an alternative for payment status.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds valuable behavioral context: it mentions that the reconnect_url allows re-authentication without disconnecting or consuming a connection slot, and that bulk support is available. 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 two sentences, front-loaded with the core functionality. It is efficient but somewhat dense; could benefit from slight restructuring (e.g., separate lines for bulk vs single). Still, each part earns its place.

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

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

No output schema exists, but the description covers return fields (status, executionStatus, connector metadata, reconnect_url) and the bulk response shape ({ count, items }). With three parameters all explained and a simple read operation, the description is sufficiently complete for effective 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 the description must compensate. It explains that 'item' is used for a single bank, 'item_ids' for bulk, and implies 'item_id' might be an alias (though not explicitly clarified). This adds meaning beyond the bare schema, though a brief explanation of 'item_id' would improve clarity further.

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

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

The description clearly states the tool returns the current status of a bank connection, lists example statuses, and specifies return fields (status, executionStatus, connector metadata, reconnect_url). It distinguishes between omitting 'item' (all banks) and passing 'item' (single bank), and notes bulk support with 'item_ids'. This provides a specific verb+resource and differentiates from other 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 explains when to omit 'item' for all banks, pass 'item' for a single bank, and use 'item_ids' for bulk execution. While it does not explicitly state when not to use this tool, the context is clear given the sibling tools list (e.g., connect, disconnect, sync) which serve different purposes.

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. The description adds behavioral details: batch processing with `{ results, errors }` shape, and explains return content. 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 front-loaded with the core purpose. It lists many fields efficiently in parentheses without being overly verbose. Could be slightly more concise but overall 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 1 parameter, no output schema, and good annotations, the description covers return shape, fields, and error handling. It is complete enough for a detail retrieval tool with clear guidance on prior steps.

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

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

Schema has 1 required array parameter with 0% description coverage. The description adds meaning: 'Pass `loan_ids` as an array (1-50),' specifying size limit and batch context. This compensates well for the schema gap.

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 details by ID, listing many specific fields. It distinguishes from sibling 'openfinance_list_loans' by stating it is for deep-diving on a specific contract.

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

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

Explicitly says 'Use after openfinance_list_loans to deep-dive on a specific contract.' Also specifies array size limits (1-50) and batch shape. No explicit when-not-to-use, but context is clear for a detail retrieval tool.

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

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

Beyond annotations (readOnly, idempotent), the description adds critical context: connector-dependent credit balance interpretation, provider_incident block (unreliable data), identity_notice (deduplication), and the relationship between name and bank brand. 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-organized with front-loaded purpose, but lengthy due to comprehensive detail. Every sentence adds value, though some conciseness could be achieved by extracting parameter details into the schema.

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 (4 params, no output schema, multiple sibling tools), the description covers return fields, parameter usage, edge cases (provider incidents, identity notices), and cross-tool references. It is sufficiently complete for an agent to use correctly.

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

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

With 0% schema coverage, the description compensates by explaining the role of 'item' (target single vs all), 'type' (BANK/CREDIT), and 'item_ids' (bulk). However, 'item_id' is not explicitly described, and the information is narrative rather than structured.

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 accounts for bank connections, specifying types (BANK, CREDIT) and key fields (balance, number, etc.). It distinguishes itself from siblings like openfinance_list_credit_card_bills by explaining when to use each.

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 guides when to omit vs pass the 'item' parameter, provides cross-tool references for credit card bills, and explains handling of provider incidents and identity notices. Covers both broad and targeted 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?

Adds caching behavior and notes 'single aggregated response — no batch ids' beyond annotations. Annotations already indicate readOnlyHint, idempotentHint, and non-destructive, so description adds useful context.

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

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

Two sentences, front-loaded with main action, no filler. 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?

No output schema, but description lists all fields (id, description, descriptionTranslated, parentId, parentDescription) and explains id's role. Could detail caching duration, but sufficient for a read-only list.

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

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

No parameters exist, so baseline is 4. No need for parameter details.

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

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

Clearly states the tool returns Pluggy's transaction category taxonomy via GET /categories, cached per session. It specifies the endpoint and differentiates by noting categories are used by openfinance_update_transaction_category.

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 context on when to use (to get categories) and gives a usage hint for pt-BR users. No explicit exclusion or alternatives, but the tool is unique among siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds beyond this: it clarifies that reconnect_url does not consume a connection slot and does not require disconnecting first. 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 moderately concise; it front-loads the main purpose and then provides detailed behavioral context for the reconnect_url. Every sentence adds value, but could be slightly tighter. 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?

Given no output schema and zero parameters, the description fully explains what is returned (fields) and the behavior of the reconnect_url. It is complete for a read-only list tool with clear annotations.

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

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

There are zero parameters, so baseline is 4. The description does not need to add parameter info as there are none. Schema coverage is 100% by default.

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

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

The description clearly states the tool returns saved bank connections and lists specific fields (connector_id, item_id, bank name, URLs). It distinguishes from siblings like openfinance_list_accounts by focusing on connection-level data. The verb 'Returns' is 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 explains usage of the reconnect_url for re-authentication, providing context on when to use that field. However, it does not explicitly state when to use this tool vs alternative list tools (e.g., openfinance_list_accounts). Still, the purpose is clear enough for a list tool.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. The description adds extensive behavioral context: derived payment_status logic, connector asymmetry, open bill availability reasons, bill grouping reliability warning, and bulk support. 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 very long and dense, covering many details in a single paragraph. It could benefit from more structure (e.g., bullet points) and trimming redundancy (e.g., multiple explanations of payment_status). Important content but lacks 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?

Given no output schema, the description covers return fields (payments[], payment_status, open_bill), edge cases (connector asymmetry, reliability), and includes an account echo block. It misses some fields but is fairly complete for a complex tool.

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

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

Schema coverage is 0%, so description must compensate. It explains include_open_bill in detail and mentions account_ids for bulk, but does not describe page, page_size, or account_id explicitly. Pagination parameters are undocumented, leaving a gap.

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

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

The description clearly states the tool returns CLOSED credit card bills for CREDIT-type accounts, listing key fields. It distinguishes itself from sibling tools like openfinance_get_credit_card_bill (singular) and openfinance_list_transactions (transactions vs bills). The verb 'list' and resource 'bills' are precise.

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

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

Provides explicit guidance: when to use openfinance_list_transactions for itemized charges, when to opt-in for open bill via include_open_bill, and warns against assuming payment status based on payments array. Also explains when open_bill is unavailable and how to handle 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 indicate read-only, non-destructive behavior. The description adds critical behavioral details: graceful error handling for disabled INVESTMENTS, data integrity checks (suspect_zeroed flag), and bulk execution via item_ids. 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 detailed and front-loaded with the core purpose. Each sentence provides value (error handling, data integrity, bulk support). Slightly verbose but appropriate for the complexity.

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

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

Given no output schema, the description adequately explains the return structure and key fields. It covers error states and data integrity warnings. However, it lacks parameter descriptions, which are part of the tool's 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?

The input schema has 6 parameters with 0% description coverage. The description only mentions bulk support via item_ids, leaving page, page_size, type, item, and item_id undocumented. This is a severe gap given low coverage.

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

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

The description clearly states the tool returns the investment portfolio for a connection, listing specific investment types (FIIs, stocks, ETFs, etc.). It distinguishes from sibling tools like openfinance_list_investment_transactions by focusing on portfolio holdings rather than transactions.

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

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

The description explains that the tool is for retrieving investment portfolios from connections with INVESTMENTS enabled. It covers error handling (returns warning instead of throwing 403) and bulk support. However, it does not explicitly compare against siblings or state when not to use it, though the context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating safe read-only behavior. The description adds details about return fields and transaction types but no additional behavioral traits beyond what annotations provide.

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

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

The description is two sentences plus a brief bullet line, front-loaded with the core purpose and key details. Every sentence provides value with no unnecessary text.

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

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

Given 4 parameters, no output schema, and good annotations, the description covers prerequisites, return fields, transaction types, and bulk support. It does not explain pagination behavior for page/page_size, which slightly reduces completeness.

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

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

The schema has 4 parameters with 0% description coverage. The description explains investment_id and investment_ids (bulk support), adding meaning beyond the raw schema. However, page and page_size are not described, leaving gaps.

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

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

The description clearly states the tool returns movement history for specific investment positions, listing transaction types (BUY/SELL/TAX/INTEREST/AMORTIZATION/TRANSFER) and fields. It distinguishes from siblings by mentioning use after openfinance_list_investments, and among siblings like openfinance_list_transactions, this one is specific to investment transactions.

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

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

The description provides clear context: use after openfinance_list_investments to get investment_id, and mentions bulk support for batched execution. It does not explicitly state when not to use, but the usage context is well defined.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context: sequential per-connection execution, rate-limit handling, and return structure of `{ 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?

The description is concise—three sentences—front-loaded with the purpose. Every sentence adds essential information: endpoint, parameter behavior, and return format. 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 no output schema, the description includes the return format `{ results, errors }` per connection. Combined with annotations covering safety and idempotency, the description provides sufficient context for an agent to correctly use this 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?

Schema description coverage is 0%, so the description bears the full burden. It thoroughly explains the sole parameter `items`: it's an array of connection selectors (item_id uuid, connector_id, or connector_name), one per connection, and the effect of omitting it. This fully compensates for the lack of schema descriptions.

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

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

The description clearly states it lists loan contracts per bank connection, mentions the HTTP method and endpoint (GET /loans), and distinguishes from sibling tool openfinance_get_loan_detail by specifying it returns multiple contracts per connection.

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

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

Provides clear guidance on when to omit or pass the `items` parameter (omit for all banks, pass per connection). Mentions sequential querying with rate-limit spacing. However, it does not explicitly state when to use this tool over siblings like openfinance_get_loan_detail for a single loan.

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 critical behavioral details: auto-pagination up to 5000 items, truncation warnings, error handling returning structured errors, variable coverage per bank for credit card data, and the provider_incident block. This far exceeds what annotations provide.

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 purpose and then detailing parameters and edge cases. While every sentence adds value, some repetitions (e.g., billId warnings) could be condensed. Nonetheless, it remains clear and organized for a complex tool.

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

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

Given 8 parameters, no output schema, and complex behaviors (pagination, credit card nuances, error handling, provider incidents), the description covers all necessary context: response structure, truncation, error responses, sync checks, and cross-connector variations. It leaves no major gaps.

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

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

Schema description coverage is 0%, but the description compensates fully. It explains all 8 parameters: from/to as ISO dates, search_queries as OR substring match, page/page_size dual modes, detail enum with specific row content, and account_ids for bulk. Each parameter's semantics are clear and actionable.

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

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

The description clearly states the tool returns transactions for bank accounts, with explicit distinction for CREDIT accounts as the only way to get itemized transactions. It references sibling tools like openfinance_list_credit_card_bills for bill totals, effectively differentiating its 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 extensive guidance: when to use this tool (e.g., for CREDIT itemized transactions), when not (don't sum by billId; use openfinance_list_credit_card_bills for totals), and includes context for edge cases like sync failures, pending/posted behavior, and provider incidents. It explicitly advises narrowing from/to on truncation and checking account echo.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds critical behaviors: a cap of 5000 transactions per account with a 'truncated:true' flag, and a 'provider_incident' block indicating possible incomplete results due to provider issues. These are valuable for safe invocation.

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

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

The description is comprehensive and well-organized, starting with purpose and then systematically covering parameters and behaviors. While it is lengthy, every sentence provides essential information, and the front-loaded purpose helps agents quickly grasp the tool's role.

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 outlines the return format (compact summary with totals, monthly evolution, top items, per-account breakdown; raw rows with optional enrichment). It also covers limitations (truncation, provider incidents) and bulk support. Minor ambiguity remains about the interaction between 'granularity' and 'detail'.

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 detailing all parameters: item (connector_id/connector_name/item_id), from/to (ISO dates), granularity (monthly vs raw), detail (compact/rich/raw), type (BANK/CREDIT), top_n (implied for top expenses), and bulk item_ids. It adds meaning beyond the schema's bare structure.

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 performs consolidated cash-flow analysis for a whole bank connection in one call, avoiding the need for separate account listing. It distinguishes itself from sibling tools like openfinance_list_transactions by resolving accounts internally. The verb 'list_transactions_by_item' is accurately reflected.

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

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

The description explains when to use this tool (for consolidated analysis) and when to use alternative granularities ('raw' only when itemized rows needed). It also mentions bulk support via item_ids. However, it does not explicitly exclude scenarios where other tools like openfinance_list_accounts might be better, but the context is clear enough.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating a safe read operation. The description adds context on what is returned (global indicator, degraded components, open incidents, your_banks_affected) without contradicting annotations. It enriches transparency but does not compensate for missing annotation coverage since annotations are already present.

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: it starts with the core purpose, then provides usage guidance, and finally lists return values. Every sentence adds value, though it could be slightly more compact 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 no output schema and zero parameters, the description provides a detailed overview of return fields (global indicator, degraded components, open incidents, your_banks_affected), sufficiently covering what the agent can expect. The tool's complexity is low, and the description is complete.

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

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

No parameters exist, so schema coverage is 100%. The baseline for 0 parameters is 4. The description does not need to add parameter semantics, and it does not attempt to, which 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 checks the LIVE operational status of the Open Finance provider's public status page, distinct from the user's connection status via openfinance_get_item_status. It specifies the resource (provider health) and scope (public status page), making 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?

Explicitly advises when to use the tool: when data looks incomplete or stale despite a connection showing UPDATED, and explains it reveals upstream outages. It also distinguishes from the sibling tool openfinance_get_item_status, providing clear context for selection.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable behavioral details: caveat warnings for non-Open-Finance connectors, plan-based visibility, and that empty keywords returns a hint. No contradictions with annotations.

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

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

The description is a single paragraph but packs a lot of useful information. Every sentence adds value, though it could be slightly restructured for brevity. It is front-loaded with the main verb and resource.

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 search tool with no output schema, the description covers all key aspects: return fields (connector id, access, audience, linked connections, connect_url, caveat), plan behavior, and the consequences of omitting keywords. It leaves no obvious gaps for an agent to misunderstand.

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

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

Schema description coverage is 0%, but the description explains both parameters thoroughly: keywords is array of bank names (required), include_accounts triggers account details in response. It also notes that omitting keywords yields a hint (not a full catalog dump).

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

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

The description explicitly states the tool searches bank connectors by name (keywords). It distinguishes itself as a pre-connect search step, unlike the 'connect' sibling. It clearly indicates the return fields and the purpose of providing a one-click connect URL.

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

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

The description commands 'Call this BEFORE connecting' and specifies that keywords[] is required, otherwise it returns a hint. It also explains plan-based filtering (PF hides PJ banks). It does not need to exclude alternative tools explicitly because the context of 'before connecting' is clear.

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

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

The description discloses that it overrides automatic categorization AND teaches Pluggy by creating a Category Rule. It also describes batch behavior with per-item errors not failing the whole batch. Annotations set readOnlyHint=false, consistent with a write operation; description adds significant context beyond annotations.

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

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

The description is detailed but not overly verbose. It front-loads the action and packs necessary information about side effects and error handling. Minor redundancy could be trimmed, but overall 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 complexity (batch update with side effects, no output schema), the description fully covers behavior, parameter sources, side effects, and error handling. It is complete enough for an agent to use correctly.

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

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

With 0% schema description coverage, the description fully explains the single parameter 'items' as an array of { transaction_id, category_id } and provides sources for the IDs. This adds necessary 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 it corrects the category of transactions via PATCH /transactions/:id, specifying the verb and resource. It distinguishes itself from sibling tools like list tools by indicating it modifies data.

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 this to fix miscategorized transactions and improve categorization accuracy going forward.' It explains the side effect of creating a Category Rule, but does not explicitly state 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 indicate idempotentHint=true and destructiveHint=false, so the description does not need to restate those. It adds that the tool is for reporting feedback, which is helpful 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 clear sentence that front-loads the purpose. No wasted words, though it could be slightly more comprehensive.

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

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

No output schema exists, but the description does not explain what happens after reporting (e.g., acknowledgment, response format). Additionally, the 'context' parameter is not clarified, leaving gaps.

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

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

Schema coverage is 0%, so description compensates partially by explaining the 'conversation' parameter. However, 'message' (required) and 'context' are not explained, limiting completeness.

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 sends feedback, and specifies including the conversation array for reproduction. This differentiates it from the sibling tools, which are primarily focused on openfinance operations.

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

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

The description advises including the conversation array, but does not explicitly state when to use this tool over alternatives or provide exclusions. Usage is implied but not fully guided.

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

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

Annotations already mark it as read-only and idempotent. Description adds that it returns version strings, which is valuable context beyond annotations.

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

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

Single sentence, zero waste, efficiently communicates 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 parameterless, read-only tool with no output schema, the description fully covers what the tool does and what information it returns. No gaps.

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

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

No parameters. Schema coverage is 100% trivially. Baseline score of 4 applies; description adds no unnecessary detail.

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 shows current MCP platform and adapter versions. Verb 'show' and specific resource distinguish it from sibling tools like toolkit_info which may show different info.

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

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

No explicit when/when-not to use. Simple tool, but competing sibling toolkit_info exists; description doesn't clarify when to prefer this over that.

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 safety profile is known. The description adds meaningful context by specifying exactly what 'toolkit state' includes (installed MCPs, connection status, accounts, catalog tool counts), which goes beyond the annotations and helps the agent anticipate the return content.

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 that front-loads the verb 'Returns', then uses a colon and comma-separated list to enumerate the components. It is concise with no extraneous words.

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

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

For a zero-parameter, read-only info tool, the description adequately conveys what information is returned. It does not provide a detailed return schema, but the enumeration of key elements is sufficient given the tool's simplicity and the presence of safety annotations.

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

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

The tool has zero parameters, so there are no parameter semantics to clarify. The baseline of 4 applies because there is no ambiguity in invocation.

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 the specific verb 'Returns' with a clear resource, 'the current toolkit state', and enumerates its components (installed MCPs, connection status, accounts, catalog tool counts). This distinguishes it from siblings like show_version, which likely focuses on version info.

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

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

The description implies usage for inspecting toolkit state but provides no explicit when-to-use guidance or alternatives. There is no mention of when not to use it or how it relates to similar tools like openfinance_provider_status or show_version, so the guidance is only implied from the described purpose.

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