Banco Bmg MCP

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

Description adds context beyond annotations: explains idempotent behavior (no args returns link), session-only vs permanent, and no destructive effects. 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?

Two sentences, efficient but the second is dense with instructions. Could be slightly clearer with bullet points, but still 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?

For a simple 1-param optional tool, description covers all usage scenarios (permanent config, session token, no-arg link). No output schema needed; return value implied.

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

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

With 0% schema description coverage, description fully compensates by explaining the token parameter: its source (JWT from browser), optionality, and effect when provided or omitted.

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 handles authentication for IDE agents, explaining two login methods (permanent via config, session via token) and a no-arg call to get a link. Verb 'authenticate' is specific and distinct from 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?

Explicitly explains when to use each method: permanent vs session-only login, and mentions adding token to config as an alternative. Provides clear context for use.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, so bar is lower. Description adds value by explaining return states (authenticated:true vs connect_urls) and that pending[] is empty when connected. 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 efficient sentences: first gives the main purpose, second adds critical behavioral details. 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 zero-parameter read-only tool, the description fully explains return values in both main scenarios. No output schema needed as description covers it.

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

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

No parameters exist, so schema coverage is 100%. Description doesn't need to explain parameters; it focuses on the tool's behavior, which is 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 the tool 'returns connection status and URLs' with specific behavioral details for two scenarios: all providers connected vs missing credentials. This distinguishes it from siblings like 'authenticate' which handles auth flows.

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 implicitly indicates when to use (e.g., to check connection status before other operations) but does not explicitly state when not to use or compare to alternatives. The context is clear enough given sibling names.

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 can invoke tools even if not installed (one-off), returns connect/checkout links for credentials or payment, makes install permanent, and requires admin for writes. This adds significant context beyond the readOnlyHint and destructiveHint flags.

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 every sentence adds value. It front-loads the core purpose and then details actions. While it could be more structured (e.g., bullet points), it remains clear and efficient given the complexity.

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

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

Given the tool's complexity (13 parameters, many actions, openWorldHint annotation, no output schema), the description is remarkably complete. It covers core flows, credential/payment handling, privilege requirements, and distinguishes between one-off and permanent 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?

With 0% schema description coverage, the description carries full burden. It explains key parameters like action, tool_id, arguments, and mentions invoke/install semantics. However, some parameters like immediate, tier_slug, conversation, request_name, report_context, request_details are not explicitly defined, though their purpose can be inferred from context.

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 and catalog of MCPs/tools, and the way to run them. It explicitly says to use this tool first before any external registry, distinguishing it from sibling tools like openfinance tools or authenticate.

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

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

The description provides explicit guidance on when to use this tool ('use THIS tool FIRST') and contrasts actions: invoke vs install, subscribe/cancel, report_bug, request_mcp. It explains when to use each action and mentions prerequisites like workspace owner/admin for writes.

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

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

Description adds value beyond annotations by specifying that data becomes unavailable and hints at reconnection via returned URL. Annotations already declare destructiveHint=true, so the description reinforces the behavior 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?

Extremely concise at 24 words, front-loaded with the core action, and includes essential return value information. No superfluous content.

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

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

Adequate for a simple destructive tool with annotations covering the safety profile. However, lacks explanation of the parameter and any conditions or error handling, leaving gaps for effective 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?

The sole parameter 'item' is not explained in the description; schema coverage is 0%. The description vaguely mentions 'a specific bank' but does not map to what 'item' represents (e.g., bank connection ID). This is a significant gap for a 1-parameter tool.

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

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

Description clearly states the tool revokes consent and deletes connection data for a specific bank, with an explicit return value. However, it does not differentiate from sibling tools or clarify the ambiguous 'item' parameter.

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 (e.g., other openfinance tools). The description implies it's for disconnecting a bank but lacks when-not-to-use or prerequisite conditions.

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 the underlying mechanism (PATCH then polls up to ~60s), the effect on lastUpdatedAt and synced, and edge cases like needs_action (LOGIN_ERROR) and timed_out. Although annotations set readOnlyHint=false, the description adds crucial behavioral context (polling, error states, return format). 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 information-dense but well-structured: core action, usage scenario, parameter details, return format, edge cases. It uses bold for emphasis and front-loads the key verb. Slightly long but 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?

