PagBank MCP

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

Annotations indicate idempotentHint=true, and the description adds context about session vs permanent connections and the token being a JWT. It does not elaborate on error conditions or side effects, but provides useful behavioral details beyond annotations.

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

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

The description is two sentences, front-loading the tool's purpose. It could be slightly more concise by splitting the long first sentence, but is generally 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?

While the tool is simple with one optional parameter and no output schema, the description could be more explicit about what the tool returns (e.g., success indication or token info). It hints at outcomes but leaves some ambiguity.

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

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

The sole parameter 'token' has no schema description (0% coverage). The description compensates by explaining its purpose: providing a JWT for session login, or omitting it to get the link. This adds significant 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 is for authentication, detailing two methods (permanent config or session token). It distinguishes its purpose from sibling tools like 'connect' but does not explicitly differentiate.

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 each mode: call with token after user pastes, or without args to get a login link. It does not address when to use this tool over 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, and destructiveHint=false, so the agent knows it's a safe read operation. The description adds valuable behavioral context: it details the two scenarios (all connected vs missing credentials) and what the return values look like (authenticated:true vs connect_url). This goes beyond the annotations.

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

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

The description is two sentences long, front-loaded with the core purpose, and adds essential details without filler. Every sentence is concise 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 no parameters and no output schema, the description covers the two main states (all connected vs missing credentials). It does not handle partial connection explicitly, but for a simple status check tool, it is sufficiently complete. The annotations cover safety, and the description adds return behavior.

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

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

There are zero parameters and schema coverage is 100%, so the baseline is 4. The description does not need to add parameter semantics since none exist.

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. It specifies conditional behavior (all connected vs missing credentials), distinguishing it from sibling tools like authenticate (which handles authentication) or openfinance_list_connections (which lists connections). The verb 'returns' and resource 'connection status and URLs' 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?

The description explains what the tool does but does not explicitly state when to use it versus alternatives like authenticate or openfinance_list_connections. There is no guidance on when not to use it or which scenarios are best suited for this tool. The usage context is implied but not directly articulated.

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

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

Discloses key runtime behaviors beyond annotations: invoke works even when the MCP is not installed, returns connect/checkout links for auth/payment, writes require workspace owner/admin, and prompt links open without login. Annotations only say readOnly=false, openWorld=true, so this context is valuable and non-contradictory.

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 logically organized (definition → core flow → invoke behavior → install guidance → other actions → prompt library) and nearly every sentence adds value. It loses half a point for the non-standard word 'pontualmente' and mild redundancy around not bloating the tool list.

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 the large action surface and no output schema, the description covers the essential workflow, permissions, auth/payment edge cases, and distinct prompt-library actions, giving an agent enough context to select and invoke the correct action.

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 compensates by explaining the central action enum values and mapping mcp_id/tool_id/arguments to the search-describe-invoke flow, plus prompt-library parameters. However, several params including immediate, tier_slug, conversation, and report_context remain unexplained, leaving gaps for a 23-param 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?

The description opens with 'official mcp.ai marketplace — in-platform catalog of every MCP/tool, AND the way to run them', clearly identifying the resource and verb. It outlines the core search-describe-invoke flow and distinguishes itself from sibling tools like report_bug and the openfinance family.

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 the agent when to use invoke vs install ('prefer invoke for a single/occasional use', 'Use install only to make an MCP PERMANENT') and covers alternatives like request_mcp for missing MCPs, list_tools for currently callable tools, and subscribe/cancel for billing.

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 destructiveHint=true. The description adds context: data will no longer be available and an add_connection_url is returned for reconnection. This enhances transparency beyond annotations, though it could mention irreversibility.

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 redundant words. Purpose, effect, and result are conveyed efficiently. Front-loaded with the core action.

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

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

Covers the overall effect and return value, but critically omits any explanation of the required 'item' parameter. For a destructive tool with only one parameter, this gap makes it 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?

The description does not mention the only parameter 'item' at all. Schema coverage is 0%, and the description fails to provide any meaning or format for the parameter, leaving the agent completely in the dark.

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

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

The description explicitly states it revokes consent and deletes connection data, with a specific verb and resource. It clearly distinguishes itself from siblings like 'connect' or 'openfinance_list_connections' by indicating a destructive action.

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

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

