Banco Bmg MCP

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

Description adds context beyond annotations: explains idempotent behavior (no args returns link), session-only vs permanent, and no destructive effects. 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 sentences, efficient but the second is dense with instructions. Could be slightly clearer with bullet points, 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?

For a simple 1-param optional tool, description covers all usage scenarios (permanent config, session token, no-arg link). No output schema needed; return value implied.

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, description fully compensates by explaining the token parameter: its source (JWT from browser), optionality, and effect when provided or omitted.

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 handles authentication for IDE agents, explaining two login methods (permanent via config, session via token) and a no-arg call to get a link. Verb 'authenticate' is specific and distinct from siblings.

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

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

Explicitly explains when to use each method: permanent vs session-only login, and mentions adding token to config as an alternative. Provides clear context for 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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing return values under different conditions, 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 sentences, front-loaded with core purpose, no wasted words.

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

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

Given no input or output schema, the description adequately covers possible outputs and behavior.

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

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

No parameters, baseline 4. The description adds no parameter info but explains the tool's action sufficiently.

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 connection status and URLs, differentiating between states (all connected vs. missing credentials). The verb 'returns' and resource 'connection status' are specific, and it 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 implicitly indicates when to use (check connection status) and explains expected outputs. However, it does not explicitly state when not to use or provide alternatives.

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

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

Discloses key behavioral traits: invoke works even when MCP not installed, may return connect or checkout links, and writes require workspace owner/admin. No contradiction with annotations (readOnlyHint=false, etc.). 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?

The description is a single dense paragraph but front-loads the most important information. It is efficient for the complexity, though could benefit from structuring into sections for easier scanning.

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 (13 parameters, no output schema, no parameter descriptions), the description covers the workflow, action distinctions, and handling of credentials/payment well. However, it lacks explicit details on output format, error handling, and parameter validation.

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 the usage of main parameters (action, query, mcp_id) implicitly through workflow descriptions. However, it lacks explicit details for all 13 parameters, such as format for 'arguments' and 'conversation'. Provides partial compensation but not comprehensive.

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 for discovering and running MCPs/tools, distinguishing it from external registries. It explains the core flow (search, describe, invoke) and lists all actions, making the purpose unambiguous.

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

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

Explicitly states "use THIS tool FIRST" when the user wants a capability, and provides detailed guidance on when to use install vs invoke, as well as other actions. It differentiates from sibling tools by positioning itself as the primary marketplace tool.

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

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

Annotations already indicate destructive risk; description adds detail: revocation of consent, deletion of data, unavailability, and return of reconnection URL. 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?

Three short sentences covering action, consequence, and return value. No unnecessary 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?

Adequate for a simple destructive tool: explains action and outcome. Missing parameter explanation and error/precondition context, but annotations fill some 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?

Single parameter 'item' is a string with no schema description. The tool description mentions 'specific bank' but does not clarify what 'item' represents, e.g., bank ID or connection ID.

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 revokes Open Finance consent for a specific bank and deletes connection data, with explicit consequence. Distinguishes from sibling tools like connect or openfinance_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?

Implies usage when disconnecting a bank, but no explicit guidance on prerequisites or when not to use vs. alternatives like openfinance_get_item_status.

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

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

Discloses full behavior: immediate sync, polling, ~60s timeout, result structure including 'timed_out', 'needs_action', 'synced'. Annotations confirm non-read-only but non-destructive, and description adds rich context beyond annotations.

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

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

Single paragraph with front-loaded purpose and behavior. Every sentence adds value: purpose, when to use, parameter details, result fields, error handling. No redundancy or unnecessary words.

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

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

Given no output schema, the description thoroughly explains result structure ({results, errors} with per-item fields). Covers timeout, status outcomes, and suggests follow-up tool. Complete for a sync operation tool.

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

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