Given the tool's complexity (sync with polling, optional parameters, multiple result fields, error states), the description is fully self-contained. It explains return structure (results, errors), each result's fields, and how to handle timed_out and needs_action. No output schema exists, so this completeness is essential.

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 fully explains both parameters: items is an array of selectors (item_id, connector_id, connector_name) and omitting it syncs all; wait is boolean for synchronous or fire-and-forget. This compensates completely for the schema's lack of 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 uses a specific verb ('forces... to re-sync') and clearly identifies the resource ('one or more connections' or 'ALL linked banks'). It distinguishes this tool from siblings like openfinance_disconnect_bank by stating it pulls fresh data 'WITHOUT disconnecting/reconnecting'. The purpose is 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?

Explicitly states when to use ('when a balance or transaction list looks stale') and what it avoids ('WITHOUT disconnecting/reconnecting'). Provides alternatives: if timed out, 're-check with openfinance_get_item_status'. Also explains behavior when omitting items (sync all) and the wait parameter (fire-and-forget).

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, but the description adds behavioral detail about CREDIT accounts possibly returning a BALANCE_FETCH_ERROR with a structured warning instead of throwing. It also outlines the response shape with results and errors arrays, providing transparency beyond the annotations.

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

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

The description is three sentences, each serving a distinct purpose: purpose statement, input guidance, and error/response explanation. It is front-loaded with the main action and avoids any filler or redundancy.

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

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

Given one parameter, no output schema, and good annotations, the description covers purpose, input constraints, error behavior, and response shape. It does not detail the 'balance payload' contents, but that is standard and not critical. Overall, it provides sufficient context for successful tool invocation.

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

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

With schema description coverage at 0%, the description compensates by stating 'Pass `account_ids` as an array (1–50)'. This clarifies the data type (array of strings), size constraint, and that the IDs correspond to account identifiers. This adds essential meaning missing from the schema.

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

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

The description explicitly states 'Returns real-time balance payload per account id' and includes the HTTP endpoint (GET /accounts/:id/balance). It specifies the verb (returns) and resource (balance payload), clearly distinguishing from tools like openfinance_list_accounts which list accounts rather than fetch balances.

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 gives input constraints (array size 1–50) and mentions error handling for CREDIT accounts, but does not explicitly state when to use this tool over siblings like openfinance_get_accounts_detail or openfinance_list_transactions. The context of when not to use it is missing, though the purpose is clear enough for an informed agent.

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 useful context beyond annotations: batch constraints (array 1-50), return shape with results/errors, and extended creditData inclusion. 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?

Three efficient sentences with no fluff; front-loads the purpose and provides clear usage and return shape.

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 essential usage but lacks details on the return structure (e.g., fields in results, error format); adequate given low complexity but not fully complete.

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

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

With 0% schema description coverage, the description compensates by specifying the parameter as an array of 1-50 items and its purpose, adding crucial constraints beyond the raw schema.

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

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

Clearly states it returns full account objects with extended creditData per ID, and explicitly distinguishes from the list sibling by focusing on detailed batch 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?

Implies usage for batch detail retrieval but does not explicitly state when to use over list or alternatives, nor does it mention exclusions.

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. Description adds batch shape, note on Pluggy not returning paid/status, and cross-reference for paid status check. 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?

Well-structured with front-loaded purpose, exclusions, usage steps, and behavioral notes. Some redundancy could be trimmed, but each 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?

Given no output schema, description explains return shape ({ results, errors }) and key fields (financeCharges, payments[] with subfields). Addresses payment interpretation nuance. Complete for a single-param 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?

Only one parameter (bill_ids) with 0% schema coverage. Description explains it's an array, how to obtain IDs via another tool. Adds practical usage context, though could be more explicit about ID format.

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 bill-level detail for credit card bills by ID, distinguishes from listing transactions and sibling tools. Verb+resource is specific.

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

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

