Banco do Brasil MCP

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

Annotations show idempotentHint=true and destructiveHint=false. Description adds behavioral context: tool can return a link (no side effect) or authenticate with token (side effect). No contradiction; further clarifies session vs permanent 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?

Three sentences, each providing distinct value: purpose, best practice, usage details. Slightly verbose but no wasted words. Well front-loaded with key action.

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, so description must clarify return values. It implies returning a link with no args but doesn't specify output format or error handling. For a simple auth tool, this is adequate but incomplete.

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 token parameter with no description (0% coverage). Description fully explains its purpose: session-only login when provided, and that omitting it returns a login link. Adds essential 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 specifies the tool's purpose: authentication via browser login and token copy. It differentiates between permanent config and session-only usage, making the verb and resource explicit. No ambiguity.

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

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

Provides explicit usage guidance: best practice to add config header for permanent connection, or paste token for session. Also explains call variants (no args for link, with token for login). Clear when to use each option.

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 and idempotentHint. Description adds behavioral details about response content in two scenarios (connected vs missing credentials), which goes beyond annotations.

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

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

Two concise sentences, front-loaded with main purpose. No wasted words.

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

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

For a zero-parameter, read-only tool, description covers the two main response states. Could mention response structure more formally but adequate.

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 100%, so baseline is 4. Description adds context about response, which is sufficient.

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

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

Description clearly states it returns connection status and URLs, distinguishing two states (connected vs missing credentials). Verb 'returns' plus resource 'connection status' is specific. Siblings like 'authenticate' suggest a different action, though not explicitly contrasted.

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

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

Implied usage for checking connection status, but no explicit when-to-use, when-not-to-use, or alternatives. Does not contrast with sibling 'authenticate' or 'openfinance_list_connections'.

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

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

Goes well beyond annotations by disclosing that invoke runs tools even when not installed, does not bloat the toolkit, returns connect links for missing credentials, returns checkout links for empty wallets, and requires owner/admin for writes. Also explains the prompt library's shareable links that open without login.

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

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

The description is long but well-structured, covering the marketplace flow, invoke nuances, install vs invoke guidance, permissions, and prompt library in a logical order. Every sentence contributes information, though it could be tightened in places.

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

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

Covers the core search→describe→invoke flow, auth/payment edge cases, write permissions, and the separate prompt library. With no output schema, it explains key return behaviors (profile details, connect/checkout links) but does not enumerate outputs or error cases for every action like subscribe, cancel, or report_bug.

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

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

The description adds meaning to the action enum and core parameter relationships (action=search, describe, invoke; tool_id; arguments). However, with 23 parameters and 0% schema coverage, many parameters such as limit, query, prompt_vars, immediate, tier_slug, and cancel_comment are left to be inferred from their names/defaults. The description provides conceptual flow but not a complete parameter reference.

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 defines the tool as the official mcp.ai marketplace and in-platform catalog, plus the way to run MCPs. It specifies the core flow (search → describe → invoke) and distinguishes itself from sibling finance-specific tools by covering capability requests and the prompt library.

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 usage guidance: prefer invoke for one-off use, use install only to make an MCP permanent, use list_tools for what is callable now, and use request_mcp when nothing fits. It also states that write actions require workspace owner/admin, clarifying when the tool is appropriate.

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 confirms the destructive hint from annotations and adds detail on what is deleted and the return of a re-connection URL. It does not contradict annotations, and provides behavioral context beyond the annotation labels.

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 only two sentences, contains no redundant information, and efficiently conveys the action and consequence.

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

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

