Banco Digio MCP

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

Annotations indicate idempotentHint=true and destructiveHint=false; the description adds behavioral context such as the presence of a link when no args are given and the distinction between persistent and session-only login. It does not cover error handling or return format, but the key behaviors are disclosed.

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

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

The description is mostly concise, front-loads the purpose, and efficiently describes two login methods. Minor redundancy ('log in in the browser, copy the access token') could be tightened.

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 tool is simple with one optional parameter and no output schema. The description covers the core functionality and two usage scenarios, making it adequate for an AI agent. Missing details like error responses are minor given the overall clarity.

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

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

Schema coverage is 0%, so the description fully compensates by explaining that 'token' is a JWT obtained from browser login, and how to use it for session-only login. This adds crucial 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's purpose: authenticating for IDE agents by logging in via browser and using an access token. It distinguishes itself from sibling tools (e.g., openfinance, marketplace) by focusing solely on authentication.

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

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

The description provides explicit when-to-use guidance: recommending a permanent config-based approach over session-only token pasting. It also explains the two invocation modes (with or without token) and their outcomes.

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. The description adds specific response details (authenticated:true vs connect_url), providing additional 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, front-loaded with purpose, no fluff. All information earns its place.

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

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

For a simple status check with no parameters and annotations covering safety, the description explains the key response states. Without an output schema, it provides sufficient context.

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

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

No parameters exist, so schema coverage is 100%. Baseline score 4 applies as the description does not need to add parameter info. The description adds no param semantics but is not required.

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 explicit examples of two scenarios (all connected vs missing credentials). This distinguishes it from siblings like 'authenticate' or 'openfinance_list_connections'.

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 state when to use this tool vs alternatives. It implies usage for checking overall connection status, but no direct comparison or when-not 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 key behaviors beyond the sparse annotations: invoke runs one-off without installing, credential/login needs return a connect link, paid MCPs return a checkout/top-up link, writes require owner/admin, and search/describe flag installed states. This fully compensates for the lack of annotation detail.

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 and front-loaded with the primary purpose. Every sentence adds value, but some redundancy (e.g., repeating 'invoke works even when...') could be trimmed. It earns a 4 for efficiency 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?

Given the tool's complexity (13 parameters, multiple actions, no output schema), the description is remarkably complete. It covers the entire workflow, special cases (credentials, payments), ownership requirements, and distinguishes between one-off and permanent usage. Very little is left unspecified.

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?

Although the input schema has 13 parameters with 0% description coverage, the description explains the meaning of several key parameters (action, query, mcp_id, tool_id, arguments) in context. However, it does not cover all parameters (e.g., limit, message, immediate, tier_slug, conversation, etc.), leaving the agent unclear on how to use them. Baseline is low, so a 3 is appropriate as it adds some but not full 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 what the tool does: it is the official mcp.ai marketplace for discovering, describing, and running MCPs/tools. It specifies the core flow (search→describe→invoke) and distinguishes itself from external registries and sibling tools like authenticate or openfinance_* (e.g., 'use THIS tool FIRST, before any external/generic registry').

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 (first for capability lookups) and when to use alternatives (e.g., 'prefer invoke for a single/occasional use' vs install for permanence). It also explains when to use other tools like report_bug, request_mcp, and list_tools, and notes that writes require workspace owner/admin.

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 matches the destructiveHint annotation and adds that the action makes bank data unavailable and returns a re-connection URL, providing useful 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 lean sentences, front-loaded with the action and outcome. Each sentence adds essential information without redundancy.

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

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

For a simple destructive tool with one parameter, the description covers action, effect, and return value. Missing parameter clarification prevents a perfect score.

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 only parameter 'item' is not explained in the description; schema coverage is 0%, and 'item' is vague. The description should clarify it's the bank identifier.

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, distinguishing it from listing or status tools.

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

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

The description implies when to use (to disconnect a bank) but provides no guidance on when not to use or mentions alternatives like checking connection status 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?

