C6 Bank MCP

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

Annotations indicate idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds behavioral context beyond annotations by explaining the two authentication modes (permanent vs session-only), how to obtain a token, and that the token is a JWT. It does not contradict annotations.

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

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

The description is a single paragraph that is efficiently written, with key information front-loaded. It covers purpose, usage methods, and parameter details without unnecessary words. Minor structuring (e.g., bullet points) could improve readability, but it is concise.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is complete. It explains both usage scenarios, the token's nature, and how to make the login permanent. No additional information is needed for an agent to correctly invoke the tool.

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

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

Schema coverage is 0%, but the description compensates by explaining that the 'token' parameter is an optional JWT string. It clarifies that omitting it returns a link, while providing it logs in. This adds significant 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: authentication for IDE agents. It specifies the verb 'log in' and resource 'access token', and describes two distinct usage methods (permanent via config header or session-only via token parameter). This clearly distinguishes it from other tools like connect or marketplace.

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

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

The description provides explicit guidance on when to use the tool (for login) and how to use it: either with no arguments to get a link or with a token parameter after pasting. It does not explicitly state when not to use it or mention alternatives, but the context is clear enough for an agent to understand.

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, and the description adds specific behavioral details about response structure (authenticated:true with empty pending[] vs. connect_url fields). 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, no superfluous words. Front-loaded with the purpose, then conditional details. Highly 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 zero parameters, no output schema, and comprehensive annotations, the description fully covers the tool's behavior. It explains the two main states clearly.

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 baseline 4 applies. The description doesn't need to add parameter information.

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

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

The description clearly states the tool returns connection status and URLs, with specific details about two distinct states (all connected vs. missing credentials). This distinguishes it from siblings like 'authenticate' and 'openfinance_list_connections'.

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

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

The description provides explicit guidance on when to use the tool (to check connection status) and what output to expect in two scenarios. While it doesn't explicitly say when not to use, the context implies alternative tools for initiating authentication.

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

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

Annotations indicate non-readonly, open-world, non-idempotent, non-destructive. The description goes beyond by specifying that invoke runs one-off without installation, that writes require workspace owner/admin, and how credentials/payment blocks are handled. 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 well-structured with clear flow and front-loaded purpose. Every sentence adds value, though it is lengthy and could be trimmed slightly. No wasted words, but density is high.

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 13 parameters, no output schema, and many actions, the description covers the main workflow and behavioral nuances. It lacks details on return shapes for search/describe and error handling, but is otherwise comprehensive for a tool of this complexity.

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

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

Schema coverage is 0%, so the description carries full burden. It explains the key parameters (action, query, mcp_id, tool_id, arguments) in the flow but leaves others (limit, immediate, tier_slug, conversation, request_name, report_context, request_details) under-explained. Partial compensation, but not exhaustive.

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 defines the marketplace as the official MCP catalog and runtime, with a specific verb-resource combination. It distinguishes itself from sibling tools like openfinance_* and authenticate by being the central discovery and execution platform.

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

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

The description provides explicit guidance: 'use THIS tool FIRST' before other registries, and details the core flow (search → describe → invoke). It differentiates between invoke (one-off) and install (permanent), and explains when each is appropriate, giving clear context for action selection.

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

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

Description aligns with annotations (destructiveHint: true) and adds detail: consent revocation and data deletion. It also discloses the return of a reconnection URL. 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 core action. No wasted words.

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

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

For a simple tool with one parameter, clear annotations, and no output schema, the description sufficiently covers purpose, behavior, and outcome.

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 one required parameter 'item' (string) with 0% description coverage. The tool description does not explain what 'item' represents (e.g., bank ID or connection ID). Given the low schema coverage, the description should compensate but fails to do so.

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 action: revoke consent and delete connection data for a specific bank. It also mentions the consequence (data no longer available) and the return of an add_connection_url. This distinguishes it from sibling tools like openfinance_list_connections.

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

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

The description implies use when disconnecting a bank, but does not explicitly state when to use versus alternatives like openfinance_force_sync. However, the action is specific enough that 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 provide basic hints (readOnlyHint=false), but the description adds significant detail: it performs PATCH and polls, waits up to 60s, returns specific status fields, and warns about needs_action or timed_out outcomes. 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?