With 0% schema description coverage, the description fully compensates by explaining both parameters: 'items' as array of selectors (item_id, connector_id, connector_name) and omission for all banks; 'wait' boolean for synchronous vs fire-and-forget behavior.

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 forces re-sync of connections and waits. It uses specific verbs ('forces', 're-sync', 'polls') and distinguishes from sibling tools like openfinance_get_item_status and openfinance_disconnect_bank.

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

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

Explicitly says when to use (stale balance/transactions), what to avoid ('Without disconnecting/reconnecting'), and provides alternatives (re-check with openfinance_get_item_status). Also explains parameter variants ('wait: false' for fire-and-forget).

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 beyond annotations: mentions CREDIT accounts may return a structured warning instead of throwing, describes response shape with results and errors. Aligns with readOnlyHint, idempotentHint, and 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?

Three sentences, front-loaded with purpose and endpoint, then parameter usage, then edge case and response 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?

Given no output schema, description adequately covers response shape and error structure. For a simple balance tool with one param, it's complete and adds context on CREDIT behavior.

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 value by specifying array format and size constraint (1–50). Lacks details on each item format, but for strings it's sufficient.

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

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

Clearly states it returns real-time balance per account ID via a specific endpoint, and specifies array size limit (1–50). Differentiated from siblings like list_accounts by focusing on balance for provided 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?

Implicitly conveys usage for fetching balance of specific accounts, but doesn't explicitly contrast with alternatives like list_accounts for listing all accounts. The CREDIT edge case warning is helpful, but lacks explicit when-to-use/when-not-to-use 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 already indicate read-only and idempotent. Description adds batch size limit (1-50) and shape of response ({ results, errors }). 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, no wasted words. Front-loaded with core purpose, then usage. Highly 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?

Without output schema, description gives minimal return structure (batch shape) but doesn't detail the account object fields. Adequate for a simple batch lookup, but could elaborate.

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

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

Schema coverage is 0%, but description adds essential constraint (array of 1-50 strings) and explains purpose. Compensates well for missing schema documentation.

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, distinguishing it from a list endpoint. Mentions batch retrieval via account_ids array.

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

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

Implies use for detailed account info with extended creditData, but does not explicitly compare to sibling list or balance tools. Lacks explicit when-not 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?

Discloses that individual transactions are not returned, that Pluggy does not return paid/status field, and explains the meaning of payments[] in Brazilian Open Finance. Adds significant context beyond annotations.

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

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

The description is well-structured with front-loaded output details. Each sentence adds value, though it could be slightly more concise.

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

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

For a tool with one parameter and no output schema, the description covers all essential behavioral aspects, including edge cases (payments interpretation) and references to sibling tools. It is complete enough 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 only parameter (bill_ids) is explained: 'Pass bill_ids as an array — use openfinance_list_credit_card_bills first to discover ids.' With 0% schema coverage, the description compensates well for the single parameter.

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

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

The description clearly states it returns bill-level detail for credit card bills by id, listing specific fields (financeCharges, payments). 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?

Explicitly advises to use openfinance_list_credit_card_bills first to discover ids, warns about payments[] interpretation, and directs to openfinance_list_transactions for itemized transactions. Provides clear when-to-use 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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral details beyond annotations by specifying the possible status values, executionStatus, and the dual response format. 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 two sentences, front-loaded with the core purpose, and then efficiently explains the two usage modes. Every word adds value; there is 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 no output schema, the description explains the return format for both cases (including `count` and `items` for all banks). It covers the main behavior comprehensively, though it does not mention error handling or invalid `item` values, which is acceptable for a simple status tool.

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

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

The input schema has a single optional parameter `item` with 0% description coverage (no schema description). The description fully compensates by explaining that omitting `item` returns status of all banks as `{ count, items }`, while passing `item` returns status for a single bank. This provides complete semantics.

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

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

