Porto Bank MCP

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

The description does not contradict annotations. It transparently explains that calling without token returns a login link, and calling with token performs session authentication. No destructive or read-only behavior is implied beyond what annotations state.

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

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

Three sentences, each serving a clear purpose. Could be slightly more concise, but the structure is logical and front-loaded with the main purpose.

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

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

For a simple authentication tool with one parameter and no output schema, the description covers the essential workflow. It lacks explicit return format but is sufficient for an agent to understand invocation.

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

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

The schema has 0% description coverage for the 'token' parameter, but the description compensates fully by explaining it is a JWT and how to use it in both modes.

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, distinguishing the two use cases (permanent config vs session-only login) with specific instructions. The verb 'authenticate' is implicit but well-defined, and it is unique among siblings.

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

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

The description explicitly explains when to use each mode: for permanent access add to config, for session-only paste token. It provides instructions for calling with or without arguments, making it easy for the 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 and idempotentHint true, and destructiveHint false. The description adds value by detailing the return values for different states (authenticated:true when all providers connected, connect_url when credentials missing). This goes beyond default annotations and provides clear 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?

The description is two sentences, front-loaded with the main purpose, and each sentence provides essential information. No wasted words, perfectly 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?

For a tool with no parameters and no output schema, the description adequately explains the expected return values for different states. It covers the main scenarios (all providers connected vs missing credentials). Could be slightly more explicit about what constitutes 'all providers', but overall complete enough.

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 the baseline is 4 per guidelines. The description does not need to add parameter semantics, but it adds value by explaining the output, which indirectly helps understand the tool's functionality.

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, specifying the behavior for different states (authenticated vs missing credentials). It distinguishes itself from sibling tools like 'authenticate' which likely performs authentication actions.

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

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

The description provides clear context on when to use this tool: to check connection status and obtain URLs when credentials are missing. While it does not explicitly say when not to use it, the existence of sibling tools like 'authenticate' provides implicit guidance, and the description is adequate for an AI agent to infer appropriate usage.

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

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

Discloses write operations (install, uninstall, subscribe, cancel, invoke) and that they require owner/admin. Explains that invoke may return connect/checkout links instead of immediate execution. No contradiction with annotations (readOnlyHint false, destructiveHint false).

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

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

The description is long but well-structured, front-loading the purpose and core flow. It groups related information logically. However, it could be more concise by trimming redundant phrases like 'THE official mcp.ai marketplace'.

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 most usage contexts: discovery, one-off invocation, permanent installation, billing, bug reporting, and permission requirements. Lacks explanation of return values from search/describe (no output schema), and some parameters like 'immediate' are not elaborated. Given the tool's complexity, it is fairly complete.

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

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

Schema coverage is 0%, so description must add meaning. It explains the action parameter values and hints at several others (mcp_id, tool_id, arguments, query, limit, etc.) but does not provide detailed semantics for all 15 parameters (e.g., 'conversation', 'immediate' are barely mentioned). The core flow is covered, but parameter-level detail 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 is the official marketplace for discovering and running MCPs/tools, contrasting with external registries. It specifies the core flow (search, describe, invoke) and distinguishes from sibling tools like openfinance_* and authenticate.

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

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

Explicitly instructs to use this tool first before external registries. Provides clear guidance on when to use invoke vs install, how to handle credentials/payment, and notes that writes require owner/admin. Differentiates from sibling tools by explaining the marketplace flow.

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

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

Annotations already mark as destructive (destructiveHint=true). Description adds detail: consent revocation, data deletion, and return of re-connection URL, enhancing understanding of side effects.

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

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

Three sentences, each adding value: main action, consequence, and possible reconnection. Front-loaded and no filler, though could be more structured with parameter guidance.

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 outcome is described (data unavailable, returns URL), the single required parameter 'item' is not explained. No output schema exists, and the description does not cover what the parameter represents or how to obtain 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 a single parameter 'item' with no description (0% coverage). The description mentions 'specific bank' but does not clarify the format or source of the parameter, 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?

Clearly states it revokes consent and deletes connection data for a specific bank. Differentiates from sibling tools like openfinance_list_connections (list) and openfinance_force_sync (sync).

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

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

Describes the action but does not provide explicit guidance on when to use this tool versus alternatives (e.g., when not to use it or prerequisites like having an existing connection).

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 many behavioral traits beyond annotations: it is a write operation that waits up to 60s, can require re-authentication, returns specific fields, and can time out. This is comprehensive, and no contradiction with annotations is present.

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

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