Usage is implied: use when needing to disconnect a bank. No explicit when-not or alternative tools are mentioned, though the sibling 'connect' suggests the opposite action. Guidance is minimal.

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 behavioral details beyond annotations: waits up to 60s, polls, handles errors with reconnect_url, timed_out flag, and no disconnect needed.

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 and each sentence adds value; no unnecessary fluff while covering purpose, parameters, return values, and edge cases.

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

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

Complete given complexity: covers sync behavior, polling, error states, return format, and fire-and-forget option.

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

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

Schema coverage is 0%, but description fully explains both parameters: wait (fire-and-forget) and items (selectors or omit for all).

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

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

The description clearly states the tool forces a bank re-sync, waits for completion, and distinguishes it from sibling tools like openfinance_get_item_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?

Explicitly says when to use (stale balances/transactions), provides alternative actions (re-check with get_item_status), and explains fire-and-forget mode via wait:false.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description details failure modes: BALANCE_FETCH_ERROR for CREDIT accounts, degradation to last-synced balance when upstream is unavailable, and structured warnings/errors. This is comprehensive behavioral disclosure.

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 yet comprehensive, covering purpose, constraints, error handling, and response shape in a well-organized manner. Every sentence adds value without repetition.

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

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

Given no output schema, the description fully explains the response format ({ results, errors }) and behavior under various conditions. Annotations cover safety and idempotency, so no gaps remain.

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

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

The input schema has no descriptions; the description adds that account_ids must be an array of 1-50 items. This provides necessary constraints and format. It could be more explicit about ID format, but it is clear enough.

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 payload for given account IDs, using a GET endpoint. It distinguishes from sibling tools like openfinance_get_accounts_detail or openfinance_list_accounts by focusing specifically 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 implies when to use (for real-time balance of specific accounts) and provides error handling details, but does not explicitly contrast with siblings or state when not to use. The use case is clear from context.

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

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

Annotations declare read-only and idempotent. The description adds critical transparency about provider_incident blocks causing unreliable data, and instructs not to present those values as real. This goes 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 and well-structured, front-loading the main purpose, then parameter instruction, batch shape, and warning. 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?

The description covers core functionality, parameter constraints, batch response, and a data reliability warning. However, with no output schema, it lacks details on the full return structure beyond creditData.

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

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

The only parameter, account_ids, is explained only as an array of 1-50, with no description in the schema. The tool description does not explain what these IDs represent or their format, leaving 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 it returns full account objects including extended creditData per ID, specifies the HTTP endpoint, and mentions the batch response shape. This distinguishes it from sibling list tools by focusing on detailed 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 tells how to pass account_ids (1-50) but does not explicitly state when to use this tool versus openfinance_list_accounts. The provider_incident warning provides context on interpreting results, but not on tool selection.

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 numerous behavioral traits beyond annotations: warns about data inconsistency across connectors (e.g., Nubank), explains that payments[] may reflect previous bill payment, notes the absence of a paid/status field, and advises against summing transactions by billId. Annotations include readOnlyHint, idempotentHint, destructiveHint but no contradiction; the description adds substantial, critical 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?

Every sentence adds value. The description is front-loaded with purpose, followed by exclusions, usage, and warnings. It is well-structured and dense with information without being verbose. The length is appropriate for the complexity of the tool.

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

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

Despite lacking an output schema, the description fully documents the return fields (financeCharges, payments[] with subfields), the batch shape ({ results, errors }), and crucial context about data quirks. It leaves no critical gaps for the agent to safely invoke this tool.

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

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

With 0% schema description coverage, the description must compensate for the single parameter (bill_ids). It explains how to obtain valid ids (use openfinance_list_credit_card_bills first) and that they should be passed as an array. While the schema already defines type and requiredness, the description adds workflow guidance, raising it above baseline 3.

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

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

The description clearly states it returns bill-level detail for credit card bills by id, listing specific fields (financeCharges, payments[]). It explicitly distinguishes from siblings by stating what it does NOT return (individual transactions) and names the alternative tool (openfinance_list_transactions). This satisfies the specific verb+resource+scope criterion.

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

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

The description provides explicit when-to-use (need bill-level detail for known bill ids), when-not-to-use (need itemized transactions), and alternative tools (openfinance_list_transactions, openfinance_list_credit_card_bills for paid status). It also advises to use openfinance_list_credit_card_bills first to discover ids, fulfilling the explicit context and exclusion guidelines.

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 annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral details: the reconnect_url reopens the widget for re-authentication without disconnecting or consuming a slot, and omitting 'item' returns a different structure. There is no contradiction.

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

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

