Banco BRB MCP

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

Annotations already specify idempotentHint=true and destructiveHint=false. The description adds behavioral context beyond annotations: it explains that calling without token returns a login link, while calling with token logs in. This explains what the tool does in each case, though it could mention potential errors or side effects.

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

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

The description is three sentences with clear structure: introduction, best practice, usage instruction. It is well front-loaded but includes some technical details (e.g., 'Authorization: Bearer') that could be trimmed for brevity. Still 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?

The description covers purpose, usage modes, and parameter meaning. However, it lacks details about the return value (e.g., success confirmation or error messages) and does not explain what happens after authentication (e.g., session state). Given no output schema, 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?

Schema coverage is 0% with no parameter descriptions, so the description fully compensates. It explains the 'token' parameter as a JWT for session-only login, and clarifies that omitting the argument returns a login link. This adds meaning beyond the raw schema.

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

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

The description clearly states the tool's purpose: authentication for MCP servers in IDE agents. It specifies the resource (authentication token) and verb (login, obtain link), and distinguishes the tool from siblings like openfinance or marketplace which are unrelated to authentication.

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

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

The description provides clear guidance on two usage modes: permanent via config or session-only by passing a token. It explains when to use each (best practice vs. session-only) and how to invoke the tool (with or without arguments). However, it does not explicitly state alternatives or when not to use the 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 read-only, idempotent. Description adds context about returning different outputs based on connection state (authenticated vs pending), which is valuable beyond annotations.

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

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

Two sentences, front-loaded with purpose, no unnecessary words. 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?

For a zero-parameter tool with clear annotations, the description covers the two scenarios and return values completely. 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?

No parameters exist, so baseline is 4. Description does not need to add param info.

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, and distinguishes two scenarios (all connected vs missing credentials). It uses specific terms like authenticated, pending, connect_url, and distinguishes from siblings like authenticate.

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

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

The description explains that the tool checks connection status, implying when to use it. It doesn't explicitly provide alternatives or exclusions, but the context is clear.

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

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