The description is detailed but front-loaded with the core action. Every sentence adds value, though it is slightly long. It could be tightened, but remains efficient for the complexity.

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

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

Given no output schema, the description thoroughly explains the return structure, including error conditions and handling. It covers all necessary context for successful use, making it complete.

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

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

The description adds significant meaning to the parameters: 'wait' is explained as fire-and-forget option, and 'items' is described as an array of selectors (item_id, connector_id, etc.) and that omitting it syncs all banks. This compensates for zero schema description coverage.

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

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

The description clearly states the tool forces a bank to re-sync connections and waits for completion. It specifies the verb 'force_sync', the resource 'bank connections', and distinguishes it from other tools by mentioning it does not disconnect/reconnect.

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

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

The description explicitly says when to use it (when balance/transaction list looks stale) and what it does without disconnecting. It also explains options like 'wait: false' for fire-and-forget and how to handle errors like 'needs_action' or 'timed_out', providing clear guidance.

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

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

Beyond annotations (readOnlyHint, idempotentHint), describes degradation behavior, warning for CREDIT accounts, and structured response with errors. Adds significant value.

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

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

Concise single paragraph with 4 sentences, each adding essential info: purpose, parameter, edge cases, 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?

Covers input, output (response shape), error handling, and degradation. No output schema, but description provides sufficient detail. Complete for a tool with one parameter.

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?

Only one parameter (account_ids), description adds constraint (1-50 items) not present in schema. Schema coverage is 0%, but description fully compensates by explaining usage and constraints.

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 returns real-time balance per account ID, with the API path and parameter usage. It clearly distinguishes from sibling tools like openfinance_list_accounts.

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

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

Provides clear parameter guidance (array of 1-50 account_ids) and explains error handling. Lacks explicit when-not-to-use, but context is sufficient given sibling tool separation.

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 read-only and idempotent. Description adds critical behavioral context: provider_incident block when Open Finance provider has an open incident, causing unreliable credit limits/balances. 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?

Description is succinct, front-loaded with main purpose, no wasted words. Three sentences cover purpose, usage, and critical edge case efficiently.

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, the description covers all essential aspects: what is returned (full objects, batch shape), the key parameter constraint, and the important provider incident warning. Sufficient for correct invocation.

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

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

Schema has 0% description coverage, so description carries full burden. It adds the array range (1–50) and explains how the parameter is used, including the batch shape and provider incident behavior.

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

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

The description clearly states it returns full account objects with extended creditData per ID, specifies the HTTP method and path, and distinguishes from sibling tools like list_accounts by focusing on per-id detail with batch shape.

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?

Specifies to pass account_ids as an array (1–50) and explains batch shape. Implicitly suggests usage when extended creditData is needed, 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?

Beyond the annotations (readOnlyHint, idempotent), the description discloses batch shape {results, errors}, notes that Pluggy doesn't return a paid/status field, explains payments[] reflects previous bill payments, and mentions sparse billId metadata on some connectors.

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

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

The description is relatively long but every sentence adds essential value and conveys nuances. It is well-structured with clear statements and caveats, though it could be slightly more streamlined.

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, lack of output schema, and connector variability, the description covers expected fields, batch shape, and important edge cases (payments timing, billId inconsistency, paid status sourcing), making it fully actionable.

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

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

The schema has 0% coverage, but the description states that bill_ids should be passed as an array and suggests using list_credit_card_bills to discover ids. While it doesn't elaborate on id format, it provides sufficient context for correct 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 explicitly states the tool returns bill-level detail for credit card bills by ID, lists included fields (financeCharges, payments) and clearly states what it does NOT return (individual transactions), distinguishing it from openfinance_list_transactions.

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

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

The description provides explicit guidance: use openfinance_list_credit_card_bills first to discover ids, use openfinance_list_transactions for itemized transactions, warns not to reconstruct bill total from transactions, and explains payment semantics to avoid misinterpretation.

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 confirm read-only and idempotent behavior. The description adds valuable context about the reconnect_url that reopens the widget in UPDATE mode, which is beyond annotations.

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

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

Two sentences plus a separate line for bulk support. Information is front-loaded with the core purpose. Slightly unstructured but still 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?

Describes inputs and outputs (status, executionStatus, metadata, reconnect_url) but does not explicitly state the response shape for a single item request. Some details missing.

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

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