The description is concise and front-loaded: the first sentence delivers the core purpose, followed by parameter usage and bulk support. Every sentence adds value, with no unnecessary words.

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

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

Given the tool has 3 optional parameters and no output schema, the description adequately explains the return fields and the two modes of operation. It could mention potential pagination for bulk results, but the provided details are sufficient for most use cases.

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 3 parameters with 0% description coverage. The description explains the 'item' parameter and the bulk 'item_ids', but does not clarify the role of 'item_id' (likely an alias for 'item'?). This leaves ambiguity, and the description could be more explicit about all 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 tool returns the current status of a bank connection, listing specific fields (UPDATED, executionStatus, connector metadata, reconnect_url). It distinguishes between fetching a single bank's status and all banks, which differentiates it from siblings like openfinance_list_connections.

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

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

The description explains when to use the 'item' parameter (single bank) versus omitting it (all banks), and mentions bulk support with item_ids. However, it does not explicitly state when not to use this tool or provide alternatives, though the sibling list implies other tools for different operations.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds value by detailing the batch response shape and listing returned fields, though does not discuss rate limits or authentication.

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 lists returned fields, second gives usage guidance and parameter details. Front-loaded and no wasted words.

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

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

Given no output schema, the description lists key fields in the response and mentions the batch shape. However, it does not explain the error structure or nested object details, leaving minor gaps for full 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% but the description adds the parameter format ('array (1-50)') and the batch response shape. It could be more explicit about the type (array of strings) and the source of loan IDs, but overall adds meaningful guidance.

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

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

The description specifies the tool returns full loan contract detail by id, lists the fields included, and distinguishes itself from the sibling openfinance_list_loans by recommending its use after that tool for deep-diving.

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 states to use it after openfinance_list_loans, clarifies the parameter as an array of 1-50 loan_ids, and explains the batch response shape with results and errors.

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

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

Discloses key behaviors beyond annotations: provider_incident for unreliable data, identity_notice for deduplication, connector-dependent CREDIT balance meaning, and bulk support.

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

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

Very informative but lengthy; each sentence adds value, but could be more structured for easier scanning.

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

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

Given no output schema and 4 parameters, the description covers return fields, parameter usage, edge cases, and error scenarios comprehensively.

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 to parameters item and item_ids (when to omit or pass, bulk execution), but item_id is not explicitly described despite schema having it.

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 accounts for a bank connection' with specific account types and fields, distinguishing it from siblings like openfinance_get_account_balance 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 guidance: 'OMIT item to list accounts across ALL linked banks... Pass item to target a single bank' and advises when to use alternative tools for bill data.

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 cache behavior and response structure beyond annotations. Annotations already declare readOnlyHint and idempotentHint, and description does not contradict them.

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

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

Three sentences, no redundant words, front-loaded with purpose. Every sentence adds value.

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

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

Tool has no parameters and no output schema, but description thoroughly explains the return fields and cache behavior, making it self-contained.

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. Description does not need to add param info. Schema coverage is 100%.

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 Pluggy's transaction category taxonomy, lists all fields with descriptions, and links to the sibling tool that uses the categoryId. Distinguishes purpose from other 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?

Implied usage: to get categories for use with openfinance_update_transaction_category. Mentions caching, which informs when to call. Could be more explicit about when not to use, but context is strong.

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 useful behavioral details about reconnect_url (reopens widget in UPDATE mode) and add_connection_url, but 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?

Description is slightly long but each sentence provides valuable information. It is front-loaded with the main return values and clearly explains the purpose of special URLs.

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 no output schema, the description fully explains what is returned (fields and URLs) and the behavior of reconnect_url and add_connection_url. No gaps remain.

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

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

No parameters exist (schema coverage 100% with empty schema). Baseline 4 per rule for 0 parameters; 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 it returns saved bank connections with specific fields (connector_id, item_id, bank name, reconnect_url, add_connection_url). It distinguishes itself from sibling tools like openfinance_disconnect_bank and openfinance_force_sync by focusing on listing connections and providing URLs for reconnection and adding new 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 provides explicit guidance on when to use the reconnect_url (for connections needing re-authentication due to MFA, LOGIN_ERROR, or stale non-Open-Finance data). It also clarifies that reconnect_url does not consume a connection slot and does not require disconnecting first, helping the agent decide between this tool and 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?

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), description discloses derivation of payment_status, connector asymmetry, bill_grouping_reliability warning, and behavior when CREDIT_CARDS product is 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?

