Next MCP

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

Discloses key behaviors beyond annotations: non-expiring vs session, how to obtain token. No contradiction with annotations (idempotentHint=true matches no mutation).

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, efficient, but could be broken into clearer sections (e.g., two options). Still well-structured for the information density.

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

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

Fully covers behavior for a simple authentication tool with no output schema. Leaves no doubt about usage and outcomes.

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

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

Adds significant meaning beyond schema: explains the 'token' parameter is for session login, and omitting it returns a link. Schema has 0% coverage, so description fully compensates.

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

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

Description clearly states the tool is for authentication, with specific verb 'authenticate' and resource 'access token'. Distinguishes from sibling tools (finance-related, connect) by its unique 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?

Provides clear when-to-use: for IDE agents, with two explicit options (permanent via config, session via pasting token). Also explains calling with no args to get the link, leaving no ambiguity.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by detailing the return structure for different connection states, which is 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?

Two efficient sentences that convey all necessary information without redundancy. Front-loaded with the key 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 zero parameters and no output schema, the description covers both possible states (all connected vs missing credentials) sufficiently. 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?

No parameters exist, and schema coverage is 100%. Per guidelines, baseline is 4. The description adds no param 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?

The description clearly states the tool returns connection status and URLs, explaining two scenarios. It does not explicitly differentiate from siblings like 'authenticate', but the purpose is very clear.

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 checking connection status but provides no explicit guidance on when to use versus alternatives like 'authenticate' or 'openfinance_provider_status'.

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

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

Annotations are sparse (no readOnlyHint or destructiveHint specifics), but the description adds significant behavioral context: invoke runs even if MCP not installed without bloat, handling of credentials and payments, and ownership requirements for writes. It does not contradict annotations.

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

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

The description is a single long paragraph (150+ words). While front-loaded with key info, it is verbose and could be structured with bullet points or sections for better readability. Valuable content but not concise.

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

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

Given complexity (13 params, no output schema), description covers overall flow, special behaviors, and ownership requirements. However, it lacks parameter descriptions and does not explain return values, leaving some gaps.

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

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

Schema coverage is 0%, so description must compensate. It explains some parameters implicitly (action enum, mcp_id, tool_id, arguments) and contextually, but many parameters (limit, query, immediate, tier_slug, conversation, request_name, etc.) are left undescribed. Partial value.

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 is 'THE official mcp.ai marketplace' for discovering and running MCPs/tools, and that it should be used first before any external registry. It distinguishes from sibling tools by specifying it is the primary entry point for capability queries.

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 'use THIS tool FIRST' and provides a detailed core flow: search → describe → invoke. It also gives guidance on when to use invoke vs install, handling auth/payment issues, and lists alternative actions like list_tools, subscribe, etc.

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 destructiveHint=true. The description adds value by specifying that consent is revoked, data is deleted, and a reconnection URL is returned, going 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?

Three concise sentences covering action, consequence, and return value, with no extraneous information.

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

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

For a simple tool with one parameter and no output schema, the description covers purpose, effect, and return value. It could mention that a connection must exist, but overall adequate.

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 for the single parameter 'item', the description provides no details on what 'item' represents or its format, leaving ambiguity 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 states the tool revokes consent and deletes connection data for a specific bank, with a specific verb and resource. It distinguishes itself from siblings like openfinance_list_connections or openfinance_force_sync.

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

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

The description implies usage for disconnecting a bank but does not explicitly state when to use versus alternatives, nor does it provide exclusions or 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?

The description discloses that the tool performs a PATCH then polls up to ~60s, waits by default, and can be fire-and-forget. It explains return fields including status, executionStatus, lastUpdatedAt, synced, needs_action, and timed_out. 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 well-structured with a clear first sentence stating the main action, followed by usage context, parameter details, and return value explanation. Every sentence provides essential information without redundancy.

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

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

Given no output schema, the description fully explains return values, error states (needs_action, timed_out), and next steps. It covers all critical aspects for a sync tool with polling, making it complete and actionable.

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 fully explains both parameters: 'items' as an array of selectors (with examples) and omission syncs all, and 'wait' as boolean with default behavior. This adds significant 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 forces a bank to re-sync connections and waits for completion. It distinguishes itself from sibling tools like openfinance_get_item_status and openfinance_disconnect_bank by specifying that it pulls fresh data without disconnecting.

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

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