Discloses polling behavior, timeout, return fields, and error states. No contradiction with annotations (readOnlyHint=false, destructiveHint=false). Adds 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?

Front-loaded with key action, but slightly verbose. Every sentence adds value, but could be trimmed 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?

No output schema, but description details return structure (results, errors, fields). Covers error states and actions needed. Complete for a sync 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 0% coverage; description fully explains items (selectors, omit for all) and wait (fire-and-forget). Adds meaning beyond type and name.

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

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

Clear verb 'forces sync', resource 'bank connections', and behavior 'waits for completion'. Distinct from siblings like openfinance_get_item_status by specifying it initiates a sync and polls.

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 (stale data) and what not to do (no disconnect). Provides alternative for timed_out and distinguishes wait=true vs false.

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 and idempotent behavior; the description adds that it returns real-time balance, and for CREDIT accounts, errors are handled gracefully with warnings instead of exceptions. 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 three sentences, ordered logically: purpose, parameter usage, error handling, and response shape. No redundant information.

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

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

For a simple balance retrieval tool with one parameter, the description covers purpose, parameter constraints, error behavior, and response structure adequately, compensating for lack of 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 schema has 0% description coverage, but the description adds that account_ids must be an array of 1-50 items, providing critical constraints not in the schema. However, it does not explain the meaning of the account ID strings.

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 a real-time balance payload for given account IDs, with the endpoint specified. It distinguishes from sibling tools like openfinance_get_accounts_detail by focusing on balance.

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 input format (array of 1-50 account_ids) and warns about CREDIT accounts returning errors with warnings. However, it does not explicitly state when to use this tool over siblings or scenarios to avoid.

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 behavioral context: the batch API returns both results and errors, and it explains that the call returns extended creditData. No contradiction with annotations.

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

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

Two concise sentences plus a parenthetical. Every part adds value: verb, resource, added fields, parameter details, and return shape. 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 simple read tool with one parameter and no output schema, the description covers purpose, parameter constraints, and return format. Context signals (low complexity) are fully addressed.

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 description must compensate. It explains that account_ids is an array (1-50) and defines the parameter's role. While it doesn't specify item type (strings), the name and array constraint add sufficient 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: returns full account objects. It specifies the resource (accounts) and the method (GET /accounts/:id). The phrase 'including extended creditData' distinguishes it from a simpler listing tool 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?

It gives explicit usage guidance: pass account_ids as an array (1-50). The batch shape '{ results, errors }' hints at usage pattern. However, it does not explicitly state when to use this instead of sibling tools like openfinance_list_accounts, though the purpose implies it.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds beyond: batch shape {results, errors}, Pluggy's lack of paid status, and the correct interpretation of payments[] as previous bill payment. 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?

Well-structured: starts with purpose, then exclusions, then usage instructions, then behavioral note. Slightly long but every sentence adds value. No fluff.

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

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

Given 1 parameter, no output schema, and the complexity of credit card billing semantics, the description is remarkably complete. It explains return shape, disambiguation from sibling tools, and critical behavioral nuance about payments.

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?

Only parameter bill_ids has 0% schema description coverage. Description explains it's an array, how to obtain valid IDs (via openfinance_list_credit_card_bills), and the batch behavior. Adds meaning beyond schema, though could explicitly state that IDs are strings.

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 bill-level detail for credit card bills by ID, enumerates included fields (financeCharges, payments[] with subfields), and clarifies it does not return individual transactions. It distinguishes from sibling tools like openfinance_list_transactions and openfinance_list_credit_card_bills.

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

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

