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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral detail about what the response looks like under different conditions (authenticated:true vs connect_url), which is valuable. 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, zero wasted words. Front-loaded with the core purpose, then expands with conditional details. 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?

With no output schema, the description must fully explain the return shape, which it does (authenticated:true vs connect_url). For a zero-parameter tool with strong annotations, this is sufficient. Minor gap: does not mention if there are other fields like user info, but the described behavior seems 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?

There are no parameters, and schema description coverage is 100% (no params to describe). The description adds meaning about the return values, which substitutes for parameter documentation. Baseline 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 clearly states it returns connection status and URLs, distinguishing it from sibling tools like 'authenticate' which likely handles login flows, and other data-fetching tools. The verb 'returns' plus the specific resource (connection status) is precise.

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

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

The description implies usage: call to check if all providers are connected or see URLs for missing credentials. It does not explicitly list when not to use it or contrast with siblings like 'authenticate', but the context is clear enough 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 indicate readOnlyHint=false and openWorldHint=true. Description adds significant behavioral context: invoke runs one-off without installation, handles credentials and payment links, and requires workspace owner/admin for writes. 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 long but well-structured and front-loaded. All sentences provide valuable information; no redundancy. Could be slightly trimmed but remains clear and efficient 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 13 parameters, no output schema, and rich annotations, the description is remarkably complete. It covers all actions, authentication, payment, permissions, and the distinction between temporary and permanent usage. No gaps identified.

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

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

Schema coverage is 0% but description explains the actions (search, describe, invoke, etc.) and implies the roles of parameters like query, mcp_id, tool_id, arguments. Adds meaning beyond schema by detailing the flow, but lacks per-field descriptions for all 13 parameters.

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

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

Description clearly states it is the official mcp.ai marketplace and the primary tool for discovering and running MCPs. It distinguishes from siblings by specifying its role as a catalog and runner, and contrasts with external registries and installation.

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 to use this tool first before external registries. Explains when to use invoke vs install, and mentions that write actions require owner/admin. Covers subscribe, cancel, report_bug, request_mcp use cases.

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 destructiveHint=true. The description adds that data will no longer be available and that a reconnection URL is returned, which goes beyond annotations.

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

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

Three concise sentences: action, consequence, return value. 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?

While the description is clear on purpose, it lacks parameter documentation and full output details, making it incomplete for a tool with one parameter and no output schema.

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

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

The sole parameter 'item' is not explained in the description despite 0% schema coverage. No guidance on what value to provide, leaving the agent unprepared.

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 action: revokes consent and deletes connection data for a specific bank. Distinguishes from siblings like openfinance_list_connections and openfinance_force_sync.

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

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

Describes what the tool does but does not provide explicit guidance on when to use vs alternatives or prerequisites. Usage is implied but not elaborated.

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?

No contradictions with annotations. The description adds critical behavior: waits up to 60s, polls, can return LOGIN_ERROR/WAITING_USER_INPUT, and explains return fields. Annotations are minimal, so description carries burden well.

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 and well-structured with first sentence summarizing, then usage, then returns. However, it is somewhat long; could be slightly more concise but every sentence adds value.

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

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