The description explicitly says use when a balance or transaction list looks stale, and provides alternatives: fire-and-forget with wait:false, and re-check with openfinance_get_item_status on timeout. It also explains when user action is needed (needs_action).

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

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

Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds real-time nature, CREDIT accounts may return BALANCE_FETCH_ERROR with structured warning instead of throwing, and response shape. 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 concise: three sentences each serving a purpose. First sentence states purpose and endpoint, second gives parameter constraint, third explains error behavior and response shape. No wasted words.

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

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

For a simple tool with one parameter and no output schema, the description covers endpoint, parameter constraint, error handling, and response shape. 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?

With 0% schema description coverage, the description adds that account_ids should be an array of 1-50 items. It provides context that CREDIT accounts may produce errors, adding meaning beyond the raw schema.

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

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

The description clearly states the verb 'Returns', the resource 'real-time balance payload per account id', and the endpoint 'GET /accounts/:id/balance'. It distinguishes from sibling tools by specifying the exact endpoint and parameter array constraint.

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 to pass account_ids as an array of 1-50, and notes behavior for CREDIT accounts (may return error with warning). It doesn't explicitly compare to alternatives like openfinance_list_accounts, but the usage context is clear enough.

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

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

Beyond annotations (read-only, idempotent), the description adds key behavioral traits: batch processing with array of IDs (1-50 limit), response shape as { results, errors }. This provides context on concurrency and error handling not captured 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?

Two sentences: first covers purpose and resource, second covers parameter usage and response shape. Every sentence earns its place with no redundancy or fluff. Information is front-loaded and scannable.

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 single-parameter tool with no output schema, the description provides adequate detail: batch shape, parameter limits, and extended creditData. However, it could mention authentication prerequisites or handling of invalid IDs, but the batch errors imply partial error handling.

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 fully compensates by explaining the account_ids parameter: it must be an array of 1-50 elements, and the response is a batch with results and errors. This adds critical constraints and response structure absent from 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 full account objects with extended creditData, specifies the HTTP path GET /accounts/:id, and distinguishes from list tools by emphasizing detail per ID. The verb 'Returns' and resource 'account objects' 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?

No explicit guidance on when to use this tool vs alternatives like openfinance_list_accounts. The description implies it is for detailed data by ID, but does not mention when not to use or provide direct comparisons 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, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context: it states the tool does NOT return individual transactions, describes the batch shape (`{ results, errors }`), reveals that Pluggy does not return a paid/status field, and clarifies the meaning of payments[] (i.e., reflects previous bill payments, not necessarily current bill status). These details go well 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 relatively long but each sentence serves a purpose. It front-loads the main purpose and then provides important caveats. Some minor redundancy exists (e.g., mentioning Pluggy twice), but overall it's well-structured and informative. A slight trim could improve conciseness.

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

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

There is no output schema, so the description must cover return values. It details the returned fields (financeCharges, payments[] with subfields) and the batch shape. It also provides essential context about how to check paid status via a sibling tool and the interpretation of payments[]. Given the complexity of credit card bills, this is a complete and self-contained description.

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 the description must compensate. It explains the single parameter: 'Pass `bill_ids` as an array' and advises using openfinance_list_credit_card_bills to discover IDs. It states that bill_ids are strings implicitly. While it effectively conveys usage, it could explicitly mention that bill_ids are an array of strings in the description. Still, it adds significant value 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 returns bill-level details for credit card bills by ID, specifying the exact fields returned (financeCharges, payments[] with subfields). It distinguishes itself from sibling tools like openfinance_list_transactions and openfinance_list_credit_card_bills, making the purpose unambiguous.

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

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

