BV MCP

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

Annotations indicate idempotentHint=true, and description adds context: authentication process, token vs no-arg behavior. No contradiction. Disclosure 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?

Three sentences, front-loaded with purpose, then methods. No wasted words. Efficient and clear.

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 main use cases and authentication flow. No output schema, but return value is implied (link or success). Could mention exact output format, but not critical for this tool.

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

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

Schema has 1 optional token parameter with 0% coverage; description fully explains its use: call with token for session or no args for link. Compensates for 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 the tool is for authentication, explaining both permanent and session-based login methods. It distinguishes from sibling tools which are about Open Finance, reporting bugs, etc.

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

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

Explicitly describes when to use: for logging in via browser (permanent) or pasting token (session). Mentions alternative of config-based permanent token, but doesn't explicitly say when not to use.

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

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

The description adds significant behavioral context beyond annotations by detailing the two response scenarios and the meaning of 'authenticated' and 'connect_url' fields. No contradictions with annotations.

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

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

Two sentences, front-loaded with purpose, followed by clear conditional details. 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?

Fully explains the tool's behavior for a simple status check with zero parameters, covering both possible outcomes.

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 to document; baseline is 4. The description does not need to add parameter details.

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

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

The description clearly states the tool returns connection status and URLs, with distinct behavior for connected vs missing credentials. This is specific and distinguishes from siblings like 'authenticate'.

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 the two output states but does not explicitly mention when to use this tool vs alternatives like 'authenticate'. No negative guidance is provided.

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

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

The description discloses behaviors well beyond annotations: invoke works even if MCP is not installed, returns connect/checkout links on demand, install makes permanent, writes require owner/admin. No contradiction with annotations; adds rich context about state changes and authentication.

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 (15 sentences) but logically structured, moving from purpose to core flow to specific actions. Every sentence adds value given the tool's complexity. Minor verbosity could be trimmed but overall well-organized and front-loaded.

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 the tool's role, main actions, and key behaviors (invoke without install, auth/wallet links, permanence of install, owner requirements). Given no output schema and 13 parameters, it leaves out parameter details but provides enough context for an AI to correctly select and invoke the tool for typical use cases.

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 compensate. It explains the action enum (search, describe, install, invoke, etc.) and the roles of tool_id, arguments, mcp_id in the flow. However, it omits details for parameters like limit, immediate, tier_slug, conversation, request_name, report_context, request_description, leaving gaps for some fields.

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

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

The description clearly defines the tool as 'THE official mcp.ai marketplace' with a specific verb-resource pair ('find an MCP', 'run them'). It distinguishes itself from external registries and sibling tools by prescribing its use as the first step for capability discovery.

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 when-to-use guidance: 'use THIS tool FIRST, before any external/generic registry.' It explains the core flow (search→describe→invoke) and when to use invoke vs install, subscribe, report_bug, request_mcp, providing clear alternatives.

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

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

Annotations already indicate destructiveHint=true. The description adds that data will no longer be available and provides the reconnect URL, giving good behavioral context beyond what annotations offer.

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 with no wasted words, front-loaded with 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?

For a simple tool with one parameter and no output schema, the description covers the main behavior but fails to explain the 'item' parameter, which is a critical gap.

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

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

With 0% schema coverage, the description must clarify the sole required parameter 'item', but only vaguely refers to 'a specific bank' without specifying if it's an ID or name. This is inadequate.

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 revokes consent and deletes connection data for a specific bank. This distinguishes it from the many read-only sibling tools like openfinance_list_accounts.

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

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

The description implicitly indicates when to use (to disconnect a bank) and mentions a reconnect URL for reversal, but lacks explicit guidance on prerequisites or when not to use.

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

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

Annotations indicate neither read-only nor destructive, which the description aligns with by explaining the sync is a safe refresh that does not disconnect. The description adds detailed behavioral traits: it performs a PATCH then polls up to ~60s, explains return fields (`status`, `executionStatus`, `synced`, `needs_action`, `timed_out`), and describes what happens on timeout or user action needed. No contradiction with annotations.

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

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