Provides clear guidance: use openfinance_list_credit_card_bills first to discover IDs, use openfinance_list_transactions for itemized transactions, and prefer openfinance_list_credit_card_bills for paid status. Includes a crucial warning about payments[] 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds value by detailing the returned data (status, executionStatus, connector metadata) and the difference in output structure based on the `item` parameter.

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, with the first sentence defining the return types and the second explaining parameter usage. Every word contributes necessary information, and the key behavior (conditional parameter) is 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 core functionality and parameter usage but lacks a detailed return structure for the single-bank case (only mentions 'executionStatus and connector metadata'). Additionally, there is no output schema to fill this gap, leaving some ambiguity.

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

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

Despite 0% schema description coverage for the single parameter `item`, the description compensates by explaining the semantic difference between omitting and passing `item`, which adds significant 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 clearly states the tool returns the status of a bank connection with specific enum values (UPDATED, UPDATING, LOGIN_ERROR) and metadata. It distinguishes between fetching all connections vs. a single one, setting it apart from sibling tools like openfinance_list_connections.

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

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

The description explicitly explains when to omit the `item` parameter (to get all banks) and when to pass it (for a single bank), providing clear context. However, it does not mention when to avoid this tool in favor of alternatives like openfinance_provider_status.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds critical behavioral details: credit card balance meaning is connector-dependent, 'name' is the legal entity not the brand, and the response structure when omitting vs. passing 'item'. 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 relatively long but well-organized: it front-loads the main purpose, then adds nuances about fields, parameter usage, and a sibling reference. Every sentence adds value, though it could be slightly more compact without losing clarity.

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

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

Given the absence of an output schema, the description covers return fields (balance, number, type, etc.) and important caveats (credit card balance interpretation). It doesn't mention pagination or limits, but for a read-only list tool with good annotations, it 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?

With 0% schema description coverage, the description fully explains both parameters: 'item' to target a single bank and 'type' to filter by account type (BANK or CREDIT). It also describes the effect of omitting 'item' (aggregate all banks) and the resulting response structure.

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

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

The description clearly states that the tool returns accounts for a bank connection with specific fields (BANK and CREDIT types, balance, number, etc.). It also distinguishes itself from siblings like openfinance_list_credit_card_bills by noting that for standardized open-bill amounts, the other tool should be used.

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

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

The description provides explicit guidance on when to omit the 'item' parameter to list all accounts across banks versus passing 'item' to target a single bank. It also advises against treating credit card 'balance' as the monthly bill and references the sibling tool for bill-related queries.

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

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

Annotations already indicate readonly, idempotent, and non-destructive behavior. The description adds value by describing caching, the aggregated nature, and the structure of entries (id, description, translated description, parentId, parentDescription). 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 three sentences that front-load the main purpose, then efficiently cover caching, structure, and hierarchy. No extraneous information.

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

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

Given zero parameters, no output schema, and comprehensive annotations, the description fully covers what the agent needs: purpose, caching, response structure linking to sibling tool, and language options.

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 there is no need for parameter description. Baseline score of 4 applies as the description appropriately has no 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 it returns the transaction category taxonomy from Pluggy, specifying the HTTP endpoint and caching behavior. It distinguishes from siblings by noting it's a single aggregated response without batch ids.

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

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

Usage is implied by mentioning that the category ID is used by openfinance_update_transaction_category, but no explicit when-to-use or when-not-to-use guidance is provided, nor comparisons to alternative 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 declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context about returned fields and the presence of an add_connection_url, but does not disclose behavioral traits beyond what annotations provide.

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

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

The description is a single sentence that conveys the purpose and key output, with zero unnecessary words. It is front-loaded and 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?

Given the tool's simplicity (no parameters, no output schema), the description covers what is returned. It could mention potential error conditions or data ordering, but is largely complete for a read-only 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 zero parameters, so schema coverage is 100% trivially. The description does not need to add parameter meaning; baseline for 0 params is 4.

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

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

The description uses a specific verb ('Returns') and clearly identifies the resource ('saved bank connections') along with the fields returned. It differentiates from sibling list tools by focusing on connections.

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 to retrieve saved connections and obtain an add_connection_url, but does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria.

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. Description adds critical behavioral details: derived payment_status logic, payment cycle rules, connector asymmetry for open bill, and warning behavior if product not enabled. 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?