Explicitly instructs to use openfinance_list_credit_card_bills first to discover IDs, and to use openfinance_list_transactions for itemized transactions. Also warns about payments[] interpretation.

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, covering safety. The description adds context on return format (single object vs. {count, items}) and lists possible status values, providing behavioral insights beyond the annotations.

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

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

The description is a single, front-loaded sentence with no unnecessary words. Every part adds value, making it highly concise and 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 tool's simplicity (one optional parameter, no output schema), the description fully covers both use cases and the return format. No additional information is needed for an agent to use it correctly.

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

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

The schema has 0% description coverage for the 'item' parameter, but the description fully compensates by explaining that omitting returns all banks and passing returns a single bank, adding critical semantic meaning.

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

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

The description clearly specifies the tool returns the current status of a bank connection with possible values (UPDATED, UPDATING, LOGIN_ERROR, etc.), along with executionStatus and connector metadata. It distinguishes between querying all banks or a single bank, making the purpose unmistakable.

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

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

The description explicitly instructs when to omit versus pass the 'item' parameter, with clear return format details. It does not mention when not to use this tool or alternatives like openfinance_list_connections, but the guidance for the two use cases is sufficient.

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

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds crucial behavioral details: response aggregation behavior, the meaning of `name` vs `bank`, and connector-dependent balance interpretation for CREDIT. 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 dense but well-organized: starts with purpose, then field details, then usage guidance, then warnings. Every sentence adds value, though it could be slightly trimmed 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?

Despite having only 2 optional parameters and no output schema, the description explains output structure, field semantics, cross-connector behavior, and references a sibling tool for deeper credit data. Fully adequate for an AI agent to invoke correctly.

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

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

Schema has two parameters (item, type) with 0% description coverage. The description thoroughly explains both: `item` usage for single vs all banks, `type` for filtering. Also explains output fields which clarify parameter purpose.

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

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

The description clearly states the verb (returns) and resource (accounts for a bank connection), specifies account types (BANK/CREDIT) and fields (balance, number, type, subtype, bankData, creditData). It distinguishes itself from sibling tools like openfinance_list_credit_card_bills and openfinance_list_accounts_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?

Explicitly explains when to omit `item` (to list across all banks) versus passing `item` (target a single bank). Warns against treating CREDIT balance as monthly bill and directs to openfinance_list_credit_card_bills for standardized open-bill amounts and total debt.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable context: caching per session, single aggregated response. 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, front-loaded with the main action. Each sentence adds specific value: source, caching, field details, usage hint. 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 fully explains the return fields and their purpose. It covers caching, session scope, and ties to a sibling tool. Complete for a simple 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?

No parameters exist, so schema coverage is 100%. The description adds no param info but explains the output fields, which is sufficient. Baseline 4 for zero-parameter tools.

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

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

The description clearly states it returns the transaction category taxonomy, specifying the source (GET /categories) and detailing each field. It distinguishes from siblings by explicitly linking to openfinance_update_transaction_category via the id field.

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 when needing category taxonomy for update operations, and notes 'no batch ids' to set expectations. However, it does not explicitly state when not to use or provide alternatives, though alternatives are limited.

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 context about returned fields and a connection URL, but does not disclose further behavioral traits beyond what annotations provide.

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

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

The description is a single sentence, front-loaded with the purpose, and contains no redundant words. It efficiently conveys the necessary 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 zero-parameter, read-only tool with clear annotations, the description fully covers what an agent needs: what is returned and a noteworthy detail (add_connection_url). No gaps.

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

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

No parameters exist, so the description naturally cannot add parameter semantics. It compensates by listing return fields, which is helpful given zero parameters.

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

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

The description clearly states the verb 'returns' and the resource 'saved bank connections', listing specific fields (connector_id, item_id, bank name, add_connection_url). This distinguishes it 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?

The description implies usage for listing connections but provides no explicit when-to-use guidance or comparisons to siblings. No exclusions or alternatives 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds deep behavioral details: payment cycle rules, derived payment_status logic, open_bill availability with reason, and warning instead of failure. 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 very long (multiple paragraphs) and information-dense. While well-structured with bolded key terms, it could be more concise. Every sentence adds value, but the length may reduce readability for an agent.

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 thoroughly documents return fields: payments array with fields, payment_status, open_bill structure, future_bills, and warning behavior. Explains edge cases like PAST_DUE_UNCONFIRMED and connector asymmetry. Complete for a high-complexity 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 description must compensate. It explains account_id, account_ids (bulk), include_open_bill (boolean with full rationale). However, page and page_size parameters are not explicitly described (though names are self-explanatory). Missing details on defaults or constraints slightly lower score.

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

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