While the action is clear, the critical gap in parameter documentation makes the tool description incomplete for correct invocation. No output schema exists to compensate, and the agent needs to infer the 'item' meaning.

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 one required parameter 'item' with zero description coverage. The description fails to explain that 'item' refers to the bank identifier or connection ID, leaving the agent without guidance on what to pass.

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 specific verbs ('revokes', 'deletes') and clearly identifies the resource (bank connection data). It distinguishes this tool from sibling tools like connect or list_connections by stating its destructive action.

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 clearly implies when to use it (to disconnect a bank). It does not explicitly exclude alternatives, but the context of sibling tools makes the use case unambiguous.

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 extensively discloses behavior: it polls up to ~60s, returns final status, explains return fields (results, errors, status, executionStatus, lastUpdatedAt, synced, needs_action, reconnect_url, timed_out). Annotations provide readOnlyHint=false and destructiveHint=false, and description aligns with no contradictions.

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

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

The description is well-structured with clear sections and front-loaded key action. However, it is fairly long; could be slightly more concise without losing clarity, but every sentence adds value.

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

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

Given the tool has only 2 params and no output schema, the description provides complete context: behavior, return fields, error states (needs_action, timed_out), and how to handle them. No gaps remain for an AI agent to effectively select and invoke the 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?

Both parameters (wait, items) are fully explained. Items can be selectors (item_id, connector_id, connector_name, custom_label). Omit items syncing all. wait defaults to true (implied) but setting to false makes it fire-and-forget. This compensates for 0% schema description 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 forces a bank re-sync and waits for completion. It specifies the verb ('forces', 're-sync'), resource ('connections'), and distinguishes from siblings by noting no need to disconnect/reconnect and referencing openfinance_get_item_status for checking status after timeout.

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 a balance or transaction list looks stale' and provides a clear alternative: fire-and-forget with wait:false, and fallback: re-check with openfinance_get_item_status if timed_out. Also explains the reconnect_url for re-authentication scenarios.

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

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

Annotations (readOnlyHint, idempotentHint) are consistent with a read operation. The description significantly adds behavioral context beyond annotations, detailing error handling (BALANCE_FETCH_ERROR with warning), degradation to last-synced balance with realtime: false, and response shape. 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 a single focused paragraph, front-loaded with purpose. Every sentence adds unique value (purpose, parameter, error conditions, response shape), with no redundant or extraneous content.

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

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

Despite no output schema, the description fully explains the response shape, error scenarios, and behavioral quirks. For a read-only tool with a single parameter, the description covers all necessary context for correct invocation.

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

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

Schema has 0% description coverage, but the description explicitly states that account_ids is an array with size constraint (1–50), which adds meaningful information beyond the schema's type declaration. Compensates well 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?

Description clearly states 'Returns real-time balance payload per account id' and specifies the endpoint GET /accounts/:id/balance. It distinguishes from sibling tools like openfinance_list_accounts and openfinance_get_accounts_detail by focusing on balance retrieval.

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

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

Description provides clear context on parameter usage ('Pass account_ids as an array (1–50)') and explains behavior for CREDIT accounts and temporary unavailability. It does not explicitly state when not to use or compare to alternatives, but the context of sibling tools and the specific purpose make usage 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 and idempotent. The description adds critical behavioral context: batch shape {results, errors}, provider_incident block, and unreliable credit data warnings, which go 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 efficient, front-loading the purpose and providing necessary details in a few sentences. Slight room for improvement in structure but no wasted words.

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

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

Despite no output schema, the description fully describes the return shape (full objects, batch shape, potential provider_incident block) and usage constraints, making it complete for this simple tool.

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

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

The input schema has 0% description coverage. The description adds size constraint (1-50) and explains the parameter purpose as an array of IDs, compensating for missing schema details.

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

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

The description clearly states the tool returns full account objects with extended creditData for given IDs, specifying the HTTP method and endpoint. It distinguishes from sibling tools like list_accounts which likely provide summaries.

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

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

The description provides specific usage guidance: pass account_ids as an array (1-50) and warns about provider_incident unreliable data. It does not explicitly contrast with alternatives, but 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?

The description adds significant behavioral context beyond annotations, including the batch shape {results, errors}, the absence of a paid/status field from Pluggy, and the nuanced behavior of the payments array. It does not contradict any annotations.

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

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