Very detailed but somewhat verbose. The description is front-loaded with purpose but then dives into lengthy explanatory paragraphs. Could be more structured with bullet points, but the information density is valuable and each sentence earns its place.

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

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

Given the high complexity (Brazilian Open Finance, payment status derivation, connector asymmetry) and no output schema, the description is exceptionally complete. Covers return fields, edge cases, limitations, and even explains why open_bill might not be available.

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

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

Schema has 0% description coverage; the description compensates fully. Explains account_id (required), account_ids (bulk), page, page_size, and especially include_open_bill with detailed semantics about what it returns and when it's unavailable. Adds meaning beyond type/required.

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 CREDIT-type accounts, listing specific fields and explicitly distinguishing from sibling tools like openfinance_list_transactions (individual transactions) and openfinance_get_credit_card_bill (single bill).

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 extensive guidance: when to use (closed bills, opt-in open_bill), when not to assume payment status, and explicitly references alternative tools for itemized transactions. Includes important semantic rules about payment cycles.

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 useful behavioral details: returns structured warning on 403 errors, and lists the specific financial fields returned. 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 a single paragraph that places the main purpose first. It includes a lot of detail but remains readable. Slightly verbose with many field names 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 no output schema, description thoroughly explains the return structure: top-level fields (total, results, warning) and per-row fields for all listed investment types. Also covers error handling. Complete for the tool's complexity.

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 must explain parameters but does so only implicitly for the 'type' parameter by listing asset types. It does not explain 'item', 'page', or 'page_size' at all.

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 the investment portfolio for a connection, listing specific asset types and data fields. It distinctly identifies this tool's function among siblings 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?

Description explains that it returns a safe error structure rather than throwing, indicating it's non-fatal to call on unsupported connections. However, it does not explicitly state when to use this over siblings like 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 declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds value by detailing the transaction types, fields returned, and bulk support, 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?

Two concise paragraphs: first explains purpose and fields, second gives usage note. No redundant information, front-loaded with essential details.

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 4 parameters, 0% schema coverage, and no output schema, the description covers main functionality, return structure, and usage dependency. It lacks details on pagination parameters and full response format, but remains largely 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 the description must compensate. It explains investment_id and investment_ids, but does not describe page or page_size parameters. Partial coverage is provided.

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

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

The description clearly states it returns movement history for a specific investment position, listing transaction types and fields. It distinguishes itself from siblings like openfinance_list_investments and openfinance_list_transactions by being investment-specific.

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 advises using after openfinance_list_investments to obtain investment_id, and mentions bulk support with investment_ids. It does not explicitly exclude alternatives but provides clear context for when 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 already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds valuable behavioral context: sequential querying with rate-limit spacing and return structure of { results, errors } per connection. No contradictions.

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

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

Two sentences with no wasted words. Front-loaded with core purpose, then parameter explanation, then behavior. Every sentence earns its place.

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

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

Given no output schema, description includes return structure. Single parameter fully explained. Annotations cover safety. Complete for a list tool with simple usage.

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

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

Schema coverage is 0%, so description fully explains the items parameter: array of connection selectors (item_id uuid, connector_id, or connector_name), one per connection, and the effect of omitting. This adds significant 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 it lists loan contracts per bank connection, specifies the endpoint (GET /loans), and explains the two modes (using items or omitting). This distinguishes it from siblings like openfinance_list_accounts 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 how to use items parameter for specific connections or omit for all connections. Mentions sequential querying and rate-limit spacing. However, does not explicitly state when not to use this tool or compare with 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?

Adds extensive context beyond annotations, including CREDIT PENDING vs POSTED variation by connector, aggregation behavior with search_queries, error handling returning warning/error instead of throwing, and bulk support.

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 relatively long but well-structured, starting with the main purpose and progressively adding details. Each sentence adds value, though some paragraphs could be slightly tighter.

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 coverage for a complex tool with 7 parameters and no output schema. Addresses edge cases, error states, cross-tool dependencies, and troubleshooting steps.

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

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