The description explicitly states it returns CLOSED credit card bills for a CREDIT-type account, listing key fields and derived payment_status. It distinguishes from sibling tools like openfinance_get_credit_card_bill (singular) and openfinance_list_transactions (itemized).

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

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

Provides explicit when-to-use guidance: explains opt-in open_bill parameter (expensive), warns about Connector Asymmetry, and gives alternative for itemized transactions ('use openfinance_list_transactions'). Also clarifies that results are bill-level summaries, not individual 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 mark it as read-only and idempotent. The description adds value by detailing error return structure (warning object on 403 or other errors) and listing specific fields returned (balance, amount, rates, etc.), providing context beyond annotations.

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

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

The description is a single, well-structured paragraph. It front-loads the main purpose and lists key details without redundancy. 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?

The description provides good detail on output fields and error behavior, but completely omits parameter documentation. Given the tool has no output schema and 4 parameters, the description should explain parameters to be fully complete.

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

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

With 0% schema description coverage, the description must explain parameters, but it does not mention any of the four parameters (item, page, type, page_size). The agent must infer their meaning from names alone, 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 returns the investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.). This specificity makes it easy to distinguish from siblings like openfinance_list_investment_transactions, which deals with transactions rather than portfolio overview.

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 implies usage for connections with INVESTMENTS product enabled and mentions graceful error handling (returns warning instead of throwing). However, it does not explicitly state when not to use or direct to alternatives like list_investment_transactions for transaction-level data.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. Description adds details about returned fields and bulk execution. No contradiction. Could mention pagination behavior.

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 with two sentences plus a line about bulk support. Front-loaded with purpose. Could be slightly more structured, but 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, description details return fields and types. Covers pre-step (list_investments) and bulk capability. Pagination is in schema but not described. Overall 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%, but description explains the key parameter investment_id and the bulk parameter investment_ids. However, it does not explain page and page_size pagination 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, listing transaction types and fields. It distinguishes from siblings like openfinance_list_investments by specifying use after that call to obtain the investment_id.

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

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

Provides clear sequencing guidance ('Use after openfinance_list_investments') and mentions bulk support. However, does not explicitly state when not to use or compare to alternatives like openfinance_list_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 indicate read-only and idempotent. Description adds that queries are sequential with rate-limit spacing and returns per-connection results/errors, providing rich behavioral detail beyond annotations.

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

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

Three sentences: purpose, detailed usage, omission behavior. Front-loaded and no unnecessary 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?

Covers main aspects: purpose, parameter behavior, return format, and execution detail. No output schema, but description includes return structure. Lacks edge cases like invalid selectors.

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 for the items parameter (0% coverage). Description explains that items is an array of connection selectors (item_id uuid, connector_id, or connector_name), adding crucial meaning. However, it does not detail the format of these selectors.

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 'Lists loan contracts per bank connection (GET /loans).' This is a specific verb and resource, distinguishing it from sibling list tools like list_accounts and 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?

Provides detailed usage for the items parameter (when to pass it vs omit), but does not explicitly compare to alternatives or state when not to use. Usage is implied but lacks exclusion 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 indicate readOnlyHint=true and idempotentHint=true. Description adds extensive behavioral details: date filters, pagination, keyword search behavior (aggregation, truncation), error returns, detail levels, and dependency on bank connector. 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 lengthy but well-organized, front-loading the primary purpose and then covering specific details. Every sentence adds value, though it could be slightly more concise with subheadings. Still, it earns a 4 for effective communication.

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 (8 params, no output schema) and the need to cover edge cases, the description is remarkably complete: it explains pending/posted behavior, connection health checks, error handling, and cross-references other tools like openfinance_list_credit_card_bills and openfinance_get_item_status.

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

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