The description clearly states it returns 'current status of a bank connection' with specific status values (UPDATED, UPDATING, LOGIN_ERROR, etc.), executionStatus, and connector metadata. It also distinguishes between querying all linked banks (omitting `item`) and a single bank (passing `item`), which differentiates it 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 provides guidance on when to omit or pass the `item` parameter, and explains the return format for each case. It could have mentioned scenarios where it is not appropriate or alternative tools, but the provided context is clear enough for most use cases.

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 non-destructive. The description adds critical behavioral details: the credit balance is connector-dependent, the meaning of `name` vs `bank`, and the significance of creditData fields. 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 lengthy. However, it is well-structured, front-loaded with the core purpose, and every sentence provides necessary context. A minor reduction for density but still highly 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 no output schema, the description covers all essential information: return fields, parameter effects, behavioral nuances, and cross-references to sibling tools. It is fully complete for an agent to use correctly without additional 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?

Schema coverage is 0%, but the description fully explains both parameters: `item` (omit for all accounts, pass for single bank) and `type` (BANK or CREDIT, with specific behavior for CREDIT balance). It also describes how the response structure changes depending on parameter usage.

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

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

The description clearly states the tool returns accounts for bank connections, distinguishing between BANK and CREDIT types with specific fields. It differentiates from sibling tools like openfinance_list_credit_card_bills by explicitly stating when to use that tool instead.

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

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

The description provides explicit guidance on when to omit vs pass the `item` parameter (all banks vs single bank), warns not to treat credit balance as 'this month's bill', and directs users to openfinance_list_credit_card_bills for standardized bill amounts. It clearly states when NOT to use this tool.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by disclosing 'cached for the adapter session' and 'single aggregated response', which are behavioral details beyond annotations.

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

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

Description is efficient: states purpose first, then details fields, then caching behavior. Every sentence adds value, 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?

With no parameters, no output schema, and annotations present, the description fully explains the tool's functionality, output fields, caching, and integration with sibling tool. Complete for agent use.

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

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

No parameters in schema (0 params), so baseline is 4. Description does not need to add parameter info; it instead explains output structure, which is acceptable for a parameterless tool.

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

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

Description clearly states 'Returns Pluggy's transaction category taxonomy (GET /categories)' with specific verb and resource. It also distinguishes the tool from sibling openfinance_update_transaction_category by noting that the categoryId is used by that tool.

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

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

No explicit when-to-use or when-not-to-use guidance, but the description implies it's for retrieving categories. The mention of 'no batch ids' provides a constraint, but no alternatives are discussed.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns an add_connection_url for linking additional banks, which is useful context but does not go beyond what annotations already signal about safety. 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 sentence that conveys the tool's purpose, scope, and output. Every word adds value, and there is 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 the tool's simplicity (no parameters, no output schema), the description covers the key aspects: what is returned and the structure of the result. However, it omits details such as whether the list is paginated, if there are limits, or the format of the add_connection_url. This is a minor 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?

The tool has zero parameters, so the schema coverage is 100%. The description does not need to provide parameter details. With no parameters, a baseline score of 4 is appropriate.

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

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

The description clearly states the verb 'Returns', the resource 'saved bank connections', and lists specific fields (connector_id, item_id, bank name, add_connection_url). It effectively distinguishes from sibling tools 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?

The description implies usage for listing existing connections but provides no explicit guidance on when to use this tool versus alternatives such as openfinance_search_bank_connectors or openfinance_get_item_status. No exclusions or prerequisites are mentioned.

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 rich behavioral context beyond annotations: detailed payment semantics, derived payment_status logic, cross-bill payment handling, connector asymmetry, opt-in nature of include_open_bill with extra scan, and warning output instead of failure. No contradiction with annotations.

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

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

The description is very long and detailed, with multiple paragraphs. While structured and informative, it is not concise. Every sentence adds value, but overall length could be reduced for easier consumption.

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 explains return fields thoroughly: dueDate, totalAmount, paymments[], payment_status, open_bill structure, etc. It also covers edge cases like connector asymmetry and warning. Missing explicit response structure (e.g., an object with results array), but still quite complete.

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

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

Schema coverage is 0%, so the description carries the burden. It explains include_open_bill in detail (purpose, default, performance implication) and account_ids for bulk. However, page and page_size are standard but not described, which is a minor gap.

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

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