The description explicitly tells when to use this tool (for bill detail) and when not to (for individual transactions, deferring to openfinance_list_transactions). It also instructs to first use openfinance_list_credit_card_bills to discover IDs and provides guidance on interpreting payments[] in Brazilian Open Finance. This leaves no ambiguity about proper usage.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description goes beyond by specifying the returned data: status values, executionStatus, and connector metadata. It also reveals the response shape difference between bulk (count and items) and single (presumably the item object). No contradictions with annotations are present.

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 consists of two concise sentences. The first sentence captures the core purpose and example values, and the second explains parameter usage. Every word adds value with no redundancy or filler. It is front-loaded with the essential information.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description covers the main usage scenarios and response keys. It does not detail error conditions or pagination for the bulk mode, but these are often beyond the minimal needed for correct invocation. With annotations providing safety guarantees, the description is sufficient for an agent to select and invoke the tool correctly.

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

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

The schema has 0% description coverage for the single parameter 'item'. The description fully compensates by explaining that omitting 'item' returns status for all linked banks, while passing 'item' returns status for a single bank. This provides complete functional semantics, even though the exact format of 'item' (likely an identifier) is not specified.

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 status of a bank connection with enumerated examples (UPDATED, UPDATING, LOGIN_ERROR). It distinguishes between bulk (omit 'item') and single (pass 'item') modes, and specifies the return includes executionStatus and connector metadata. This clearly differentiates it from sibling tools like openfinance_list_connections, which likely list connections without detailed status.

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

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

The description provides explicit guidance on when to omit vs. pass the 'item' parameter, covering both use cases. It implies that the tool should be used to get status rather than listing connections (handled by openfinance_list_connections). However, it does not explicitly state when not to use this tool or mention alternatives for other cases.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses important behavioral traits: the connector-dependent meaning of CREDIT balance, the structure of the response when 'item' is omitted or passed, and the distinction between account name (legal entity) and brand (bank). This adds significant transparency.

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 comprehensive but slightly verbose, covering nuanced credit balance behavior and cross-references. Every sentence adds value, but it could be tightened. The structure is good: high-level purpose first, then 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 simple input schema (2 optional parameters) and no output schema, the description provides complete context: response fields, parameter behavior, credit balance caveats, and cross-reference to a sibling tool. It is self-contained 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?

With 0% schema description coverage, the description compensates fully by explaining both parameters: 'item' (omit for all banks, pass for specific bank) and 'type' (BANK or CREDIT). It also explains the impact on the response structure (tagged vs root fields). No additional meaning is needed from 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 that the tool returns accounts for a bank connection, distinguishing between BANK and CREDIT account types, and specifies the fields returned (balance, number, type, subtype, bankData, creditData, bank, connector_id). It also clarifies the use of 'bank' vs account 'name', and differentiates from sibling tool openfinance_list_credit_card_bills, making the purpose unmistakable.

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

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

The description provides explicit guidance on when to omit vs pass the 'item' parameter (list all banks vs target a single bank), and when to use the sibling tool openfinance_list_credit_card_bills for standardized credit card bill amounts. It also warns against misinterpreting the 'balance' field for CREDIT accounts. This level of detail fully covers usage context and alternatives.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context: the data is cached for the adapter session and is a single aggregated response with no batch ids. 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, no redundant words. Front-loaded with main purpose, then key details. Efficient and clear.

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

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

Given no parameters and no output schema, the description fully covers the tool's behavior and return fields. It explains caching, structure, and related tool usage. Complete for its simplicity.

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

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

No parameters exist, so baseline is 4 per rules. The description does not need to add parameter information.

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 for the adapter session. It specifies the exact fields returned (id, description, descriptionTranslated, parentId, parentDescription) and notes it's a single aggregated response. No sibling tool duplicates this purpose.

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

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

The description explains that the 'id' is used by openfinance_update_transaction_category and that descriptionTranslated is preferred for pt-BR users. This implies context but lacks explicit when not to use it, though no alternatives exist.

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=true, idempotentHint=true, and destructiveHint=false, so the description adds value by specifying the returned fields and the add_connection_url. No contradictions, but no additional 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?

The description is a single, focused sentence that covers the purpose and output without extraneous information. Every word contributes 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?

The description lists the return fields, which compensates for the lack of an output schema. However, it does not mention pagination or whether the list is limited. Given the simplicity of the tool (list all connections), it is reasonably 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 zero parameters and 100% schema coverage, the description does not need to add parameter details. It correctly focuses on output fields, which is appropriate given the lack of 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 states the verb 'Returns' and the resource 'saved bank connections' and lists the specific fields returned (connector_id, item_id, bank name, add_connection_url). It distinguishes from sibling tools that list accounts or transactions.

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

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