Description is very long and contains many details, which is informative but not concise. Front-loaded with main purpose but could be more structured (e.g., separate sections). Every sentence adds value, but overall length reduces 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?

Given the complexity of Brazilian Open Finance semantics and no output schema, description is highly complete. It explains edge cases (payment_status logic, connector asymmetry, reliability warnings) and what the tool does not do, making it fully contextual for an AI agent.

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

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

With 0% schema description coverage, description adds meaning for include_open_bill (detailed explanation) and account_ids (bulk support). However, pagination parameters (page, page_size) are not explained, leaving a 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?

Description clearly states the tool returns CLOSED credit card bills with specific fields including derived payment_status. It distinguishes from sibling tools like openfinance_get_credit_card_bill and openfinance_list_transactions by specifying it returns bill-level summaries and not individual 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?

Explicitly provides when to use (for closed bills), when not to use (e.g., not for individual transactions, not to assume payments[] indicate payment), and alternatives (use openfinance_list_transactions for itemized charges). Also gives detailed guidance on interpreting payment_status and open_bill.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds critical context: graceful error handling (returns structured response instead of throwing), a detailed data integrity checking mechanism with warnings and suspect flags, and instructions on how to treat zero balances. This goes well 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 detailed but front-loaded with the core purpose. It has structured sections for data fields, error handling, and data integrity. Some redundancy exists (e.g., listing asset types again), but overall it's appropriately sized for a complex tool.

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 there is no output schema, the description provides a good overview of return structure (total, results, warning) and specific fields. It covers edge cases like data integrity warnings and mass zeroing, making it nearly 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 0% coverage in description. The description only mentions 'item_ids' for bulk operations and lists types via 'type' enum but does not explain other parameters like 'item', 'page', 'page_size', or 'item_id'. Since schema coverage is absent, the description fails to compensate for these 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 identifies the tool's purpose: returning investment portfolio data for a connection. It lists specific asset types and response fields, and distinguishes from the sibling tool 'openfinance_list_investment_transactions' which focuses on 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 specifies the use case (connections with INVESTMENTS enabled) and highlights error handling. It mentions bulk support. However, it does not explicitly guide when to avoid this tool in favor of siblings, though the context makes it 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, confirming safe read behavior. The description adds transparency by enumerating transaction types and returned fields (e.g., agreedRate, brokerageNumber, itemized expenses), and notes batch support via investment_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?

Two concise paragraphs: first establishes purpose and return fields, second covers bulk usage. Could merge bulk mention without repetition, but overall efficient relative to 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?

With 4 parameters, no output schema, and many transaction types, the description explains return fields, transaction categories, prerequisite (investment_id from list_investments), and bulk support. Missing pagination guidance and detailed batch semantics, but sufficient for most use cases.

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 the main parameter investment_id and mentions investment_ids for bulk, but provides no details on page, page_size, or how batch execution works. Partial improvement over schema-only.

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

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

The description clearly states it returns movement history for an investment position, listing transaction types (BUY/SELL/TAX/INTEREST/AMORTIZATION/TRANSFER) and specific fields. It distinguishes from sibling tools like openfinance_list_investments and openfinance_list_transactions by focusing on transactions for a single position.

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 advises using this after openfinance_list_investments to get the investment_id, and mentions bulk support with investment_ids. While it doesn't list alternative tools, the context is clear enough for an agent to decide when to invoke this tool.

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

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

While annotations declare readOnlyHint=true and idempotentHint=true, the description adds valuable details about sequential querying, error handling per connection, and the return format (`{ results, errors }`), enriching the behavioral model beyond annotations.

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

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

Three concise sentences with no wasted words. The first sentence states purpose and endpoint, the second explains the parameter, and the third covers the omission case. Information is front-loaded and 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 the single optional parameter, no output schema, and simple role (listing loans), the description covers all necessary details: usage patterns, query behavior, and return structure. No gaps remain.

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

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