The description clearly states that the tool returns CLOSED credit card bills with specific fields. It distinguishes from openfinance_list_transactions for itemized purchases, but doesn't explicitly differentiate from the sibling openfinance_get_credit_card_bill, though the plural 'bills' implies listing.

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

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

Provides explicit when-to-use: for bill-level summaries (not transactions), and points to openfinance_list_transactions for itemized data. Also explains when to use include_open_bill and the warning about connector asymmetry. Gives alternatives clearly.

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 idempotentHint=true. The description adds value by disclosing the error handling pattern (returns {total:0, results:[], warning} instead of throwing on 403 or upstream errors), which is beyond annotation scope.

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 with three front-loaded sentences: purpose, output details, and error behavior. 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 annotations and no output schema, the description covers error handling and output fields but fails to explain pagination parameters or how to specify the connection. Parameter semantics are incomplete, leaving gaps for effective tool 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?

With 0% schema description coverage and 4 parameters, the description adds minimal input semantics. It implicitly references the 'type' parameter via asset type listing but does not explain the meaning or usage of any parameter (item, page, type, page_size).

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

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

The description clearly states the tool returns the investment portfolio for a connection with INVESTMENTS enabled, listing specific asset types. This distinguishes it from sibling tools like openfinance_list_investment_transactions, which focus on transactions, not the portfolio snapshot.

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

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

The description implies usage for retrieving portfolio overview when INVESTMENTS product is enabled, but does not explicitly state when to prefer this tool over alternatives (e.g., list_investment_transactions) or provide 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 and idempotent. Description adds concrete details on returned fields and transaction types, plus bulk execution capability. 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 efficient paragraphs: first covers purpose and return fields, second covers bulk. No extraneous information. Front-loaded with main action.

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

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

Provides field details and transaction types despite no output schema. Links to predecessor tool. Lacks pagination behavior explanation, but schema hints allow inference.

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, so description must compensate. It explains investment_id (required) and investment_ids (bulk) but omits page and page_size. Partial coverage for key params but misses pagination.

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

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

The description states it returns movement history for an investment position with specific transaction types (BUY, SELL, etc.), differentiating it from sibling tools like openfinance_list_investments which lists positions. It explicitly links to the prerequisite tool.

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

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

Clear guidance to use after openfinance_list_investments to obtain investment_id. Mentions bulk support via investment_ids. Could be improved with explicit 'when not to use' but sufficient given sibling context.

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, establishing safety. The description adds valuable behavioral context: sequential queries with rate-limit spacing, return format per connection ({ results, errors }). No contradictions.

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

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

Description is three succinct sentences: first states purpose and endpoint, second explains parameter usage, third covers omission case and return format. Every sentence earns its place; front-loaded with the core action.

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

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

Given no output schema, the description sufficiently covers input and output structure ('returns { results, errors } per connection'). It does not detail the contents of loan contracts or error objects, but for a simple list tool with one parameter, this is adequate. The sequential rate-limit note adds operational 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?

With 0% schema description coverage, the description fully compensates by explaining the items parameter: it is an array of connection selectors (item_id uuid, connector_id, or connector_name), one per connection, and its omission lists all loans. This adds essential 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 'Lists loan contracts per bank connection (GET /loans)', specifying the verb, resource, and endpoint. It differentiates from sibling tools like list_accounts or list_transactions by focusing on loan contracts and providing distinct usage options for connection selectors vs. all.

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

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

Description explains when to use the tools: for listing loan contracts. It provides explicit guidance on the items parameter (include for specific connections, omit for all) and notes sequential rate-limited querying. While it does not explicitly compare to alternative tools, the sibling context makes the differentiation 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?

Discloses key behaviors beyond annotations: search_queries aggregation limit (5000), truncated flag, error handling with warning/error fields, and troubleshooting steps for zero results (check connection health). Annotations only indicate read-only and idempotent.

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

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

Well-structured with logical sections (purpose, credit details, parameter notes, error handling, bulk support). Slightly lengthy but every sentence adds value; front-loads core purpose.

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

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