Schema coverage is 0%, so description must explain all parameters. It explains 'item' and 'item_ids' but does not address 'item_id', leaving ambiguity about its role.

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

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

The description clearly states it returns the current status of a bank connection with specific states listed. It distinguishes from siblings by explaining the difference between single and bulk 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?

Provides clear guidance on when to omit 'item' for all banks or pass it for a single bank, and mentions bulk support with 'item_ids'. However, it does not compare with sibling tools like openfinance_list_connections.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by detailing the batch return shape ({ results, errors }) and the array limit (1-50), which are not covered by annotations. 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, front-loading the purpose, then listing key fields, then providing usage guidance and parameter details. Every sentence adds value with no redundancy.

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

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

Despite no output schema, the description covers return shape (fields and batch format), usage flow (after list loans), and parameter constraints. For a single-parameter read tool, this is complete.

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

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

Schema coverage is 0%, so the description compensates by specifying that loan_ids is an array of strings with a batch size limit of 1-50. This adds meaning beyond the schema's type definition, though it does not describe each item in detail.

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

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

The description clearly states it returns full loan contract detail by ID, lists specific fields returned, and distinguishes from sibling openfinance_list_loans by indicating it is for deep-diving on a specific contract. The verb 'get' and resource 'loan detail' are precise.

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 use after openfinance_list_loans for deep-diving, providing clear context. While it does not list exclusions or alternatives, the sibling tool name implies the list-before-detail pattern, making usage guidance adequate.

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

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

Annotations already mark as readOnly and idempotent. Description adds critical nuances: CREDIT balance meaning is connector-dependent, provider_incident may cause unreliable data, identity_notice requires deduplication. 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 well-organized and front-loaded with core purpose. Each sentence adds value, though some density may reduce readability. No redundancy.

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

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

No output schema, but description thoroughly explains return structure (accounts with fields, bank, connector_id, item_id) and error scenarios (provider_incident, identity_notice). Fully covers the tool's behavior for a list endpoint with 4 parameters.

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

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

Schema has 0% description coverage, but description compensates by explaining parameter usage (item for single bank, type filter, item_ids for batch) and their effects. Could be more structured but sufficient.

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

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

The description clearly states it returns accounts for bank connections with specific types (BANK/CREDIT) and includes fields like balance, number, type, subtype, bankData, creditData. It also distinguishes from sibling tools like openfinance_list_credit_card_bills by noting its limitations.

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 item (single bank) vs omit item (all banks), and when to use alternative tool for standardized bill amounts. Also provides guidance on interpreting provider_incident and identity_notice.

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?

Describes caching behavior and the single aggregated response nature. Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false; description adds valuable context about session caching and response structure without contradiction.

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

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

Three concise sentences covering purpose, fields, and response characteristics. 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, description fully explains return fields, caching, and relationship to update tool. Complete for a zero-parameter read 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?

No parameters (0), so baseline 4. Description correctly omits parameter info as 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?

Clearly states it returns Pluggy's transaction category taxonomy, cached for the session. Lists specific fields returned (id, description, descriptionTranslated, etc.) and distinguishes from sibling tools focused on other resources like accounts or transactions.

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

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

Provides guidance on using the returned categoryId for openfinance_update_transaction_category and prefers descriptionTranslated for pt-BR users. Lacks explicit when-not or alternative tools, but the context is helpful.

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

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral context: reconnect_url does not consume a connection slot and does not require disconnecting first. No contradictions with annotations.

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

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

The description is concise: two sentences, no redundancy. The first sentence clearly states the return values, and the second adds critical behavioral detail. Every sentence serves a purpose, and the most important information is front-loaded.

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

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

Given no output schema, the description adequately lists the key fields (connector_id, item_id, bank name, URLs). However, it omits potential details like pagination or sorting, but for a zero-parameter read-only list, this is sufficient.

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

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

The input schema has zero parameters, so the description carries full semantic weight. It adds meaning by detailing the return fields and the roles of reconnect_url and add_connection_url, which are not included in the schema.

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

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

The description clearly states that the tool returns saved bank connections with specific fields (connector_id, item_id, bank name, reconnect_url, add_connection_url). It distinguishes itself from sibling tools by explaining the unique reconnect_url behavior, making its purpose unmistakable.

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

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