The description is thorough but slightly long. It is front-loaded with the main action and well-structured, but every sentence earns its place. Could be trimmed slightly without losing meaning, but remains effective.

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

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

Given the tool's complexity (polling, waiting, multiple statuses), the description covers all aspects: return values, error conditions (`needs_action`, `timed_out`), usage variations, and comparison to alternatives. No output schema exists, but the description adequately explains the return shape.

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

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

Schema coverage is 0%, but the description fully compensates by explaining both `wait` (boolean, 'false for fire-and-forget') and `items` (array of selectors: item_id, connector_id, connector_name; omitting syncs all). It adds meaning beyond the schema's property definitions.

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: 'Forces the bank to re-sync one or more connections NOW and WAITS for it to finish'. It uses specific verbs ('forces', 're-sync', 'polls') and resources ('connections', 'banks'), and distinguishes from siblings like openfinance_disconnect_bank and openfinance_get_item_status by noting that it pulls fresh data without disconnecting.

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'), provides alternative behavior (`wait: false` for fire-and-forget), and clarifies what happens when `items` is omitted ('sync ALL linked banks'). It also differentiates from disconnecting/reconnecting by emphasizing it does NOT require that.

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

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

Annotations already mark it as readOnly and idempotent. The description adds that CREDIT accounts may return a structured warning instead of throwing an error, and describes the response shape { results, errors } — valuable context beyond annotations.

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

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

Two sentences, each serving a purpose: first states the tool's action, second details parameter usage and error behavior. 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 single-parameter tool with no output schema, the description covers purpose, parameter details, error handling, and response shape. It lacks explicit pagination or rate limit info, but is sufficiently complete.

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

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

Schema coverage is 0%, so description compensates by explaining account_ids is an array of strings with size constraint 1–50 and its purpose. The description adds meaning 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 explicitly states it returns real-time balance per account ID, including the endpoint. This clearly distinguishes it from sibling tools like openfinance_get_accounts_detail or openfinance_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?

It specifies the parameter account_ids must be an array (1–50) and mentions CREDIT accounts may return a warning. It could explicitly contrast with other balance-related tools, but the guidance 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 read-only and idempotent. Description adds value by specifying the batch response shape ({ results, errors }) and the inclusion of extended creditData, which supplements the schema.

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 defines the operation, second gives parameter format and response shape. No wasted words, front-loaded with key information.

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

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

Given no output schema, description covers return shape and key data (extended creditData). Does not detail error handling or full account object fields, but sufficient for a detail retrieval 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 coverage, description adds the array size constraint (1–50) and implies the parameter is an array of IDs. This provides important behavioral and usage context 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?

Clearly states it returns full account objects with extended creditData per ID. Distinguishes from sibling list and balance tools by specifying batch querying and extended data.

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

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

Explicitly states to pass account_ids as array (1–50), providing a usage size constraint. However, does not compare to similar sibling tools like openfinance_list_accounts or describe when not to use.

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

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

Goes beyond annotations by explaining the batch shape {results, errors}, noting that Pluggy does not return paid/status field, and clarifying the meaning of payments[] in Brazilian Open Finance. This additional context is valuable for correct use.

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 lengthy but well-structured, with clear sections and no wasted words. Some minor redundancy could be trimmed, but overall efficient given the complexity.

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

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

Without an output schema, the description adequately describes the output shape ({results, errors} batch), fields in each result (financeCharges, payments with sub-fields), and important limitations (no paid status, payments meaning). It is complete for a tool that returns bill detail.

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

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

Despite 0% schema coverage, the description fully explains the single parameter bill_ids: it is an array of strings, should be passed as an array, and guidance to use list tool first to discover ids. This compensates well and adds meaning beyond the schema.

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

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

Description clearly states the tool returns bill-level detail for credit card bills by id, specifying what is included (financeCharges, payments) and what is not (individual transactions). It distinguishes from sibling tool openfinance_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?