The description implies usage for viewing saved connections and obtaining the add_connection_url for linking more banks, but it does not explicitly state when to use this tool versus alternatives (e.g., list_accounts or list_transactions). No exclusion criteria or alternative tool mentions.

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 (readOnlyHint, idempotentHint, destructiveHint), the description details the payment cycle semantics, derived payment_status logic, connector asymmetry for open bills, and warning instead of failure when product not enabled. 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 lengthy but well-organized, front-loading key info and using paragraphs for different aspects. Some redundancy could be trimmed, but the structure aids comprehension for complex Brazilian Open Finance semantics.

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 (derived fields, connector asymmetry, no output schema), the description is highly complete. It explains return structure, derived payment_status, open_bill behavior, and fallback methods, leaving no essential aspects unexplained.

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 explicitly explains include_open_bill (opt-in, default false) and account_ids (bulk support). However, page, page_size, and account_id are not described, leaving gaps. Partial compensation but not full 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 the tool returns CLOSED credit card bills for CREDIT-type accounts, listing specific fields. It distinguishes from sibling tool openfinance_list_transactions for itemized purchases, making the purpose unambiguous.

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

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

Provides explicit guidance on when to use this tool (for bill-level summaries) versus when to use openfinance_list_transactions (for itemized charges). Also explains the derived payment_status interpretation, open_bill availability conditions, and connector asymmetry, covering when-not-to-use and alternatives.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds error handling behavior (returns warning instead of throwing) and lists returned fields. No contradictions with annotations.

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

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

The description is a single, well-structured sentence that front-loads the primary purpose, then efficiently lists asset types, fields, and error behavior. No redundant or irrelevant information.

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

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

Given 4 parameters, no output schema, and many siblings, the description is adequate but incomplete. It covers purpose and error handling, but lacks parameter documentation and pagination details, leaving gaps for agent understanding.

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

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

With 0% schema description coverage, the description implicitly links 'item' to connection and lists asset types that map to the 'type' enum, but does not explicitly explain page or page_size parameters. Partial compensation but insufficient for full clarity.

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 investment portfolios for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.). It distinguishes itself from sibling tools like openfinance_list_investment_transactions by focusing on portfolio snapshot versus transactions.

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

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

The description implies usage for connections with INVESTMENTS enabled and describes fallback behavior, but does not explicitly compare to alternatives or state when not to use this tool. Implied but lacks 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, so safety profile is covered. The description adds value by detailing the return fields (quantity, value, amount, netAmount, expenses) and transaction types, enhancing 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 concise with two paragraphs: first explaining purpose and output fields, second mentioning bulk support. It avoids fluff but could be more structured (e.g., separating output details from usage notes).

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 output structure (fields like quantity, netAmount, expenses) and transaction types. It also provides prerequisite context (use after list_investments). Missing pagination parameter documentation slightly reduces 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 description must compensate. It explains investment_id (required) and investment_ids for bulk, but omits pagination parameters (page, page_size). Partial coverage leaves some parameters unexplained, resulting in a moderate score.

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

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

The description clearly states the tool returns 'movement history for a specific investment position' with enumerated transaction types (BUY, SELL, TAX, etc.) and detailed field names. This distinguishes it from siblings like openfinance_list_investments which lists investments themselves.

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 after openfinance_list_investments to get the investment_id', providing a clear prerequisite. Also mentions bulk support via investment_ids, helping the agent decide when to use 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 indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable behavioral details: sequential querying with rate-limit spacing and the return structure {results, errors} per connection. No contradictions.

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

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

The description is two sentences, front-loaded with purpose and endpoint, then parameter usage and behavior. Every sentence adds value with no wasted words.

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

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

Given one optional parameter, no output schema, and annotations covering safety, the description explains input and output sufficiently. It mentions errors per connection but lacks detail on error handling. Still, it's largely 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 input schema has one parameter 'items' as an array of strings with 0% coverage. The description explains that items are connection selectors (item_id uuid, connector_id, or connector_name), and the behavior when omitted. This adds critical 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, specifies the HTTP endpoint GET /loans, and distinguishes between providing items for specific connections or omitting for all linked banks. This differentiates it from sibling tools like openfinance_list_accounts or openfinance_list_transactions.

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

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

