Stone Pagamentos MCP

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

Discloses behavior beyond annotations: no args returns a link, token arg authenticates, and permanent config alternative. Annotations already indicate idempotent and non-destructive, and description adds valuable 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?

Single dense paragraph effectively conveys all necessary info. Could be slightly more structured, but 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 optional parameter and no output schema, the description covers all critical aspects: audience, methods, token format, and permanent vs session behavior.

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

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

With 0% schema coverage, description fully compensates by explaining the 'token' parameter's purpose (JWT for session login) and behavior when omitted (returns link).

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's for authentication, specifying the target audience (IDE agents) and the two login methods (permanent config vs session token). Distinguishes from sibling tools like 'connect' which likely involve external service 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?

Provides clear when-to-use (for login) and explains both permanent and session approaches. Lacks explicit exclusions but gives sufficient context for agent to decide.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds value by explaining the return values (authenticated, pending, connect_url) in different states, which is 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, front-loaded with the main purpose, and no wasted words. 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?

For a tool with no parameters and no output schema, the description sufficiently explains the two return scenarios, making it complete for an agent to understand the 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 no parameters, so schema coverage is 100%. The description does not need to add parameter semantics. Baseline for zero parameters is 4.

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

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

The description clearly states it returns connection status and URLs, with specific behavior for when all providers are connected versus when credentials are missing. This distinguishes it from sibling tools like 'authenticate' or 'marketplace'.

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

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

The description explains when to use the tool (to check connection status). While it doesn't explicitly say when not to use it or compare to alternatives, the sibling tools provide context that this is for overall connection, not individual 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?

The description adds substantial behavioral context beyond annotations: invoke works even if MCP not installed, returns connect/checkout links for auth/payment, and distinguishes one-off vs permanent usage. Annotations show readOnlyHint=false, openWorldHint=true, etc., but description enriches with specific behaviors like credentials handling.

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 longer but well-structured: starts with a bold statement, then core flow, then key distinctions (invoke vs install), then other actions. Every sentence adds value, though it could be slightly more concise.

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

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

Given the complexity (15 parameters, multiple actions, no output schema), the description covers purpose, usage flow, auth/permissions, credential/payment handling, and links. It is sufficiently complete for an AI agent to understand when and how to use the 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. It provides overall context (e.g., action options, query, tool_id) but lacks specific details on parameter formats or constraints (e.g., how to format 'arguments' JSON, limit usage). Some meaning is added, but not enough for full compensation.

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 that this tool is 'THE official mcp.ai marketplace' and lists specific actions (search, describe, invoke, install) with clear purposes. It distinguishes itself from siblings by stating 'use THIS tool FIRST, before any external/generic registry' and contrasts invoke vs install.

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 a clear core flow: search → describe → invoke, and explains when to use invoke vs install. It explicitly says 'use THIS tool FIRST' for finding MCPs and gives alternatives (install for permanent use, invoke for one-off). Also mentions that writes require workspace owner/admin.

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 is destructive (deletes data), aligning with the destructiveHint annotation. It adds value by stating the data will no longer be available and returns a re-connection URL, which annotations alone don't provide. No contradictions.

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

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

The description is two sentences, both front-loaded with essential information: the action and its consequence, followed by a relevant return detail. No unnecessary words or redundant information.

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

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

For a simple destructive tool with one parameter and no output schema, the description covers the core action and outcome but omits parameter semantics. It adequately conveys the general behavior but leaves a significant gap in understanding the required input.

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 'item' is a required string with 0% schema description coverage. The description does not explain what 'item' represents (e.g., bank connection ID), leaving the agent unclear on what to pass. The purpose of the parameter must be inferred from context, which is insufficient.

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, making bank data unavailable. It distinctly identifies the resource (a specific bank) and the action (disconnect/revoke). Sibling tools like 'connect' and 'openfinance_list_connections' serve different purposes, though the description doesn't explicitly differentiate them.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies it's for disconnecting a bank, but doesn't mention prerequisites (e.g., existing connection) or when to use other tools like 'openfinance_force_sync' or 'authenticate'.

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

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

Discloses waiting up to ~60s, polling behavior, return fields (status, executionStatus, lastUpdatedAt, synced), and error states (needs_action, timed_out). Adds value beyond annotations which show readOnlyHint=false and destructiveHint=false.

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

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

