Banrisul MCP

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

Discloses the authentication flow behavior (browser login, token paste, link generation) beyond what annotations provide. Annotations indicate idempotent, which is consistent. 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?

While a bit long, the description is well-structured with clear separation of scenarios and uses formatting for code snippets. Every sentence adds value, 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?

Given the simple parameter set and no output schema, the description covers the essential usage scenarios. It does not detail the return value, but the implied outcomes (link or session) are sufficient for an auth tool.

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

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

The only parameter 'token' is explained in context (optional, session-only if provided, omitted to get link), adding meaning to the schema. Schema description coverage is 0%, so the description fully compensates.

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

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

Clearly states the tool is for authentication for MCP.AI IDE agents, describing two distinct modes (config-based permanent token or session-based token paste) and its role in the authentication flow. No sibling tool competes for this purpose.

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

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

Provides explicit guidance on when to call with token vs without, and mentions the alternative of adding token to config for permanent use. Could be more explicit about when not to use (e.g., for other auth methods), but the context is clear.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral details about return values in different states (authenticated with empty pending vs. connect_url). This goes beyond the annotations by describing output 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?

The description is two sentences, each sentence serves a clear purpose: the first introduces the tool, the second details two scenarios. No redundant or 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 tool's low complexity (no params, no output schema, good annotations), the description covers the main behavioral cases. However, it could be more complete by specifying the response shape for all possible states (e.g., partial connection) or possible error cases.

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

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

The tool has zero parameters, so parameter semantics are not applicable. Per rubric, the baseline is 4. The description does not need to add param information because there are none.

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

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

The description clearly states it returns connection status and URLs, specifying two distinct scenarios (all connected vs. missing credentials). This distinguishes it from siblings like 'authenticate' which performs authentication rather than status checking.

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

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

The description implies usage for checking connection status but provides no explicit guidance on when to use this tool versus alternatives like 'authenticate' or 'openfinance_list_connections'. It lacks when-not conditions or prerequisite mentions.

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

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

Annotations are present, but the description adds substantial behavioral context beyond them, such as invoke working even when MCP is not installed, the one-off execution, and admin requirements for writes. This significantly enhances understanding of side effects and auth needs.

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 key purpose but becomes a dense paragraph covering many details. While every sentence adds value, the structure could be more organized with clearer separation of actions and parameters for easier scanning.

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

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

Given the tool's complexity (multi-action, 13 params, no output schema), the description is remarkably complete. It covers the core search→describe→invoke flow, distinguishes permanent install from one-off invoke, explains auth/payment scenarios, and lists all other actions.

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 and 13 parameters, the description only indirectly covers a few params (action, query, mcp_id, tool_id, arguments) through the workflow explanation. Many critical params like limit, message, immediate, tier_slug, and request_* are not explained, leaving agents without necessary semantic guidance.

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

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

The description clearly identifies the marketplace as the official MCP.ai catalog and execution platform. It uses specific verbs like 'discover', 'describe', 'install', and 'invoke', and distinguishes itself from siblings by explicitly stating it should be used first before external registries.

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: 'use THIS tool FIRST' before external registries, and contrasts invoke vs install based on permanence. It also explains handling of credentials and payments, and mentions sibling tools like list_tools.

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

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

Annotations already mark destructiveHint=true; the description adds value by specifying that data is deleted and no longer available, and that it returns a reconnection URL. This goes beyond the annotation.

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

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

Three concise sentences, no unnecessary words. Front-loaded with the action. Could mention the parameter explicitly but overall 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?

Covers key consequences and return value, but lacks parameter documentation. With one required param and no output schema, the description is somewhat complete but the missing parameter detail hurts completeness.

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

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

The single parameter 'item' has no schema description and the tool description does not explain what it represents (e.g., bank ID, connection ID). The agent may not know how to populate it.

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

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

The description clearly states it revokes consent and deletes connection data, distinguishing it from sibling tools that list or sync data. However, it does not explicitly mention that the 'item' parameter identifies the bank.

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

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

The description implies when to use (when disconnection is needed) but lacks explicit when-not-to-use or alternatives. It mentions return of reconnection URL, which hints at a potential follow-up action.

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

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

