ASA MCP

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

Annotations already indicate idempotentHint=true and destructiveHint=false. Description adds that calling with no args returns a link, and with token sets session login. No contradictions.

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

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

Description is moderately concise, front-loads core purpose. Sentences are efficient though slightly verbose with alternative config advice.

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 an authentication tool with no output schema, description covers both session and permanent modes, expected user actions, and output (link or success). Complete for intended 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 has one optional string 'token' with 0% coverage. Description explains its meaning: paste token for session login or omit to get login link, providing essential semantics missing from schema.

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

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

Description clearly states the tool authenticates IDE agents to MCP.AI, explaining login methods and token usage. It is a distinct authentication tool among siblings.

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?

Description explains when to use: for logging in via browser and obtaining a token, either as persistent header or session. It gives explicit steps but does not mention when not to use or compare to siblings like 'connect'.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing the tool's response in different states (all connected vs missing credentials), including the presence of connect_url and per-install URLs. No contradictions with annotations.

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

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

The description is concise: two sentences that are front-loaded with the main purpose, followed by specific scenarios. Every sentence adds value with no waste.

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

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

For a simple tool with no parameters and no output schema, the description covers the two main states and gives hints about the response structure (authenticated, pending, connect_url). It does not fully describe the return format, but it is adequate given the tool's simplicity and the context from 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 0 parameters, and schema coverage is 100%. Per guidelines, baseline is 4 when no parameters exist. The description adds no parameter information because none are needed.

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

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

The description clearly states the tool returns connection status and URLs, with specific details about two scenarios (all connected vs missing credentials). It distinguishes itself from sibling tools like 'authenticate' or 'openfinance_list_connections' by focusing on a simple status check.

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 on when to use the tool (to check connection status) and what output to expect in different states. However, it does not explicitly state when not to use or name alternative tools, which would make it a 5.

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 key behaviors beyond annotations: invoke works without installation, returns connect/checkout links when auth/payment needed, and writes require owner/admin. Annotations declare readOnlyHint=false, consistent with the description's mention of writes.

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 highly structured, front-loaded with the core flow and then covering prompt library and permissions. It is dense with useful details and has minimal filler, though the length is substantial.

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

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

Given the tool's complexity (23 params, 14 actions) and lack of output schema, the description covers all major flows, edge cases (credential/payment), and permission requirements. It is sufficiently complete for an agent to select and invoke the tool correctly.

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

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

With 0% schema description coverage, the description compensates by explaining the action enum and the purpose of core parameters (query, mcp_id, tool_id, arguments, prompt_slug, etc.). However, some parameters like immediate, conversation, and cancel_reason remain unexplained, leaving minor 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 identifies the marketplace as the in-platform catalog of MCPs and the way to run them, with a specific core flow (search → describe → invoke). It distinguishes itself from siblings like openfinance_* by being a meta-tool for discovery and execution.

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

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

Explicitly explains when to use each action (e.g., 'prefer invoke for a single/occasional use', 'Use install only to make an MCP PERMANENT'), and contrasts with alternatives like list_tools. Also mentions owner/admin requirement for writes.

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 destructiveHint: true, which aligns with 'revokes' and 'deletes'. The description adds value by mentioning that data becomes unavailable and that a reconnection URL is returned. 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?