Provides explicit guidance: use openfinance_list_credit_card_bills to discover ids, use openfinance_list_transactions for itemized transactions with specific date range and account_id, and explains the nuance about payments and cross-bill match for paid status, pointing to an alternative 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=true, destructiveHint=false, and idempotentHint=true, indicating a safe read operation. The description adds beyond this by specifying the return fields (status, executionStatus, connector metadata) and the response structure for both modes, providing richer behavioral context without contradicting 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: two sentences, front-loaded with purpose, and no wasted words. Every part adds value, covering purpose, usage modes, and response 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?

Despite lacking an output schema, the description adequately covers the response structure (count, items for list; single object for individual) and lists example statuses. Minor gap: it doesn't detail the exact fields in the single response beyond mentioning status, executionStatus, and connector metadata, but this is sufficient for a simple read tool with one optional parameter.

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 zero descriptive coverage for the single parameter 'item'. The description fully compensates by explaining that omitting it returns all banks' statuses and including it returns a single bank's status, thus providing complete semantic 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?

The description clearly states it 'Returns the current status of a bank connection', enumerates possible values (UPDATED, UPDATING, LOGIN_ERROR, etc.), and distinguishes two usage modes (all vs. single). This specific verb+resource combination differentiates it from sibling tools that perform different operations like authenticate, connect, or force sync.

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 instructions for when to use each mode: 'Omit item to get the status of ALL linked banks at once; pass item for a single bank.' This is clear context, but it does not explicitly mention when not to use this tool or point to alternatives among siblings for related tasks (e.g., using openfinance_force_sync to trigger a sync instead of checking status).

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

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

Discloses that 'name' is the legal entity not the brand, explains credit balance is connector-dependent, and defines open billing cycle fields. Adds significant context beyond annotations which already mark it read-only.

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?

Somewhat lengthy but every sentence adds value. Front-loaded with main purpose. Minor redundancy in examples but overall well-structured.

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

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

Given the complexity of optional parameters and no output schema, the description covers return fields, edge cases, parameter behavior, and cross-references to other tools, making it fully complete 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 fully explains both 'item' (omit for all banks vs pass for specific) and 'type' (BANK vs CREDIT) parameters, providing usage guidance and 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?

Clearly states it returns accounts for bank connections, distinguishing between BANK and CREDIT types, and lists returned fields. Differentiates from sibling tools like openfinance_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?

Explicitly explains when to omit vs pass the 'item' parameter for aggregating vs targeting a bank. Provides alternative tool openfinance_list_credit_card_bills for standardized billing data, and warns about interpreting credit balance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by disclosing caching behavior, response structure (including fields like id, description, parentId), and the relationship to the update tool, which goes beyond the annotations.

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

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

The description is three sentences with no wasted words. It front-loads the core purpose (returns taxonomy), then adds caching, structure, and cross-tool reference. 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?

For a tool with zero parameters and no output schema, the description covers the endpoint, caching, return fields (including id, description, translated description, parent), and relevance to another tool. It is sufficiently complete for a simple cached list operation.

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

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

There are no parameters, so schema coverage is 100%. The description correctly avoids mentioning parameters, and baseline for zero parameters is 4. No additional parameter detail 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 Pluggy's transaction category taxonomy, cached, and specifies it corresponds to the GET /categories endpoint. It distinguishes itself from sibling list tools by explicitly mentioning categories and their use in openfinance_update_transaction_category.

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

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

The description indicates the data is cached and provides a single aggregated response with no batch ids, but does not explicitly say when to use this tool versus alternatives. However, it does hint at its use for updating transaction categories, providing adequate context for a zero-parameter 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=true, idempotentHint=true, destructiveHint=false. The description adds useful context on returned fields but no further behavioral details like rate limits or side effects. With good annotations, 3 is appropriate.

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 sentence that efficiently conveys the tool's output. Slightly verbose with 'for this install' and 'via the Open Finance widget', but still concise and front-loaded.

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 sufficiently lists the returned fields and their purpose. It does not mention pagination or limitations, which may not be critical for this tool.

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

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

No parameters exist, and schema description coverage is 100%, so the description inherently adds no parameter info. Baseline 4 for zero-parameter tools.

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

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