Front-loaded with action and purpose, then detailed but efficient. Every sentence adds value without redundancy.

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

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

Given no output schema, the description explains return structure and error handling. Covers all necessary context for an AI agent to use 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?

Fully explains both parameters: items as array of selectors with OMIT to sync all, and wait for fire-and-forget. Compensates for 0% schema 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?

Describes a clear verb (force re-sync) and resource (connections), with specific context (when balance/transactions look stale). Distinguishes 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 states when to use (stale data) and when not (without disconnecting). Mentions alternative tool for re-checking timed out syncs and 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?

Discloses graceful degradation for CREDIT accounts (BALANCE_FETCH_ERROR with warning) and unavailable institutions (falls back to last-synced balance with realtime:false), adding value beyond annotations which already mark it read-only and idempotent.

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

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

Front-loaded with main action, then details error handling; no redundancy, but could be slightly tighter (e.g., merge first two sentences).

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 single-parameter tool with no output schema, includes response shape, error types, and fallback behavior, providing a complete picture.

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 important constraint '1–50' for array length, compensating for 0% schema description coverage. Could specify that each item is an account ID, but the parameter name is self-explanatory.

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?

Specific verb 'returns real-time balance payload per account id' with endpoint and parameter, clearly distinguishing from sibling tools that list or detail accounts.

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

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

States when to use (get real-time balance per account) and constraints (array 1-50), but does not explicitly mention when not to use or alternatives, though sibling tools are distinct.

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

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

The description adds critical context beyond annotations: it warns about provider_incident blocks causing unreliable credit limits/balances and advises not to present those values as real. This is high-value 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?

Three sentences with no wasted words. The first sentence states the main purpose, the second specifies input, and the third provides an important caveat. Well-structured and front-loaded.

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

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

Given the tool's simplicity (1 param, no output schema), the description covers the main purpose, input constraints, and a key edge case (provider_incident). It does not detail the full return shape beyond 'batch shape', but this is reasonable for a read-only detail endpoint.

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 clarifies the account_ids parameter format as an array of 1-50 items, adding value beyond the schema. It doesn't explain what each item represents, but the tool name implies account IDs.

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

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

The description clearly states it returns full account objects with extended creditData per ID, and specifies the batch shape. This distinguishes it from sibling tools like openfinance_list_accounts which likely returns a list without detail.

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?

It says to pass account_ids array (1-50) but does not explicitly state when to use this tool versus alternatives like openfinance_list_accounts. Usage is implied but not guided with exclusions or when-not 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?

The description adds significant behavioral context beyond annotations, including that Pluggy does not return a paid/status field, the batch response shape { results, errors }, and the nuance that payments[] may reflect a previous bill's payment. This is far beyond the readOnlyHint and idempotentHint 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 moderately long but well-structured, with key information upfront. It earns its length by providing critical caveats and usage guidance. Minor redundancy could be trimmed, but overall it is effective.

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

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

Given the tool's simplicity (single required parameter, no output schema), the description is remarkably complete. It details the return fields, explains edge cases (sparse billId, payments misinterpretation), and provides actionable workflow steps.

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

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

The single parameter 'bill_ids' has 0% schema coverage, but the description compensates by explaining its purpose ('Pass bill_ids as an array') and providing workflow guidance. While it doesn't elaborate on types or constraints, the context is sufficient for an 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 that the tool returns bill-level detail for credit card bills by ID, listing specific fields (financeCharges, payments). It explicitly distinguishes itself from sibling tools by noting that it does NOT return individual transactions, which is a strong differentiator.

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 and when-not-to-use guidance. It advises using openfinance_list_credit_card_bills first to discover IDs, and directs agents to openfinance_list_transactions for itemized transactions. It also warns against reconstructing totals from transactions and explains the semantics of the payments array.

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

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

Adds value beyond annotations by specifying response structure ('{ count, items }') and fields returned (status, executionStatus, connector metadata). Annotations already indicate readOnly, idempotent, non-destructive; description aligns and enriches.

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 superfluous content, front-loaded with key purpose. Every word serves a purpose.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description covers all necessary contextual information: usage modes, response hints, and returned data.

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

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

The sole parameter 'item' is fully described: its effect when provided (single bank status) and when omitted (all banks). This compensates for the 0% schema coverage on parameter 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 it returns bank connection status, lists example statuses, and distinguishes between single and all bank retrieval. It uses specific verbs and resources, differentiating 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?