Three short sentences, front-loaded with the primary action. No redundant or unnecessary information. Every sentence adds a distinct piece of information (action, consequence, return 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?

For a simple destructive tool with one param and no output schema, the description covers purpose, effect, and return value. However, the parameter remains unexplained, which is a notable gap. Overall adequate but not fully complete.

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

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

The single parameter 'item' (string, required) has no description in the schema (0% coverage), and the tool description does not explain what 'item' represents. The agent cannot infer whether it is a bank ID, connection ID, or something else.

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 'revokes' and 'deletes', the resource 'consent' and 'connection data', and the outcome 'data will no longer be available'. It distinguishes itself from sibling tools like openfinance_list_connections by focusing on destruction.

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 disconnecting a bank (revoking consent). It does not explicitly state when to use vs alternatives, nor does it provide exclusions or prerequisites. The context is understandable but lacks direct 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?

Thoroughly explains behavior: it is a write operation (no annotation contradiction), polls up to ~60s, returns timed_out and needs_action states with remedial actions. Details return fields including lastUpdatedAt, synced, reconnect_url. Annotations (readOnlyHint=false, destructiveHint=false) are consistent with the described behavior.

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

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

The description is detailed but every sentence adds value. It is front-loaded with the primary action, then covers parameters, return values, and edge cases in a logical flow. No unnecessary words or 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 complexity of a sync operation with polling, multiple modes, and error states, and the absence of an output schema, the description is remarkably complete. It covers all return fields, error scenarios (needs_action, timed_out), and provides actionable links for user re-authentication.

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. It explains items as an array of selectors (item_id, connector_id, connector_name, custom_label) and that omitting it syncs all. It explains wait parameter semantics (true by default, false for fire-and-forget). No parameters left ambiguous.

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

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

The description clearly states the tool forces a bank to re-sync one or more connections and waits for completion. It uses specific verbs ('forces', 're-sync', 'polls') and identifies the resource ('connections'). It distinguishes itself from siblings like 'openfinance_get_item_status' for re-checking timed-out syncs.

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

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

Explicitly tells when to use ('when a balance or transaction list looks stale') and when not (for timed-out cases, use 'openfinance_get_item_status'). Provides guidance on wait parameter (fire-and-forget vs. waiting) and error recovery (re-authenticate via reconnect_url for needs_action).

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?

Even though annotations already declare readOnlyHint, idempotentHint, and destructiveHint, the description adds substantial behavioral context: snapshot semantics tied to the last upstream sync, updateDateTime meaning, credit-account error modes (BALANCE_FETCH_ERROR, BALANCE_CONSENT_ERROR), graceful degradation with realtime:false and warnings, and the response envelope. This goes well beyond the annotations.

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

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

The description is long but dense and well-structured: it front-loads the core purpose, then adds freshness caveats, failure modes, and response shape in a logical order. Every sentence adds necessary information that the schema and annotations do not provide.

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 behavioral complexity and the absence of an output schema, the description covers everything an agent needs to invoke and interpret results correctly: freshness limits, sync refresh path, per-error handling, degraded rows, and the exact response structure. No critical gap remains.

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. It does by stating that account_ids is passed as an array and explicitly limiting it to 1–50 items. It does not elaborate on the string format of the IDs, but the parameter name and endpoint usage make that reasonably inferable.

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 opens with a precise verb and resource—'Returns the latest available balance per account id'—and cites the exact endpoint. It distinguishes itself from sibling tools by clarifying freshness semantics and explicitly referencing openfinance_force_sync and openfinance_list_transactions for related 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 gives clear guidance on when to call this tool versus alternatives: it notes that the balance is not a live read and directs the agent to run openfinance_force_sync when recent movements are missing or totals disagree with openfinance_list_transactions. It could more explicitly enumerate alternative tools for historical transactions or account details, but the core decision path is present.

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 critical behavioral context beyond annotations: warns about provider_incident block with unreliable values during provider outages, advising not to present them as real. Annotations already indicate read-only, non-destructive, idempotent.

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

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

Three sentences, no wasted words. Front-loaded with core purpose, then usage format, then important warning. Excellent structure.

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

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

Covers key usage details and a critical edge case (provider incident). Could briefly mention that response includes full account objects with creditData, but for a single-parameter tool it is quite thorough.

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?

Provides meaning beyond the minimal schema (which has no description): specifies array size constraint (1-50) and batch result format. Schema coverage is 0%, so description compensates well.

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

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

The description clearly states it returns full account objects with extended creditData by ID, distinguishing it from the sibling list_accounts tool which likely provides a summary list.

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

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

Specifies the parameter format (array of 1-50 IDs) and the batch result shape { results, errors }, but does not explicitly differentiate when to use this vs list_accounts.

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 builds beyond those without contradicting them. It discloses subtle behaviors: the bank payload contains no transactions (opt-in triggers an extra scan), the three possible values of transactions_basis and what each means, that totalAmount is authoritative and must not be re-derived by summing, that Pluggy does not return a paid/status field, and the counterintuitive semantics that Brazilian Open Finance payments[] typically refer to the previous bill. This is exactly the kind of context an agent cannot infer from annotations or schemas.

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 every sentence earns its place: can't afford to waste space given the hidden semantics (false paid-status assumptions, estimated transactions, scan costs). Core data is front-loaded before the opt-in mechanics and gotchas. The main deduction is that it's a dense wall of text without bullet breaks or bolded terms; a light structural pass would make the key warnings (totalAmount authoritative, payments[] = previous bill) easier to surface for a quick-reading agent.

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 and zero schema_parameter descriptions, the description has to deliver everything, and it does. It covers the return shape, the optional enrichment path, the reconciliation field (reconciles_with_total), the estimation basis and its confidence, the batch shape { results, errors }, the paid-status limitation with a recommendation, and a fallback to list_transactions. For a tool this complex (Braziliian Open Finance bill semantics), an agent has enough to select, call, and correctly interpret the result.

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 carry the full burden for all four parameters. It explains bill_ids ('Pass bill_ids as an array — use list first'), include_transactions ('plus account_id of the credit card, since the bill itself carries no account reference'), and account_id's role implicitly. However, transactions_detail ('compact', 'rich', 'raw') is never described — the agent cannot tell what 'rich' or 'raw' yields without guessing. That gap keeps this from a 5.

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 opens with a specific verb and resource — 'Returns bill-level detail for one or more credit card bills by id' — and enumerates the exact fields returned (dueDate, billClosingDate, totalAmount, financeCharges, payments[]). It clearly differentiates itself from siblings: it's the detail tool distinct from openfinance_list_credit_card_bills (discovery/payment_status) and openfinance_list_transactions (transaction fetching on the account).

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

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

Usage context is explicitly spelled out: 'use openfinance_list_credit_card_bills first to discover ids', 'To check paid status, prefer openfinance_list_credit_card_bills', and for transactions 'fetch them yourself via openfinance_list_transactions'. It also states when NOT to use the opt-in (costs an extra full transaction scan) and when the estimate is unavoidable (open bills have no billId until the cycle closes). Alternatives are named outright and the selection criteria are 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, destructiveHint=false. The description adds valuable behavioral context, such as the reconnect_url reopening the widget in UPDATE mode without disconnecting or consuming a connection slot, and the return format for bulk vs. single queries. 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 reasonably concise and front-loaded with the core purpose (status, executionStatus, connector metadata, reconnect_url). It avoids redundancy but could be more structured by separating single vs. bulk use cases more clearly.

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

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

The description covers return values (status, executionStatus, connector metadata, reconnect_url) and usage variations, but fails to explain the `item_id` parameter. Given no output schema, the description should be fully self-contained; the missing parameter detail 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 description explains `item` (single bank) and `item_ids` (bulk support) but does not clarify the role of `item_id`. With 0% schema coverage, the description should cover all parameters. The omission of `item_id` weakens the parameter semantics.

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

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

The description clearly states that it returns the current status of a bank connection, lists possible status values (UPDATED, UPDATING, LOGIN_ERROR, etc.), and explains the difference between querying all connections vs. a single one. It also mentions bulk support via item_ids. This specificity distinguishes it from sibling tools.

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

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

The description provides explicit guidance on when to omit `item` (for all banks) and when to pass it (for a single bank), as well as how to use `item_ids` for batch execution. While it does not explicitly contrast with sibling tools like `openfinance_list_connections`, the usage scenarios are clearly 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?

Annotations already indicate readOnly, idempotent, non-destructive. Description adds that it's a GET request and returns a batch shape, but does not describe error details or rate limits. No contradictions.

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

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

Two sentences: first lists return fields, second gives usage and parameter constraint. No wasted words, well organized.

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

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

Despite no output schema, the description enumerates key return fields (interestRates, charges, schedule, etc.) and batch shape, sufficient for an agent to understand the output fully.

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

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

Schema has 0% description coverage for the lone parameter. Description adds that loan_ids is an array (1-50 items), which is critical usage detail beyond the schema's type definition.

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

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

The description clearly states the tool returns full loan contract detail by ID, listing many fields. It distinguishes from the sibling openfinance_list_loans by specifying it's for deep-diving into a specific contract after listing.

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

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

Explicitly states 'Use after openfinance_list_loans to deep-dive on a specific contract' and specifies passing loan_ids as an array of 1-50 items. Also mentions batch shape with results and errors.

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

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

Beyond the readOnly/idempotent annotations, the description discloses many non-obvious runtime behaviors: connector-dependent `balance` meaning for CREDIT accounts, `balance_notice` semantics, lagging `bankData` fields, `provider_incident` unreliability, and `identity_notice` deduplication guidance. This is substantial value added 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 and dense, but nearly every sentence conveys operationally relevant caveats or routing guidance. A bit of trimming could tighten it, yet it remains front-loaded with the core purpose and then builds to edge cases without filler.

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

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

Given the complexity, no output schema, and 0% schema coverage, the description is remarkably complete: it covers return shape, field semantics, multi-connection aggregation, credit-card pitfalls, provider incidents, ownership notices, bulk execution, and cross-tool alternatives.

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 carries the full burden. It thoroughly explains `item` omission vs. passing, and `item_ids` batch support. However, `item_id` is mentioned as an output field and parameter but never explicitly explained as a call parameter, leaving a small ambiguity about how it differs from `item`.

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 accounts for a bank connection') and enumerates the account types and returned fields. It also explicitly differentiates the tool from openfinance_list_credit_card_bills by clarifying that standardized bill amounts come from that sibling instead.

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 selection criteria: omit `item` to aggregate across all linked banks, pass `item` to target one bank, and use openfinance_list_credit_card_bills when standardized card bill amounts are needed. It also references openfinance_force_sync as the reconciliation mechanism for lagging 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?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: caching for the session, single aggregated response, no batch ids, and explains the tree structure (parentId, parentDescription). This goes beyond annotations.

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

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

The description is concise and front-loaded with the main purpose. Each sentence is informative: function, caching, field details, relationship to sibling. Could be slightly more compact but 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?

For a tool with no parameters and no output schema, the description fully explains the output fields (id, description, descriptionTranslated, parentId, parentDescription) and behavioral traits (cached, single response). It is complete for an agent to understand and invoke correctly.

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

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

There are no parameters (0 params, 100% schema coverage). The description does not need to add parameter info as there are none. Baseline 4 applies.

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 Pluggy's transaction category taxonomy (GET /categories)', specifying the verb and resource. It distinguishes from siblings by noting the category IDs are used by openfinance_update_transaction_category and that it's cached.

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

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

The description implies usage for retrieving category taxonomy for use with other tools like openfinance_update_transaction_category, but does not explicitly state when to use it versus alternatives or when not to use it. No exclusions or context for when it would be inappropriate.

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

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral details: the reconnect_url behavior (opens widget in UPDATE mode, does not consume a slot, does not require disconnecting). This goes beyond the annotations by explaining side effects and limitations.

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

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

The description is concise at about 5 sentences, front-loaded with the main purpose, then providing additional details on the returned fields and reconnect_url semantics. Every sentence adds value, and there is no 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?

With no output schema, the description must explain return values, which it does by listing the fields. It also explains the crucial reconnect_url behavior and its use case. This is complete for a list tool, covering both what is returned and how to use the returned URLs.

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

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

The input schema has no parameters (0 params), so schema coverage is trivially 100%. The baseline for zero-parameter tools is 4. The description does not add parameter-specific meaning, but none is needed.

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 starts with 'Returns the saved bank connections for this install', clearly stating the action (return) and resource (bank connections). It lists specific fields returned: connector_id, item_id, bank name, reconnect_url, add_connection_url. This distinguishes it from sibling list tools like openfinance_list_accounts or openfinance_list_transactions, which have different scopes.

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 the reconnect_url (for re-authentication), but does not explicitly state when to use the tool itself vs alternatives. However, the purpose is clear enough that an agent would infer when listing connections is needed. It provides good context about the widget and connection slots, which aids decision-making.

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

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

Annotations declare readOnlyHint=true and idempotentHint=true, and the description reinforces reading behavior while disclosing complex derivations (payment_status logic, payments[] cross-bill assignment, connector asymmetry, open bill unavailability). It explains edge cases like 'PAST_DUE_UNCONFIRMED' and warns about per-connector inconsistencies. 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 verbose but well-structured with sections (e.g., 'CONNECTOR ASYMMETRY:', 'Bulk support:') and uses formatting like '—' and 'IMPORTANT' to highlight critical points. Every sentence adds value for the complex domain. It is front-loaded with essential return data. Slight room for trimming but justified by informational density.

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

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

Given no output schema, the description fully details the return structure (fields like dueDate, totalAmount, payments[], payment_status, open_bill) and covers edge cases, warnings, and instructions for cross-bank verification. Parameter explanations cover most inputs, and behavioral notes ensure agents can handle all scenarios correctly.

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

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

Schema description coverage is 0%, so the description must explain parameters. It discusses account_id (required), account_ids (bulk support), and include_open_bill (opt-in) in detail. However, page and page_size pagination parameters are not explicitly described, though they are standard. The description partially compensates for the lack of schema descriptions but misses two parameters.

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

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

The description clearly states it 'Returns CLOSED credit card bills for a CREDIT-type account' with specific fields. It distinguishes from sibling tool 'openfinance_get_credit_card_bill' (singular) and explains the scope as bill-level summaries. The verb and resource are explicit and unambiguous.

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

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

The description provides extensive guidance: when to use this tool (to get closed bills), when to use alternatives (e.g., openfinance_list_transactions for itemized purchases), and explicit warnings (e.g., not to assume payments[] indicates paid bill, not to reconstruct totals by billId). It also explains the opt-in parameter for open bill and connector asymmetry, leaving no ambiguity about appropriate usage.

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 details: error handling (graceful fallback on 403), data integrity cross-checking, suspect-zero row flagging, and instructions to treat those as unavailable. This goes well beyond annotations and is highly valuable.

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 purpose and returns a wealth of detail. While comprehensive, it could be slightly more concise by separating parameter documentation. Overall, every sentence contributes 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?

The description covers core behavior, error handling, and data integrity. However, without an output schema, it only partially lists return fields. Parameter documentation is incomplete. For a complex tool, this is good but not exhaustive.

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

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

With 0% schema coverage, the description must explain parameters. It only mentions 'item_ids' for bulk support and implicitly uses 'type' via the enum, but does not document 'item', 'page', 'page_size', or 'item_id'. This leaves AI agents guessing about half the parameters.

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

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

The description starts with a clear verb ('Returns') and specifies the resource ('investment portfolio for a connection'), listing all investment types covered. It distinguishes from siblings 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 provides context on when to use the tool (for connections with INVESTMENTS enabled) and mentions bulk execution via item_ids. However, it does not explicitly state when not to use this tool or compare directly with sibling tools, which is a minor gap.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, which the description does not contradict. The description adds value by listing the transaction types and fields returned (quantity, value, amount, etc.), giving the agent more behavioral context 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 two brief paragraphs. The first explains what the tool returns, the second gives usage guidance. Every sentence provides useful information, no fluff.

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

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

No output schema exists, but the description enumerates key returned fields. It does not specify pagination behavior or default values for page/page_size, which would be helpful. Overall, it is fairly complete for understanding the tool's core purpose and usage.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains investment_id (prerequisite) and investment_ids (bulk support), but does not mention page or page_size. This adds some meaning but is incomplete for all parameters.

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

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

The description clearly states it returns movement history for a specific investment position, listing specific transaction types (BUY, SELL, etc.). It distinguishes itself from sibling tools like openfinance_list_investments and openfinance_list_transactions by specifying it's for a specific investment position and listing detailed fields.

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

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

The description explicitly says 'Use after openfinance_list_investments to get the investment_id', providing a clear prerequisite. It also mentions bulk support with investment_ids. However, it does not explicitly state when not to use this tool, 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 indicate readOnly, idempotent, non-destructive. Description adds sequential execution, rate-limiting, and return structure of `{ results, errors }` per connection, providing valuable behavioral context beyond annotations.

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

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

Three sentences with front-loaded purpose. No wasted words, but includes the endpoint detail (GET /loans) which is redundant with name. Otherwise 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 a single optional parameter and no output schema, the description provides sufficient context on usage and return format. No pagination details, but reasonable for a list tool with rate-limit spacing mentioned.

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

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

Schema has 0% description coverage. Description fully compensates by defining `items` as connection selectors (item_id, connector_id, connector_name), explaining one per connection and sequential behavior. Adds critical meaning absent from schema.

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

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

The description clearly states the tool lists loan contracts per bank connection, specifying the endpoint. It distinguishes itself from sibling tools like openfinance_get_loan_detail, which targets a single loan.

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

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

Explicitly explains when to pass `items` (for specific connections) and when to omit it (all linked banks). Describes sequential querying with rate-limit spacing. Does not directly contrast with get_loan_detail but implies difference via scope.

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 reveals auto-pagination versus manual pagination, the 5000-transaction truncation ceiling, error-return behavior instead of throwing, future-dated scheduled rows, provider incidents, and inconsistent `billId` data. These behavioral traits are not visible in the annotations or schema and are fully disclosed.

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, and each major behavior has a clear labeled section (e.g., PENDING vs POSTED, SCHEDULED ROWS, PAGINATION). It is slightly redundant, particularly around the billId warning repeated in both the intro and the rich-detail section. It is justified coverage for a complex domain, though not perfectly concise.

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

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

There is no output schema, but the description explicitly documents the `account` echo block, `scheduled_count`, `notice`, `truncated`, `total:0` error shape, and provider incident behavior. It also tells the agent how to resolve failure modes through sibling tools. This fills the missing schema coverage very completely.

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 descriptions are 0%, and the description compensates extensively: from/to ISO format, date filter, `search_queries` case/accent-insensitive OR matching, `page`/`page_size` manual mode, and `detail` enum semantics including compac/rich/raw. The only noticeable gap is `account_ids`, which is not clearly explained as a batched variant, even though every other parameter has meaningful guidance.

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

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

The opening sentence names the exact resource and operation: returns transactions for a bank account of type BANK or CREDIT. It further says that for CREDIT accounts this is the ONLY way to get itemized transactions, which clearly separates it from the transaction-bill tools. This is specific, not a tautology.

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 routing: use openfinance_list_credit_card_bills for standardized open-bill totals, openfinance_list_accounts for closing/due dates, and openfinance_get_item_status when a credit account returns zero. It also gives conditional guidance like passing `to = today` to exclude future-dated rows. Alternatives and exclusions are explicitly named.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description discloses important behavioral traits: internal account resolution, caps at 5000 transactions/account with truncation flag, provider incident block causing incomplete data, and bulk support via item_ids. All consistent 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 long but front-loaded with the main purpose and key differentiator. Logical flow: purpose, convenience, parameter details, use cases, exceptions. Some redundancy (e.g., 'also' in raw mode) but generally efficient for the information density.

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

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

Given no output schema, the description thoroughly explains the return structure (compact summary fields, raw rows, top items, per-account breakdown) and edge cases (truncation, provider incidents). Covers all 9 parameters sufficiently and provides context for execution.

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

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

With 0% schema description coverage, the description compensates by explaining item (connector_id, name, or item_id), from/to as ISO dates, granularity values, detail options (compact, rich, raw), and type filter. Implicitly describes top_n via 'largest N each.' Could be more explicit about top_n parameter name.

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: 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call.' It distinguishes itself from having to call openfinance_list_accounts first, and contrasts with sibling tools like openfinance_list_transactions by offering aggregation and bulk analysis.

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 omit 'item' to analyze all banks, when to use monthly vs raw granularity, and example use cases ('análise anual/mensal', 'fluxo de caixa'). It tells you not to call openfinance_list_accounts first. However, it does not explicitly compare to all sibling tools or say when not to use this 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 declare readOnlyHint, idempotentHint, destructiveHint. Description adds what the tool returns: global indicator, degraded components, open incidents, and affected banks. No contradictions.

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

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

Front-loaded with core purpose, then usage scenarios, then return details. No wasted words, 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 parameters or output schema, but description fully explains return values (indicator, components, incidents, affected banks) and differentiates from siblings. Complete for 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?

Input schema has zero parameters so schema coverage is 100%. No parameter explanation needed; baseline 4 per guidelines.

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 checks the LIVE operational status of the Open Finance provider, distinguishing from sibling tool openfinance_get_item_status by specifying 'PROVIDER's health' vs 'own connection'.

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

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

Explicitly states when to use: when data is incomplete/stale despite UPDATED connection status. Provides specific indicators (missing accounts/transactions/balances) and distinguishes from reconnection scenario.

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

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

The description reveals non-obvious behaviors: plan-based filtering (PF hides PJ), caveat warnings for non-Open-Finance connectors, and that keywords are required. Annotations already mark it as read-only and idempotent, so description adds valuable context without contradiction.

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

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

The description is a single, dense paragraph that conveys all necessary information without fluff. It could be slightly more structured (e.g., separated notes), but every sentence earns its place.

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

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

Given the tool's moderate complexity (2 params, plan handling, caveats, no output schema), the description covers return fields, usage flow, and edge cases (empty keywords, plan types). 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?

The input schema has 0% description coverage, but the description compensates by explaining that keywords[] is required and provides example usage, and include_accounts triggers account details. This adds critical meaning beyond the bare schema 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 searches bank connectors by name and returns specific fields (id, access, audience, connections, connect_url). It differentiates from siblings like 'connect' and 'openfinance_list_connections' by specifying its role as a pre-connect search.

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 'Call this BEFORE connecting' and explains that keywords are required, with a fallback hint. However, it does not explicitly list when not to use it, though the context implies it's for targeted search, not bulk listing.

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

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

Discloses critical side effect: recategorizing creates a Category Rule affecting future transactions. Also explains batch error handling (per-item errors don't fail whole batch) and response shape. Compensates fully for lack of 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?

Every sentence adds value; no redundancy. Front-loaded with purpose, followed by param details, side effects, and error handling. Efficient and well-structured.

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

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

Despite no output schema, description provides complete batch response shape and error handling. Covers purpose, param semantics, side effects, and error mode. 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?

Despite 0% schema coverage, description fully explains the `items` parameter: array with required fields, source of each field, and the implication of using it. Adds significant meaning beyond 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?

Clearly states the tool corrects category of one or more transactions, with HTTP method and endpoint. Distinguishes from sibling tools by specifying source of IDs (openfinance_list_transactions, openfinance_list_categories).

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

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

Explains when to use (fix miscategorized transactions, improve categorization) and provides guidance on obtaining IDs from sibling tools. Lacks explicit when-not-to-use or alternatives, but context is adequate.

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 idempotentHint=true and destructiveHint=false, so safety profile is clear. The description adds that conversation array is used for reproduction, which is useful contextual 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, no fluff. Front-loaded with the tool's purpose, followed by a key usage instruction. Every word earns its place.

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

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

For a simple reporting tool with no output schema, the description is largely complete. It could mention the required message parameter more explicitly, but the overall context is sufficient.

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

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

With 0% schema description coverage, the description partially compensates by explaining the conversation parameter. However, it does not clarify the required 'message' or optional 'context' parameters beyond the general purpose.

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

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

The description clearly states the tool reports bugs, missing features, or sends feedback (verb+resource). It distinguishes from sibling tools which are predominantly financial data retrieval 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?

Provides a usage tip to include the conversation array for reproduction, implying the tool is for reporting with context. No explicit when-not-to-use or alternatives, but no competing sibling tool exists.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds that it shows versions, which is consistent. No further behavioral context is provided, but none is needed given the simple read operation.

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 is perfectly concise and front-loaded with the action. There is no wasted 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 no parameters, no output schema, and robust annotations, the description is complete. It conveys everything an agent needs to know to invoke the tool correctly.

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

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

There are no parameters, and schema coverage is 100% trivially. The description does not add parameter information, but per the rule, 0 parameters baseline is 4.

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

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

The description clearly states the tool shows current MCP platform and adapter versions, using a specific verb and resource. It is easily distinguishable from sibling tools, which are mostly openfinance-related or authentication 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 implicitly indicates use when version information is needed. With no parameters and a straightforward purpose, explicit guidelines are not critical. However, it does not explicitly list when to use versus alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond these by specifying what state is returned (installed MCPs, connection status, connected accounts, catalog tool counts). 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?

A single, front-loaded sentence that immediately states the verb and object. No filler, every phrase adds specificity about the returned state.

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 simple nature, absent output schema, and strong annotations, the description fully covers what the agent needs to know: what kind of state is returned and what components are included. No obvious 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?

The tool has zero parameters, so the schema leaves nothing to explain. The description focuses on output semantics instead, which is entirely appropriate for a parameterless tool.

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

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

The description uses a specific verb 'Returns' and a concrete resource 'current toolkit state', then enumerates exact contents (installed MCPs, connection status, accounts, catalog tool counts). This clearly distinguishes it from sibling tools like show_version or 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 implies clear usage: when a summary of toolkit state is needed, use this tool. It does not explicitly mention alternatives or exclusions, but the context is unambiguous enough for an agent to select it appropriately.

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