Despite 0% schema description coverage, the description fully explains each parameter: account_id (required), from/to (ISO format), page/page_size (max 500), detail (three levels with use cases), search_queries (OR semantics, aggregation), and account_ids (bulk). Provides format, constraints, and 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 'Returns transactions for a bank account (BANK or CREDIT type)' and distinguishes itself from siblings like openfinance_list_credit_card_bills for bill totals and openfinance_list_transactions_by_item.

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 this tool (e.g., 'for CREDIT accounts, this is the ONLY way to get itemized transactions'), when to use alternatives (e.g., 'To get a standardized open-bill total... use openfinance_list_credit_card_bills'), and provides extensive context on filtering, pagination, error handling, and bulk support.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds important behavioral context: internal account resolution, default compact summary vs raw rows, transaction caps at 5000/account with truncation flag, and mentions heaviness of raw mode. 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 fairly long but well-structured with distinct sections: purpose, parameter explanations, use cases, and behavioral notes. Every sentence adds value; no fluff. Slightly verbose but appropriate for the tool's 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 adequately describes return values: compact summary includes total entradas/saídas/saldo_liquido, monthly evolution, top despesas/recebimentos, per-account breakdown. Raw mode returns consolidated transactions. Truncation behavior is noted. Could be improved by explicitly listing the output structure for raw mode, but 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?

Schema description coverage is 0%, so the description carries full burden. It explains all 7 parameters: `item` (connector_id, name, or item_id; optional for all banks), `from`/`to` (ISO dates), `granularity` (monthly vs raw with compact summary vs all rows), `detail` (compact, rich, raw with enrichment details), `type` (BANK/CREDIT filter), and `top_n`. Interactions between granularity and detail are 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 performs consolidated cash-flow analysis for a whole bank connection in one call, specifying the exact resource (bank connection) and action. It explicitly distinguishes from siblings like openfinance_list_accounts by stating there is no need to call that 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 provides explicit when-to-use guidance, including use cases like 'análise anual/mensal' and 'fluxo de caixa'. It explains when to omit `item` for all banks, when to use raw granularity, and contrasts with alternatives by saying 'do NOT need to call openfinance_list_accounts first'.

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

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

The description adds behavior beyond annotations: it explains what the tool returns (global indicator, degraded components, open incidents, affected banks). It does not contradict annotations (readOnlyHint, idempotentHint, destructiveHint are consistent).

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

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

The description is a single sentence but well-structured and front-loaded with the main purpose. It is concise, but could be slightly more readable with sentence breaks. However, it earns its place without fluff.

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

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

Given no output schema, the description thoroughly explains the output: global indicator, degraded components, open incidents, and affected banks. This provides sufficient context for the agent to understand the tool's results.

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 the description does not need to add parameter meaning. Schema coverage is 100% (no params to cover). The description is still clear about the tool's function.

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, distinguishing it from the sibling tool `openfinance_get_item_status`. The verb 'checks' and the 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 explicitly states when to use this tool: when data looks incomplete or stale even though the connection shows UPDATED. It also clarifies it is separate from checking the connection's own status, providing clear guidance on when not to use it.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive nature. The description adds behavioral context: returns ready connect_url, honors plan, and behavior when keywords missing. 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 a single paragraph that is front-loaded and concise. It includes all necessary details without redundancy. Minor improvement could be to split into clearer sections.

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 only 2 parameters and no output schema, the description fully covers functionality, return values, usage context, and constraints. It is complete for the tool's purpose.

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

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

Despite 0% schema description coverage, the description explains both parameters: keywords (array of strings, example values) and include_accounts (boolean). However, it states 'keywords[] is REQUIRED' while schema shows no required properties, introducing slight inconsistency.

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 'Searches' and the resource 'bank connectors', with specific details on what is returned (connector id, access, audience, etc.). It distinguishes itself from sibling tools like 'connect' by explicitly stating 'Call this 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?