The description clearly states the tool returns saved bank connections and lists specific fields (connector_id, item_id, bank name, add_connection_url). It distinguishes from siblings like openfinance_list_accounts or openfinance_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 implies usage for viewing connections and obtaining a URL to add more, but does not explicitly state when to use this tool over alternatives, such as openfinance_list_accounts for other data.

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?

Provides extensive behavioral context beyond annotations: payment semantics, derived payment_status logic, open bill derivation method, connector asymmetry, and warnings about assumptions. Annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent, no contradiction.

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

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

The description is long but front-loaded with the core purpose. It is well-structured into sections: return fields, important semantics, open bill opt-in, connector asymmetry, and related tool. While comprehensive for a complex tool, some sentences could be more concise, but overall it earns its length.

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 (5 parameters, no output schema), the description fully covers return fields, derived fields, edge cases (connector asymmetry, payment timing), and provides cross-references to related tools. It leaves no major gaps for an agent to understand behavior and limitations.

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

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

Despite 0% schema coverage, the description explains the key parameters: account_id, include_open_bill (with detailed behavior), account_ids (bulk), and mentions pagination implicitly. However, page and page_size are not explicitly described, but they are standard. The description compensates well for missing schema descriptions.

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

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

The description clearly states the tool returns 'CLOSED credit card bills for a CREDIT-type account' and lists specific fields, distinguishing it from siblings like openfinance_get_credit_card_bill and openfinance_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?

Explicit guidance on when to use (closed bills), when to opt-in for open bills (include_open_bill:true), and connector asymmetry scenarios. Also mentions that for itemized transactions, use openfinance_list_transactions. Sets clear alternatives and limitations.

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. The description adds important behavioral context: returns { total:0, results:[], warning } on error rather than throwing. 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 informative and front-loaded with the main purpose. It is slightly long but every sentence adds value, listing return fields and error behavior. Could be more concise but still effective.

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

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

Given 4 optional parameters, no output schema, and no parameter descriptions, the description covers the return fields and error handling adequately. However, it lacks parameter details and output structure, leaving gaps for a complete understanding.

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%, and the description does not explain any of the 4 parameters (item, page, type, page_size). The types listed in the output hint at the 'type' enum but no direct mapping.

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 investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, fixed income, mutual funds, retirement, COE). It distinguishes this tool from siblings like openfinance_list_accounts by focusing solely on investments.

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 (for connections with INVESTMENTS product enabled) and notes that it returns a graceful response instead of throwing when the product is not enabled. However, it does not explicitly differentiate from sibling openfinance_list_investment_transactions.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by detailing the returned fields (quantity, value, expenses, etc.) and batch capability, providing 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 sentences plus a line for bulk support, efficiently conveying purpose, data details, prerequisite, and optional batch use. No superfluous 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?

Given annotations cover safety, the description sufficiently explains return data and usage order. Missing pagination handling details (page/page_size) and response metadata, but otherwise adequate for a read-only list tool.

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

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

Schema coverage is 0%, so description must compensate. It adds meaning for investment_id (prerequisite) and hints at investment_ids (bulk), but does not describe page or page_size parameters. Partial compensation; more parameter detail would improve score.

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 an investment position, listing specific transaction types (BUY, SELL, TAX, etc.) and data fields per row. It distinguishes from siblings like openfinance_list_investments by focusing on transactions rather than investment listings.

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 to use after openfinance_list_investments to obtain investment_id, providing a clear prerequisite. Bulk support is mentioned. No explicit exclusions, but context is well-defined.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses sequential execution with rate-limit spacing and the return format (`{ results, errors }` per connection). 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 three sentences, front-loading the purpose, then explaining the parameter and behavior. Every sentence adds essential information with 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?

Given no output schema, the description includes the return format. It covers purpose, parameter semantics, and behavioral notes (sequential, rate-limit spacing). The tool is well-documented 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?

