Banco PAN MCP

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds behavioral context: calling with no args returns a link, providing a token logs in for the session. It does not contradict annotations and provides useful details about the two modes of operation.

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

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

The description is three sentences long, front-loads the purpose, and uses clear, direct language. Every sentence adds value, and there is no redundancy or unnecessary information. It is highly concise and well-structured.

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

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

For a simple authentication tool with no output schema, the description covers the two main use cases and the parameter. It could be improved by briefly mentioning what happens after successful authentication (e.g., session state change), but overall it is complete enough for an agent to use correctly.

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

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

The schema has a single optional parameter 'token' with no description (0% coverage). The description explains that 'token' is a JWT obtained from the browser, and omitting it will return a login link. This adds essential meaning that the schema lacks, fully compensating for the coverage 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 the tool's purpose: authentication for MCP.AI IDE agents. It explains two distinct methods (permanent config vs. session token) and specifies the action of logging in via browser and copying the access token. This is specific and distinguishes the tool from potential 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?

The description provides clear guidance on when to use each authentication method: 'Best: add it to this server's config...' for a permanent connection, or 'paste it here for a session-only login'. It also explains calling with no args to get the login link. However, it does not explicitly compare to sibling tools like 'connect', so it loses a point for not differentiating from 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 and idempotentHint=true. Description adds specific behavioral detail about return values under different states (authenticated vs. missing credentials). 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 key output.

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

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

Given no parameters, rich annotations, and a simple status-check purpose, the description fully covers what the agent needs to know about return values and usage scenarios.

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 is 100%. With 0 parameters, baseline is 4. Description adds no parameter info, but none is needed.

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

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

Clearly states it returns connection status and URLs. Distinguishes from siblings like authenticate by focusing on overall connection health.

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 use context (checking when providers are connected or missing credentials) but does not explicitly state when to use vs. alternative tools like authenticate.

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: invoke works without installation, returns connect/checkout links for auth/payment, and that writes require permissions. Annotations provide limited info (destructiveHint=false), but description adds contextual detail beyond them. 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 lengthy but front-loaded with the essential purpose. It contains no filler and each sentence adds information. However, it could be better organized with clear sections for each action or parameter group to improve scanability.

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 strong context for the main workflow and special cases (auth, payment). However, it omits details on the return format (no output schema) and many input parameters. For a complex tool with many parameters, more parameter context would improve completeness.

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

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

Despite 0% schema description coverage, the description explains the 'action' parameter and its values well. However, it does not clarify other parameters like 'limit', 'message', 'arguments', 'immediate', 'tier_slug', etc. Their semantics remain undocumented, which is a significant gap for a tool with 13 parameters.

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

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

The description clearly defines the tool as the official marketplace for MCPs and explains its central role. It distinguishes from siblings by being the first tool to use for capability discovery, and it outlines the core flow of search → describe → invoke. The verb 'use' and resource 'marketplace' are specific and unambiguous.

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

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

Provides explicit when-to-use guidance: 'use THIS tool FIRST' for capability search, preference for invoke over install for one-off use, and conditions for credential or payment links. Also states required owner/admin permissions for write actions. This fully informs the agent on choosing this tool 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?

Annotations already declare destructiveHint=true, so the description adds that data will be unavailable and returns a re-connect URL. However, it does not mention authorization needs or if the action is reversible beyond the URL.

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 effectively communicate purpose and key outcome. No unnecessary words or repetition.

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 deletion tool, the description covers purpose and main behavior. However, it fails to specify the format or source of the 'item' parameter, and lacks output schema details. Given the parameter count of 1, this is a notable 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 single required parameter 'item' has no description in the schema (0% coverage) and the description does not clarify what 'item' represents (e.g., bank ID, name). Schema lacks enum or format, making it unclear for the agent.

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

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

The description clearly specifies the verb 'revokes' and resource 'Open Finance consent for a specific bank', and distinguishes from sibling tools like openfinance_list_connections which only 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 implies when to use (to disconnect a bank) but lacks explicit guidance on when not to use or alternatives. It mentions a re-connect URL but no 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?