The description is somewhat lengthy but every sentence adds value. It is front-loaded with the core purpose and well-structured. Minor room for tightening, 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 of credit card bills, the absence of an output schema, and the need to explain payment subtleties, the description is remarkably complete. It covers inputs, output shape, usage flow, and important caveats.

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 'bill_ids' parameter is an array and recommends using list_credit_card_bills to discover IDs. It adds meaning beyond the bare schema.

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

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

The description explicitly states the tool returns bill-level detail for credit card bills by ID, listing specific fields. It clearly distinguishes itself from sibling tools by stating it does NOT return individual transactions and directs to openfinance_list_transactions for that purpose.

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

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

The description provides explicit when-to-use (for bill-level detail), when-not-to-use (for transactions), and recommends alternatives (openfinance_list_transactions). It also advises using openfinance_list_credit_card_bills first to discover IDs, and includes crucial caveats about payment semantics.

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

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

The description adds useful behavioral context beyond annotations, such as the reconnect_url behavior (opens widget in UPDATE mode without slot consumption) and the return fields (executionStatus, connector metadata). 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 but includes some details (e.g., status list, reconnect_url explanation) that could be streamlined. It is front-loaded with the main purpose but slightly verbose.

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

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

No output schema is provided, yet the description only partially describes return values (e.g., bulk returns `{ count, items }` but single bank structure is vague). The undocumented `item_id` parameter also contributes to incompleteness.

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?

While `item` and `item_ids` are explained, the schema lists an `item_id` parameter that is not described, leaving ambiguity. With 0% schema description coverage, the description fails to fully clarify 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 the tool returns the current status of a bank connection, enumerates possible statuses, and distinguishes between querying all banks vs. a single bank, effectively differentiating 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?

Guidance is provided on when to omit `item` (all banks) vs. pass it (single bank), and bulk support via `item_ids` is mentioned. However, it lacks explicit advice on when not to use this tool compared to similar listing tools.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint, so the description adds moderate behavioral context (e.g., batch response structure `{ results, errors }`). It doesn't mention error handling or rate limits, but overall 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 a single paragraph with three sentences, front-loading purpose then fields, usage, and parameter details. No fluff, but could be more structured (e.g., bullet points for fields). Still efficient and informative.

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 complexity and lack of output schema, the description lists many fields and indicates the batch response shape. It also states the endpoint and usage context with sibling. Missing details like authentication are not critical and are covered by 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?

Schema description coverage is 0%, so the description compensates well by specifying 'Pass `loan_ids` as an array (1-50)', clarifying type and range. It also implies the parameter accepts up to 50 items, adding meaning beyond the raw schema.

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

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

The description clearly states the tool returns full loan contract detail by ID, listing specific fields (interestRates, installments, etc.). It also distinguishes from the sibling tool openfinance_list_loans by advising to use it after listing, providing a clear verb+resource+context.

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?

Explicit guidance to use after openfinance_list_loans for deep-diving, and notes the batch parameter limit (1-50 IDs) and response shape. Though it doesn't explicitly state when not to use, the context is strong and covers key usage constraints.

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 read-only, idempotent, non-destructive. Description adds critical behavioral details: credit balance meaning is connector-dependent, provider_incident may produce unreliable data, identity_notice for common accounts. 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 primary purpose and structured into logical sections (bank field, name caveat, usage, credit balance, incidents, deduplication, bulk). While verbose, every sentence adds unique value, so conciseness is adequate.

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 0% parameter descriptions, the description fully compensates by explaining return fields, edge cases (credit balance, incidents, identity), bulk support, and sibling tool usage. It provides complete context for correct invocation.

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

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

Despite 0% schema description coverage, the description mentions all 4 parameters: `item` (used for single bank targeting), `type` (implied by BANK/CREDIT returns), `item_id` (in response context), and `item_ids` (for bulk execution). However, it does not explicitly state that `type` is a filter parameter, requiring some inference.

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

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

