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?

Annotations already carry readOnlyHint/idempotentHint/destructiveHint, and the description adds substantial behavior beyond them: the freshness caveat (snapshot anchored to last upstream sync, not a live read), the updateDateTime semantics, structured warnings instead of throws for CREDIT accounts (BALANCE_FETCH_ERROR, BALANCE_CONSENT_ERROR), and row degradation with realtime:false on upstream 5xx. Nothing contradicts 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?

Front-loaded with purpose, then logically ordered caveats: freshness semantics, recovery path, parameter format, credit-card error modes, degradation behavior, response shape. It is long, but each sentence earns its place given the error complexity; minor redundancy exists in the two 'instead of throwing/error' clauses.

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 supplies the response shape '{ results: [...], errors: [{ id, status, message }] }' plus the row fields that matter (realtime, updatedAt, warning), covering param constraints, error conditions, and degradation. The one gap is that successful result rows are not fully enumerated (e.g., balance amount/currency field names), so an agent parsing results has to infer the value field.

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

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

Schema coverage is 0%, so the description must compensate — and it does with 'Pass account_ids as an array (1–50)', adding the size bound and confirming the expected format. It does not enumerate the account id string format, but that is largely self-evident from the parameter name and sibling tool 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 first sentence states a specific verb and resource — 'Returns the latest available balance per account id (GET /accounts/:id/balance)' — naming the exact endpoint. This is unambiguous against siblings like openfinance_list_accounts (listing) or openfinance_get_credit_card_bill (credit bills), so an agent can distinguish it without opening the schema.

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 names openfinance_force_sync as the alternative and gives the selecting condition: 'If a movement that just happened is not reflected yet, or the balance disagrees with the sum of openfinance_list_transactions, run openfinance_force_sync to pull fresh data and then re-read.' The recovery sequence is spelled out rather than left to inference.

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 declare readOnlyHint=true and destructiveHint=false, but the description goes far beyond that. It discloses the transactions_basis estimation logic (bill_id vs date_window vs unavailable), the cost of the opt-in ('extra full transaction scan'), the authority of totalAmount (do NOT rebuild by summing), the semantics of payments[] (which may refer to the previous bill), and the lack of a paid field in Pluggy. This is rich behavioral context that prevents misinterpretation.

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 densely packed with essential details. Critical info is front-loaded (what it returns and the main parameters), followed by opt-in behavior, estimation logic, and a crucial payment-status caveat. Every sentence adds value—there's no fluff or repetition. The structure follows a logical flow that an agent can parse efficiently.

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?

There is no output schema, so the description fully explains the response shape: bill fields, transactions[] when opted in, batch {results, errors}, and the transactions_hint. It also covers error-prone edge cases (open bills, pending lines, payments of previous bills). For a tool with this complexity, the description is extremely complete and leaves no critical 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 must compensate. It explains bill_ids (array, use with list tool), account_id (required for include_transactions), and include_transactions (opt-in, triggers extra scan). However, transactions_detail (an enum with values compact/rich/raw) is not explained in the description, leaving a gap for that parameter. Still, the majority of parameters are well covered, so a 4 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 states a specific verb and resource ('Returns bill-level detail for one or more credit card bills by id') and lists the key fields. It clearly distinguishes this from sibling tools like openfinance_list_credit_card_bills (which discovers bill ids) and openfinance_list_transactions (which fetches transactions separately). An agent can tell exactly what this tool does and when it differs.

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

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

The description gives explicit usage guidance: 'use openfinance_list_credit_card_bills first to discover ids' and 'prefer openfinance_list_credit_card_bills which derives payment_status' for paid status. It explains when to pass account_id and include_transactions, and even provides an alternative method for fetching transactions via openfinance_list_transactions. The when/when-not conditions are explicit and actionable.

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?

Annotations already mark this as read-only and idempotent, so the safety profile is covered. The description adds substantial behavioral nuance: connector-dependent credit `balance` semantics, `balance_notice` meaning, stale `bankData` fields after connection creation, provider-incident unreliability, and identity/dedupe caveats for joint accounts. This far exceeds the annotation-only baseline.

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 nearly every sentence contributes operational value: field meaning, cross-tool routing, caveats, and bulk behavior. It is front-loaded with the core purpose and then layers important warnings. It is dense and could be tightened, but it avoids redundancy and fluff.

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

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

For a tool with no output schema and complex credit/incident/identity edge cases, the description is unusually thorough. It explains return fields, caveats, and when to use alternatives. The main missing pieces are explicit semantics for `type` and `item_id`, which keep it from being fully complete.

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

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

With 0% schema description coverage, the description must carry parameter meaning. It does well for `item` (omit vs pass) and `item_ids` (bulk support), but it never explicitly explains the `type` parameter as a filter, and `item_id` is not mentioned. The meaning of BANK/CREDIT is present in the return description but not mapped to the parameter. This is a meaningful gap given 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?

States a specific action and resource: 'Returns accounts for a bank connection' with explicit account categories (BANK/CREDIT) and field names. It clearly separates this tool from nearby siblings like openfinance_list_credit_card_bills and openfinance_get_accounts_detail by describing exactly what it returns.

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

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

Provides explicit when-to-use guidance: omit `item` to list across all banks, pass `item` to target a single bank, and use openfinance_list_credit_card_bills instead for standardized open-bill amounts. It also explains when force sync is relevant and warns against misinterpreting certain fields.

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?

Beyond the readOnly/idempotent annotations, the description discloses key behavior: descending date ordering, scheduled flag semantics, auto-pagination versus manual pagination, 5000-transaction ceiling with truncated:true, fallback error shape, provider_incident block, and per-connector variation in PENDING/POSTED coverage. No contradiction with annotations exists.

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 appropriately so for a high-complexity financial tool with upstream inconsistencies. It is organized into coherent sections (credit behavior, pagination, detail levels, troubleshooting) and front-loads the core purpose. Some billId caveats are repeated, which slightly lengthens the text, but the detail is warranted.

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?

Even without an output schema, the description covers the response shape: account echo, scheduled_count/notice, truncated, total/results, error fallback, and provider_incident block. It also mentions per-row fields for rich/raw detail modes, making the agent sufficiently prepared to interpret results.

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

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

Schema coverage is 0%, but the description fully compensates: explains ISO date filters, search_queries substring and OR semantics, page/page_size switching modes, default page_size limits, detail enum values and their consequences, account_ids bulk support, and the account echo for account_id verification. Every parameter is given actionable meaning.

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

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

States a precise purpose: 'Returns transactions for a bank account (BANK or CREDIT type)' and explains the credit-card-specific role as the 'ONLY way to get itemized transactions'. It also distinguishes itself from siblings like openfinance_list_credit_card_bills and openfinance_list_transactions_by_item via explicit references.

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 guidance on when to use the tool versus alterninates: use openfinance_list_credit_card_bills for an authoritative open-bill total, use openfinance_list_accounts for closing/due dates, and check openfinance_get_item_status when a credit account returns zero. These direct references explicitly map scenarios to alternatives.

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

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

Beyond annotations (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.