The description fully compensates for the 0% schema description coverage by explaining the `items` parameter's type (array of connection selectors: item_id uuid, connector_id, or connector_name) and its purpose—one entry per connection. This is thorough and actionable.

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 'lists' and resource 'loan contracts per bank connection', specifies the HTTP endpoint, and differentiates from sibling tools like get_loan_detail which focuses on a single loan.

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

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

Explicitly explains when to use the `items` parameter (for specific connections) versus omitting it (for all banks), and describes sequential querying with rate-limit spacing. This provides clear guidance on usage scenarios.

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

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

Adds extensive behavioral context beyond annotations: auto-pagination, truncation, error handling, bulk support, credit card metadata caveats, provider incidents, and per-connector differences. 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?

Long but efficiently structured with clear sections; every sentence adds value. Could be slightly more concise, but the complexity justifies the length.

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

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

Covers all aspects: parameters, return structure, pagination, search, error handling, credit card metadata, provider incidents, and cross-tool references. Complete 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 thoroughly explains every parameter: from/to format, pagination modes, detail levels, search_queries behavior, and bulk usage. Fully compensates for missing schema descriptions.

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

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

The description clearly states the tool returns transactions for bank accounts (BANK or CREDIT type) and distinguishes it from siblings like openfinance_list_credit_card_bills, making it easy to select correctly.

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 (e.g., for credit card itemized transactions) and when-not-to-use (e.g., use openfinance_list_credit_card_bills for standardized totals), along with alternatives and error recovery steps (check item status, force sync).

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 capabilities beyond annotations: scan caps at 5000/account with truncated flag, provider_incident block, bulk support. Annotations indicate readOnlyHint, idempotentHint, destructiveHint=false, which are 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?

Description is well-structured but somewhat verbose. However, all sentences add value and it is organized logicaly from purpose to parameters to edge cases. Could trim a bit without losing clarity.

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

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

With 9 parameters, no output schema, and high complexity, the description fully covers usage, parameter semantics, edge cases (truncated, provider_incident), and bulk support. 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?

Schema coverage is 0%, but description explains all 9 parameters in detail: item accepts connector_id/connector_name/item_id, from/to are ISO dates, granularity choices, detail levels, type filtering, top_n, item_ids for bulk. Adds meaning beyond schema.

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

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

Clearly states 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call.' Distinguishes from siblings by noting it resolves accounts internally, avoiding the need to call openfinance_list_accounts first.

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 (for 'análise anual/mensal', 'fluxo de caixa', etc.) and when to use alternatives (raw granularity for itemized rows, detail for enrichment). Also says 'you do NOT need to call openfinance_list_accounts first'.

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

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

Annotations already provide readOnlyHint and idempotentHint. Description adds that it checks a public status page, returns global indicator, degraded components, incidents, and affected banks, which is useful context beyond annotations.

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

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

Single paragraph that front-loads core purpose then gives usage guidance. Not overly verbose, but could be slightly more concise. All sentences add 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 output schema, description fully explains what the tool returns: global indicator, degraded components, incidents, and affected banks. Contextually complete for a status check.

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

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

No parameters in schema, so schema coverage is 100%. Baseline 4 for zero-param tools; no additional info 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?

Description clearly states it checks the LIVE operational status of the Open Finance provider, contrasting with sibling tool openfinance_get_item_status. Specific verb and resource, and distinguishes scope.

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

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

Explicitly says when to use: when data looks incomplete/stale despite updated connection, and differentiates provider health from connection status. Names alternative 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 provide readOnlyHint=true and idempotentHint=true. The description adds behavioral context: it honors the user's plan (PF hides PJ banks, PJ covers both), non-Open-Finance connectors carry a caveat warning about auto-update, and the tool never dumps the whole catalog. No contradictions with annotations.

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

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

The description is somewhat lengthy but well-structured: starts with the main action and return fields, then caveat, plan behavior, usage note, and requirement. Every sentence adds value, but could be slightly more concise by combining some details. Still, it is front-loaded with the most critical info.

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 is no output schema, the description fully explains the return values (connector id, access, audience, linked connections, connect_url) and behavioral details (caveat, plan honor). It also specifies the required nature of keywords and the order of use. This is complete for an agent to invoke 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?