The description clearly states it returns accounts for bank connections with detailed fields (balance, type, subtype, etc.) and distinguishes between BANK and CREDIT types. It differentiates from sibling tools like openfinance_list_credit_card_bills by noting which tool to use for standardized bill amounts.

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?

Explicit guidance on when to omit `item` for all banks vs. pass `item` for a single bank, including user-facing scenarios. Directs users to use openfinance_list_credit_card_bills for specific credit card bill information.

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

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

Annotations provide readOnlyHint, idempotentHint, destructiveHint. Description adds behavioral traits: caching per session, single aggregated response, no batch ids. This adds value beyond annotations.

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

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

Four sentences, front-loaded with main action, no redundant 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?

Given no parameters and no output schema, the description fully explains the return structure, caching behavior, and relevance to sibling tools. Complete for agent 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?

No parameters, schema coverage 100%. Description adds meaning by explaining the output structure (id, description, descriptionTranslated, parentId, parentDescription) and usage context. Baseline 4 for 0 params.

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

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

Clearly states it returns Pluggy's transaction category taxonomy, cached for the session, with specific fields. Distinguishes itself from siblings by linking to openfinance_update_transaction_category, which uses the categoryId.

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 by mentioning the categoryId is used by a sibling tool (openfinance_update_transaction_category), and notes caching and single aggregated response. Lacks explicit 'when to use' or alternatives, but the connection is strong.

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

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

The description adds significant behavioral context beyond the annotations (readOnlyHint, destructiveHint). It explains that reconnect_url reopens the widget in UPDATE mode, refreshes data in place, and does not require disconnecting. 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, well-structured paragraph that front-loads the main purpose. Every sentence adds value: listing returned fields, clarifying reconnect_url behavior, and noting it does not consume a slot. 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?

The description explains all returned fields (connector_id, item_id, bank name, reconnect_url, add_connection_url) and provides detailed behavior for reconnect_url. It does not mention pagination or limits, but for a connection list tool, this is sufficient. Minor gap for 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 tool has zero parameters, and schema coverage is 100% (empty). Per guidelines, no parameters baseline is 4. The description adds no parameter information as none are needed, but it does describe the return fields which is relevant for usage.

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

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

The description explicitly states it returns saved bank connections with specific fields (connector_id, item_id, bank name, reconnect_url, add_connection_url). The verb 'list' combined with the resource 'connections' is clear and distinct from sibling tools like openfinance_list_accounts which serve different purposes.

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 specific guidance on when to use reconnect_url (for re-authentication after LOGIN_ERROR), clarifying it does not consume a connection slot. While it doesn't explicitly compare to all siblings, the usage context is adequately explained for a read-only list operation.

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 significant behavioral detail: payment cycle semantics, payment_status derivation, connector asymmetry, and bill_grouping_reliability warnings. 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 lengthy but well-structured with sections like CONNECTOR ASYMMETRY and BULK SUPPORT. It front-loads the core purpose. Some redundancy exists (e.g., multiple warnings about not reconstructing totals), but each section adds necessary domain-specific context. Could be tightened slightly.

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 0% schema coverage, the description covers the tool's complete behavior: return fields, derived payment_status, open_bill opt-in, edge cases (connector asymmetry, confidence levels), and warnings about reliability. It addresses all key aspects an agent needs to use this 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?

Schema description coverage is 0%, placing full burden on the description. While account_id and include_open_bill are explained, the pagination parameters (page, page_size) are not mentioned at all. The description also covers account_ids briefly but misses this standard pagination, leaving agents without guidance on a common parameter.

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

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

The description clearly states it returns 'CLOSED credit card bills for a CREDIT-type account' and lists return fields. It distinguishes from siblings implicitly via name (list vs. get) and mentions deriving payment_status. However, it does not explicitly differentiate from the sibling tool openfinance_get_credit_card_bill, leaving some ambiguity.

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

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