Explicitly explains when to omit vs. pass 'item' for different use cases. Does not explicitly state when not to use or mention alternatives, but the context is clear enough given the 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which the description is consistent with (no contradiction). The description adds transparency about batch processing behavior and the { results, errors } response shape, though it does not cover rate limits or auth requirements.

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

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

The description is a single paragraph but efficiently packed: main purpose first, then return fields, then usage guidance, then parameter 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?

Despite no output schema, the description lists many return fields and the batch shape, making it complete for a simple detail retrieval tool. It also ties usage to the earlier list step, providing full context for invocation.

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

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

Schema coverage for loan_ids is 0%, but the description compensates by explaining the parameter: 'Pass loan_ids as an array (1-50).' This adds meaning beyond the bare schema, clarifying the size constraint and usage.

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

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

The description clearly states the tool's purpose: 'Returns full loan contract detail by id'. It specifies the endpoint, lists key fields (interestRates, etc.), and distinguishes from sibling tool openfinance_list_loans by indicating this is for deep-diving on a specific contract after listing.

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

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

The description explicitly states when to use: 'Use after openfinance_list_loans to deep-dive on a specific contract.' It provides specific parameter guidance (array of 1-50 loan_ids) and mentions the batch response shape, though it does not include explicit when-not 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?

Annotations indicate readOnlyHint=true and destructiveHint=false, which the description aligns with. It adds behavioral context by warning about potential provider_incident blocks that may make balances unreliable, and explains that credit balance meaning varies by connector. 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 fairly long but each sentence provides essential information. It is well-structured with front-loaded purpose and logical flow. Slight verbosity is justified by the complexity of the tool's behavior.

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

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

With no output schema, the description fully explains return values including account fields, bank, connector_id, item_id, and provider_incident. It covers edge cases, credit balance nuances, and directs to the appropriate tool for bill-related queries. Highly complete for a complex financial tool.

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

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

The input schema has 0% description coverage for parameters, but the description fully compensates by explaining the effect of omitting 'item' versus passing it, and how the 'type' enum filters accounts. It details response structure changes and the meaning of parameters, adding substantial value 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?

The description clearly states the tool returns accounts for a bank connection with specific fields like balance, type, and provider data. It distinguishes between BANK and CREDIT accounts and explains how to list all accounts versus a single bank, differentiating from 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?

The description provides explicit guidance on when to omit or include the 'item' parameter to list all accounts or target a single bank. It also warns about the connector-dependent meaning of credit balance and suggests using openfinance_list_credit_card_bills for standardized bill amounts, giving clear when-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?

Annotations already declare readOnlyHint=true. The description adds caching behavior, that it's a single aggregated response, and details the structure with fields like id, description, descriptionTranslated, parentId, parentDescription. No contradictions.

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

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

Two sentences: first states purpose with source, second lists response characteristics and fields. No wasted words, front-loaded with key 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?

With no parameters and good annotations, description fully explains the output format and the significance of the id field. No missing context for intended use.

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

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

No parameters, so baseline 4 is appropriate. Description adds context about output fields but parameter semantics are not applicable.

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 verb 'Returns' and the resource 'Pluggy's transaction category taxonomy'. It distinguishes itself from sibling tools like list_transactions by specifying it returns a static category taxonomy, and explicitly links to openfinance_update_transaction_category.

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 this tool should be used to obtain category mapping before using update transaction category, but does not explicitly state when not to use or alternative approaches. It mentions caching and no batch ids, which guide usage behavior.

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, and destructiveHint=false. The description adds the specific return fields but does not discuss any additional behavioral traits such as lack of side effects or authentication needs, which are already covered by 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 sentence, front-loaded with action and resource, efficiently lists key output fields, no filler.

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 zero-parameter tool, the description adequately explains what is returned. It does not mention pagination or ordering, but these are not critical given the tool's simplicity and the presence of annotations covering read-only behavior.

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

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

No parameters exist, so the schema coverage is 100% vacuously. Baseline for 0 params is 4; the description does not need to add parameter info, and 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 it returns saved bank connections and lists specific fields (connector_id, item_id, bank name, add_connection_url). This distinguishes it from sibling list tools like list_accounts or 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?

No explicit guidance on when to use this tool vs alternatives. The name and description imply it should be used to retrieve existing connections before performing other actions, but lacks explicit when-not or alternative recommendations.

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

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