The description explicitly explains when to pass items (for specific connections) and when to omit items (for all banks). It also mentions sequential querying with rate-limit spacing. While it doesn't explicitly list when not to use it, the context is clear and provides good guidance.

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

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

Discloses read-only and idempotent behavior consistent with annotations. Explains nuances like PENDING/POSTED variation, search query aggregation limits, and error response 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?

The description is lengthy but well-organized with clear sections for credit card behavior, detail levels, and bulk support. Every sentence adds value, though slight trimming could improve conciseness.

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

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

Covers all critical aspects: error handling, credit card specifics, filtering, pagination, search, bulk mode, and integration with sibling tools. No output schema, but describes return shape (total, results, warning, error).

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 fully defines each parameter: account_id, account_ids, from/to (ISO dates), page, page_size (500 max), detail (enum with compact/rich/raw meanings), and search_queries (substring, OR, aggregation).

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 or CREDIT accounts, distinguishes itself as the only way to get itemized credit card transactions, and references sibling tools like 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-to-use and when-not-to-use guidance, including alternatives for credit card bills and account details. Also explains pagination, date filters, search queries, error handling, 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, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context beyond annotations: it resolves accounts internally, fans out transactions, caps at 5000 transactions per account with a truncated flag, and describes the compact vs. raw output formats and enrichment options. No contradiction with annotations is present.

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 front-loaded with the core purpose and key differentiators. It is concise given the complexity, but the single paragraph format is dense and could benefit from bullet points or shorter sentences for easier parsing. Still, every sentence adds value and avoids redundancy.

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

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

Given the tool's complexity (7 parameters, no output schema, multiple modes), the description covers most aspects: purpose, usage, parameter semantics, behavioral limits, and output summary structure. It lacks a full description of the raw output rows, and the 'top_n' parameter is not explicitly documented, leaving a small gap. Overall, it provides sufficient context for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must carry the full parameter documentation. It explains 'item', 'from', 'to', 'granularity', 'detail', and 'type' well, including defaults and allowed values. However, the 'top_n' parameter is not explicitly described in the text, only implied by 'largest N each' in the output context. This is a minor gap for a parameter that controls output shape.

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

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

The description clearly states the tool's purpose: 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call.' It specifies the resource (transactions aggregated across accounts), the action (analysis), and the scope (single connection or all). It also distinguishes itself from siblings by noting that you do not need to call openfinance_list_accounts first, differentiating from account-level 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 provides explicit usage guidance: when to call this tool (for annual/monthly analysis, cash flow, income/expenses, top expenses/revenues), when to omit the 'item' parameter (to analyze all connections), and when to use different granularity/detail settings. It explicitly tells the agent not to call openfinance_list_accounts first. However, it does not directly contrast with the sibling openfinance_list_transactions, leaving some ambiguity about when to use that instead.

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, idempotentHint, and destructiveHint. Description adds context about it being a live public status page check and details return fields (global indicator, degraded components, open incidents, your_banks_affected). No contradictions.

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

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

Description is a single dense paragraph that efficiently conveys purpose, usage, and return value. Every sentence adds value, no wasted words.

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

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

For a parameterless tool with good annotations, the description is complete: it explains the purpose, when to use, what it returns (without output schema). 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?

Tool has 0 parameters, so schema coverage is 100%. Description adds no parameter info but correctly implies no input needed. Baseline 4 for zero 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?

Description clearly states it checks the LIVE operational status of the Open Finance provider's public status page, distinguishing it from the user's connection status (openfinance_get_item_status). It provides specific use cases and sibling differentiation.

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: when data looks incomplete or stale despite an UPDATED connection, indicating an upstream outage or incident. Clearly contrasts 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 declare readOnlyHint=true and destructiveHint=false. Description adds context about plan filtering (PF plan hides PJ banks) and the behavior when keywords are missing (returns hint). No contradictions. Description supplements annotations well.

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?