Given no output schema, explains return structure sufficiently (total, results, warning, error, truncated flag, creditCardMetadata.billId). Could mention pagination metadata, but overall complete for a complex tool.

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

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

Despite 0% schema description coverage, the description adds meaning for most parameters: from/to as ISO dates, page_size cap, search_queries as case-insensitive substring match with OR semantics. Lacks details on defaults (e.g., page_size default) but generally compensates well.

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

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

The description clearly states the tool returns transactions for bank accounts, distinguishes between BANK and CREDIT types, and explicitly differentiates from sibling tools like openfinance_list_credit_card_bills and openfinance_list_transactions_by_item.

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

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

Provides explicit when-to-use guidance: for CREDIT accounts, it's the only way to get itemized transactions. Offers alternatives (openfinance_list_credit_card_bills for standardized totals) and explains behavioral nuances like PENDING vs POSTED varying by connector.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. Description adds critical behavioral details: scan caps at 5000/account with truncated flag, compact vs raw output, and internal account resolution. 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?

Description is somewhat lengthy but well-organized with key information front-loaded. Every sentence serves a purpose, though some restructuring (e.g., bullet points) could improve scanability. Still 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?

Given 6 parameters, 0% schema coverage, no output schema, and sibling tools, the description covers output format (compact summary fields, truncated flag), defaults, filtering options, and usage context. Adequately prepares an agent to use this tool correctly.

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

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

Schema has 0% description coverage, but description fully explains each parameter: item (multiple identifier types), from/to (ISO dates), granularity (monthly/raw with behavior difference), type (BANK/CREDIT filter), top_n (number of top items). Adds meaning beyond 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?

Description clearly states it provides consolidated cash-flow analysis for a bank connection in one call, resolving accounts internally. Distinguishes from siblings like openfinance_list_accounts and openfinance_list_transactions by noting it avoids separate account listing calls.

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 lists use cases ('análise anual/mensal', 'fluxo de caixa', etc.) and explains when to omit item for all banks. Warns about raw granularity being heavier. Provides clear context for when to use this tool versus alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds substantial behavioral detail: it returns a global indicator, degraded components, open incidents, and flags incidents affecting the user's connected banks in 'your_banks_affected'. 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?

While the description is somewhat lengthy, every sentence contributes value: it states the purpose, provides usage guidance, and describes return data. The structure is logical, front-loading the primary action. Minor conciseness improvements could be made (e.g., slightly tightening the usage scenario list), but overall it's well-organized.

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

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

Given zero parameters, no output schema, and annotations covering safety, the description is remarkably complete. It explains when to use, what it returns, and how it interacts with connected banks. It also explicitly distinguishes from a sibling tool, providing full context for an agent to decide on 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 zero parameters, so the description cannot add parameter-level meaning. However, the description indirectly clarifies that no parameters are needed, which is adequate. Baseline for zero parameters is 4, and the description meets this without needing further param 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 checks the LIVE operational status of the Open Finance provider, explicitly distinguishing it from the sibling tool 'openfinance_get_item_status' which checks the user's own connection. The verb 'checks' and the specific resource 'provider status' make the purpose unambiguous.

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

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

The description provides explicit when-to-use scenarios: 'whenever data looks incomplete or stale even though a connection shows UPDATED', with concrete examples like missing accounts/transactions/balances. It further explains that the tool helps differentiate provider-side problems from connection issues, offering clear guidance on when this tool is appropriate over 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 value beyond annotations: describes plan-based filtering of results, the behavior when keywords are omitted (returns hint), and the returned fields. Annotations already indicate readOnly, idempotent, non-destructive.

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 paragraph, front-loaded with action, no redundancy. Could be slightly more structured but remains 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?