The description provides explicit guidance on when to use this tool and alternatives: it warns against reconstructing totals from transactions and directs to openfinance_list_transactions for itemized charges. It also explains the include_open_bill opt-in and connector asymmetry, giving clear context for when to avoid misinterpretation.

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 the tool as read-only and idempotent. The description adds significant behavioral context: it explains the error response structure (returns {total, results, warning} instead of throwing), the data integrity cross-checking mechanism, and the integrity flag for suspect zeroed rows. This goes well 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 well-structured with clear sections, front-loads the main purpose, and is appropriately detailed for the tool's complexity. However, it could be slightly more concise.

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

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

Despite no output schema, the description thoroughly explains the response structure (total, results, warning, data_integrity_warning) and the fields within each row (balance, amount, rates, etc.). It also covers error handling for disabled product and data integrity edge cases. This makes the description highly 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 input schema has 6 parameters with no descriptions, and the description only explicitly mentions the item_ids parameter for bulk support. It does not explain the meaning of item, page, type, page_size, etc. With 0% schema coverage, the description should compensate but fails to do so.

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 that the tool returns the investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.). This clearly distinguishes it from sibling tools like list_accounts or list_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 does not explicitly tell when to use this tool versus alternatives like list_investment_transactions. It mentions error handling and bulk support, but lacks guidance on use cases or exclusions.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds return field details and bulk execution support, 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?

Two concise paragraphs with front-loaded purpose and specific details. Every sentence adds value; 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?

No output schema, but description lists many return fields. Covers prerequisite, bulk support, and transaction types. Missing pagination parameter details and potential error conditions.

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%, yet description only explains investment_id and investment_ids (batched). No explanation for page or page_size parameters, leaving pagination undocumented.

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 investment positions, listing specific transaction types (BUY, SELL, etc.) and fields. It distinguishes from sibling tool openfinance_list_investments by noting the prerequisite.

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 using after openfinance_list_investments to obtain the investment_id. Mentions bulk support but lacks explicit when-not-to-use or alternatives.

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

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

Discloses sequential querying with rate-limit spacing and per-connection output format {results, errors}. Annotations already declare readOnly and idempotent; the description adds valuable behavioral details 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, front-loaded with purpose, each sentence adds essential information. No redundancy or 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?

Complete for a simple list tool: covers input, behavior (sequential with rate-limiting), and output shape. No output schema exists, so description suffices.

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 items parameter: acceptable selector types (item_id uuid, connector_id, connector_name) and that each entry maps to one connection. Adds significant 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?

Explicitly states 'Lists loan contracts per bank connection' with the GET endpoint, and the optional items parameter distinguishes between fetching for specific connections vs all. Differentiates from sibling openfinance_get_loan_detail which handles single loans.

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?

Clear guidance on when to include items (for specific connections) and when to omit (for all). Does not explicitly state when not to use, but the context implies alternatives for single loan detail.

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

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

Discloses many behaviors beyond annotations: auto-pagination with 5000 ceiling, detail levels affecting token usage and coverage, credit card pending/posted variance by connector, provider_incident block, upstream error handling, and bulk support. Annotations already indicate read-only/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?

Though lengthy, the description is well-structured and front-loaded with core purpose, then detailed sections on pagination, detail levels, echo response, and troubleshooting. Every sentence adds necessary value for the tool's complexity.

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

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

Given 8 parameters, no output schema, and complex edge cases (credit card behavior, provider incidents, bulk support), the description covers all necessary context, including response structure, error handling, and links to other tools. 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 has 0% description coverage, but the description fully explains all 8 parameters: account_id, from/to (ISO YYYY-MM-DD), page, page_size, detail (compact/rich/raw), search_queries (substring match), account_ids (bulk). Provides defaults, behaviors, and caveats for each.

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

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

Clearly states the verb 'returns' and resource 'transactions for a bank account', distinguishes from siblings like openfinance_list_credit_card_bills by specifying it's the only way to get itemized credit card 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?