Every sentence serves a purpose: core action, use case, parameter details, return format, and error handling. The description is front-loaded and well-organized, with no redundant information.

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

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

The description covers all aspects: purpose, usage, inputs, outputs, behaviors (waiting, polling, timeout), error states, and re-querying. No missing elements for this 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?

With 0% schema description coverage, the description fully compensates by explaining items as an array of selectors (with three allowed types) and the effect of omitting it (sync all), and wait as fire-and-forget. Both parameters are clarified.

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 action ('forces the bank to re-sync one or more connections NOW and WAITS') and resource. It distinguishes itself from sibling tools by emphasizing the wait-for-completion behavior and contrasting with fire-and-forget mode.

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

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

The description explicitly says when to use ('when a balance or transaction list looks stale') and explains how it differs from alternatives (no disconnect/reconnect). It also directs users to re-check with openfinance_get_item_status on timeout and offers wait=false for 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?

Description adds significant behavioral context beyond annotations: real-time nature, array length constraint, credit account error handling with warnings instead of exceptions, and response shape. 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 sentences pack all necessary information: function, HTTP method, parameter constraints, error handling, and response format. 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?

With no output schema, the description adequately explains the return shape (results/errors) and error handling. For a single-parameter, read-only tool, this covers all needed context.

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 that parameter 'account_ids' should be an array of account IDs with a 1–50 constraint, adding essential meaning beyond the schema's type definition.

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 real-time balance for an account, specifies the API endpoint, and the required parameter. It distinguishes from sibling tools like 'list_accounts' 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 clear guidance on input array size (1–50) and explains error behavior for credit accounts with structured warnings. However, it does not explicitly describe when not to use this tool or mention alternatives among siblings.

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

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

Annotations indicate read-only and idempotent, and the description adds the batch shape (results/errors) and endpoint reference, providing useful context beyond annotations.

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

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

Two concise sentences front-load the core purpose and input rules without any extraneous 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?

While the input and output shape are described, the description omits details about the account object fields beyond creditData, which would be helpful given no output schema.

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

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

With 0% schema description coverage, the description adds meaning by specifying the array size limit (1–50) and the per-ID nature, compensating for the lack of schema description.

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

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

The description clearly states the tool returns full account objects with extended creditData for given IDs, distinguishing it from sibling list 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 input format (array of 1-50 IDs) but lacks explicit guidance on when to use this tool versus alternatives like openfinance_list_accounts.

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 set readOnlyHint, idempotentHint, destructiveHint. Description adds critical behavioral details: batch {results, errors} shape, Pluggy's lack of paid/status field, and the non-intuitive payment semantics (payments[] likely from previous bill). 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?

Single informative paragraph, front-loaded with purpose, and every sentence adds value. Slightly long but justified by complexity of the domain caveats.

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 thoroughly explains output shape (results/errors), included fields, and what is excluded. Also provides domain-specific guidance on Brazilian Open Finance payment interpretation, making it contextually 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 has one parameter (bill_ids array) with 0% description coverage. Description advises passing as array and using list tool first, but does not detail ID format or constraints. Provides some context but insufficient for full parameter understanding.

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

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

The description clearly states it returns bill-level detail for credit card bills by ID, lists included fields (financeCharges, payments), explicitly excludes individual transactions, and distinguishes from openfinance_list_transactions.

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

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

Provides explicit when to use (bill-level detail) and when not (individual transactions), directs to use openfinance_list_credit_card_bills first, and includes a crucial caveat about interpreting payments[] in Brazilian Open Finance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that the tool returns status, executionStatus, and connector metadata, but this is minimal additional context beyond what annotations already convey.

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

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

The description is two sentences long, with the purpose and key usage immediately presented. Every word earns its place; no extraneous information.

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

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

Given the tool has only one optional parameter, no output schema, and no nested objects, the description fully covers its behavior for both invocation patterns. It is sufficient for an agent to correctly use the tool.

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

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