Despite 0% schema description coverage, the description explains all 8 parameters clearly, including format (ISO YYYY-MM-DD for dates), constraints (max 500/page), and search behavior (case-insensitive, OR semantics, aggregation limit).

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 transactions for bank accounts (BANK or CREDIT) and distinguishes that for CREDIT accounts it is the only way to get itemized transactions, contrasting with openfinance_list_credit_card_bills.

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 mentions when to use (get itemized transactions for CREDIT) and when not (use openfinance_list_credit_card_bills for billing totals). Also provides guidance on handling zero results and connection health checks.

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 key behavioral details: internal resolution of accounts, fan-out transactions, scan caps at 5000/account with truncated flag, and omission of item analyzes all banks. 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 dense but well-structured, front-loading the core purpose and gradually revealing details. A bit lengthy but each sentence adds value; minor points for lack of bullet points or structured layout.

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 specifies return structure: total entries/exits, net balance, monthly evolution, top expenses/receipts, per-account breakdown, and truncation flag. Also covers caps and limitations. Complete for a transactions 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 compensates fully. Explains 'item' accepts connector_id/connector_name/item_id, 'from'/'to' are ISO dates, 'granularity' monthly vs raw, 'type' filters BANK/CREDIT, and 'top_n' is implied for largest N top items. All six parameters are semantically enriched.

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

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

The description clearly states the tool performs consolidated cash-flow analysis for a bank connection or all connections in one call, using specific verbs and resource. It distinguishes itself from sibling tools by eliminating the need for separate account listing or account_id uuids.

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 (annual/monthly analysis, cash flow, entries/exits, top expenses/receipts) and when not to (no need to call openfinance_list_accounts). Provides clear alternatives and granularity selection 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 declare readOnlyHint, idempotentHint, destructiveHint. Description adds behavioral context: calls the provider's public status page, side-effect-free, and details the returned information. 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?

Two sentences with high information density. Front-loaded with main verb. Slightly long 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?

Comprehensive for a zero-parameter tool with good annotations. Explains return values and use case thoroughly, no gaps.

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

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

No parameters, schema coverage 100%. Baseline 4, and description adds value by explaining the output, which compensates for lack of output 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 checks the LIVE operational status of the Open Finance provider, distinguishing it from the own connection's status. Specifies what it returns: global indicator, degraded components, incidents, and affected banks.

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

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

Explicitly tells when to use it when data looks incomplete or stale even though a connection shows UPDATED. Contrasts with sibling tool openfinance_get_item_status, providing clear context and alternatives.

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

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

Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds important behaviors: it honors user's plan (PF hides PJ banks), it never dumps full catalog without keywords, and returns a ready connect_url. No contradictions with annotations.

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

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

The description is a single paragraph of 4 sentences, front-loading the main action. It is concise but could be slightly more structured (e.g., separate param descriptions). However, every sentence provides valuable 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, the description adequately explains what is returned per match. It covers key aspects for an agent: connector id, access type, audience, existing connections, connect_url. Could benefit from mentioning if results are paginated or limited, but it's fairly complete.

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

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

Schema has 0% description coverage, but the description fully explains both parameters: keywords (required, with example usage) and include_accounts (effect on returning accounts). It also clarifies that keywords is REQUIRED behaviorally despite schema showing 0 required.

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

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

The description clearly states the tool searches bank connectors by name, using keywords array. It specifies the returned fields (connector id, access, audience, linked connections, accounts, connect_url). This differentiates it from sibling tools like 'connect' (which likely performs connection) and 'marketplace'.

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

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