Thoroughly explains behavior: blocking vs fire-and-forget, waiting up to ~60s, returned fields (status, executionStatus, lastUpdatedAt, synced), and edge cases like needs_action and timed_out. Annotations do not contradict.

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?

Concise yet comprehensive; no fluff. Front-loaded with key action and behavior.

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

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

Given no output schema and minimal parameter descriptions, the description provides complete context for correct 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?

Compensates for 0% schema description coverage by explaining items (array of selectors, omit for all) and wait (blocking vs fire-and-forget) in detail.

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

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

The description clearly states the tool forces a re-sync and waits for completion. It distinguishes from siblings like openfinance_get_item_status and openfinance_list_accounts.

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

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

Explicitly describes when to use (stale balance/transactions), what it does not do (reconnect), and mentions alternatives (re-check with 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?

Annotations already mark it as read-only and idempotent. The description adds value by detailing error handling for CREDIT accounts (returning warning instead of throwing) and the response shape with results and errors array. No contradictions with annotations.

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

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

The description is concise with three sentences: core function, parameter specifics with error handling, and response shape. No unnecessary words; front-loaded with the main 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?

For a simple tool with one parameter and no output schema, the description covers the response structure and error behavior adequately. It could mention authentication or edge cases but is 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?

The schema has no description for the account_ids parameter, but the description adds the crucial constraint that it must be an array of 1-50 strings. This provides 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 real-time balance for account IDs, with the API endpoint and specific usage. It distinguishes from siblings like openfinance_get_accounts_detail by focusing on balance retrieval.

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

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

The description provides context for when to use (e.g., pass account_ids array of 1-50) but does not explicitly state when not to use or compare with sibling tools. It implies usage through the description of the operation.

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

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

Annotations already mark it as readOnly, idempotent, and non-destructive. The description adds that it returns batch results with `{ results, errors }` shape and extended creditData, which provides 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?

The description is two sentences with no wasted words. It efficiently conveys the purpose, usage, and return shape.

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 batch return structure and mentions extended creditData. It is complete enough for a tool fetching account details by ID, though additional details about the account object fields could enhance completeness.

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

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

With 0% schema description coverage, the description adds crucial meaning: it specifies that `account_ids` is an array (1–50 items). This compensates for the lack of parameter descriptions in the schema, though it doesn't detail each account object's properties.

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

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

The description clearly states it returns full account objects with extended creditData per ID, using a batch shape. It distinguishes itself from list tools by specifying detail retrieval per ID, though it doesn't explicitly compare to 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?

The description instructs to pass `account_ids` as an array of 1–50 items, which is useful usage guidance. However, it lacks information on when to use this tool vs alternatives (e.g., when to use list_accounts instead) and when not to use 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 (readOnlyHint, idempotentHint, destructiveHint) already indicate safe read operation. The description adds critical context: does not return individual transactions, batch error handling, Pluggy's lack of paid/status field, and the nuance that payments[] may refer to previous billing cycle. 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?

Every sentence adds value, but the description is somewhat lengthy. Could be slightly more concise without losing clarity, but it is well structured with clear sections and front-loaded main 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, the description details returned fields (financeCharges, payments with subfields), batch shape, limitations (no transactions, no paid status), and alternative tools. For a complex financial tool, this is comprehensive.

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 compensates: explains that bill_ids is an array, instructs to use another tool to discover ids, and implies the format. 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?

The description clearly states it returns bill-level detail for credit card bills by id, listing specific fields (financeCharges, payments) and the batch shape. It distinguishes from transaction listing tools, making the verb+resource+scope 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?

Explicitly instructs to use openfinance_list_credit_card_bills to discover ids first, and for itemized transactions to use openfinance_list_transactions with account_id and date range. Also warns about the interpretation of payments[] in Brazilian Open Finance, providing 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 the tool is read-only, idempotent, and not destructive. The description adds context about the return data (status, executionStatus, connector metadata) and the difference in return format between bulk and single queries, providing transparency 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 only two sentences long, front-loaded with the main purpose, and includes all necessary information without extraneous content. Every sentence adds value.

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

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

Given the simple input schema (one optional parameter) and no output schema, the description covers both usage modes, the return format, and hints at possible status values. It is 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?

The sole parameter 'item' is not described in the schema. The description fully compensates by explaining its meaning: omit for all banks, pass for a single bank, and details the return structure for each case.

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, listing specific status values like UPDATED, UPDATING, LOGIN_ERROR. It distinguishes between getting status for all linked banks or a single one, making the purpose specific and unambiguous.

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

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

The description provides clear guidance on when to omit or include the 'item' parameter, distinguishing two use cases for single vs. all banks. However, it does not explicitly mention when this tool should be preferred over alternatives like 'openfinance_list_connections' or state prerequisites.

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 significant behavioral context beyond annotations: clarifies that CREDIT balance meaning varies by connector, that account 'name' is the legal entity not the brand, and that omitting 'item' aggregates results with per-item metadata. Annotations already state readOnlyHint and idempotentHint, and description complements without contradiction.

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

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

The description is thorough but verbose, spanning multiple paragraphs. However, it is logically structured: first core function, then parameter guidance, then caveats. Some sentences could be tightened without losing meaning.

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 and the complexity of accounts (subtypes, connector-dependent balances), the description is remarkably complete. It explains response fields, the distinction between bank brand and account name, the credit balance caveat, and references a sibling tool for standardized data. No critical gaps remain.

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' usage (omit vs pass) and 'type' (BANK or CREDIT). It could have a clearer mapping of parameter to response behavior, but the provided examples effectively demonstrate their 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 accounts for a bank connection, distinguishing between BANK and CREDIT accounts, and specifies the fields returned (balance, number, type, etc.). It differentiates from siblings like openfinance_list_connections (which lists connections) and openfinance_list_credit_card_bills (for standardized bill data).

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

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

Explicitly explains when to omit 'item' (to list all linked banks) and when to pass it (to target a single bank). Also warns about the connector-dependent meaning of CREDIT balance and directs users to openfinance_list_credit_card_bills for standardized amounts, providing clear alternatives and 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, idempotentHint=true. The description adds that the response is cached for the adapter session, a single aggregated response with no batch ids, providing useful behavioral context beyond the annotations.

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

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

Three sentences, each adding essential information: purpose+caching, field details, and aggregation behavior. No redundancy or 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 parameters and no output schema, the description fully covers what the tool returns (id, description, etc.), its caching behavior, and its connection to another tool. Nothing missing.

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

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

There are no parameters, so schema coverage is 100% trivially. The description adds clarity by stating 'no batch ids' and explaining the fields, exceeding the baseline for zero-parameter tools.

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

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

The description clearly states it returns Pluggy's transaction category taxonomy, specifies it is cached for the adapter session, and distinguishes from sibling tools that deal with accounts, transactions, etc. It also links to openfinance_update_transaction_category, clarifying its role.

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 getting category IDs before updating transaction categories (mentions categoryId used by openfinance_update_transaction_category). However, it does not explicitly state when to use or contrast with other 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, so the safety profile is clear. The description adds value by detailing the response fields and the inclusion of an add_connection_url for linking additional banks, which goes beyond the annotation.

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

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

The description is a single sentence that is front-loaded with the core purpose and lists key response fields without unnecessary detail. Every word earns its place.

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

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

Given that the tool has no parameters, no output schema, and the annotations cover safety, the description sufficiently explains what the tool returns (saved connections with specific fields and a URL). No additional information is needed for a simple 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?

The input schema has no parameters, so schema coverage is 100% trivial. The description explains what the tool returns, which adds meaning beyond the empty schema. For zero-parameter tools, a baseline 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 specifies the verb 'Returns' and the resource 'saved bank connections' with concrete fields (connector_id, item_id, bank name, add_connection_url). This clearly distinguishes it from sibling tools that focus on accounts, transactions, or other operations.

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

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

The description implies usage for listing existing connections but does not explicitly state when to use it versus alternatives like openfinance_list_accounts or openfinance_get_item_status. No exclusions or when-not-to-use 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?

Annotations show readOnlyHint, idempotentHint, destructiveHint=false. Description adds extensive behavioral context: derived payment_status logic, cross-bill payment detection, open bill opt-in behavior, connector asymmetry, and more. 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 long but well-structured with clear sections. Every sentence adds value, though some might consider it verbose. It is appropriately front-loaded with key 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?

Given the complexity of Brazilian Open Finance semantics, connector asymmetry, and derived fields, the description is highly complete. It covers return values, warnings, opt-in behavior, and references sibling tools. No output schema needed.

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 explains include_open_bill and its default, but page, page_size, account_ids are not explicitly described. Partially compensates but not fully.

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

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

The description clearly states the tool returns CLOSED credit card bills for a CREDIT-type account, listing specific fields. It differentiates from siblings like openfinance_list_transactions and openfinance_get_credit_card_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?

Explicitly provides when to use (getting closed bills) and when not (not for individual transactions, not for paid status directly). Mentions alternatives like openfinance_list_transactions for itemized purchases.

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, indicating a safe read operation. The description adds value by disclosing that the tool returns a consistent structure with a warning field instead of throwing errors when investments are not enabled or on upstream errors. This is 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?

Three sentences: first defines purpose, second details output fields, third addresses error handling. No redundant information; essential details are front-loaded. Highly concise and well-structured.

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

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

Given the tool's complexity (4 optional parameters, no output schema), the description provides a good overview of return fields and error behavior but omits parameter explanations. It also does not mention authentication or prerequisites like having an open finance connection. Adequate but with notable 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?

Schema description coverage is 0%, meaning the description must compensate. However, it provides no explanation for the four parameters (item, page, type, page_size). Even the type parameter's enum values are not elaborated. The description focuses solely on output, leaving parameter semantics entirely undocumented.

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

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

The description clearly states the tool returns an investment portfolio for a connection and enumerates specific asset classes (FIIs, stocks, ETFs, etc.). It is specific and uses a clear verb ('Returns'). However, it does not explicitly differentiate from sibling tools like openfinance_list_investment_transactions, which likely deals with transaction history. Hence, a 4.

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 guidance on when to use this tool versus alternatives. The description only implies usage by describing the output, but with many openfinance siblings, contextual cues are absent. No 'when to use' or 'when not to use' instructions are 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?

Annotations already provide readOnlyHint and idempotentHint. The description adds value by detailing the specific output fields and types of movements, giving more transparency 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 and details. 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, the description lists return fields, which is helpful. It covers prerequisites and bulk support but omits pagination parameter semantics, leaving it partially incomplete.

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

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

Schema description coverage is 0%, so description must compensate. It mentions investment_id and investment_ids in context, but does not describe page and page_size parameters, leaving some parameters without semantic meaning.

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

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

The description clearly states the tool returns movement history for a specific investment position, listing movement types and fields. It differentiates from sibling tools like openfinance_list_investments by specifying 'specific' and from openfinance_list_transactions by focusing on a single investment.

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

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

Explicitly states to use after openfinance_list_investments to get investment_id, providing clear usage context. Does not explicitly exclude alternatives but the prerequisite guides appropriate 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 read-only and idempotent. Description adds sequential execution and rate-limit spacing, plus return format per connection.

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 concise sentences with no unnecessary words. Front-loaded with purpose and endpoint.

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 provides return format `{ results, errors }` per connection. Covers purpose, parameter usage, and behavior sufficiently.

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% coverage. Description fully explains that `items` is an array of connection selectors (item_id uuid, connector_id, or connector_name), compensating completely.

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 lists loan contracts per bank connection with the HTTP method. Distinguishes from sibling tools by specifying 'loan contracts per bank connection'.

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

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

Provides explicit guidance on using the `items` parameter for specific connections or omitting it for all. Mentions sequential querying with rate-limit spacing.

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?

Annotated as readOnly, idempotent, non-destructive. The description adds transparency about CREDIT PENDING vs POSTED variability by connector, error handling (returns warning/error instead of throwing), and bulk support. 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 long, every sentence adds essential detail. It is front-loaded with the core purpose. Minor verbosity but justified by 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 7 parameters, no output schema, and high complexity, the description covers error handling, edge cases (truncated, zero total), bulk support, and cross-references sibling tools for 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?

With 0% schema description coverage, the description compensates thoroughly: explains from/to as ISO dates, pagination (max 500/page), search_queries behavior (case-insensitive, OR semantics, aggregation of up to 5000), and account_id vs account_ids for bulk.

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

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

The description clearly states it returns transactions for bank accounts (BANK or CREDIT) and distinguishes it from siblings by noting it is the only way to get itemized CREDIT transactions and contrasts with openfinance_list_credit_card_bills for standardized totals.

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 it (e.g., for CREDIT itemized transactions) and when not (use openfinance_list_credit_card_bills for standardized totals). Provides guidance on handling truncated results, zero total, 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 indicate readOnlyHint=true and idempotentHint=true. The description adds valuable detail: it internally fans out transactions, caps scanning at 5000 per account with a truncated flag, and provides a compact summary by default. 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 long but every sentence adds necessary information. It is well-structured: purpose first, then usage context, parameter details, and use-case keywords. Slightly verbose but 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?

Despite lacking an output schema, the description thoroughly details the response format: compact summary with total entradas/saídas/saldo_líquido, monthly evolution, top expenses/revenues, and per-account breakdown. It also explains the behavior of 'raw' granularity and truncation, leaving 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?

With 0% schema description coverage, the description fully compensates. It explains the purpose and behavior of all six parameters: 'item' (optional, targets a bank or all), 'from'/'to' (ISO dates), 'granularity' (monthly with default summary, raw for itemized), 'type' (BANK/CREDIT), and 'top_n' (implicit in top_despesas/recebimentos). Defaults and effects are clearly stated.

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 performs 'consolidated cash-flow analysis for a whole bank CONNECTION over a period'. It distinguishes from sibling tools by noting that you do not need to call openfinance_list_accounts first. It also lists specific use-case phrases like 'fluxo de caixa' and 'maiores gastos/recebimentos'.

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 (e.g., for annual/monthly analysis, cash flow) and explains key parameter choices like omitting 'item' for all linked banks and selecting granularity. It does not, however, explicitly exclude cases where a raw transaction list without aggregation is needed (which would be better suited to openfinance_list_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 and idempotentHint, so the tool is safe. The description adds behavioral context about checking a public status page and returning specific fields (global indicator, degraded components, incidents, your_banks_affected), which goes beyond the annotations.

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

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

The description is a single paragraph but well-structured: first sentence states purpose, then usage context, then what it returns. Every sentence adds value, and the most important information 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?

Given no parameters, no output schema, and annotations present, the description sufficiently explains the tool's purpose, usage, and return values. The agent can fully understand when and how to use it.

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 no parameter semantics are needed. Schema description coverage is 100% by default. The description does not need to add parameter info, and it does not.

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, and distinguishes it from the sibling openfinance_get_item_status which checks the user's own connection. The verb 'checks' and resource 'provider status' are 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?

The description explicitly says when to use it: when data looks incomplete or stale despite a connection showing UPDATED, and explains how it helps differentiate provider-side problems from connection issues. It also lists what the returns include, providing clear 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?

Beyond annotations (readOnly, idempotent), description adds: plan-based filtering (PF hides PJ), hint behavior when keywords omitted, and that it never dumps whole catalog. 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 sentences, front-loaded with core purpose, then details. 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?

Despite no output schema, description fully covers returns (connector id, access, audience, connections, accounts, connect_url). Also covers plan filtering and hint behavior. Complete for a search tool with two parameters.

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 compensates by explaining keywords as array of bank names with examples, and include_accounts role. It states keywords is required, though schema doesn't mark it required (minor inconsistency).

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

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

The description uses specific verbs ('Searches', 'returns') and clearly identifies the resource ('bank connectors'). It lists returned fields and distinguishes from siblings by focusing on searching for available connectors before connecting.

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

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

Explicitly states 'Call this BEFORE connecting' and that keywords is required. Provides guidance on when to use but does not explicitly state when not to use or list alternatives, though context 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?

The description discloses that recategorizing overrides Pluggy's automatic categorization and teaches it by creating a Category Rule for future similar transactions. It also describes the response format and that per-item errors do not fail the batch. This adds significant behavioral context beyond the annotations (which only set readOnlyHint, destructiveHint, idempotentHint to false).

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

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

The description is detailed and well-structured, starting with the main action, then explaining side effects and response. While it is somewhat long, every sentence provides useful information, and it is front-loaded effectively. It could be slightly more concise but is appropriately sized for 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 sibling tools and the absence of an output schema, the description is complete: it explains how to use the tool in conjunction with list tools, describes the batch update behavior, error handling, and the effect on future categorizations. No additional context is needed.

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 only one parameter 'items' with 0% coverage, but the description fully explains that items is an array of objects with transaction_id and category_id, and specifies where to retrieve these IDs. This adds essential meaning beyond the bare schema.

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

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

The description clearly specifies the tool corrects the category of one or more transactions, using PATCH /transactions/:id. It distinguishes from siblings like openfinance_list_transactions and openfinance_list_categories, which are retrieval tools.

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

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

The description explains when to use the tool (to fix miscategorized transactions), how to obtain required IDs (from openfinance_list_transactions and openfinance_list_categories), and notes the side effect of creating a Category Rule. It also describes batch behavior and error handling, providing clear usage 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 (idempotentHint: true, destructiveHint: false) already indicate the tool is safe and non-destructive. The description adds no behavioral context beyond 'report a bug', such as rate limits, confirmation, or state modification details.

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 short sentences, front-loading the core purpose and key parameter guidance. It is concise and avoids unnecessary detail.

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 bug report tool with 3 parameters and no output schema, the description covers the purpose and one parameter. Missing details on the context parameter and what happens after reporting (e.g., confirmation) reduce completeness.

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

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

Schema coverage is 0%, so the description must compensate. It explains the conversation parameter's purpose ('with recent messages for reproduction') and implies message is the bug report text. However, it does not clarify context or output 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 the tool reports bugs, missing features, or feedback. It distinguishes itself from sibling tools (e.g., authentication, finance management) by being the only feedback mechanism.

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 advises to include the conversation array with recent messages for reproduction, providing specific usage guidance. However, it does not specify when to use this tool versus alternatives or exclude cases, but given no direct alternatives, clarity is high.

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 context by specifying that both platform and adapter versions are shown, which is not in 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 sentence that is concise, front-loaded with the action, and contains no unnecessary words.

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

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

Given no parameters and no output schema, the description sufficiently explains the tool's purpose and output (versions). It could mention the return format, but it is not essential for a simple version info 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?

There are no parameters, and schema coverage is 100%. The description does not need to add parameter meaning, but it clearly states what the tool does without parameter details, which 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 'Show the current MCP platform and adapter versions' uses a specific verb ('Show') and clearly identifies the resource (current versions). It distinguishes from sibling tools, none of which provide version information.

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 version info, which is clear given no parameters and no alternative among siblings. However, it does not explicitly state when or when not to use it, but this is less critical for a simple read-only tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about what is returned (installed MCPs, connection status, catalog tool counts), which is valuable beyond the annotations. 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 concisely and front-loads the core purpose. 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?

The tool has no parameters and no output schema. The description fully explains what the tool returns (installed MCPs, connection status, catalog tool counts), making it complete for an informational tool with no dependencies.

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

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

The tool has no parameters (0 params, 100% schema coverage). With zero parameters, the baseline is 4 per instructions, and the description does not need to add parameter-level detail.

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

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

The description clearly states it returns the current toolkit state: installed MCPs, connection status, and catalog tool count. This is a specific verb+resource combination that distinguishes it from sibling tools like authenticate, connect, and openfinance_* operations.

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

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

The description implicitly suggests it is for checking overall toolkit state, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. As a read-only info tool, usage is straightforward, but the absence of explicit directives keeps it at a 3.

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