The input schema provides no description for the `item` parameter (0% coverage). The description compensates by explaining that omitting `item` returns all connections in a `{ count, items }` format, while passing it returns a single bank's status. This adds critical 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 that this tool returns the current status of a bank connection, listing specific statuses like UPDATED, UPDATING, LOGIN_ERROR. It distinguishes between two modes: omitting `item` for all connections versus passing `item` for a single bank. This differentiates it from sibling tools like openfinance_list_connections, which likely provides a different view.

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

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

The description explicitly tells when to omit the `item` parameter (to get status of all linked banks) and when to pass it (for a single bank). While it does not mention when not to use it or alternatives, the context is clear for an agent to decide.

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

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

Annotations already indicate readOnlyHint=true. The description adds critical behavioral details: CREDIT balance is connector-dependent, and the billing cycle fields are defined. 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?

Somewhat long but each sentence adds value. Front-loaded with main purpose, then elaborates on nuances. Minor redundancy 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?

No output schema present, but description comprehensively covers return fields, edge cases (balance meaning), and references related tool for consistency. Highly complete for a listing 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 has 0% description coverage. Description compensates fully by explaining the `item` parameter (omit for all banks, pass for single) and `type` parameter (BANK/CREDIT enum).

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 with specific fields (balance, number, type, etc.) for BANK and CREDIT types. It distinguishes from siblings by referencing openfinance_list_credit_card_bills for standardized bill amounts.

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` (list all banks) vs pass it (single bank). Also warns against misinterpreting CREDIT balance and directs to another tool for consistent 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?

The description discloses caching behavior ('cached for the adapter session') and response structure ('Single aggregated response — no batch ids'), which go beyond the annotations (readOnlyHint, idempotentHint). This adds useful context for model 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?

Three sentences, each adding value: purpose, response fields with details, and a note about aggregation. No fluff, well-structured.

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

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

Given no output schema, the description provides a clear overview of response fields (id, description, descriptionTranslated, parentId, parentDescription). It covers core needs for a taxonomy list tool, though could mention if the list is static or dynamic.

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

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

With 0 parameters and 100% schema coverage, the description does not need to add parameter detail. Baseline 4 applies. The description focuses on output, which is helpful but not required for parameter 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 the transaction category taxonomy, with specific verb 'Returns' and resource 'Pluggy's transaction category taxonomy'. It explicitly links to the sibling tool openfinance_update_transaction_category by identifying how the 'id' field is used, distinguishing it from other tools.

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

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

The description implies usage for obtaining category IDs to use with openfinance_update_transaction_category, but does not explicitly state when to use or not use this tool versus alternatives. No when-not scenarios are mentioned.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds value by detailing the specific output fields (connector_id, item_id, bank name, add_connection_url) and the purpose of the URL, which is beyond annotations.

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

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

One sentence that is front-loaded with the main purpose and includes key output 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?

Despite no output schema, the description lists the fields returned. It could specify types or format, but for a simple list with no parameters, it is sufficiently 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?

No parameters exist, so baseline 4 applies. Description adds no parameter info, but that's acceptable as 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 the tool returns saved bank connections and lists specific fields (connector_id, item_id, bank name, add_connection_url). It distinguishes from siblings like openfinance_list_accounts or openfinance_disconnect_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 usage is implied (to retrieve connections), but no explicit guidance on when to use this vs. alternatives like openfinance_list_accounts or openfinance_get_item_status. No exclusions or when-not-to-use information.

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

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

Annotations already provide readOnlyHint and idempotentHint, but the description adds critical behavioral context: payment semantics (payments land on next bill), derived `payment_status`, connector asymmetry for open bills, and that the tool returns a warning instead of failing if CREDIT_CARDS product is 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?

The description is long (multiple paragraphs) and contains very detailed Brazilian Open Finance semantics. While necessary for completeness, it lacks conciseness and could be restructured or shortened for easier consumption.

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

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

No output schema exists, but the description thoroughly explains return fields (dueDate, totalAmount, etc.), derived `payment_status` legend, `open_bill` and `future_bills` structure, and warning behavior. Fully covers the complexity of the tool.

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

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

Schema description coverage is 0%, yet the description compensates well by explaining `include_open_bill` (opt-in, default false, reason for `available: false`), `account_ids` for bulk, and implicitly `account_id`. Page and page_size are not detailed but are standard. Adds meaningful context beyond the schema.

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

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

The description clearly states it returns CLOSED credit card bills for a CREDIT-type account, listing specific fields. It distinguishes from sibling tools like openfinance_get_credit_card_bill (single bill) and openfinance_list_transactions (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?

Explicit guidance on when to use the opt-in `include_open_bill` parameter, when results are bill-level summaries not transactions, and how to get itemized data via `openfinance_list_transactions`. Also explains connector asymmetry and when a warning is returned.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context: it returns a structured error response on 403 or other upstream errors, and enumerates supported investment types, going 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 concise sentences with front-loaded purpose. Lists examples of returns and error handling without unnecessary detail. 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?

Missing parameter documentation (especially page and page_size for pagination) and no full response structure. The description hints at fields but is incomplete for a tool with 4 parameters and no output schema.

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

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

Schema description coverage is 0%. The description does not explain any parameter (item, page, type, page_size). The only parameter mention is the enum list for type, but not its purpose. No compensation for missing schema descriptions.

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

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

The description clearly states the tool returns the investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.). The verb 'Returns' and resource 'investment portfolio' are specific, and it distinguishes from sibling tools like openfinance_list_investment_transactions.

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

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

No explicit guidance on when to use this tool vs. alternatives. It mentions handling errors with a specific return structure when INVESTMENTS isn't enabled, but lacks when-to-use or when-not-to-use context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context beyond annotations, detailing the return fields (quantity, value, expenses, etc.) and bulk support. 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 concise with two paragraphs: first detailing what it returns, second providing usage context. Every sentence adds value with no redundancy.

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

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

Given the tool has 4 parameters, no output schema, and moderate complexity, the description covers return fields, transaction types, and bulk support. It lacks information on pagination defaults or limits, but overall is reasonably complete for a list tool.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies the use of investment_id and investment_ids (bulk support) but does not describe page and page_size parameters, leaving some ambiguity about pagination behavior.

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

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

The description clearly states it returns movement history for a specific investment position, listing specific transaction types (BUY/SELL/TAX/etc.) and fields. It distinguishes from the sibling tool openfinance_list_investments by indicating it should be used after that to get 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?

The description provides clear context for use: it should be used after openfinance_list_investments to obtain the investment_id. It also mentions bulk support with investment_ids. However, it does not include when-not-to-use or alternative 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 readOnly and idempotent, but the description adds: items semantics, sequential querying, rate-limit spacing, and the 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?

Two sentences, front-loaded with purpose and endpoint, then parameter 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 tool with one optional parameter and no output schema, the description covers purpose, parameter usage, and return format. Could mention error handling or pagination but still comprehensive enough for typical 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?

Schema coverage is 0%, so description carries full burden. It explains that items are connection selectors (item_id, connector_id, or connector_name) and that each entry corresponds to a connection. This adds significant meaning beyond the schema.

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

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

The description clearly states it lists loan contracts per bank connection, mentions the HTTP GET endpoint, and distinguishes it from sibling tools like openfinance_list_accounts by specifying 'loans' as the resource.

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 explains when to pass the `items` parameter (for specific connections) and when to omit it (list all), and mentions sequential querying with rate-limit spacing. While it doesn't explicitly mention when not to use, the context is clear for a list 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 declare readOnlyHint, idempotentHint, and destructiveHint, indicating safe read-only operation. The description adds extensive behavioral context: auto-pagination with 5000 cap, CREDIT pending/posted variance by bank, error return structure, token cost implications for detail levels, and connection health check. 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 thorough but somewhat verbose, spanning multiple paragraphs. It is well-structured with topical paragraphs (CREDIT specifics, pagination, detail levels) and front-loads the main purpose. While efficient for the complexity, minor redundancy could be trimmed. Still, it earns a 4 for being informative without being excessively long.

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 (8 parameters, no output schema), the description is remarkably complete. It covers all parameters, special behaviors for CREDIT accounts, pagination mechanics, error handling, detail levels with examples, and cross-references to sibling tools for additional context. No aspect seems missing.

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

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

Schema has 0% description coverage, so the description bears full responsibility. It clearly explains all 8 parameters: account_id (required), account_ids (bulk), from/to (ISO date filters), search_queries (case-insensitive substring OR), detail (compact/rich/raw with trade-offs), page and page_size (pagination control). Every parameter is semantically described.

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

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

The description clearly states that the tool returns transactions for bank accounts, specifying BANK or CREDIT types. It distinguishes itself from siblings like openfinance_list_credit_card_bills by explaining that for CREDIT accounts, this is the only way to get itemized transactions, and recommends alternatives for standardized totals. The verb 'list' and resource 'transactions' are explicit.

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 comprehensive usage guidance: explains when to use this tool (listing transactions), when not to (for standardized credit totals use openfinance_list_credit_card_bills), how to handle pagination (omit vs explicit page), how to choose detail level, and what to do if total is 0 for CREDIT accounts. It also mentions bulk support and error handling.

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 important behavioral details: scan caps at 5000 transactions per account with a truncated flag, and explains the difference between monthly and raw granularity modes. No contradiction with annotations.

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

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

The description is a single long paragraph (~200 words) that packs all information. It front-loads the core purpose but becomes dense. While informative, it could benefit from bullet points or clearer structure to improve skimmability.

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

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

No output schema is provided, but the description thoroughly explains the return structure: compact monthly summary with totals, por_mes, top_despesas/recebimentos, by_account, and raw mode with every consolidated transaction and optional enrichment. Also mentions truncation flag. This is fully adequate for an agent to understand the tool's output.

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 fully compensates. It explains all parameters: item (accepts connector_id, connector_name, or item_id, and behavior when omitted), from/to (ISO dates), granularity (monthly/raw with output differences), detail (compact/rich/raw and what enrichment is provided), type (BANK/CREDIT filter), and top_n (implied via top_despesas/recebimentos).

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, resolving accounts internally. It lists specific use cases like 'analise anual/mensal' and 'fluxo de caixa', and distinguishes from siblings by noting that it eliminates the need to call openfinance_list_accounts first.

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

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

The description explicitly says when to use this tool instead of calling openfinance_list_accounts, and lists typical analysis contexts. It does not explicitly state when not to use it, but implies that for per-account raw transactions without consolidation, other tools should be used.

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, and idempotentHint=true. The description adds behavioral context: it checks a public status page and returns fields like global indicator, degraded components, incidents, and 'your_banks_affected'. 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 bit long (4 sentences) but each sentence adds value. It front-loads the purpose and provides clear usage guidelines without unnecessary words.

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

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

Given zero parameters and no output schema, the description fully explains the tool's purpose, when to use it, and what it returns. No additional context is needed.

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

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

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

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

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

The description clearly states the verb 'Checks' and the resource 'LIVE operational status of the Open Finance provider'. It distinguishes itself from the sibling tool 'openfinance_get_item_status' by noting that it checks the provider's health separately from the connection's 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?

Provides explicit when-to-use guidance: 'whenever data looks incomplete or stale even though a connection shows UPDATED'. It also explains what the tool reveals (upstream outage, known incident) and how it helps differentiate provider-side problems from connection issues.

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 context beyond annotations: caveat about non-Open-Finance connectors, plan-based filtering, empty keywords behavior (returns hint). No contradiction with readOnlyHint or idempotentHint.

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

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

Front-loaded with purpose and packed with useful details, but slightly long. Could be split into clearer sections for 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?

Despite no output schema, completely describes return fields, edge cases (caveat, plan filtering), and intended usage. Covers all necessary context for an agent.

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

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

Explains both parameters with examples and behavior (keywords example, include_accounts triggers account inclusion). However, states keywords as REQUIRED while schema has no required field, creating minor 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?

Clearly states it searches bank connectors by name, specifies returned fields (id, access, audience, connections, connect_url). Distinguishes from siblings as a search tool to be called before connecting.

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

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

Explicitly says 'Call this BEFORE connecting to hand the user a one-click link' and mentions honoring user's plan. Could be improved by contrasting with other tools like list_connections.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=false, etc., but the description adds significant behavioral context: it overrides automatic categorization, teaches Pluggy by creating rules, and explains per-item error handling (errors don't fail whole batch).

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 that front-loads the purpose and packs in necessary details. It is efficient but slightly dense; could benefit from minor structuring into separate sentences or bullet points.

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 explains the batch result shape and side effects. It covers prerequisites, behavior, and outcomes, making it highly 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?

Schema description coverage is 0%, but the description fully explains each field: transaction_id comes from openfinance_list_transactions, category_id from openfinance_list_categories, and the items array structure. It adds essential meaning beyond the schema.

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

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

The description clearly states it corrects transaction categories, names the endpoint (PATCH /transactions/:id), and explains the effect. It references sibling tools for obtaining IDs (openfinance_list_transactions, openfinance_list_categories), distinguishing itself from read-only list 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 explicitly says use it to fix miscategorized transactions and improve future categorization. It explains the side effect of creating a Category Rule. While it doesn't explicitly say when not to use, the context is clear enough.

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

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

Annotations indicate the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), with idempotentHint=true. The description confirms it sends feedback but does not explain side effects (e.g., ticket creation, notifications) or the exact behavior upon submission. Some transparency is gained from annotations, but the description adds little beyond the purpose.

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 short (two sentences) but could be more structured. It front-loads the purpose but mixes a parameter instruction in the second sentence. It is not overly verbose, but it lacks conciseness by not following a clear format.

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 tool with 3 parameters and no output schema, the description should cover all parameters and return expectations. It fails to explain the 'context' and 'message' parameters beyond their names, and does not describe what the tool returns or what happens after reporting. This leaves significant gaps for an agent.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions including the 'conversation array' but does not explain the 'message' or 'context' parameters. The names are somewhat self-explanatory, but the description fails to provide essential details like what constitutes a valid message or 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?

Clearly states the tool is for reporting bugs, missing features, or sending feedback. The verb 'report' and specific resources (bug, feature, feedback) make the purpose unmistakable, and it is distinct from all sibling tools which are financial or authentication operations.

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

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

The description implies usage for feedback submission but does not explicitly state when to use this tool versus alternatives or when not to use it. No guidance on prerequisites or scenarios where it should be avoided.

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 specific context about displaying 'MCP platform and adapter versions', which goes beyond the annotations. No contradiction.

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

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

The description is a single sentence, front-loading the verb and resource. Every word earns its place, with no redundancies.

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 parameters, clear annotations), the description is complete enough to guide an agent. No output schema is needed for a version display 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 zero parameters, the description cannot add parameter meaning beyond the schema. The description is sufficient and does not introduce confusion.

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 'Show' and the specific resource 'current MCP platform and adapter versions', making the tool's purpose unambiguous. It distinguishes itself from sibling tools which focus on banking 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?

The description implies usage for checking versions but provides no explicit guidance on when to use this tool versus alternatives or any prerequisites. The trivial nature of the tool partially mitigates this gap.

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

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

Annotations already provide readOnlyHint and idempotentHint, so the description's role is light. It adds some behavioral context (what is returned) but no additional traits like authentication requirements or side effects.

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

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

Single sentence, front-loaded with the core purpose. No redundant information.

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

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

For a read-only introspection tool with zero parameters and clear annotations, the description is largely complete. It lacks output schema details, but the verbal description suffices for the simplicity level.

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 compensates adequately by describing the output, achieving the baseline for 0 params.

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

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

The description uses specific verbs ('Returns') and resources ('current toolkit state: installed MCPs, their connection status, and how many catalog tools each exposes'), clearly distinguishing it from sibling tools like authenticate or openfinance operations.

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

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

The description implies usage for checking toolkit state, but lacks explicit context on when to use this vs. alternatives (e.g., show_version, authenticate). No when-not-to-use guidance is provided.

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