The description adds extensive behavioral context beyond annotations: it explains that invoke works without installation, returns connect/checkout links when needed, and details billing/subscription management. No contradiction with annotations (readOnlyHint=false, destructiveHint=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 a single, dense paragraph. While every sentence adds value, it lacks structure (e.g., bullet points) and could be more easily parsed. It is not overly long but sacrifices readability for completeness.

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

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

Given the tool's complexity (13 parameters, multiple actions, no output schema), the description covers the overall flow, usage guidelines, and behavioral traits well. However, it does not fully explain all parameters or return values, leaving some aspects 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?

With 0% schema description coverage and 13 parameters, the description provides meaning for key parameters like action, mcp_id, tool_id, and arguments by explaining the core flow (search, describe, invoke). However, it does not detail parameters like limit, query, message, conversation, etc., leaving gaps for an AI 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 states the tool is 'THE official mcp.ai marketplace' and explains its core function: discovering, describing, and running MCPs. It distinguishes itself from external registries by instructing to use this tool first. The purpose is specific and well-defined.

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

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

The description provides explicit guidance on when to use this tool ('use THIS tool FIRST'), distinguishes between invoke and install for one-off vs permanent usage, and explains scenarios for credential/login and payment issues. It also notes that writes require owner/admin permissions.

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 operation. Description adds details about consent revocation, data deletion, and the returned re-connection URL, adding value beyond annotations.

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

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

Two sentences, no extraneous information. The primary action and key consequence are front-loaded effectively.

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 single parameter with no description and no output schema, the description omits important context about the 'item' parameter and potential prerequisites, leaving the agent to infer.

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 should clarify the 'item' parameter, but it does not. The term 'item' is ambiguous without further explanation.

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 revokes consent and deletes connection data for a specific bank. This distinguishes it from sibling tools like 'connect' or 'openfinance_list_connections'.

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

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

The description explains the effect and mentions a return URL for re-connection, providing context. However, it lacks explicit when-not-to-use guidance or comparisons to 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?

Description adds behavioral details beyond annotations: it waits up to 60s, polls, returns timed_out and needs_action. Annotations indicate non-read-only and non-destructive, which matches. 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?

Somewhat lengthy but well-structured: starts with main action, then details use, parameters, and return values. Could be tighter, but every part 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?

No output schema; description covers return object shape ({results, errors}) with field descriptions (status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out). Comprehensive for a sync tool.

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

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

Schema has 0% coverage; description thoroughly explains both parameters: 'wait' for fire-and-forget, 'items' as selectors (item_id, connector_id, connector_name) with omission meaning all. Adds practical 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 it forces a sync and waits, with a specific use case (stale balance/transactions). It distinguishes from siblings like openfinance_get_item_status by mentioning re-check if timed 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?

Explicitly tells when to use (stale data), what it does (fresh pull without disconnect), and when not to (needs_action user intervention). Provides alternative: openfinance_get_item_status for ongoing syncs.

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 explains error handling for CREDIT accounts (returning warnings instead of throwing) and provides the response structure. This adds significant behavioral context beyond the annotations, which only indicate readOnly, idempotent, and not 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?

The description is two sentences plus a short note on response shape. It is front-loaded with the core purpose and each sentence adds value without redundancy.

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

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

The description covers the parameter, response shape, and error handling. It lacks mention of prerequisites like authentication or connection status, but for a read-only tool with good annotations, it is nearly complete.

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

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

Despite 0% schema description coverage, the description explains that account_ids must be an array of strings with 1–50 items, effectively compensating for the lack of schema 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 real-time balance for given account IDs, specifies the HTTP endpoint, and the parameter format. It differentiates from sibling tools like openfinance_list_accounts 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 specifies the parameter requirements (array of 1–50 account_ids) but does not explicitly guide when to use this tool over alternatives like openfinance_list_accounts or openfinance_get_accounts_detail. No exclusionary criteria 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 declare read-only, idempotent, non-destructive behavior. The description adds that results are batch-shaped with separate errors and includes extended creditData, providing useful behavioral context beyond annotations.

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

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

Two sentences: first defines purpose and output, second specifies parameter and response shape. No wasted words, front-loaded 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?

For a simple read tool with annotations covering safety, the description covers return type, batch shape, and parameter constraints. Lacks details on error handling or field specifics, but sufficient given no output schema.

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

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

With 0% schema description coverage, the description compensates by specifying the parameter 'account_ids' as an array of 1-50 values, clearly indicating it's a batch operation. This adds essential 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 full account objects with extended creditData, distinguishing it from sibling tools like openfinance_list_accounts which likely return summaries. The specification of batch shape and ID-based retrieval enhances clarity.

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 obtaining detailed account info by ID, but does not explicitly contrast with sibling alternatives or provide when-not-to-use guidance. Adequate but minimal explicit 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?

Adds significant value beyond annotations: batch shape { results, errors }, notes that Pluggy does not return paid/status field, and explains the critical nuance that payments[] belong to previous bill. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint all consistent).

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

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

Well-structured with purpose, exclusions, parameter guidance, and warnings. Slightly long but every sentence adds value; no redundancy.

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

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

For a tool with no output schema, the description is remarkably complete: it details return fields (financeCharges, payments with fields), what is not included, how to get transactions, parameter shape, batch response, and behavioral nuance about payment interpretation.

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 bill_ids with 0% schema coverage. Description explains it must be an array and how to discover IDs via list bills tool, adding context beyond schema type.

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

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

Description clearly states it returns bill-level detail for credit card bills by ID, and explicitly says what it does NOT return (individual transactions). Distinguishes from sibling tools openfinance_list_transactions and openfinance_list_credit_card_bills.

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

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

Provides explicit when and how to use: first use openfinance_list_credit_card_bills to discover IDs; for transactions use openfinance_list_transactions with date range. Warns about payments[] interpretation and recommends checking paid status via openfinance_list_credit_card_bills.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral details beyond annotations by explaining the return structure for both cases (all vs single bank), including the format '{count, items}' for the all case, which is not evident from annotations alone.

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, consisting of two sentences. It front-loads the main purpose and then provides usage details efficiently. Every sentence adds value without redundancy.

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

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