The description provides specific scenarios for using reconnect_url (re-authentication, MFA, LOGIN_ERROR, stale data), but lacks explicit guidance on when to use this tool vs. alternative list tools (e.g., list_accounts, list_transactions). Usage context is implied but not fully clarified.

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 read-only, idempotent, non-destructive. Description adds behavioral context: payment allocation rules, connector asymmetry, open_bill derivation, and reliability warnings. 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?

Very long but front-loaded with core functionality. Every section adds necessary detail for the complex domain. Some redundancy could be trimmed, but overall efficient for the complexity.

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

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

With no output schema, the description fully explains return fields, derived values, and edge cases. Covers warnings, cross-tool references, and batch support. Highly complete.

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

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

Description adds meaning for account_id, account_ids, and include_open_bill beyond schema. However, page and page_size parameters are not described, leaving gaps. With 0% schema coverage, description partially compensates.

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

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

Clearly states it returns closed credit card bills for CREDIT-type accounts, lists key fields, and differentiates from sibling tools like openfinance_list_transactions and openfinance_get_credit_card_bill.

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

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

Provides explicit guidance on when to use, including the derived payment_status logic, cross-bank attribution warnings, and when to use alternative tools for itemized purchases.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description details error handling (returns {total:0, results:[], warning} instead of throwing on 403), and provides a comprehensive data integrity warning mechanism for mass zeroing, flagging suspect rows. This adds significant 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?

The description is lengthy and covers many details, but is front-loaded with the core purpose. The data integrity section is verbose and could be condensed 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?

Given no output schema, the description thoroughly explains the return structure (total, results, warning), field details, and the integrity warning flag. It also addresses error scenarios and the bulk execution mode, making the tool behavior fully understandable.

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 fails to explain individual parameters except briefly mentioning 'item_ids' for bulk. Parameters like 'item', 'page', 'type', and 'page_size' are left undefined, forcing the agent to infer their 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 it returns the investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.), and distinguishes from sibling tools like openfinance_list_accounts and openfinance_list_investment_transactions by focusing on the investment portfolio.

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 mentions bulk support via 'item_ids' for batched execution, indicating when to use that variant. However, it does not provide negative guidance (when not to use) or contrast with closely related tools like openfinance_list_investment_transactions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context by detailing the specific fields returned (quantity, value, amount, netAmount, etc.), which goes beyond annotations. However, it does not mention pagination behavior despite having page/page_size parameters.

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

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

The description is two sentences plus a line, with no wasted words. It is front-loaded with the core action and return data, then adds usage guidance and bulk support. Every sentence earns its place.

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

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

Given no output schema, the description compensates by listing many output fields. However, it lacks explanation of pagination (page, page_size) and does not mention error cases or behavior for invalid investment_id. For a tool with 4 parameters and 0% schema coverage, the description is adequate but incomplete on pagination.

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 document parameters. It mentions investment_id is needed from the prerequisite tool and implies investment_ids for bulk support, but page and page_size are completely undocumented. This leaves the agent without guidance on pagination, which is a significant 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, listing the types of movements and the fields returned. It distinguishes itself from sibling tool openfinance_list_investments by specifying it should be used after that tool to obtain the investment_id. The description also notes bulk support, making its scope clear.

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

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

The description explicitly says 'Use after openfinance_list_investments to get the investment_id,' providing a clear prerequisite and order of operations. It also mentions bulk support via investment_ids. While it doesn't explicitly state when not to use, the context is sufficient for correct 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?

Annotations already declare readOnly, idempotent, non-destructive. Description adds sequential fetching with rate-limit spacing and return format `{ results, errors }` per connection, providing extra 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?

Two concise sentences: first states purpose, second details parameter usage and return format. No superfluous 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?

Covers purpose, parameter usage with examples, behavioral traits, and return structure. Adequate for a simple list tool with one optional parameter and 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?

Schema has 0% description coverage. The description fully explains the only parameter `items` as an array of connection selectors (item_id, connector_id, connector_name) and its usage, compensating completely.

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

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