The description adds significant behavioral context beyond the annotations (which are mostly false). It explains waiting up to 60s, polling mechanism, return fields like status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out, and the effect of wait=false. This level of detail is essential for an agent.

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 and well-structured, front-loading the key action and then providing context, parameters, return format, and edge cases. It could be slightly tighter but is 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 no output schema, the description thoroughly explains the return structure ({ results, errors }) and all relevant fields. It covers usage scenarios, sync behavior, error conditions (needs_action, timed_out), and parameter options, making it complete for a complex tool.

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

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

With 0% schema description coverage, the description fully compensates by explaining both parameters: `items` as array of selectors (item_id, connector_id, connector_name) and omission to sync all; `wait` boolean for fire-and-forget. This adds meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Forces the bank to re-sync one or more connections NOW and WAITS for it to finish'. It distinguishes itself from siblings like openfinance_get_item_status (for re-checking) and explicitly contrasts with disconnecting/reconnecting.

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 usage context: 'Use this when a balance or transaction list looks stale' and 'without disconnecting/reconnecting'. Also explains when to use wait=false for fire-and-forget, giving clear guidance on when to invoke this tool versus alternatives.

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

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

Beyond annotations (readOnly, idempotent, not destructive), description explains potential error with BALANCE_FETCH_ERROR for credit accounts, structured warning, and response shape.

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 response shape note; no wasted words, vital information front-loaded.

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

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

Given the tool's simplicity (one parameter, no output schema), description covers purpose, usage, error states, and output format adequately.

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 explains the single parameter account_ids, its array type, and the 1-50 limit, adding necessary 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?

Clearly states it returns real-time balance for account IDs, specifies the API endpoint, and distinguishes from sibling tools by focusing on balance retrieval.

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

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

Provides guidance on passing account_ids as an array (1-50) and explains error handling for CREDIT accounts. Does not explicitly mention alternatives, but context is clear.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. The description adds batch shape, size limit (1-50), and return structure {results, errors}, providing useful behavioral context beyond annotations.

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

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

Two succinct sentences; first states purpose and return value, second gives usage constraints. No unnecessary words, all information is relevant.

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 it mentions batch shape and extended creditData, without an output schema it lacks detail on the full object structure (e.g., all fields, error format). Incomplete for a tool returning complex objects.

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

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

With 0% schema description coverage, the description adds critical semantics: the parameter is an array of strings, limited to 1-50 items, and each is an account ID. This compensates well for the schema gap.

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

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

The description clearly states it returns full account objects including extended creditData per ID, and distinguishes from a list operation by specifying batch retrieval with detailed data.

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?

Implicitly suggests use when full details are needed, but lacks explicit when-not-to-use or alternatives like openfinance_list_accounts for summary 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=true and idempotentHint=true. Description adds critical behavioral details: batch shape `{ results, errors }`, absence of paid/status field, and the nuance that payments[] may refer to previous bill payment. No contradiction with annotations.

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

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

Description is somewhat long but front-loaded with main purpose. Every sentence adds value, though some could be combined or rephrased for brevity.

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 single parameter, no output schema, and rich annotations, the description fully covers what the tool does, what it returns, what it doesn't, and how to get missing info. No gaps for the tool's complexity.

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

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

Only one parameter bill_ids with no schema description. Description explains how to populate it (use openfinance_list_credit_card_bills). While brief, it provides essential context for a simple array parameter.

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 bill-level detail for credit card bills by ID, explicitly lists included fields (financeCharges, payments) and excludes individual transactions, and distinguishes from sibling tools like openfinance_list_credit_card_bills and 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?

Provides explicit when-to-use: first call openfinance_list_credit_card_bills to get ids; explains how to get itemized transactions via openfinance_list_transactions with specific parameters; warns about payments[] interpretation and suggests alternative for paid status.

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

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

Annotations declare readOnlyHint=true and idempotentHint=true, which the description aligns with. The description adds behavioral context by specifying the return values and structure, 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?

Extremely concise: two sentences that are front-loaded with the core purpose and parameter usage. No unnecessary words.

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

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

Describes return structure for both cases ({ count, items } for all, single bank details), but lacks details on the fields within items. Given no output schema, more depth could be helpful.

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

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