Explicitly advises when to use this tool (e.g., for credit card itemization), when not to (e.g., do not sum by billId for total), and suggests alternatives like openfinance_list_credit_card_bills for standardized totals. Provides detailed pagination instructions and troubleshooting steps.

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 important behaviors: scanning caps at 5000/account with truncation flag, provider incident block affecting data completeness, and that reconnecting doesn't fix incidents. This provides rich behavioral context.

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

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

The description is fairly long but well-structured, starting with main purpose, then parameter details, then special behaviors. Every sentence adds value, though it could be slightly trimmed 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, the description still describes the return structure (total entradas, saídas, por_mes, top lists, by_account) and caveats like truncation and provider incidents. This is very 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?

With 0% schema description coverage, the description fully compensates by explaining all key parameters: item (as connector_id/name or item_id, omit for all banks), from/to as ISO dates, granularity (monthly vs raw), detail (compact/rich/raw), type filtering, top_n implicit in top_despesas/recebimentos, and item_ids for bulk.

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

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

The description clearly states it provides consolidated cash-flow analysis for a whole bank connection in one call, resolving accounts internally and fanning out transactions. It distinguishes from sibling tools like openfinance_list_accounts by noting you don't need to call that first.

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

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

The description explicitly states when to use the tool (for cash-flow analysis, with example Portuguese phrases) and explains parameter choices like granularity and detail. However, it lacks explicit comparisons to other transaction tools like openfinance_list_transactions, so not 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?

Description adds context beyond annotations: indicates it reads a public status page, returns global indicator, degraded components, open incidents, and flags incidents affecting user's banks. No contradiction with readOnlyHint and idempotentHint.

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 front-loaded with the core purpose and includes essential usage context. Every sentence adds value, though could be slightly more concise.

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

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

Despite no output schema, the description thoroughly explains what the tool returns: global indicator, degraded components, open incidents, and user-specific affected banks, making it self-contained.

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 the description does not need to add parameter information. Baseline 4 applies as there are 0 parameters and schema coverage is 100%.

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

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

The description clearly states the tool checks the LIVE operational status of the Open Finance provider, distinguishing it from the sibling tool openfinance_get_item_status which checks the user's 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?

Provides explicit guidance on when to use: when data appears incomplete or stale despite a connection showing UPDATED, helping differentiate between provider-side issues and connection problems.

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

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

The description adds significant behavioral context beyond annotations: it discloses caveats for non-Open-Finance connectors, plan-based filtering (PF vs PJ), and the behavior when no keywords are provided. This fully informs the agent of the tool's 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 well-structured and front-loaded with the main action. Every sentence adds value, though it is slightly verbose. It could be tightened 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 only two parameters, the description covers all necessary aspects: what the tool returns (connector id, access, audience, accounts, connect_url, caveat), important behavioral nuances (plan handling, keyword requirement, caveats), and usage context (call before connecting). It is fully actionable for an AI agent.

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

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

With 0% schema description coverage, the description compensates by explaining keywords as bank name array with examples, noting it is required, and explaining include_accounts. However, it does not provide default values or edge cases for 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 clearly states that the tool searches bank connectors by name, specifying the verb and resource. It distinguishes itself from sibling tools by focusing on searching for connectors to provide a connect URL, and mentions it should be called before connecting.

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 'Call this BEFORE connecting' and explains that keywords are required, returning a hint otherwise. It also guides users to prefer Open Finance connectors over credential ones with caveats. However, it does not explicitly exclude any alternative tools or give when-not-to-use conditions.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description goes beyond annotations by explaining the side effect: recategorizing creates Category Rules for future similar transactions. This adds valuable behavioral context that annotations alone do not 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 moderately long but well-structured: it starts with the core purpose, then explains the input format, then the behavioral side effect, and finally the return shape. Every sentence adds value, though it could be slightly more compact.

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 that the tool has one parameter (an array), no output schema, and the description explains the return shape (`{ updated, results, errors }`), it is complete. It also differentiates from sibling tools and covers error handling for batches.

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 fully compensates by explaining that `items` is an array of objects with `transaction_id` and `category_id`, and specifies where to obtain these IDs from sibling tools. This adds essential meaning beyond the bare schema.

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

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