Annotations already declare readOnlyHint and idempotentHint; the description adds significant behavioral context: payment semantics (pre-payment vs. cross-bill), derived payment_status logic, connector asymmetry (open_bill.available false with reasons), warning for missing CREDIT_CARDS product, and bill grouping reliability. No contradiction with annotations.

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

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

Description is front-loaded with the core purpose, but is extremely verbose with multiple dense paragraphs covering edge cases. While every sentence adds value, it could benefit from structure (e.g., bullet points). Still, it is not wasteful.

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 (5 parameters, no output schema, no schema descriptions), the description is highly complete. It explains return fields, derived values, edge cases, multi-bank handling, and provides authoritative guidance on using totalAmount over by-billId summing.

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

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

Schema description coverage is 0%, so description must compensate. It thoroughly explains include_open_bill (opt-in, return structure, failure modes) and account_ids for batch. However, pagination parameters (page, page_size) remain undocumented in both schema and description, a minor gap.

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

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

Clearly specifies it returns CLOSED credit card bills for CREDIT-type accounts, lists returned fields, and distinguishes from sibling tools like openfinance_list_transactions (itemized purchases) and openfinance_get_credit_card_bill (singular bill).

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

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

Provides extensive guidance: when to use vs. alternatives (use openfinance_list_transactions for itemized purchases), when to cross-check account echo for multi-bank, when to opt-in for open_bill and total debt, and warns about connector asymmetry and bill grouping reliability.

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 that it returns a warning instead of throwing errors for missing INVESTMENTS, and lists return fields (balance, amount, etc.). This adds value beyond annotations.

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

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

The description is a single paragraph that efficiently lists asset types and return fields. It is well-structured with a clear purpose and no redundant information.

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

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

Given the complexity (4 optional parameters, no output schema), the description covers the return structure and error handling but lacks parameter explanations. It is mostly complete for a read-only tool with annotations.

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

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

Schema description coverage is 0%, so description must compensate. It does not explain the parameters (item, page, type, page_size) beyond the schema's type enum. The agent cannot infer constraints or usage for these parameters from the description.

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 investment portfolios for a connection, listing specific asset types (FIIs, stocks, etc.). It distinguishes from sibling tools like openfinance_list_accounts or openfinance_list_transactions by focusing on investments.

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 (to get investment portfolio) and mentions fallback behavior (returns empty structure instead of error for non-enabled investments). It does not explicitly mention alternatives, but the context from annotations (readOnlyHint) and sibling names provides implicit 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 provide readOnlyHint and idempotentHint. The description adds that the tool lists specific transaction types with detailed fields and supports batch execution 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?

Three concise sentences with no extraneous information. The most critical information is front-loaded: purpose, then usage hint, then bulk feature.

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

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

Given no output schema, the description details return fields. It covers prerequisites and bulk capability. However, it omits pagination behavior for page and page_size, which are present in the input 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?

Schema description coverage is 0%, so the description must explain parameters. It mentions investment_id and investment_ids (bulk), but does not describe page and page_size parameters, 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?

The description clearly states it returns movement history for a specific investment position, enumerates transaction types (BUY, SELL, etc.) and output fields. It distinguishes from sibling tools like openfinance_list_investments and openfinance_list_transactions by specifying a specific investment 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?

Explicitly advises to use after openfinance_list_investments to obtain the investment_id, and mentions bulk support. Does not explicitly state when not to use, but 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.

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

Adds valuable behavioral details beyond annotations: sequential querying with rate limits per connection, return format `{ results, errors }`. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint).

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

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

Two sentences, no fluff. First sentence states purpose and endpoint; second explains parameter usage and return format. Front-loaded with essential 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?

Complete for a read-only list tool with optional parameters. Covers both use cases (specific connections vs all), rate-limiting behavior, and return structure, despite lacking 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?

Compensates for 0% schema coverage by explaining `items` as an array of connection selectors (item_id, connector_id, connector_name) with examples and semantics (one entry per connection). Adds meaning beyond the bare schema.

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

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