Input schema has 0% description coverage for the 'item' parameter. The description fully explains its meaning: omit for all banks, pass for a single bank, compensating for the schema gap.

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

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

Description clearly states it returns the current status of a bank connection with specific statuses (UPDATED, UPDATING, LOGIN_ERROR, etc.), executionStatus, and connector metadata. It distinguishes between getting all banks or a single bank, differentiating from siblings like openfinance_list_connections.

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

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

Provides clear guidance on when to omit the 'item' parameter (all linked banks) vs. pass it (single bank). While it doesn't explicitly mention alternatives, the use case is well-defined.

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 critical behavioral context: credit balance meaning is connector-dependent, and the `name` field is not the brand. No contradictions.

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

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

Description is thorough but relatively verbose. It front-loads the core purpose and structures information logically. Some redundancy (e.g., repeated bank/connector_id/item_id). Still, valuable content 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 adequately describes return fields (balance, number, type, subtype, bankData, creditData, bank, connector_id). Also notes limitations and references a sibling tool for billing, making it self-contained.

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

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

With 0% schema coverage, the description fully explains both parameters: `type` enum (BANK/CREDIT) and optional `item` for filtering. Explains behavior when omitted, adding value beyond schema.

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

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

The description clearly states it returns accounts (BANK and CREDIT) with specific fields, and distinguishes between account holder name and brand bank name. It differentiates 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?

Explicitly instructs when to omit `item` (to list all banks) vs pass `item` (single bank). Warns against misinterpreting credit balance and directs to another tool for standardized billing amounts.

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 readOnly, idempotent, and non-destructive. The description adds valuable context: the response is cached for the session. It does not contradict annotations. It could disclose data freshness or refresh behavior, but the given info is sufficient.

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 action, and every sentence adds value. No redundant or filler 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?

Given no parameters and no output schema, the description fully explains what is returned, field meanings, and relationships to other tools. It is complete for the tool's simple nature.

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

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

There are no parameters, and the schema coverage is 100%. The description adds meaning by detailing the response fields (id, description, descriptionTranslated, parentId, parentDescription), which enriches understanding beyond the empty 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 identifies the tool as returning Pluggy's transaction category taxonomy, with a specific verb 'returns' and resource 'categories'. It distinguishes this from sibling tools by focusing on the category taxonomy, which is unique among list and update tools.

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

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

The description explains the cache behavior and provides guidance on using the categoryId for updating transactions, and mentions language preferences for pt-BR users. While it doesn't explicitly state when to use this tool over alternatives, the context implies it should be used before updating transaction categories.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds value by detailing the output fields and mentioning the add_connection_url for linking additional banks, 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?

Single sentence that is front-loaded with purpose and includes key 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?

Description covers the return values and purpose adequately for a simple list tool with no parameters. Lacks mention of pagination or limits, but given the simplicity, 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?

No parameters, so baseline is 4. Description adds meaning by explaining what the tool does and what it returns, compensating for the lack of output schema.

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

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

Description clearly states it returns saved bank connections and specifies the exact fields returned (connector_id, item_id, bank name, add_connection_url). It distinguishes from sibling list tools (e.g., list_accounts) by focusing on connections.

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

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