The input schema has 0% description coverage for the sole parameter `items`. The description fully compensates by explaining it as an array of connection selectors (item_id uuid, connector_id, or connector_name), effectively 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 lists loan contracts per bank connection, specifying the GET /loans endpoint. It distinguishes from sibling list tools by focusing on loans and explicitly detailing how to target specific connections via the `items` parameter.

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 guidance on when to include `items` (for specific connections) versus omit it (to list all bank connections). It also mentions sequential querying with rate-limit spacing. However, it does not explicitly compare with sibling list tools like openfinance_list_accounts, though the resource specificity suffices.

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?

Descriptions disclose auto-pagination behavior, 5000 ceiling, error handling (returns error object instead of throwing), variability by connector for credit pending/posted, and search query aggregation. These details go well beyond the annotations (readOnlyHint, idempotentHint, destructiveHint).

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 into logical paragraphs (general, credit cards, filters, pagination, detail options, cross-references). However, it is somewhat verbose, especially in explaining credit card pending/posted behavior, which could be more succinct. Still, 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?

For a tool with 8 parameters and no output schema, the description covers all necessary aspects: purpose, parameter semantics, usage guidelines, behavioral traits, error handling, pagination, bulk support, and cross-references to sibling tools. It leaves no major gaps 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 coverage, the description fully explains all 8 parameters: from/to as ISO dates, page/page_size for pagination, detail enum with use cases, account_id and account_ids for bulk, and search_queries with OR semantics and case-insensitive substring match. No ambiguity remains.

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 transactions for bank accounts (BANK or CREDIT). Distinguishes from siblings: for CREDIT accounts, this is the only way to get itemized transactions, linking to bills from openfinance_list_credit_card_bills, and defers to openfinance_list_accounts for statement dates.

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

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

Provides explicit when-to-use (e.g., for itemized credit transactions) and when-not (e.g., use openfinance_list_credit_card_bills for total debt). Explains pagination strategies, date range narrowing, and detail levels. Offers alternatives and troubleshooting steps (check connection health if total is 0).

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?

Descriptors beyond annotations: internal fan-out, compact summary vs raw rows, detail enrichment with merchantInfo and creditCardMetadata, 5000/account cap with truncated flag, and behavior when item is omitted. Annotations already state readOnlyHint and idempotentHint, which are consistent.

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 (5 sentences) and front-loaded with the core purpose. However, the density of information could be improved with bullet points or clearer separation of sections, but it remains effective.

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

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

Comprehensive: covers all parameters, return structure (compact summary fields and raw rows), constraints (5000 cap, truncated), enrichment options, and usage scenarios. No output schema exists, but the description compensates by detailing the response shape.

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 thoroughly explains all parameters: item (connector_id, connector_name, item_id, or omit), from/to (ISO dates), granularity (monthly vs raw), detail (compact, rich, raw) with their interplay, type (BANK or CREDIT), and top_n implied via top_despesas/recebimentos.

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 bank connection over a period in one call, eliminating the need for prior calls to list accounts or carry account IDs. It distinguishes itself from siblings like openfinance_list_transactions and 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?

Provides explicit guidance on when to use (e.g., 'análise anual/mensal', 'fluxo de caixa'), how to target a single bank via item or omit for all, default granularity vs raw, and detail options. Implicitly contrasts with siblings by stating you don't need to call openfinance_list_accounts first.

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

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

Beyond annotations (readOnly, idempotent), describes return data: global indicator, degraded components, open incidents, and affected banks. Adds value by specifying output structure and 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?

Dense but well-organized; front-loads main purpose. Could be slightly more concise, but each sentence earns its place without being overly verbose.

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

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

For a tool with no parameters and no output schema, the description fully covers purpose, usage context, expected return values, and differentiation from siblings. Complete and informative.

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?

Zero parameters; description adds no parameter info, but baseline of 4 is appropriate given high schema coverage (100%). No further meaning 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?

Clearly states the tool checks the live operational status of the Open Finance provider, distinct from connection status. Distinguishes from sibling tool openfinance_get_item_status.

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

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

Explicitly provides when to use (when data looks incomplete/stale despite updated connection) and what it diagnoses (upstream outage/incident). Contrasts with alternative tool, offering clear decision guidance.

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

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