Covers all needed aspects: required parameter behavior, returned fields, plan filtering, and usage order relative to other operations. No output schema but description sufficiently explains returns.

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 effectively explains both parameters: keywords[] is REQUIRED and used for name matching, include_accounts enriches output. Provides example keywords format.

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 action ('searches'), target ('bank connectors'), and method (by name/keywords). It distinguishes from siblings by specifying that it returns a ready connect_url and honors user plan, which other tools like connect or authenticate do not.

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 instructs 'Call this BEFORE connecting', providing clear usage context. While it does not list alternatives, the directive is sufficient for agent decision-making.

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

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

Annotations (readOnlyHint=false) indicate a write operation, and the description adds critical behavioral context: it overrides automatic categorization and teaches Pluggy by creating a Category Rule. It also discloses the exact batch response format and error handling per-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 somewhat long but every sentence adds value: purpose, parameter details, side effects, and response format. It is well-structured with clear information ordering, though a minor reduction in verbosity could improve conciseness.

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

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

Despite no output schema, the description completely covers the response shape, side effects (Category Rule creation), batch processing behavior, and error handling. It leaves no significant gaps for agent decision-making.

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

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

With 0% schema description coverage, the description fully compensates by explaining the `items` array structure, the required `transaction_id` and `category_id` fields, and their origins from other tools. This provides meaning far beyond the schema's empty 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 corrects transaction categories via PATCH, specifies the verb ('Corrects') and resource ('transactions'), and distinguishes from sibling tools by referencing openfinance_list_transactions and openfinance_list_categories for obtaining 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?

The description provides explicit guidance on when to use the tool ('to fix miscategorized transactions') and explains the side effect of creating a Category Rule for future similar transactions. It also specifies batch behavior and error handling, leaving no ambiguity about usage.

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

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

Description adds no behavioral context beyond annotations. Annotations indicate idempotentHint=true, which contradicts the likely non-idempotent nature of reporting, creating a potential 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 clear sentences, no fluff. Could benefit from more structure or a title, but effective for 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 3 parameters with no schema descriptions, no output schema, and sibling context, the description lacks completeness. Does not explain return values or parameter usage beyond a single hint.

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%. The description only mentions 'conversation' but does not explain its format or the other parameters (message, context). Provides marginal help.

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

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

Clearly states the verb 'Report' and resources 'bug, missing feature, or send feedback'. Differentiates from sibling tools which are all Open Finance related, so it stands out.

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

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

Provides a hint to include conversation array for reproduction, but no explicit when-to-use or alternatives. Adequate but not explicit.

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, fully covering the behavioral safety profile. The description adds the specific domain of version info but no further behavioral traits 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 a single succinct sentence that front-loads the purpose with no extraneous words.

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

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

Given the simplicity of the tool (no parameters, clear annotations), the description sufficiently conveys its functionality. No output schema exists, but the output is inherently understood as version strings.

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

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

The tool has zero parameters, so the description does not need to add parameter details. Baseline score of 4 applies per rubric for no-parameter tools.

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

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

The description clearly states the tool shows current MCP platform and adapter versions, using a specific verb and resource. It is distinct from sibling tools which are mostly openfinance operations 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 guidance on when to use this tool versus alternatives is provided. The description merely states what it does without any context or exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, fully covering the safety profile. The description adds no additional behavioral traits (e.g., data freshness, rate limits) 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 front-loads the purpose and provides specific details without any wasted words. Every component 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?

The tool is simple (no parameters, no output schema), and the description clearly states what information is returned: installed MCPs, connection status, and catalog tool counts. This is complete for a status inspection tool.

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

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

The tool has zero parameters, and the schema coverage is 100%. Per rubric, 0 parameters warrants a baseline of 4. The description adds no parameter semantics because none are needed.

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

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

The description uses a specific verb ('Returns') and clearly identifies the resource ('current toolkit state') with explicit details on what is returned (installed MCPs, connection status, catalog tool counts). It distinguishes itself from siblings, none of which serve a similar state-inspection purpose.

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

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

The description implies when to use this tool (to inspect toolkit state) and no sibling tool serves the same purpose, so context is clear. However, it provides no explicit instructions on when not to use it or alternatives, which is acceptable for a unique read-only tool.

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