Provides explicit guidance: 'Call this BEFORE connecting to hand the user a one-click link to the right bank.' Also notes that keywords[] is required and what happens if omitted ('returns a hint, never dumps the whole catalog'), and that it honors user's plan.

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 only provide readOnlyHint=false and destructiveHint=false. The description goes far beyond: it reveals that the tool overrides automatic categorization AND creates a Category Rule (case-insensitive exact match), affecting future similar transactions. It also describes batch error handling ('per-item errors do not fail the whole batch') and the response shape. This is comprehensive behavioral disclosure.

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

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

The description is a single paragraph but dense with information. Every sentence adds value, from the HTTP method to side effects to error handling. It could be slightly better structured (e.g., bullet points for the batch shape), but it is not verbose and is easy to parse for an AI agent.

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

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

The description covers all key aspects: input sources, side effects (creating rules), batch behavior, error handling, and response shape (`{ updated, results, errors }`). Given no output schema, this is thorough. The tool complexity is moderate, and the description leaves no major gaps.

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

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

Schema description coverage is 0%, so the description carries full burden. It explains that `items` is an array of objects with `transaction_id` and `category_id`, and crucially, it tells the user where to source these IDs (from other tools). This adds essential meaning beyond the raw schema, which only defines types and requirements.

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 'Corrects the category of one or more transactions (PATCH /transactions/:id).' This provides a specific verb and resource, and the context of 'fix miscategorized transactions' distinguishes it from sibling listing tools (e.g., openfinance_list_transactions, openfinance_list_categories). No ambiguity.

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 clearly specifies how to format the `items` array and where to obtain the IDs ('transaction_id comes from openfinance_list_transactions, category_id from openfinance_list_categories'). It also states the use case: 'use this to fix miscategorized transactions and improve categorization accuracy going forward.' It lacks an explicit 'when not to use' or alternative, but the guidance is sufficient given there are no sibling update tools.

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

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

Description adds no behavioral context beyond annotations. Annotations indicate idempotentHint=true, which contradicts the likely non-idempotent nature of reporting, creating a potential 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?

Two clear sentences, no fluff. Could benefit from more structure or a title, but effective for its 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 3 parameters with no schema descriptions, no output schema, and sibling context, the description lacks completeness. Does not explain return values or parameter usage beyond a single hint.

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%. The description only mentions 'conversation' but does not explain its format or the other parameters (message, context). Provides marginal help.

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 the verb 'Report' and resources 'bug, missing feature, or send feedback'. Differentiates from sibling tools which are all Open Finance related, so it stands out.

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

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

Provides a hint to include conversation array for reproduction, but no explicit when-to-use or alternatives. Adequate but not explicit.

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, fully covering the behavioral safety profile. The description adds the specific domain of version info but no further behavioral traits beyond the annotations.

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

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

The description is a single succinct sentence that front-loads the purpose with no extraneous words.

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

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

Given the simplicity of the tool (no parameters, clear annotations), the description sufficiently conveys its functionality. No output schema exists, but the output is inherently understood as version strings.

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 description does not need to add parameter details. Baseline score of 4 applies per rubric for no-parameter tools.

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

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

The description clearly states the tool shows current MCP platform and adapter versions, using a specific verb and resource. It is distinct from sibling tools which are mostly openfinance operations or authentication.

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

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

No guidance on when to use this tool versus alternatives is provided. The description merely states what it does without any context or exclusions.

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 specifying the exact content of the return value (installed MCPs, connection status, catalog counts), providing behavioral context beyond annotations. 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?

Single sentence with no wasted words. It is front-loaded with the main action and includes specific details. Every word contributes to 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 zero parameters and no output schema, the description fully covers what the tool returns. No additional details are needed for an agent to correctly invoke and interpret results.

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

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

Tool has no parameters, so schema coverage is 100%. According to guidelines, baseline is 4. The description correctly adds no extraneous 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?

The description clearly states the tool returns 'current toolkit state' with specific details: installed MCPs, connection status, and catalog tool counts. It uses a specific verb 'Returns' and resource 'toolkit state', and distinguishes from siblings which focus on operations like authentication or Open Finance queries.

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

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

The description implies appropriate use for inspecting toolkit state. It lacks explicit exclusions or alternatives, but given the tool's simplicity and zero parameters, the intended context is clear. Siblings cover different functionalities, so no confusion arises.

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