Annotations mark it as readOnly, idempotent, non-destructive. Description adds that it returns connector info and caveats about non-Open-Finance connectors needing reconnection, fully consistent.

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

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

The description is detailed and front-loaded with purpose, but contains multiple clauses; 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?

No output schema, but description fully explains return fields, plan behavior, caveats, and when to call, making it 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?

Schema has 0% description coverage, but description explains that keywords[] is required and what happens if omitted, and include_accounts triggers account inclusion, adding essential 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?

The description clearly states it 'Searches the available bank connectors by name' and lists the returned fields, distinguishing it from sibling tools like authenticate or connect.

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?

It explicitly says 'Call this BEFORE connecting' and explains behavior with keywords and plan restrictions, but does not explicitly mention when not to use or compare 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?

The description extensively discloses behavioral traits beyond annotations: it explains the side effect of creating a Category Rule for future similar transactions, and the response structure. 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 thorough but slightly verbose; however, every sentence provides value. It is front-loaded with the core purpose and then adds necessary details. Could be slightly more concise but still effective.

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

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

Given the tool's complexity (batch update with side effects), the description covers input, output, side effects, and error handling. No output schema exists, so the description compensates fully. The context signals are simple, and the description is complete.

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

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

Despite 0% schema description coverage, the description thoroughly explains each parameter: transaction_id comes from a specific tool, category_id from another, and the response format for items, updated, and errors. This adds significant meaning beyond the schema.

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

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

Clearly states the tool corrects transaction categories (PATCH /transactions/:id) and distinguishes from sibling tools like openfinance_list_transactions and openfinance_list_categories by explaining where input IDs come from. Specifies the effect of overriding automatic categorization and teaching Pluggy.

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 the purpose: to fix miscategorized transactions and improve future categorization. Provides details on the batch shape and error handling, but does not explicitly state when not to use it. However, the context is clear enough.

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

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

Annotations already indicate idempotent and non-destructive, and the description does not add further behavioral details beyond the purpose.

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

Adequate for a simple tool but lacks parameter details and response information; could be more complete given no output schema.

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 mentions 'conversation array' but does not explain the 'message' or 'context' parameters, even though schema coverage is 0%.

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 reports bugs, missing features, or feedback, distinguishing it from sibling tools which are finance-related.

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 guidance to include the conversation array for reproduction, but does not specify when not to use or mention 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, idempotentHint, and destructiveHint, providing safety context. The description adds that it shows platform and adapter versions, but no additional behavioral traits 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 a single, clear sentence with no extraneous words, effectively communicating the tool's function.

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

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

While the description states what the tool does, it does not describe the return format or structure of the version information, which is relevant given the absence of an output schema.

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 zero parameters and 100% schema coverage, the description is not required to add parameter details. The baseline for zero parameters is 4, and the description does not detract from this.

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

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

The description specifies the verb 'Show' and the resource 'MCP platform and adapter versions', clearly distinguishing it from sibling tools which focus on authentication, financial data, or system settings.

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 that the tool is for retrieving version information, but does not explicitly state when to use it or when to prefer alternatives. For a simple read-only query, the context is sufficient but not explicitly guided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering behavioral safety. The description adds no further behavioral context (e.g., auth needs, rate limits), but it does detail the return contents, which is useful but not strictly behavioral.

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

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

The description is a single, well-structured sentence that front-loads the core action and outcome. Every word contributes meaning, 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 that there are no parameters, no output schema, and annotations cover safety, the description fully informs what the tool does and returns. No additional context is necessary 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?

The input schema has zero parameters, so schema coverage is 100% by default. Following the baseline guidance for 0 parameters, a score of 4 is appropriate; the description adds no parameter information, 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 clearly states the verb 'Returns' and the resource 'current toolkit state', listing specific data fields (installed MCPs, connection status, catalog tool counts). This distinguishes it from sibling tools like 'authenticate' or '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?

While there is no explicit when-to-use or when-not-to-use guidance, the description's unique purpose among siblings provides implicit context. The tool is clearly for inspecting overall toolkit state, with no competing alternatives among the listed siblings.

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