Explicitly states it lists loan contracts per bank connection, specifying the HTTP endpoint GET /loans. Clearly distinguishes from sibling list tools (e.g., accounts, transactions) by focusing on loans.

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 guidance: pass `items` for specific connections, omit for all linked banks. Also notes sequential querying with rate-limit spacing, helping the agent manage batch 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 declare readOnlyHint, idempotentHint, and destructiveHint. The description adds rich behavioral context: auto-pagination up to 5000 ceiling, truncation warnings, error format returning {total, results, warning, error}, provider incident block, per-connector variability for credit card metadata, and batch execution via account_ids.

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

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

The description is long but well-structured and front-loaded with core purpose. Every sentence adds value for the agent, though some details could be more concise 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?

Covers many edge cases (provider incidents, connection health, truncation) but lacks a formal return schema. Describes some response fields (account echo, creditCardMetadata, merchantInfo) but not all transaction fields. Adequate for agent use given the 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?

Schema coverage is 0%, but the description thoroughly explains each parameter: account_id (required), from/to (ISO dates), page/page_size (pagination modes), detail (enum with compact/rich/raw explanations), search_queries (OR semantics, case-insensitive, aggregation), and account_ids (batch). Adds meaning beyond the schema.

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

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

The description clearly states it returns transactions for bank accounts (BANK or CREDIT type). It specifies that for CREDIT accounts it is the only way to get itemized transactions, distinguishing it from siblings 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?

Extensive guidance on when to use vs alternatives (e.g., for credit card itemized transactions vs bills), detail levels, pagination modes, handling truncation, checking connection health, and cross-referencing account echo. Explicitly states not to sum by billId and directs to openfinance_list_credit_card_bills for bill totals.

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 adds critical behavioral details: transaction scan caps at 5000/account with 'truncated:true' flag, potential 'provider_incident' block affecting completeness, and the difference between compact and raw returns.

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 information-dense; every sentence adds value. It is front-loaded with the core purpose and then details. Could be slightly more concise, but it remains well-structured.

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

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

Given the complexity (7 parameters, no output schema), the description is quite complete. It covers return format, caveats (truncation, provider incidents), and parameter effects. It doesn't list every return field, but that is acceptable without an 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?

Schema description coverage is 0%, but the description extensively explains parameters: 'item' (target one bank or omit), 'from'/'to' (ISO dates), 'granularity' (monthly vs raw), 'detail' (compact, rich, raw), 'type' (BANK or CREDIT), and implies 'top_n' from 'top_despesas' context. It adds meaning beyond the schema, though top_n could be more explicit.

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 and resource: 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call.' It distinguishes from siblings like openfinance_list_transactions by explicitly noting it resolves accounts internally and avoids needing 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?

The description explicitly tells when to use (for 'análise anual/mensal', 'fluxo de caixa', etc.) and when not to ('do NOT need to call openfinance_list_accounts first'). It also gives guidance on omitting the 'item' parameter to analyze all linked banks, and explains the granularity options.

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, and openWorldHint. The description adds value by detailing the return structure: global indicator, degraded components, open incidents, and flags for affected banks. There is 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 a single, well-structured paragraph of about 100 words. It starts with the core purpose, then explains usage context, and finally lists return values. Every sentence adds value without redundancy.

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

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

Despite no output schema, the description fully explains what the tool returns (global indicator, degraded components, open incidents, affected banks). Combined with 0 parameters and clear annotations, the description is complete for an agent to use 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?

With 0 parameters and 100% schema coverage (empty schema), the baseline is 4. The description does not need to describe parameters, so it is adequate.

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

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

The description clearly states the tool checks the LIVE operational status of the Open Finance provider's public status page. It distinguishes from sibling 'openfinance_get_item_status' by emphasizing it's the provider's health, not the connection's health. The verb 'checks' and resource 'provider status' 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 provides explicit guidance on when to use this tool: 'whenever data looks incomplete or stale even though a connection shows UPDATED...'. It also contrasts with the sibling tool 'openfinance_get_item_status' to prevent misuse. This helps the agent decide correctly.

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, idempotentHint, destructiveHint. The description adds critical behavioral context: returns connect_url, honors user's plan (PF hides PJ), returns caveat for non-Open-Finance connectors, and returns a hint if no keywords provided. No contradictions with annotations.

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

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

The description is a single paragraph that packs substantial detail. It is front-loaded with purpose and every sentence adds value. Slightly verbose but not wasteful; could be broken into bullet points for better scanability.

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

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

Given no output schema, the description fully explains return fields (connector id, access, audience, connections, connect_url) and edge cases (no keywords, plan filtering, caveat). Complete for selection and invocation decisions.

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

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