Despite having no output schema, the description specifies the returned data: status, executionStatus, and connector metadata, along with the structure for both single and bulk calls. This is sufficient for a simple status retrieval tool and covers the context needed for selection and 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 one parameter 'item' with no description. The description fully compensates by explaining that omitting it returns status for all linked banks and passing it returns status for a single bank. This adds essential meaning beyond the schema, which had 0% coverage.

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

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

The description clearly states it returns the current status of a bank connection, specifying the resource and action. It distinguishes between getting status for all linked banks or a single one, and among sibling tools like openfinance_list_connections, this tool's specific purpose is 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 explicitly explains when to omit the 'item' parameter (to get all banks' status) and when to pass it (for a single bank). It provides clear context for use, though it could mention alternatives like openfinance_list_connections for listing connection names versus 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 indicate read-only, idempotent, non-destructive. Description adds nuanced behavior: 'balance' meaning is connector-dependent, 'name' vs 'bank' distinction, and response structure when omitting 'item'. 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, front-loading purpose and using paragraphs for nuances. Every sentence adds value, though slight verbosity exists due to thoroughness.

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

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

With no output schema, the description fully explains return fields and their meanings, including subtle points like creditData usage. Provides complete guidance for 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?

Schema has 0% description coverage, but the description compensates by explaining 'item' targeting and 'type' filtering. It details effects of omitting 'item' and clarifies response tagging.

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

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

The description clearly states it returns accounts for bank connections, listing both BANK and CREDIT types with specific fields. It distinguishes itself from siblings like openfinance_list_credit_card_bills by directing users to that tool for standardized billing.

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 omit 'item' (all banks) vs. pass 'item' (single bank), and warns about 'balance' interpretation for CREDIT, recommending an alternative tool. 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, idempotentHint, destructiveHint. The description adds that the data is cached for the session and that the response is a single aggregated response with no batch ids, providing useful behavioral context beyond annotations.

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

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

The description is concise, front-loaded with the main purpose, and each sentence adds necessary information without redundancy. Efficiently uses three sentences to convey core functionality, caching, and response structure.

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

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

Given no output schema, the description adequately explains the response structure and links the categoryId to a sibling tool. For a zero-parameter, read-only tool, it is complete and leaves no ambiguity about what the tool returns 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?

No parameters, so baseline is 4. The description adds value by detailing the response fields (id, description, descriptionTranslated, parentId, parentDescription) and their usage, which compensates for the lack of an output schema.

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

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

The description clearly states the tool returns Pluggy's transaction category taxonomy, cached, and specifies the endpoint. It distinguishes itself by mentioning the categoryId is used by openfinance_update_transaction_category, effectively differentiating from other list tools.

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

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

The description implies usage for retrieving categories, especially for use with openfinance_update_transaction_category. It mentions the response is cached and a single aggregated response, which provides context, but does not explicitly state when to use vs alternatives. Given the sibling context, it is clear enough.

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

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

Annotations already denote readOnlyHint and idempotentHint. The description adds behavioral context by specifying the returned fields and the add_connection_url for linking additional banks, which is beyond what annotations cover.

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 concise sentence that front-loads the action and output, with no unnecessary words. Every part earns its place.

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

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

For a simple list tool with no parameters and clear annotations, the description fully covers what the tool does and what it returns, including the important add_connection_url for subsequent actions.

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

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

With zero parameters and 100% schema coverage, the description has no need to explain parameters. Baseline 4 is appropriate as no param information is necessary.

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

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

The description clearly states the verb 'Returns' and the resource 'saved bank connections', listing specific fields (connector_id, item_id, bank name, add_connection_url). It effectively distinguishes from siblings like openfinance_list_accounts by focusing on connections.

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

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

The description implies usage for retrieving existing connections but does not explicitly state when to use this tool versus alternatives like openfinance_search_bank_connectors or authenticate. No when-not or exclusion criteria 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?