No explicit when-to-use or when-not-to-use guidance. The context implies usage for viewing connections, but without explicit differentiation from alternatives (though none are direct siblings for listing 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 provide readOnlyHint=true, idempotentHint=true. Description adds extensive behavioral context: payment status derivation logic, cross-bill matching, PAST_DUE_UNCONFIRMED status, connector asymmetry, and warning when product not enabled. 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?

Description is long but each sentence adds value. Front-loaded with main purpose, then detailed logic. Could be slightly more structured, but no waste.

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 covers return fields, payment status logic, open_bill opt-in, connector asymmetry, and links to sibling tool for itemized transactions. Complete for an agent to use correctly.

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

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

Schema coverage is 0%, but description compensates well for include_open_bill (detailed explanation of derived fields and default), account_ids (bulk support), and implies account_id context. Page/page_size not explained but understandable 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 verb 'Returns CLOSED credit card bills' for a CREDIT-type account, specifying key fields and distinguishing from sibling tools like openfinance_list_transactions for itemized purchases.

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 (list closed bills with derived status), when not to (for itemized transactions, use openfinance_list_transactions), and provides alternatives. Also explains opt-in behavior for open_bill and connector asymmetry.

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 (readOnly, idempotent, non-destructive), description adds error behavior details, specifies return fields (balance, amount, rates, dueDate, etc.), and clarifies the response format for non-enabled connections. 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?

Single sentence that front-loads the main purpose, but is long and could benefit from structured formatting. Still concise enough, though slightly cramped.

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 it covers return types and error handling, it completely omits parameter descriptions. Given 4 parameters and no output schema, the description is incomplete, failing to guide the agent on inputs.

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 does not mention any of the 4 parameters (item, page, type, page_size) or their semantics, leaving the agent with no guidance on how to use them.

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 tool returns the investment portfolio for a connection with INVESTMENTS product enabled, lists specific asset types (FIIs, stocks, ETFs, fixed income, etc.), and distinguishes from siblings like openfinance_list_investment_transactions and 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 context for when to use: for brokers/banks with INVESTMENTS enabled, and describes error handling (returns warning instead of throwing on 403). Lacks explicit alternatives but implies its specific role among many sibling tools.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds detailed return field information (quantity, value, amount, etc.) and mentions bulk execution, providing useful behavioral context beyond annotations. It does not cover pagination behavior or rate limits, but the annotations cover safety aspects.

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 paragraphs: first covers purpose and return fields, second covers prerequisite and bulk support. It is efficient with no wasted sentences, though the field list in the first paragraph is somewhat lengthy but still relevant.

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 explains the required parameter and bulk variant, but omits pagination parameters (page, page_size) entirely. Without output schema, the return field list helps, but the missing pagination details mean the agent may not know how to handle large result sets.

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 explain parameters. It clarifies investment_id (required, obtained from prerequisite) and investment_ids (bulk support). However, it does not document page and page_size at all, leaving a gap in understanding pagination semantics.

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

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

The description clearly states it returns movement history for investment positions, listing specific transaction types. It distinguishes from sibling tools like openfinance_list_investments by specifying it should be used after that tool, and from openfinance_list_transactions by focusing on investment-specific 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 a clear prerequisite: 'Use after openfinance_list_investments to get the investment_id.' It also mentions bulk support, guiding usage. However, it does not explicitly state when not to use this tool, such as for non-investment transactions, though the context of siblings implies 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?

Beyond annotations (readOnlyHint, idempotentHint), the description adds behavior: HTTP GET, sequential querying, rate-limit handling, and return format (results, errors per connection). 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 concise, front-loading the purpose, then usage details. Every sentence adds value; no superfluous text.

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

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

Given the single parameter and annotations, the description covers purpose, parameter usage, behavior, and return structure. A minor gap is lack of pagination or limit info, but it's not critical.

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 one parameter with 0% description coverage. The description fully explains it: items are connection selectors (item_id uuid, connector_id, or connector_name), one per connection, and effect of omitting.

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

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

The description clearly states it lists loan contracts per bank connection. The resource 'loans' is distinct from sibling tools like openfinance_list_accounts, but no explicit differentiation is provided.

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

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

The description explains how to use the `items` parameter, including omitting it for all banks, and mentions sequential querying with rate-limit spacing. It does not specify when to avoid using this tool or recommend 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?

The description adds significant behavioral context beyond annotations: CREDIT PENDING/POSTED variation by connector, search query aggregation up to 5000 transactions, error response structure instead of exceptions, zero-total troubleshooting, and bulk support. Annotations already indicate read-only and idempotent, but description enriches understanding of operational nuances.

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 thorough but slightly verbose, with multiple paragraphs. However, it is well-organized: starts with core function, then CREDIT specifics, filtering, error handling, and bulk. Every sentence adds value, though a bit of restructuring could improve scannability.

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

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

Given the tool's complexity (7 parameters, no output schema, interrelationships with sibling tools), the description covers all critical aspects: account types, date filtering, pagination, search behavior, error handling, troubleshooting zero results, and bulk execution. It leaves no obvious 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?

With 0% schema description coverage, the description fully compensates by explaining each parameter's format (ISO dates for from/to), constraints (pagination max 500/page), and behavior (search_queries semantics: case-insensitive substring match, OR across terms, aggregation behavior). It also clarifies the role of account_id and account_ids for bulk.

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, specifies its unique role for CREDIT accounts (only way to get itemized transactions), and contrasts with sibling tools like openfinance_list_credit_card_bills and openfinance_get_credit_card_bill, making the purpose highly specific and distinguishable.

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 (e.g., the only way for CREDIT itemized transactions), when not to (use openfinance_list_credit_card_bills for standardized totals), and how to handle edge cases (check connection health via openfinance_get_item_status if total is 0). It also explains PENDING vs POSTED behavior and search filter limitations.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds important behavioral details: it resolves accounts internally, fans out transactions, caps at 5000/account with a truncation flag, and describes the compact vs. raw output modes. 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 detailed but every sentence adds value. It is front-loaded with the main purpose and gradually provides specifics. While slightly long, it avoids redundancy and is well-organized for its 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 and lack of output schema, the description provides a good overview of return fields (total entradas, saídas, monthly evolution, top despesas, etc.). It covers main use cases and limitations (truncation). Minor omission: does not specify exact output structure or field types, but it is sufficient for an AI agent to understand the return.

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, but the description fully compensates by explaining all six parameters: item (connector_id/connector_name/item_id), from/to (ISO dates), granularity (monthly/raw), type (BANK/CREDIT), and top_n (implicitly as 'largest N'). This adds significant meaning beyond the schema names.

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

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

The description clearly states the tool's purpose: 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call.' It specifies the verb (list/analyze), resource (cash-flow of a connection), and distinguishes from siblings by noting it resolves accounts internally, avoiding separate calls to 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 provides explicit guidance on when to use the tool: for 'análise anual/mensal', 'fluxo de caixa', etc. It explains how to target one bank via 'item' or omit for all connections, and when to use 'raw' granularity. However, it does not directly compare to sibling tools like openfinance_list_transactions, though the context makes the distinction clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as true, true, false respectively. The description adds meaningful behavioral context: it calls the provider's public status page, returns a global indicator, degraded components, open incidents, and flags incidents affecting the user's banks. 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 well-structured with front-loaded purpose, clear usage guidance, and return value details. Every sentence adds value, though it is slightly verbose. It is concise enough for an AI agent to quickly understand.

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 describes the return value (global indicator, degraded components, open incidents, your_banks_affected) and the external call behavior. It covers all necessary information for an AI agent to use the tool correctly.

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

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

The tool has zero parameters, and the schema coverage is 100% (trivially). The description does not need to add parameter semantics, and it provides no additional parameter info, which is acceptable. Baseline for zero parameters is 4.

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

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

The description clearly states the tool checks the LIVE operational status of the Open Finance provider (its public status page), using specific verbs and resources. It distinguishes itself from the sibling tool openfinance_get_item_status by explicitly stating it is separate from the user's connection status.

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

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

The description provides explicit guidance on when to use this tool: 'Use it whenever data looks incomplete or stale even though a connection shows UPDATED' and explains how it helps diagnose provider-side problems versus connection issues. It also clarifies when not to use it by contrasting with openfinance_get_item_status.

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

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

The description confirms the readOnlyHint and idempotentHint annotations, and adds behavioral details such as honoring the user's plan (hiding PJ banks for PF plans) and returning a connect_url. It does not contradict any annotations.

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

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

The description is a single paragraph that efficiently packs many details. It is front-loaded with the main action. While slightly long, every sentence adds value and there is no unnecessary verbosity.

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 covers the return values and key behaviors. It lacks explicit details on the 'hint' returned when keywords are omitted, but overall it is sufficient for a two-parameter search tool.

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

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

With 0% schema description coverage, the description compensates well by explaining the keywords[] parameter (required array of strings) and the include_accounts boolean. It adds meaning but could provide more detail about keyword matching behavior.

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

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

The description clearly states that the tool searches bank connectors by name, returning connector id, access type, audience, linked connections, and a connect URL. It distinguishes itself from sibling list tools by focusing on keyword-based search of specific connector names.

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 advises calling this tool before connecting to provide a one-click link. It emphasizes that keywords are required. While it does not explicitly state when not to use it or mention alternatives, it provides clear context for its 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?

The description discloses important side effects: overriding automatic categorization and teaching Pluggy by creating a Category Rule for future similar transactions. It also details batch error handling (per-item errors do not fail the whole batch). With no annotations beyond hints, this adds valuable 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 compact yet information-dense, with each sentence serving a distinct purpose: purpose and method, input structure, side effects, and response format. It is front-loaded with the primary action. Minor improvements could trim redundancy, 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 and low schema coverage, the description provides almost all necessary context: input requirements, side effects, and response shape. It covers the batch behavior and error handling. It does not mention item array limits or authentication, but those are common to all 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?

The schema has 0% description coverage, so the description must compensate. It explains the items parameter as an array of objects with transaction_id and category_id, and specifies where these IDs come from. This adds meaningful understanding beyond the raw schema structure.

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 begins with 'Corrects the category of one or more transactions (PATCH /transactions/:id),' clearly stating the verb and resource. It distinguishes from sibling tools by specifying that it updates categories, while other tools list or get data. The mention of batch operation further clarifies its scope.

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

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

The description advises to 'use this to fix miscategorized transactions and improve categorization accuracy going forward,' providing clear use context. It also explains where to obtain transaction_id and category_id from sibling tools (openfinance_list_transactions, openfinance_list_categories), though it does not explicitly state when to avoid using 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 idempotentHint=true (safe to retry) and destructiveHint=false (non-destructive). The description adds that the conversation array should be included for reproduction. No additional behavioral traits are disclosed beyond what annotations provide. No contradictions.

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

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

The description is a concise two-sentence structure. It front-loads the purpose in the first sentence and provides usage guidance in the second. No extraneous information. 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 the tool's simplicity (no output schema, few parameters), the description covers the core purpose and one usage hint. However, it lacks details on expected response or additional context for effective usage, making it adequate 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?

Schema description coverage is 0%, so the description must compensate. It mentions the 'conversation' parameter's purpose (for reproduction) but does not explain 'context' or 'message' beyond their names. The description adds minimal meaning to the parameters, leaving ambiguity for the agent.

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

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

The description clearly states the tool's purpose: 'Report a bug, missing feature, or send feedback.' It specifies the action (report) and the resource (bug/feature/feedback). This distinguishes it well from sibling tools which are unrelated (authentication, finance 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 includes guidance to 'Include the conversation array with recent messages for reproduction,' which hints at usage context. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. Usage is implied but not fully prescriptive.

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 no extra behavioral details. With full annotation coverage, the description isn't required to add more, so a 3 is fair.

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

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

A single, clear sentence with no wasted words. perfectly concise and front-loaded.

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

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

For a simple version tool with no parameters and clear annotations, the description is complete enough. It provides the essential information without needing more.

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, and schema coverage is 100% (empty schema). The description doesn't need to provide parameter info. Baseline for 0 parameters is 4, and it's adequate.

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

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

The description clearly states the tool shows versions, specifically platform and adapter. It's concise and unambiguous, with no confusion from siblings since no other version tool exists.

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

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

No explicit guidance on when to use vs alternatives, but it's a simple info tool. The context implies usage when version info is needed. A 3 is appropriate as it's minimal but sufficient for such a straightforward tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds specific behavioral context by listing the exact return fields (installed MCPs, connection status, catalog tool counts), enhancing transparency beyond annotations.

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

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

The description is a single, well-structured sentence with no wasted words. It front-loads the purpose and clearly enumerates the return 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?

For a tool with no parameters and no output schema, the description adequately conveys the return content. However, it could briefly mention the expected response format (e.g., JSON object) for completeness.

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

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

No parameters exist, so schema coverage is 100%. The description adds no parameter information, which is acceptable as there are none. Baseline of 4 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 uses a specific verb 'Returns' and clearly identifies the resource as 'current toolkit state', detailing the content: installed MCPs, connection status, and catalog tool counts. This distinguishes it from siblings like 'marketplace' 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 implies usage context by describing the output, but does not explicitly state when to use it or mention alternatives. Since it is a unique informational tool, the lack of exclusions is acceptable, but more explicit guidance would elevate it.

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