Schema description coverage is 0%, so description carries full burden. It explains keywords[] as array of bank names (required, without it returns hint) and include_accounts as boolean to include accounts. Adds meaning beyond the schema's bare type definitions.

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

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

The description clearly states the tool searches bank connectors by name (with keywords array), and specifies what it returns (connector id, access, audience, linked connections, connect_url). It differentiates from sibling tools like openfinance_list_connections by focusing on pre-connection search and one-click link generation.

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 when to use ('Call this BEFORE connecting'), emphasizes that keywords[] is REQUIRED (despite schema not marking it required), and warns against dumping catalog. Also explains plan-based filtering and caveat for non-Open-Finance connectors, guiding the agent on proper invocation.

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 non-read-only, non-idempotent, non-destructive. The description adds significant behavioral context: it overrides automatic categorization, creates a Category Rule for future matching, and handles partial failures gracefully. 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, front-loading the action and then providing details on side effects and return shape. Every sentence adds value, though slight brevity could be improved.

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 (batch update, side effects, return format), the description covers all necessary context: how to use, what it does, side effects, error handling, and return shape. No output schema exists, but the return structure is explicitly described.

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 no description (0% coverage), but the description fully explains the 'items' parameter structure, including required fields (transaction_id, category_id) and their sources (list tools). This compensates for the schema gap.

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

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

The description states it 'corrects the category of one or more transactions' using PATCH. It clearly distinguishes from sibling listing tools (e.g., openfinance_list_transactions, openfinance_list_categories) by indicating this tool performs updates.

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: to fix miscategorized transactions and improve categorization accuracy. It provides context on sourcing IDs from other tools but does not explicitly mention when not to use or 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 idempotentHint=true and destructiveHint=false, so the description's mention of reporting is consistent. No additional behavioral traits are disclosed, such as whether the request is sent immediately or requires confirmation.

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 with no redundant information. It is concise and front-loaded with the purpose.

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

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

For a simple feedback tool with 3 parameters and no output schema, the description covers the main purpose but lacks sufficient detail on parameter usage and the expected behavior after submission.

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 minimal value. It mentions the conversation array but does not clarify the format or expected structure. The required 'message' parameter and optional 'context' are not explained.

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 reporting bugs, missing features, or sending feedback, which is a specific verb-resource combination. It is distinct from all sibling tools, which are focused on financial 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 explicitly advises to include the conversation array with recent messages for reproduction, providing clear guidance on how to use the tool. However, it does not specify when not to use it or mention any alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond the purpose, such as authentication requirements, rate limits, or output format. Thus, description provides minimal added 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 a single, concise sentence with no unnecessary words. It is front-loaded with the action and resource, making it easy to parse.

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

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

Given the tool's simplicity (no input parameters, no output schema, a single clear purpose), the description is fully complete. It covers all needed information for an AI agent to understand when and how to invoke it.

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

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

The input schema has no parameters, so schema description coverage is 100%. The description correctly implies there are no parameters; baseline for zero parameters is 4. No additional parameter information is necessary or provided.

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

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

The description 'Show the current MCP platform and adapter versions' clearly specifies the action (show) and the resource (MCP platform and adapter versions). It is distinct from sibling tools, which focus on authentication, banking operations, or other functionalities.

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 does not provide explicit guidance on when to use this tool versus alternatives. Since it is a simple informational tool, usage context is implied, but no exclusions or prerequisites are mentioned.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, establishing a safe, read-only profile. The description adds valuable behavioral context by specifying the exact contents of the return (installed MCPs, connection status, catalog tool counts), which goes beyond the annotations.

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

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

A single sentence that packs all essential information with no wasted words. It is front-loaded with the core purpose and immediately lists the return contents.

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 completely specifies what the tool returns. It covers all needed information: installed MCPs, connection status, and catalog tool counts.

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 naturally has no parameter details to add. The baseline for zero-parameter tools is 4, and the description does not need to compensate.

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 toolkit state, including installed MCPs, connection status, and catalog tool counts. It uses specific verbs and resource details, distinguishing it from all sibling tools which focus on authentication, market data, or banking operations.

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

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

The description implies usage for retrieving toolkit state but provides no explicit when-to-use or when-not-to-use guidance. Given the simplicity and self-explanatory nature of a status tool, this is minimally adequate.

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