The description explicitly says 'Call this BEFORE connecting' and notes that without keywords it returns a hint, never the full catalog. It also mentions honors user's plan. However, it doesn't explicitly name alternative tools when not to use this, though context signals provide sibling names.

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 details behavioral traits beyond annotations, including the side effect of teaching Pluggy through automatic Category Rule creation, batch behavior with per-item errors, and the response shape. Annotations are neutral and not contradicted.

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 each sentence adds value. It is well-structured, starting with the main action and then detailing behavior and response. Slightly verbose but justified 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 provides the response shape. It integrates well with the context of sibling tools by referencing how to obtain input IDs. The description is complete for a batch update tool with side effects.

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 zero description coverage (0%), but the description fully compensates by explaining the structure of the `items` parameter as an array of { transaction_id, category_id } objects and specifying where to get each ID. It also includes the response format, adding meaning well 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 tool corrects transaction categories (PATCH /transactions/:id) and distinguishes it from sibling tools by explaining how to obtain transaction_id and category_id from openfinance_list_transactions and openfinance_list_categories. This provides a specific verb+resource and explicit references to related tools.

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

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

The description explains when to use the tool: to fix miscategorized transactions and improve future categorization. It mentions the side effect of creating a Category Rule. Although it doesn't explicitly state when not to use it, the context is clear, and no alternative tools are needed for this specific action.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false, so the description's mention of 'report' implies a safe write operation. The description does not add further behavioral detail beyond what annotations provide, but there is no contradiction. Adequate, but could elaborate on outcome (e.g., ticket creation).

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

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

The description is two sentences, front-loading the purpose and providing a key usage instruction. Every sentence adds value 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?

With no output schema and 0% schema description coverage, the description is minimal. It does not cover return behavior, authentication, or what happens after reporting. For a feedback tool, this lacks necessary context for an agent to understand the full impact.

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%, meaning none of the 3 parameters have descriptions. The description only mentions 'conversation array' but does not explain the 'context' or 'message' fields or their formats. The description fails to compensate for the lack of schema descriptions.

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

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

The description clearly states the tool's purpose: report a bug, missing feature, or send feedback. It uses specific verbs and resources. Among siblings focused on finance and authentication, this tool's purpose is distinct.

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 (bug/feature/feedback) and a specific instruction to include the conversation array for reproduction. However, it does not explicitly state when not to use or compare to alternatives, though siblings are unrelated.

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 that the output is version info, but no further behavioral traits beyond what annotations cover. Does not contradict annotations.

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

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

Single sentence, no wasted words. Front-loaded with the action and resource. Perfectly concise for the tool's simplicity.

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?

Low complexity, empty schema, annotations cover safety. No output schema, but description adequately states what is returned. A bit sparse on return format, but acceptable given simplicity.

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 (schema coverage 100% empty). Description doesn't need to add parameter info. Baseline for 0 params is 4.

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

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

The description clearly states it shows 'MCP platform and adapter versions'. The verb 'Show' and resource 'versions' are specific. This distinguishes it from sibling tools which are finance-related or authentication.

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

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

No explicit alternatives or when-not-to-use guidance, but the tool's purpose is self-evident. In context of siblings, it's the only version tool, so usage is clear. Lacks exclusion criteria.

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 specific behavioral context: that it returns installed MCPs, connection status, and catalog tool counts. This supplements the annotations well without contradicting them.

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

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

The description is a single, clear sentence that immediately states the purpose and lists the three key pieces of information returned. No redundant 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?

Given the tool's simplicity (no parameters, no output schema), the description fully specifies what the tool returns. It covers all relevant aspects for an agent to decide and invoke the tool correctly.

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

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

There are zero parameters, so the description does not need to add parameter information. The baseline score of 4 is appropriate as no additional parameter details are required.

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 toolkit state, specifically listing installed MCPs, their connection status, and catalog tool counts. This precisely identifies the resource and result, and differentiates it from siblings which focus on specific functions.

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 this tool is for inspecting the overall toolkit state, but does not explicitly state when to use it versus alternatives or when not to use it. No exclusions or alternative tool references are provided.

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