The description clearly states the action ('Corrects the category of one or more transactions') and identifies the resource (transactions). It distinguishes from sibling tools like openfinance_list_transactions and openfinance_list_categories by indicating it is a write operation that modifies categorization.

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 tool ('fix miscategorized transactions and improve categorization accuracy going forward') and provides context for inputs (transaction_id from openfinance_list_transactions, category_id from openfinance_list_categories). It does not explicitly state when not to use it, but the guidance is clear and practical.

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 annotations already declare destructiveHint=false and idempotentHint=true, so the safety profile is clear. The description adds that the tool is for reporting and that conversation data should be included, but it does not disclose what happens after submission (e.g., whether a response is returned, rate limits, or data handling). This is adequate given 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 sentences long with no filler. It front-loads the purpose and then provides usage guidance. Every sentence adds value.

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

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

Given 3 parameters and no output schema, the description covers the core purpose and one parameter. However, it lacks details on the return value, potential limitations (e.g., message length), and what happens after reporting. It is minimally complete but not rich.

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 the 'message' and 'conversation' parameters (message is the required content, conversation should include recent messages for reproduction). However, it does not explain the 'context' parameter. With 2 out of 3 parameters partially explained, it provides some meaning but misses the third parameter.

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: 'Report a bug, missing feature, or send feedback.' It identifies a specific verb (report) and resources (bug, feature, feedback), and it distinguishes itself from sibling tools by being the only feedback submission tool.

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

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

The description provides explicit guidance to 'Include the conversation array with recent messages for reproduction.' This tells the agent when to use this tool (to report issues) and what data to include. There are no similar siblings, so alternatives are not needed.

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

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

The description does not add behavioral insights beyond what the annotations already provide (readOnlyHint, idempotentHint). It neither contradicts nor enriches the annotation information, resulting in a neutral addition.

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 of eight words, front-loading the action and resource. Every word is essential, with no redundancy or filler.

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

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

Given the tool's zero parameters, no output schema, and detailed annotations, the description is fully adequate. It clearly states what the tool returns (version information) without needing further elaboration.

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

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

The tool has no parameters, and the input schema fully describes this. The description does not need to add parameter details; thus, it meets the baseline for zero-parameter tools.

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

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

The description clearly states the tool shows current MCP platform and adapter versions, using a specific verb and resource. It is easily distinguishable from sibling tools, which are primarily action-oriented or domain-specific, like 'authenticate' 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 provides a clear context for use: retrieving version information. While it does not explicitly state when not to use or suggest alternatives, the tool's simplicity and its standalone nature among siblings make the usage context sufficiently 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, destructiveHint=false, and idempotentHint=true, so safety is covered. The description adds value by detailing exactly what data is returned (installed MCPs, connection status, accounts, catalog counts), which is useful beyond the structured annotations. It does not mention auth or rate limits, but for a read-only state tool this is acceptable.

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, front-loaded with the primary action ('Returns the current toolkit state') and followed by clarifying specifics. Every word earns its place; no fluff 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 tool's simplicity (no params, no output schema), the description fully covers what the tool returns and its scope. It is complete enough for an agent to know exactly what to expect, and the sibling tools provide sufficient context for the term 'MCPs.'

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 and an empty schema (100% coverage), so the baseline for 0 params applies. The description correctly avoids inventing parameter details and adds no unnecessary param information.

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

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

The description clearly states the tool's function: 'Returns the current toolkit state' with specifics (installed MCPs, connection status, accounts, catalog tool count). It uses a precise verb and resource, and no sibling tool appears to duplicate this function.

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

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

The description implies usage for checking toolkit state but does not explicitly state when to use it versus alternatives or provide any context like 'use this before connecting.' It lacks the explicit guidance seen in high-scoring examples, but the purpose itself makes the intended use reasonably clear.

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