Clearly states it lists loan contracts per bank connection, referencing GET /loans. Distinguishes from sibling tools like openfinance_get_loan_detail (single loan) and openfinance_list_accounts (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?

Provides explicit guidance: pass `items` for specific connections, omit for all banks. Notes sequential querying with rate-limit spacing. Does not explicitly contrast with alternatives like get_loan_detail.

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 and idempotentHint. The description adds rich behavioral details: auto vs manual pagination, search_queries OR semantics, detail levels, error handling returns warning/error, provider_incident blocks, 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?

The description is long but well-structured, with logical sections. Some repetition (e.g., creditCardMetadata billId caveats mentioned twice) could be trimmed, 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?

Given 8 parameters, no output schema, and moderate complexity, the description is thoroughly complete, covering edge cases, error states, provider incidents, and cross-references to sibling tools.

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 exhaustively explains each parameter: detail levels, search_queries substring match, pagination parameters, account_ids for batching, and date formats. This compensates fully for the lack of 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 or CREDIT accounts, and uniquely for CREDIT accounts it is the only way to get itemized transactions. It distinguishes 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 extensive when-to-use guidance, including when NOT to sum by billId, alternatives for bill totals, pagination strategies, date range narrowing, and connection health checks.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral details beyond annotations: scanning caps at 5000 per account with a truncation flag, possibility of a provider_incident block that may make totals/rows incomplete, and bulk support. No contradictions with annotations.

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

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

The description is verbose but front-loaded with the core purpose. Each paragraph adds essential information for a complex tool with 9 parameters and multiple behaviors. Could be slightly more streamlined, but every sentence earns its place, making it efficient overall.

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 thoroughly explains the return structure: compact summary with totals, monthly evolution, top expenses/revenues, per-account breakdown, and raw mode options. It also covers provider incidents, truncation, and bulk support. This is highly complete for such a feature-rich tool.

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

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

Schema description coverage is 0%, so the description carries the full burden. It explains all 9 parameters: 'item' can be connector_id/connector_name/item_id; 'from'/'to' are ISO dates; 'granularity' options ('monthly' for compact summary, 'raw' for rows); 'detail' options with their effects; 'type' filters; 'top_n' implied; and 'item_ids' for bulk. This is comprehensive and goes well beyond what the schema alone provides.

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 performs consolidated cash-flow analysis for a whole bank connection in one call. It specifies the resource (transactions) and action (list/analyze), and distinguishes from sibling tools by noting users do not need to call openfinance_list_accounts first, implying a higher-level aggregated approach.

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: for 'análise anual/mensal', 'fluxo de caixa', etc. Provides guidance on when to omit the 'item' parameter to analyze all linked banks and when to set granularity to 'raw' for itemized rows. However, it does not explicitly name the sibling tool openfinance_list_transactions as an alternative for when only raw transactions are needed without aggregation, which is a minor gap.

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, covering safety. The description adds valuable behavioral details: it returns a global indicator, degraded components, open incidents, and a 'your_banks_affected' field that filters incidents relevant to connected banks. 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, relatively long sentence (approx. 70 words) that packs purpose, usage guidance, and return details. It is front-loaded with the core action. While efficient, it could be slightly more terse by splitting into multiple sentences for readability.

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

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

Given no output schema, the description fully explains the return values (global indicator, degraded components, open incidents, your_banks_affected). Together with annotations covering read-only/idempotent behavior and zero parameters, the description provides complete context for an agent to understand and 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?

The tool has zero parameters, and schema description coverage is trivially 100%. With 0 params, baseline is 4. The description does not need to add parameter semantics, and it does not attempt to, so this score is appropriate.

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

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

The description clearly states it checks the live operational status of the Open Finance provider, using the specific verb 'Checks' and resource 'LIVE operational status of the Open Finance provider (its public status page)'. It explicitly distinguishes from the sibling tool 'openfinance_get_item_status' by contrasting provider health vs. own connection health.

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

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

The description provides explicit when-to-use guidance: 'whenever data looks incomplete or stale even though a connection shows UPDATED'. It further explains the differential diagnosis benefit: distinguishing provider-side problems from connection issues. This clearly helps an agent decide when to invoke this tool over alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds behavioral detail: returns per-match fields, honors user plans, contains caveat warnings, and never dumps the catalog. While thorough, it does not mention pagination or response size limits, which would improve completeness.

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

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

The description is information-dense and front-loaded with the core action. It avoids fluff, but the length (multiple sentences) is justified by the complexity. Slightly tighter phrasing could improve conciseness, but it remains efficient.

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

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

Given no output schema, the description fully explains return values: connector id, access, audience, linked connections/accounts, and connect_url. It also covers the caveat behavior, plan filtering, and the hint on missing keywords. No critical gaps remain for an agent to use the tool effectively.

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

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

With 0% schema coverage, the description must explain parameters. It does: keywords is required (despite schema lacking 'required'), described as an array of strings; include_accounts controls account inclusion. It clarifies that omitting keywords returns a hint. The description compensates well but lacks format examples or constraints (e.g., case sensitivity).

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

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

The description clearly states the tool searches bank connectors by name and enumerates the returned fields (connector id, access, audience, linked connections/accounts, connect_url). It specifies the scope ('never dumps the whole catalog') and distinguishes from sibling tools by advising to call before connecting.

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

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

Explicitly instructs to call before connecting, warns that keywords are required (otherwise returns a hint), explains how the tool handles plan filtering, and advises surfacing caveats to guide users toward Open Finance connectors for automation. No reference to alternative tools is needed given the clear context.

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

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

With annotations only providing readOnlyHint=false, the description adds critical behavioral context: overriding automatic categorization, creating Category Rules for future similar transactions, and batch error handling (per-item errors do not fail whole batch). This fully informs the agent of side effects.

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

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

The description is front-loaded with purpose and efficient, though slightly verbose with behavioral details. Every sentence earns its place, but a minor restructuring could improve readability.

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

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

Given the batch nature with side effects and no output schema, the description comprehensively covers usage, parameter sources, behavioral impact, and response shape. It leaves no critical gaps for agent 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?

Despite 0% schema description coverage, the narrative explains the `items` parameter structure, required fields, and provides source tools for valid IDs. This adds meaning beyond the raw schema, enabling correct parameter construction.

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: 'Corrects the category of one or more transactions' with a specific verb and resource. It distinguishes from sibling tools by referencing related list tools for input IDs and implying this is the only categorization correction tool.

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

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

The description provides clear context for when to use: 'to fix miscategorized transactions and improve categorization accuracy going forward.' It lacks explicit when-not-to-use guidance but effectively sets expectations about side effects (creating category rules).

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 non-destructive and idempotent behavior. The description adds the need to include conversation context but does not elaborate on authentication, rate limits, or what happens after submission. It neither contradicts nor substantially enriches the annotation information.

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 filler. The first sentence immediately states the purpose, the second provides key usage instruction. Every word is functional.

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 no output schema, the description sufficiently covers what the tool does and what information to provide. It could mention if a confirmation response is sent, but overall it is complete enough for an agent to use correctly.

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

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

Schema coverage is 0%, so the description must compensate. It explains the conversation parameter's purpose ('recent messages for reproduction') but does not clarify 'context' or 'message' beyond their names. This partial coverage raises it from baseline 1 to 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 explicitly states three use cases (bug, missing feature, feedback) with a clear verb 'report' and identifies the resource. It distinguishes from all sibling tools, which are unrelated to bug reporting.

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?

Advises to include the conversation array for reproduction, which is helpful context. While it doesn't explicitly exclude alternative uses or state when not to use, the sibling set contains no other feedback tools, so the guidance is clear enough.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is clear. The description adds no further behavioral context (e.g., network dependency, caching). Given annotation coverage, a 3 is appropriate.

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 with no extraneous words. Efficiently communicates the tool's 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 zero-parameter, read-only tool with no output schema, the description covers the core purpose. Could specify the exact version format, but not critical for such a simple operation.

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

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

Schema has zero parameters and 100% coverage. The description doesn't need to add parameter info. Baseline 3 for high schema coverage with no params.

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

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

The description uses a specific verb 'show' and resource 'MCP platform and adapter versions', clearly distinguishing from sibling tools like toolkit_info or openfinance_provider_status. It is unambiguous about what it does.

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 guidance on when to use this tool versus alternatives. Siblings include other info tools, but no criteria are provided to choose between them.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context about what is returned (installed MCPs, connection status, catalog counts), which goes beyond the annotations' safety profile.

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

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

The description is a single, concise sentence that front-loads the purpose and includes all key details without any 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?

For a simple read-only info tool with no output schema, the description fully explains what the tool returns. No additional context is needed given the low complexity and complete annotation coverage.

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 the baseline is 4. No parameter information is needed in the description, and the 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?

The description clearly states the tool returns the current toolkit state, including installed MCPs, connection status, and catalog tool counts. It uses a specific verb ('returns') and resource ('toolkit state'), and the details distinguish it from sibling tools that focus 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 does not explicitly state when to use this tool or when to avoid it. As a read-only info tool, usage is implied but no alternatives or exclusions are mentioned.

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