Four sentences, front-loaded with purpose. Every sentence adds value: search action, return fields, plan context, usage instruction, keyword requirement. 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?

For a small tool with 2 params and no output schema, the description covers purpose, parameters, behavior, constraints (plan), output, and usage context. 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?

Schema has 0% description coverage. Description explains that keywords is an array of strings required (despite schema not marking required) with example, and include_accounts boolean. Adds meaning beyond schema, though lacks detail on exact keyword matching 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?

Description clearly states it searches bank connectors by name, returns connector details (id, access, audience, linked connections, accounts, connect_url), and honors user's plan. It distinguishes from siblings by being the search tool to call 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 says 'Call this BEFORE connecting to hand the user a one-click link to the right bank.' Also explains that keywords are REQUIRED and without it returns a hint, not the whole catalog, providing clear when-to-use guidance.

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

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), description reveals side effect: overriding automatic categorization AND teaching Pluggy by creating Category Rules. Also describes batch error handling and output shape. Provides comprehensive behavioral context.

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

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

Three sentences that front-load purpose, then detail input, side effect, and output. Efficient and well-structured, though slightly dense. 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?

Covers purpose, input format, side effect (rule creation), and output shape. Without an output schema, the description adequately documents response structure. No gaps for complexity level.

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, description fully explains the 'items' parameter: an array of objects with transaction_id and category_id, including where to get these IDs. Adds critical meaning beyond the plain schema.

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

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

Description clearly states the tool corrects transaction categories via PATCH endpoint, specifies input format (items array with transaction_id and category_id), and references sibling tools for ID sources. Distinguishes itself from listing 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?

Explicitly says 'use this to fix miscategorized transactions and improve categorization accuracy going forward.' Provides context for when to use but does not explicitly state when not to use or list alternatives. However, the guidance is clear and actionable.

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

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

Beyond the annotations (which indicate idempotentHint: true and destructiveHint: false), the description adds no behavioral context. It does not disclose side effects, authorization needs, rate limits, or what happens upon submission. The mention of conversation array is a parameter hint, not behavioral.

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

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

The description is a single sentence, concise and front-loaded with the core action. Every word serves a purpose, with no filler or redundancy.

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

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

Given the tool has 3 parameters and no output schema, the description is incomplete. It does not cover the context parameter, expected format of message, or any return values. An agent would lack sufficient information to use the tool reliably.

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 adds meaning to the conversation parameter (should be an array with recent messages) but does not explain context or message. This partial addition provides some value but leaves gaps.

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

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

The description clearly states the tool's purpose: 'Report a bug, missing feature, or send feedback.' It uses specific verbs and resources, distinguishing it from sibling tools that focus on OpenFinance operations 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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or contextual cues for choosing this tool over others.

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 that it returns 'platform and adapter versions', providing additional 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?

The description is a single sentence that is perfectly front-loaded and concise. Every word is meaningful and 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 there are no parameters and no output schema, the description fully covers what the tool does. It is complete for a simple version retrieval tool.

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

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

The tool has no parameters, and schema coverage is 100%. The description does not need to elaborate on parameters. A score of 4 is appropriate as 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 that the tool shows current MCP platform and adapter versions. It uses a specific verb and resource, and given the sibling tools (authentication, finance operations, etc.), it stands out as a version information tool.

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

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

The description implies that the tool should be used when version information is needed. There are no explicit when-not or alternatives, but due to its simplicity and zero parameters, the usage 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 fully discloses what the tool returns, and annotations already confirm it's read-only and idempotent. There are no contradictions, and the description adds specific behavioral context about the output components.

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

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose. It is concise without being vague.

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 completely explains what the tool returns and its purpose. There are no gaps for an agent to interpret.

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 baseline is 4. The description does not need to add parameter information, and it appropriately focuses on the output.

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

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

The description clearly states what the tool does: it returns the toolkit state including installed MCPs, their connection status, and how many catalog tools each exposes. This distinguishes it from siblings like 'authenticate' or 'connect' which serve different purposes.

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

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

While the description doesn't explicitly say when to use this tool over alternatives, its read-only nature and lack of parameters imply use for informational queries. Given no similar tools exist among siblings, the context is clear enough.

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