Input schema has 0% description coverage, so the description must compensate. It explains keywords[] with examples (['nubank','btg']) and clarifies its requirement. It explains include_accounts adds accounts to the return. Without the description, agents would have no guidance on these 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 it searches available bank connectors by keywords and returns specific fields (connector id, access, audience, linked connections, connect_url). It distinguishes this from other tools like 'connect' by explaining its role in the workflow. The verb 'search' and resource 'bank connectors' are specific.

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

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

Explicitly states 'Call this BEFORE connecting to hand the user a one-click link to the right bank.' Also specifies that keywords[] is required (otherwise returns a hint) and advises surfacing the caveat for users to prefer Open Finance connectors. This provides clear when-to-use and how-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?

Discloses side effect of creating a Category Rule for future similar transactions and batch error behavior. Annotations only provide hints, so description adds significant 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?

Description is reasonably concise and front-loaded with the core action. Every sentence adds value, though slightly verbose on batch shape; still well-structured.

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

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

Given no output schema, description includes return shape and error behavior. Covers side effect and parameter sourcing, making it complete for an agent to use correctly.

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

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

Schema description coverage is 0%, but description fully explains the `items` parameter structure and sources for transaction_id and category_id (from specific sibling tools), adding necessary semantics.

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

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

Description explicitly states it corrects transaction categories via PATCH /transactions/:id, and distinguishes from sibling tools like list transactions and list categories by referencing their outputs.

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?

Clearly explains when to use (to fix miscategorized transactions) and mentions side effects (creates Category Rule). Lacks explicit when-not-to-use but context is sufficient.

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 the operation is safe and repeatable. The description adds that the conversation array should be included for reproduction, but does not disclose side effects (e.g., whether data is stored or a confirmation response). With annotations already covering some behavioral aspects, the description adds limited additional 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 two sentences with no filler. The first sentence states the purpose, the second gives a key instruction. Every word earns its place, and it is front-loaded with the tool's core function.

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 (3 string params, no output schema), the description is minimally adequate. However, it lacks details about the return value or what happens after submission (e.g., confirmation). The 'context' parameter remains unexplained, leaving a gap for agents.

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 partially explains the 'conversation' parameter ('include the conversation array with recent messages for reproduction') but does not clarify 'context' or 'message' beyond their schema definitions. 'message' is required but its content purpose is left to interpretation.

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 tool's purpose: 'Report a bug, missing feature, or send feedback.' It identifies the resource (bug/feature/feedback) and the action (report/send), clearly distinguishing it from sibling tools which are mostly finance-related operations.

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

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

The description implies the tool is for reporting issues or feedback but provides no explicit guidance on when to use it versus alternatives, nor when not to use it. There are no exclusions or context for when this tool is appropriate beyond its stated purpose.

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

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

Annotations declare readOnlyHint, idempotentHint, destructiveHint. Description adds that it returns platform and adapter versions, providing specific behavioral context beyond safety hints.

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

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

Single sentence, directly front-loaded with purpose, no unnecessary words. High efficiency.

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, read-only tool with no output schema, the description fully covers what the tool does. No gaps.

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

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

No parameters exist; baseline for 0 params is 4. Description adds no param info because none 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?

Description specifies the verb 'Show' and the resource 'current MCP platform and adapter versions'. Among siblings, no other tool provides version information, so it is clearly differentiated.

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, but the simplicity and uniqueness of the tool make usage obvious. Lacks explicit context like 'check version before using other tools'.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the agent knows this is a safe read-only operation. The description adds beyond this by specifying what data is returned (installed MCPs, connection status, accounts, catalog tool counts), providing useful context on the tool's output composition.

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, front-loaded sentence that immediately states the verb and resource, then lists the specific return components without any 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?

For a zero-parameter, no-output-schema info tool, the description fully covers return value composition. It lists all major components of the toolkit state, making the tool's behavior understandable without additional schema or annotation details.

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

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

The tool has zero parameters, so schema coverage is 100% trivially. The baseline for zero-param tools is 4; since there are no parameters to explain, the description appropriately does not include parameter details.

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

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

The description clearly states the tool returns the current toolkit state with specific components: installed MCPs, connection status, connected accounts, and catalog tool counts. This uses a specific verb (Returns) and resource (current toolkit state), distinguishing it from siblings like show_version or connect.

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 toolkit state but does not explicitly state when to use it vs alternatives or when not to use it. There is no mention of exclusions or preferred scenarios, so it relies on the reader to infer its role among sibling tools.

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