No output schema, but description covers return structure and key fields (status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out) and alternative wait:false behavior. Very 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 coverage is 0%, but the description fully explains both parameters: wait (true/false behavior) and items (array of selectors, omit for all), adding 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 forces a bank re-sync and waits for completion, distinguishing from sibling tools like openfinance_get_item_status which is mentioned for re-checking after timeout.

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 when to use (stale balance/transactions), how to use (items array or omit for all), and mentions alternatives (openfinance_get_item_status) and optional behavior (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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: error handling for credit accounts (warning instead of throwing) and the response shape, going beyond the annotations.

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

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

Three sentences, each earning its place: first defines purpose, second gives usage tip, third explains error handling and response shape. No redundancy or 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?

For a simple tool with one parameter, annotations, and no output schema, the description covers endpoint, array limit, error handling, and response shape. It is fully complete for the given 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 must add meaning. It does so by specifying the array size limit (1-50) and error handling context for credit accounts, which are not inferable from the schema alone.

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 real-time balance per account ID, specifying the exact endpoint. It distinguishes itself from siblings like openfinance_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?

Specifies to pass account_ids as an array of 1-50 and explains error handling for credit accounts. While it doesn't explicitly state when not to use it, the context is clear enough for agent selection.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral details: returns extended creditData, batch shape {results, errors}, which provides 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 sentences, each earning its place: first explains purpose, second gives usage constraints and return shape. No wasted words.

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

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

With one parameter and no output schema, the description provides essential context: batch shape and extended creditData. It could mention possible error reasons or that results are for valid account IDs, but overall it's fairly complete.

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

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

Schema description coverage is 0%, so the description carries the burden. It adds that account_ids must be an array of 1-50 strings, which provides a constraint missing from the schema. However, no further details on individual items or validation rules are given.

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 per ID, distinguishing it from sibling list_accounts which likely provides a summary. Verb 'Returns' and resource 'account objects' are specific.

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

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

The description specifies the parameter format (array of 1-50 account_ids) and the batch shape, but does not explicitly state when to use this tool over alternatives like openfinance_list_accounts. Implicitly it's for detailed lookups.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds valuable behavioral context: explains Pluggy does not return paid/status field, clarifies semantics of payments[], and describes batch shape { results, errors }.

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 informative and well-structured, front-loaded with purpose. Slightly verbose but each sentence adds value; could be more concise 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?

Given complexity and no output schema, description covers return fields, batch shape, important caveats about payment semantics, and links to related tools for discovery and payment status. Complete for 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?

Only parameter bill_ids is explained: its type (array), how to obtain values (use openfinance_list_credit_card_bills), and that it should be passed as an array. Schema coverage is 0%, so 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?

Description clearly states it returns bill-level detail for credit card bills by id, specifies HTTP method and endpoint, and distinguishes from sibling tools by stating it does not return individual transactions, recommending openfinance_list_transactions instead.

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

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

Provides explicit guidance: pass bill_ids as array, use openfinance_list_credit_card_bills to discover ids, warns about interpreting payments[] correctly, and recommends openfinance_list_credit_card_bills for payment 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 already declare readOnlyHint=true and idempotentHint=true, so the description adds value by explaining the return fields (status, executionStatus, connector metadata) and the output structure difference. 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?

Two sentences that are front-loaded with the core purpose and immediately follow with actionable usage guidance. No extraneous 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?

Despite no output schema and only one optional parameter, the description covers both usage modes, expected output shapes, and possible status values. Complete for a read-only status retrieval 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% (no parameter descriptions), but the description fully explains the effect of omitting vs providing the `item` parameter, including the shape of the response, making the parameter meaning crystal clear.

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

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

The description clearly states it returns the current status of a bank connection with specific statuses (UPDATED, UPDATING, LOGIN_ERROR, etc.) and distinguishes between single and all bank usage. This contrasts with sibling tools like openfinance_list_connections or openfinance_provider_status.

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

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

Explicitly instructs to omit `item` for all banks and pass `item` for a single bank. While it doesn't mention when not to use, the guidance is clear and actionable for the intended use cases.

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

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds critical behavioral details: connector-dependent meaning of CREDIT balance, explanation of creditData fields (balanceCloseDate, balanceDueDate), and behavior when `item` is omitted vs included. 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 thorough but somewhat lengthy. It is front-loaded with purpose and key behaviors. Every sentence adds value, though minor redundancy could be trimmed. Still, excellent for agent clarity.

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

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

No output schema, but description thoroughly covers return fields (balance, number, type, etc.), caveats about CREDIT balance, and relationships to sibling tools. Complete for a 2-parameter, read-only 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 provides types but 0% description coverage. Description fully compensates: explains `item` controls scope (all banks vs single), `type` filters by account type, clarifies `name` field meaning and `bank` field usage. Adds meaning 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?

Description clearly states it returns accounts for a bank connection with BANK and CREDIT types, listing fields like balance, number, type, subtype, bankData, creditData. It distinguishes from sibling tools like openfinance_list_credit_card_bills by noting when to use each.

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

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

Explicitly explains when to omit `item` (to list across all banks) vs pass it (to target a single bank). Advises against treating CREDIT balance as monthly bill and directs to openfinance_list_credit_card_bills for standardized amounts. Provides clear context for agent decision-making.

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 caching and single aggregated response details beyond annotations (readOnlyHint, idempotentHint). It provides behavioral context without contradicting 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 yet comprehensive, covering purpose, caching, response fields, and usage hints in a single paragraph with 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?

Given no parameters and no output schema, the description fully explains what the tool returns and how to use the data, including the significance of the 'id' field for another 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 and schema coverage at 100%, the baseline is 4. The description does not need to add parameter info; it instead focuses on the output.

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 Pluggy's transaction category taxonomy (GET /categories), cached. It specifies the response structure and distinguishes from sibling tools by focusing solely on categories.

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 caching behavior and suggests preferring descriptionTranslated for pt-BR users. Although it doesn't explicitly state when not to use it, the tool is the only category-listing option among siblings, making usage 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, destructiveHint. Description adds specific return fields and mentions 'add_connection_url' for linking additional banks, but doesn't expand on side effects, errors, or rate limits. Value added beyond annotations is moderate.

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 clearly states the tool's purpose and key return fields. No unnecessary words; front-loaded with the action and resource.

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

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

No output schema, but description lists key return fields. For a simple read-only list tool with no parameters, the description covers the main aspects. Could mention if the list is paginated or filtered, but 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?

No parameters, so schema coverage is 100%. Baseline is 4, and description doesn't need to add param info. The description briefly notes the return fields, which is sufficient for a parameterless tool.

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

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

Clearly states it returns saved bank connections and lists specific fields (connector_id, item_id, bank name, add_connection_url). Differentiates from sibling tools like 'openfinance_list_accounts' or 'connect' by focusing on connections rather than other entities.

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

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

No explicit guidance on when to use this tool vs alternatives. The description implies it's for viewing connections, but doesn't mention criteria for choosing between this and related tools like 'openfinance_list_accounts' or 'authenticate'.

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

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

The description explains several behavioral traits beyond the readOnlyHint and idempotentHint annotations: the derived payment_status logic, how payments are assigned to cycles, the open_bill availability flag with reasons for false, and the meaning of total_pending_debt. It also warns about the variable meaning of the CREDIT account's balance across connectors.

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

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

The description is lengthy but necessary given the complexity of Brazilian Open Finance semantics. It is front-loaded with the main purpose and key fields, and every section adds value. A minor deduction for not being more streamlined, though the density is justified.

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 absence of an output schema and the tool's complex domain, the description covers all necessary aspects: return structure, derived fields, cross-bill payment logic, open bill behavior with connector asymmetry, and cross-references to sibling tools. It even provides a legend for payment_status. The completeness is exceptional 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?

Despite 0% schema description coverage, the description thoroughly explains the critical parameters: include_open_bill (opt-in, what it returns, open_bill structure, and fallback), account_ids (bulk support), and implicitly account_id (the credit account). Pagination parameters (page, page_size) are typical for list endpoints and require no further explanation in this 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 it returns CLOSED credit card bills for a CREDIT-type account, listing key fields and derived aggregates. It distinguishes from the sibling tool openfinance_get_credit_card_bill (which retrieves a single bill) and other list tools like openfinance_list_transactions. The verb 'list' and resource 'closed credit card bills' are specific and unambiguous.

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

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

Explicit guidance is provided: when to use include_open_bill (opt-in for open bill and total debt), when to use an alternative tool for itemized purchases (openfinance_list_transactions), and what not to assume (e.g., 'do NOT assume this bill was paid just because payments[] is non-empty'). It also cautions about connector asymmetry and advises against calling a bill 'vencida' categorically.

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 by describing that the tool returns a warning structure instead of throwing errors (e.g., 403). Also lists the types of investments returned, which is not covered by annotations.

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

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

The description is front-loaded with the main purpose and includes necessary details about return fields and error handling. It could be more concise but it's efficient and informative.

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 provides a partial list of return fields but does not explain all parameters or fully describe all fields. The tool complexity (4 params, detailed return) requires more completeness for an agent to use effectively.

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

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

Schema description coverage is 0% and the description does not explain any of the 4 parameters (item, page, type, page_size). The description fails to compensate for the lack of schema descriptions, providing no guidance on parameter usage.

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

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

Clearly states the tool returns the investment portfolio for a connection, listing specific financial products (FIIs, stocks, ETFs, fixed income, etc.) and distinguishing it from sibling tools like list_accounts and list_transactions.

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

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

Implies usage for retrieving investment data, mentions condition (connection with INVESTMENTS product enabled) and error behavior, but does not explicitly state when not to use it or suggest alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing it as a safe, read-only, idempotent operation. The description adds value by detailing the return structure (quantity, value, amount, expenses, etc.), which annotates the output beyond what annotations provide.

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

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

The description is concise with two well-structured sentences. The first sentence defines purpose and output, the second adds usage context. Every sentence is meaningful 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?

The tool has 4 parameters, no output schema, and moderate complexity. The description covers the return format and parameter purpose for investment_id/ids, but fails to address pagination parameters (page, page_size), which is essential 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 description coverage is 0%, so the description must compensate. It explains the use of investment_id and investment_ids for bulk queries, but ignores page and page_size parameters entirely, leaving agent without guidance on pagination.

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 an investment position, listing specific types (BUY/SELL/TAX/INTEREST/AMORTIZATION/TRANSFER) and fields. This distinguishes it from sibling tools like openfinance_list_investments, which likely returns the positions themselves.

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

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

The description explicitly advises using openfinance_list_investments first to get the investment_id, providing clear sequential usage. It also mentions bulk support with investment_ids. However, it does not discuss when not to use this tool or compare with alternatives like openfinance_list_transactions.

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

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

Annotations indicate read-only and idempotent; description adds that multiple connections are queried sequentially with rate-limit spacing, and returns per-connection results/errors. 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, front-loaded with purpose, no wasted words. Each sentence adds value: action, parameter usage, omission behavior, and rate-limit note.

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 parameter and behavior well; hints at output format. Lacks details on error content, pagination, or connection limits. Without output schema, some minor gaps remain, but sufficient 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 coverage is 0%, so description carries full burden. It explains items as connection selectors (item_id, connector_id, connector_name), how omission works, and that multiple connections are handled sequentially. 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?

Description clearly states it lists loan contracts per bank connection, with specific verb 'Lists' and resource 'loan contracts'. It distinguishes omission vs. inclusion of items, and the name differentiates from other list tools among siblings.

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

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

Describes how to use the items parameter (include for specific connections, omit for all) but does not explicitly compare to sibling list tools or state when to use this tool over alternatives. Lacks explicit when-to-use or when-not-to-use guidance.

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

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

Adds significant behavioral context beyond annotations: explains CREDIT pending/posted variance, search aggregation up to 5000, truncation flag, error return instead of throw, and bulk support. 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?

Somewhat long but front-loaded with essential info. Every sentence adds value. Organized into clear paragraphs. Could be slightly more concise, but 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?

Very thorough: covers edge cases (CREDIT pending/posted, truncation, zero total troubleshooting), bulk support, and references sibling tools. Missing return structure specification (no output schema), but otherwise 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 0% description coverage, but description explains from/to (ISO format), page_size (max 500), search_queries (substring match, OR semantics, aggregation), and account_ids for batch. Could be slightly more structured but compensates well.

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

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

The description clearly states it returns transactions for BANK or CREDIT accounts, distinguishes CREDIT usage from openfinance_list_credit_card_bills, and mentions bulk support. Purpose is specific and unambiguous.

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

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

Provides extensive guidance: when to use vs credit card bills, date filters, pagination, search_queries behavior, error handling, and troubleshooting for zero total on CREDIT accounts. Clearly differentiates from 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating safe read operations. The description adds significant behavioral context: it explains that the tool resolves accounts internally, fans out transactions, and caps scanning at 5000 per account with a truncation flag. It also describes the default granularity and the compact summary output. 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 longer than average but every sentence adds necessary information. It is front-loaded with the core purpose and key differentiator (resolving accounts internally). The structure flows logically from purpose to parameters to output details. There is no wasted text; it is concise for the amount of information conveyed.

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 lack of an output schema, the description thoroughly explains what the return value contains: total entradas, saídas, saldo_liquido, monthly evolution (por_mes), top expenses/revenues (top_despesas, top_recebimentos), and per-account breakdown (by_account). It also mentions the truncation flag for large datasets. All six parameters are covered, and the description distinguishes itself from sibling tools effectively.

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

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

Despite 0% schema description coverage, the description explains most parameters in detail: 'item' can be connector_id, connector_name, or item_id; 'from'/'to' are ISO dates; 'granularity' enum values are explained ('monthly' gives compact summary, 'raw' gives all transactions); 'type' filters BANK or CREDIT. The 'top_n' parameter is implied by the mention of 'top_despesas' and 'top_recebimentos'. Minor gap: 'top_n' not explicitly linked to the top-N lists, but context is sufficient.

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

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

The description clearly states the tool's purpose: 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call.' It distinguishes itself from siblings by noting that it resolves accounts internally, eliminating the need for separate calls to openfinance_list_accounts. Specific use cases like 'análise anual/mensal' and 'fluxo de caixa' are listed, making the purpose concrete and differentiated.

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 (e.g., for annual/monthly analysis, cash flow) and when to set granularity to 'raw' for itemized rows. It also advises against needing to call openfinance_list_accounts first. However, it does not explicitly mention alternatives when not to use this tool, such as when only raw transaction rows are needed without summary, but the granularity option covers that.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating safe, non-destructive behavior. The description adds value by detailing the return information: global indicator, degraded components, open incidents, and flags for affected banks, which is beyond what annotations provide.

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

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

The description is two sentences, front-loaded with the core purpose, then usage guidance, then a brief output summary. Every sentence is efficient and contributes meaningfully, with 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?

Given no parameters, no output schema, and a complex context with many sibling tools, the description is highly complete. It clearly distinguishes the tool, explains when to use it, and outlines the output, leaving no gaps for this use case.

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 no parameters, and the input schema is fully covered (100%). According to guidelines, baseline is 4 for zero-parameter tools, and the description adds no unnecessary 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 checks the LIVE operational status of the Open Finance provider, distinguishing it from the sibling tool openfinance_get_item_status by specifying it's the provider's health, not the user's connection. The verb 'Checks' and resource 'LIVE operational status' 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 explicit guidance on when to use this tool: when data looks incomplete or stale despite a connection showing UPDATED. It explains the tool helps differentiate between provider-side problems and connection issues, effectively telling the agent when to call this tool versus others.

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, not destructive. Description adds valuable behavioral context: honors user's plan (PF hides PJ), returns a pre-built connect_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?

Efficiently structured: first sentence states core function and returns, then outlines behavior (plan honor), then usage instruction. Every sentence adds information; no fluff.

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

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

Given no output schema, description fully explains return fields (id, access, audience, connections, accounts, connect_url) and edge cases (empty keywords, plan filtering). Sufficient for agent to understand and invoke correctly.

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

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

Schema coverage is 0%, so description must compensate. Explains keywords[] well (required, example values, returns hint if empty). For include_accounts, only says it includes accounts, lacking detail on behavior when false or its impact. Adds some but not full value.

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 and lists returned fields (id, access, audience, connections, connect_url). Explicitly distinguishes from siblings by focusing on pre-connection search, not listing existing connections.

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

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

Explicitly instructs to call this BEFORE connecting to provide a one-click link. Notes that keywords[] is REQUIRED and without it returns a hint. Could be stronger on when not to use (e.g., use other tools for listing connections), but still 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?

Beyond annotations (which declare no read-only or destructive behavior), the description reveals that updating a category creates a Category Rule affecting future transactions, and details batch error handling ('per-item errors do not fail the whole batch'). This adds critical 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 efficiently structured: it starts with the primary action, then explains parameter sources, side effects, and batch behavior. Every sentence adds value without redundancy.

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

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

Given the tool's complexity (one parameter with nested structure, no output schema, sparse annotations), the description covers purpose, usage, parameter semantics, behavioral side effects, and response format completely. No critical 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 compensates by explaining that 'items' is an array of {transaction_id, category_id} and specifies the origin of each ID. It could provide more detail on value formats or constraints, but the given explanation is adequate.

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

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

The description explicitly states 'Corrects the category of one or more transactions' and references the HTTP method and endpoint. It clearly distinguishes this tool from siblings like openfinance_list_transactions and openfinance_list_categories by addressing categorization updates and rule creation.

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 using this tool to 'fix miscategorized transactions and improve categorization accuracy,' and provides context on sourcing transaction_id and category_id from sibling tools. It lacks explicit when-not-to-use conditions but gives sufficient guidance for correct invocation.

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

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

Annotations indicate 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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds specific behavioral context by detailing exactly what the return value includes (installed MCPs, connection status, catalog tool counts). This goes beyond the annotations' safety profile.

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

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

The description is a single sentence with no waste. It front-loads the action ('Returns the current toolkit state') and then lists the specific information items. Every word 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?

With no output schema, the description appropriately explains the return value in sufficient detail for a simple info tool. It lists three categories of information, which is adequate for an AI agent to understand what to expect. Could optionally clarify how to interpret connection statuses.

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

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

There are no parameters, so schema coverage is 100%. The description does not need to add parameter information. The description focuses on the return value, which is appropriate given the absence of parameters.

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

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

The description uses a specific verb ('Returns') and clearly identifies the resource ('current toolkit state') and the three types of information returned (installed MCPs, connection status, catalog tool count). It distinguishes itself from siblings (e.g., openfinance_* tools, authenticate) by being a general status/diagnostic tool.

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

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

The description does not explicitly state when to use this tool versus alternatives or mention any prerequisites. While it's implied as a diagnostic tool for checking toolkit health, there is no guidance on when not to use it or which sibling tools to use instead.

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