The description goes far beyond annotations by explaining Open Finance semantics (payments land on next bill's array), derived payment status logic, connector asymmetry for open bill, and that results are summaries not transactions. Annotations are readOnly, idempotent, non-destructive; description adds no contradiction.

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

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

Every sentence is necessary for understanding the tool's complex behavior. It is front-loaded with the main purpose and then delves into details. No wasted words 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?

With no output schema, the description fully explains the output structure: `payments[]`, `payment_status`, derived fields, `open_bill` inner structure, `future_bills[]`, and edge cases like connector asymmetry and warning scenarios. It also cross-references other tools for transactions.

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 compensates by explaining `include_open_bill` in great detail and mentioning `account_ids` for bulk. However, `page` and `page_size` are not explained; their behavior is implied but not explicitly stated. Still, the most complex parameter is well-covered.

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 'Returns CLOSED credit card bills for a CREDIT-type account' and lists the returned fields. It distinguishes from siblings by noting that for itemized transactions to use `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 provides explicit guidance: when to use `include_open_bill`, when to use the alternative tool for transactions, how to interpret `payment_status`, warns about not calling a bill 'vencida' categorically, and explains bulk support.

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 detail beyond annotations: describes return fields (balance, rates, dueDate, ISIN) and error handling (returns {total:0, results:[], warning} instead of throwing). Annotations already declare readOnly 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?

Single paragraph, reasonably concise but could be more structured. Some information could be 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?

Lacks explanation of pagination (page, page_size) and parameter semantics. Despite listing many return fields, it does not fully describe the output structure, which is important since no output schema is provided.

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?

Description does not mention any parameters (item, page, type, page_size). Schema coverage is 0%, and description fails to compensate, leaving their meaning unclear.

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 the investment portfolio, listing specific asset types (FIIs, stocks, ETFs, etc.). Distinguishes from sibling tools like list_investment_transactions and 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?

Implies usage for retrieving portfolio data but does not explicitly state when to use vs alternatives like list_investment_transactions or list_accounts.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by detailing the types of movements and returned fields, beyond what annotations provide. 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 each sentence adds essential information. No superfluous content.

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

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

For a list tool with 4 parameters and no output schema, the description covers purpose, usage hints, and return fields. However, pagination details (page/page_size) are not clarified, leaving 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?

Schema description coverage is 0%, but the description explains the role of investment_id and investment_ids for batch execution. However, page and page_size parameters are not mentioned, leaving some ambiguity.

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 transaction types (BUY/SELL/TAX/etc.) and key fields. It differentiates from siblings like openfinance_list_investments by instructing to use that tool first to obtain the investment_id.

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: 'Use after openfinance_list_investments to get the investment_id.' It also mentions bulk support via investment_ids. While it doesn't explicitly state when not to use, the context makes alternatives clear.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds value by disclosing sequential execution with rate-limit spacing and per-connection result/error structure.

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

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

Two sentences with no wasted words. Purpose is stated first, followed by parameter behavior and return format. Every sentence earns its place.

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

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

No output schema, but the description specifies the return format '{ results, errors }' per connection. Covers parameter usage, behavioral traits, and output structure adequately for a simple list tool.

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

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

Schema has 0% description coverage with a single 'items' field of type array of strings. The description explains that items are connection selectors (item_id, connector_id, connector_name), adding 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 lists loan contracts per bank connection, referencing the GET /loans endpoint. It distinguishes from siblings by specifying per-connection behavior and the option to omit 'items' for all linked banks.

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

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

Provides explicit guidance on using the 'items' parameter for specific connections versus omitting it for all banks. Mentions sequential queries with rate-limit spacing, but lacks direct comparison to sibling 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=true and destructiveHint=false, so no contradiction. The description adds valuable behavioral context beyond annotations: details on PENDING vs POSTED behavior varying by bank, search query aggregation up to 5000, error handling returning warning/error instead of throwing, and bulk support. It does not, however, explicitly mention that the operation is idempotent (already in annotations) or describe the response format in full.

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, starting with the main purpose, then covering credit card specifics, filters, pagination, search, error handling, and bulk support. Every sentence adds necessary detail, and the information is logically ordered. It could be slightly more compact, but it remains informative without being excessively verbose.

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

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

Given the tool has 7 parameters, no output schema, and annotations present, the description is thorough. It covers parameter usage, edge cases (truncated, zero total, credit card behavior), error handling, and bulk support. It references sibling tools appropriately. The only minor gap is the lack of explicit response format details, but the description provides enough to use the tool effectively.

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 must compensate. It explains the purpose of all key parameters: from/to as ISO dates, page_size max 500, account_ids for bulk, and search_queries as case-insensitive substring match with OR semantics and aggregation limit. It also clarifies the truncation behavior. The description does not specify default page value, but overall adds substantial 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 'Returns transactions for a bank account (BANK or CREDIT type).' It identifies the specific resource (transactions) and distinguishes itself from the sibling tool openfinance_list_credit_card_bills by noting that for credit cards this is the only way to get itemized transactions while the sibling returns 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?

The description provides explicit guidance on when to use this tool vs. alternatives, including that it is the only way for itemized credit card transactions and that for standardized totals one should use openfinance_list_credit_card_bills. It also advises narrowing date range when truncated:true and checking connection health if total is 0.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false. The description adds key behavioral details: scan caps at 5000/account with 'truncated' flag, and explains the compact vs. raw output structure, fully aligning 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 information-dense and front-loaded, but could be more structured (e.g., bullet points for parameters or return fields). Every sentence adds value, but length slightly reduces quick 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?

No output schema exists, yet the description fully explains return values: total entradas/saídas, monthly evolution, top categories, per-account breakdown, and optional raw rows. Also covers truncation and default granularity. Comprehensive 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?

Despite 0% schema coverage, the description compensates completely: explains that 'item' accepts connector_id/connector_name/item_id, 'from'/'to' are ISO dates, 'granularity' enum values, 'type' filters, and 'top_n' is implied. Adds meaning beyond the schema.

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

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

The description clearly states the tool does consolidated cash-flow analysis for a bank connection in one call, resolving accounts internally. It distinguishes itself from sibling tools like openfinance_list_transactions by emphasizing the aggregated, connection-level view.

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

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

Explicitly tells when to use (e.g., 'análise anual/mensal', 'fluxo de caixa'), that you do NOT need to call openfinance_list_accounts first, and explains behavior when 'item' is omitted or 'granularity' is set to 'raw'.

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. Description adds context about it being LIVE, checking a public status page, and returning specific fields (global indicator, degraded components, etc.). No contradictions; adds value beyond annotations.

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

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

Description is well-structured but slightly lengthy. It starts with primary purpose, then usage guidance, then return details. Every sentence adds value, but could be tightened slightly.

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

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

Given no output schema, the description compensates by detailing return fields and context. It explains how to interpret results (flags affecting connected banks) and when to use. Complete for a simple, no-parameter 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?

Input schema has zero parameters, so schema coverage is 100%. Description does not add parameter-level information because there are none. The description focuses on output and usage, which is appropriate 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 it checks the LIVE operational status of the Open Finance provider, distinguishing it from the connection-specific status check via openfinance_get_item_status. It specifies the resource (provider's public status page) and return fields, making its 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 describes when to use: 'whenever data looks incomplete or stale even though a connection shows UPDATED'. Also clarifies it reveals upstream outage vs connection problem, and implies alternative tool (openfinance_get_item_status) for connection-level issues.

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 valuable behavioral context: it honors the user's plan (PF plan hides PJ banks), returns a ready connect_url, and on missing keywords returns a hint instead of the full catalog. These details go 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 two sentences, front-loading the primary action and return value. The second sentence adds critical usage notes. While dense, every part serves a purpose. Slightly better structuring could improve readability, but it 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?

Given zero output schema and moderate complexity (2 params), the description fully covers purpose, usage timing, parameter behavior, constraints (plan filtering), and edge case (missing keywords). An agent can confidently invoke this tool based on the description alone.

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%, but the description compensates well. It explains keywords with example values (['nubank','btg']) and describes the effect of include_accounts: 'returns... accounts when include_accounts=true'. This adds meaningful semantics beyond the bare schema.

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

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

The description clearly states the tool searches bank connectors by name and lists what is returned (connector id, access type, audience, linked connections, connect_url). It explicitly distinguishes this tool from siblings by focusing on searching before connecting, and no other sibling tool performs this function.

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

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

The description provides clear when-to-use guidance: 'Call this BEFORE connecting to hand the user a one-click link to the right bank.' It also explains that keywords[] is required and what happens without it. While it doesn't explicitly mention when not to use or list alternatives, the context is strong enough for an agent to decide.

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 important behavioral details beyond annotations: it overrides Pluggy's automatic categorization, creates a Category Rule, and describes batch error handling ('per-item errors do not fail the whole batch'). No contradictions with annotations.

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

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

The description is a single paragraph but effectively front-loads the core purpose. It provides rich detail without excessive verbosity, though breaking into bullet points could improve readability.

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

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

Given no output schema, the description includes the response shape ({ updated, results, errors }) and covers side effects and error handling. It is comprehensive for a batched update 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?

Although schema description coverage is 0%, the description adds meaning by explaining the provenance of transaction_id and category_id and their roles. It also clarifies that items is an array of objects with required fields.

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

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

The description explicitly states the action ('Corrects the category of one or more transactions'), specifies the HTTP method and endpoint, and distinguishes the tool from siblings by referencing data sources (openfinance_list_transactions, openfinance_list_categories) and the effect of creating a Category Rule.

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

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

The description indicates when to use the tool ('to fix miscategorized transactions and improve categorization accuracy') and explains the consequence (creates a Category Rule). It does not explicitly state when not to use it, but the context is clear.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false, suggesting safe, repeatable behavior. The description adds that the conversation array is for reproduction, implying the tool logs the report. However, it does not explain what happens after submission (e.g., ticket creation, response).

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—two sentences with no unnecessary words. It front-loads the purpose and follows with actionable guidance. A slightly more structured format (e.g., listing parameters) could improve scannability.

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 3 parameters and no output schema. The description covers the reproduction aspect but omits details on the 'context' parameter and what the user can expect as a result (e.g., confirmation message). Adequate for a simple reporting tool but not fully complete.

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

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

With 0% schema coverage, the description must add meaning. It partially does by mentioning 'conversation array' should include recent messages. However, it does not explain the 'context' parameter or the format of 'message', so only partial compensation for the schema 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: 'Report a bug, missing feature, or send feedback.' It identifies the specific verb (report) and resource (bug/feature/feedback), and distinguishes effectively from sibling tools that are focused on financial data access and authentication.

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

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

The description provides explicit guidance: 'Include the conversation array with recent messages for reproduction.' This tells users what to include when using the tool. However, it does not mention when not to use it or provide alternatives for other types of queries.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as true/false appropriately. The description adds useful context by specifying exactly what versions are shown ('MCP platform and adapter versions'), going 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, succinct sentence with no extraneous words. It is appropriately front-loaded and every word adds value.

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

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

Given no parameters, no output schema, and a simple task, the description is complete. It tells the agent exactly what the tool does without missing any necessary 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?

There are no parameters, so the description cannot add parameter information. With 0 parameters, the baseline is 4, and the description suffices without needing to explain anything about inputs.

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 'Show' and the resource 'current MCP platform and adapter versions,' making its purpose specific and distinct from all sibling tools, none of which deal with version display.

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

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

While no explicit when-to-use or when-not-to-use guidance is given, the function is so simple (retrieve version info) that its usage is self-evident. A minor deduction for lack of explicit context compared to more complex 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=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying exact return contents (installed MCPs, status, catalog count), which is 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?

A single, clear sentence with no wasted words. Every word adds necessary 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?

Given zero parameters, simple output, and comprehensive annotations covering safety, the description is fully adequate. No output schema 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?

No parameters exist, so schema coverage is 100%. The description does not need to add parameter meaning. Baseline for no parameters is 4.

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

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

The description clearly states the tool returns the current toolkit state, specifying installed MCPs, connection status, and catalog tool count. This distinguishes it from siblings like 'show_version' or 'report_bug'.

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 alternatives are provided, but the purpose is self-explanatory for checking state. Implicitly, it's for inspecting the toolkit, not for actions like authentication or connecting.

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