Banco PAN MCP

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds behavioral context: calling with no args returns a link, providing a token logs in for the session. It does not contradict annotations and provides useful details about the two modes of operation.

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

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

The description is three sentences long, front-loads the purpose, and uses clear, direct language. Every sentence adds value, and there is no redundancy or unnecessary information. It is highly concise and well-structured.

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

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

For a simple authentication tool with no output schema, the description covers the two main use cases and the parameter. It could be improved by briefly mentioning what happens after successful authentication (e.g., session state change), but overall it is complete enough for an agent to use correctly.

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

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

The schema has a single optional parameter 'token' with no description (0% coverage). The description explains that 'token' is a JWT obtained from the browser, and omitting it will return a login link. This adds essential meaning that the schema lacks, fully compensating for the coverage gap.

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

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

The description clearly states the tool's purpose: authentication for MCP.AI IDE agents. It explains two distinct methods (permanent config vs. session token) and specifies the action of logging in via browser and copying the access token. This is specific and distinguishes the tool from potential siblings.

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

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

The description provides clear guidance on when to use each authentication method: 'Best: add it to this server's config...' for a permanent connection, or 'paste it here for a session-only login'. It also explains calling with no args to get the login link. However, it does not explicitly compare to sibling tools like 'connect', so it loses a point for not differentiating from 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 indicate read-only and idempotent behavior. The description adds specific behavioral context: what happens when all providers are connected vs. when credentials are missing. 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 two sentences with no wasted words. The first sentence states the overall purpose, and the second provides scenarios on the return value. It is front-loaded and 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 zero parameters and no output schema, the description explains the return structure reasonably well (authenticated flag, pending array, connect_url). However, it could be more detailed about URL formats, but overall it is sufficient for tool understanding.

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 the baseline is 4. The description does not need to add parameter semantics, but it correctly implies no input is needed. It adds value by explaining the output based on state.

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. It distinguishes between connected and missing credentials states, providing specific return fields (authenticated, pending, connect_url). This sets it apart from sibling tools like authenticate, which likely perform actions.

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

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

The description implies usage for checking connection status by describing both success and failure scenarios. It gives clear context on when each type of output is returned. However, it does not explicitly state when to use alternatives, such as 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?

Beyond annotations (readOnlyHint=false, openWorldHint=true), the description discloses key behaviors: invoke works without installation, returns connect/checkout links when needed, and writes require workspace owner/admin. It also explains that install makes an MCP permanent. This adds significant contextual value beyond the structured fields.

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

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

The description is detailed and front-loaded with the core purpose. While long, every sentence adds value by covering specific behaviors and use cases. It could be slightly more concise, but the structure supports understanding of a complex tool with multiple actions.

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

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

Given the tool's complexity (13 parameters, 10 actions, no output schema), the description covers the main flows, user scenarios, and edge cases (e.g., credential requirements, billing). It does not detail return values, but the actions are described sufficiently. Overall, it provides a solid understanding for an AI 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?

With 0% schema coverage, the description compensates by explaining the actions (search, describe, install, invoke, etc.) and linking parameters like tool_id and arguments to invoke. However, many parameters (e.g., message, immediate, tier_slug, conversation, request_name, report_context, request_details) are not described. The description provides functional context but misses details on lower-level 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 clearly states the tool is 'THE official mcp.ai marketplace' and defines its dual role as catalog and execution platform. It explicitly distinguishes from external registries and outlines the core flow (search → describe → invoke). This provides a precise purpose that differentiates it from sibling 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 gives explicit guidance on when to use this tool ('use THIS tool FIRST, before any external/generic registry'), contrasts invoke vs install ('prefer invoke for a single/occasional use'), and describes when other actions like list_tools or request_mcp are appropriate. This is comprehensive and helps the agent select the correct approach.

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 aligns with annotations (destructiveHint=true) and adds valuable behavioral context: data will no longer be available and a re-connection URL is returned. This goes beyond the mere annotation flags, providing clear side-effects.

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

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

The description is very concise: three sentences that front-load the main action and immediately state consequences. No unnecessary words or repetition.

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 destructive tool with one parameter and no output schema, the description adequately covers the action, effect, and return value. However, it does not address potential error states or idempotency (annotations say not idempotent), leaving minor 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?

The single 'item' parameter is not described in the input schema (0% coverage), but the description mentions 'a specific bank', implying that 'item' identifies the bank. This adds some meaning, though not explicit syntax or format. A more detailed parameter description would improve clarity.

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: revokes Open Finance consent and deletes connection data for a specific bank. The verb 'revokes' and resource 'consent for a specific bank' are precise, and the tool is distinguished from siblings like openfinance_list_connections by its destructive nature.

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

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

The description implicitly guides usage: use when you need to disconnect a bank. It mentions the return of a re-connection URL, which provides context for subsequent actions, but lacks explicit when-to-use or when-not-to-use comparisons with 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?

Fully describes behavior: waits up to 60s, polls until done, returns status fields like 'needs_action', 'timed_out', and explains the wait parameter for fire-and-forget mode.

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

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

The description is a single paragraph but well-organized. Every sentence adds value, though slightly long; could be broken into bullet points for easier reading.

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

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

Given only 2 parameters and no output schema, the description provides complete guidance: return format with fields explained, error handling, and suggested next steps.

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

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

Schema has no descriptions (0% coverage). The description explains each parameter: items accepts selectors (item_id, connector_id, connector_name) and can be omitted to sync all; wait controls synchronous vs fire-and-forget 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 the tool 'forces the bank to re-sync one or more connections' and distinguishes it from sibling tools like openfinance_get_item_status which only checks 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 says when to use (stale balance/transaction list), what it does (force sync without disconnecting), and provides alternatives (re-check with openfinance_get_item_status if timed out).

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 the tool safe and idempotent. The description adds significant behavioral context: real-time data, partial error handling (structured warnings for CREDIT accounts instead of exceptions), and response shape. This fully informs the agent of edge cases.

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 fluff. Every sentence adds unique information (endpoint, array constraint, error handling, response structure).

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 one-parameter tool with no output schema, the description covers everything an agent needs: input constraints, error behavior, and response format. It is sufficiently complete for reliable invocation.

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

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

The schema has 0% description coverage, so the description must explain parameters. It does: specifies 'account_ids' as an array, size 1-50, and notes CREDIT account error behavior. This adds value beyond the raw schema, though it could mention format constraints or defaults.

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 real-time balance per account ID, referencing the specific endpoint. Although it doesn't explicitly distinguish from siblings, the resource 'balance' is unique among sibling tools, making the purpose unambiguous.

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

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

The description provides constraints (array size 1-50) and special behavior for CREDIT accounts, but does not explicitly advise when to use this over siblings like list_accounts or get_accounts_detail. Usage is implied through the resource specificity.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context: returns extended creditData, batch shape {results, errors}, and HTTP method (GET). No contradictions. Could mention error handling details, but acceptable.

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 fluff. First sentence states purpose and includes HTTP path in parentheses for clarity. Second sentence gives parameter format and return shape. Every word is necessary.

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?

Tool is simple with one parameter and clear annotations. Description covers input constraints, batch behavior, and return shape. Lacks output schema but the {results, errors} shape is described. Sufficient for the tool's complexity.

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

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

With 0% schema coverage, description compensates by explaining 'account_ids' must be an array of 1–50 strings, and that the call is batched. This adds meaning beyond the bare schema 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 uses specific verb 'Returns' and noun 'full account objects including extended creditData'. It clearly distinguishes from sibling tool 'openfinance_list_accounts' by specifying the detail level and batch processing per 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?

Description states to pass 'account_ids' as an array (1–50), implying batch retrieval. It does not explicitly contrast with alternatives, but the detail-oriented purpose and sibling name 'list_accounts' suggest when to use this 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?

Adds value beyond annotations by clarifying return shape, missing status field, and the nuanced meaning of payments array. Addresses potential misinterpretation.

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?

Longer than minimal but every sentence adds value. Front-loaded with main purpose. Minor redundancy could be trimmed but overall efficient.

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

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

Despite no output schema, description explains return fields and batch shape. Covers necessary context for usage. Could mention that results contain each bill's detail.

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 that bill_ids is an array of strings, advises to use list tool to discover ids, and mentions batch shape. Good compensation for lack of schema descriptions.

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

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

Clearly states it returns bill-level detail for credit card bills by id, distinguishes from sibling tools like openfinance_list_credit_card_bills and openfinance_list_transactions.

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

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

Explicitly tells when to use (get bill detail) and when not (for transactions, use another tool), provides prerequisite (list bills first), and warns about payment field interpretation.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is safe. Description adds behavioral context: the conditional behavior (single vs. bulk) and the data returned (status, executionStatus, connector metadata). 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, no filler. 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?

Given one optional parameter, no output schema, and well-covered annotations, the description is complete. It explains both invocation modes, the returned fields, and the bulk response format ({count, items}). Sufficient for correct tool selection and invocation.

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

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

Schema has one optional 'item' parameter with no description (0% coverage). Description fully compensates by explaining the two distinct use cases: omit for all banks, pass for a single bank. This adds critical meaning beyond the schema type.

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 bank connection status with specific possible values (UPDATED, UPDATING, LOGIN_ERROR, etc.), and distinguishes between single and bulk retrieval. Differentiates from sibling tools like openfinance_list_connections by focusing on 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 states when to omit or pass the 'item' parameter for single vs. all banks. Provides clear context, though no explicit alternatives are given; sibling list implies existence of other list-type tools.

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

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

Annotations already indicate readOnlyHint and idempotentHint. Description adds critical context: CREDIT balance meaning is connector-dependent and explains creditData fields, 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?

Description is long but densely informative, front-loaded with main purpose. Each sentence adds value, though some rephrasing could reduce length slightly without losing substance.

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 key returned fields (balance, name, bank, creditData) and links to another tool for credit card bills. Adequate for the tool's complexity with 2 optional parameters.

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

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

Schema has 0% description coverage, but description explains `item` (optional, target single bank) and implies `type` enum. Adds meaning but could explicitly describe `type` parameter 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 accounts for bank connections with specific types (BANK/CREDIT) and fields. It distinguishes from sibling tools like openfinance_list_credit_card_bills by explaining the difference in balance meaning.

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 omit or pass the `item` parameter for listing across all banks vs targeting a single bank, and advises against misinterpreting CREDIT balance, directing to the appropriate sibling tool for standardized bill amounts.

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

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

Annotations already declare readonly, idempotent, and non-destructive. The description adds that it is cached for the adapter session and that it returns a single aggregated response (no batch ids). This adds useful behavioral context beyond annotations.

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

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

Three clear, front-loaded sentences with no wasted words. Each sentence adds distinct value: what it returns, the fields, and caching behavior.

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 what the tool does, its output format, and its relationship to a sibling tool. It covers all relevant aspects for an agent to use it correctly.

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

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

There are no parameters, so the input schema is fully covered. The description compensates by detailing the output structure, which is valuable since there is no output schema.

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

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

Description clearly states it returns the transaction category taxonomy (GET /categories) and specifies the fields (id, description, descriptionTranslated, parentId, parentDescription). It distinguishes itself by naming the sibling tool openfinance_update_transaction_category and noting that it is a single aggregated response, which differentiates it from potential batch-oriented 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 as a prerequisite for openfinance_update_transaction_category and gives guidance on preferring descriptionTranslated for pt-BR users. However, it does not explicitly state when not to use it or compare to alternatives among the large sibling list, leaving some context implicit.

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 value by specifying the returned fields and the inclusion of an add_connection_url, which is behavioral context 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?

Single sentence, no fluff. Important details are front-loaded: returns saved bank connections, then lists fields. Efficient and well-structured.

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

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

For a read-only list tool with no output schema, the description adequately covers what is returned and the purpose. Annotations provide safety guarantees. Context signals show no output schema, so the description compensates fully.

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 coverage is 100%. The description adds meaning by detailing what the tool returns, which is valuable since there is no output schema. For zero parameters, baseline is 4, and description meets it.

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

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

The description clearly states that the tool returns saved bank connections, listing specific fields like connector_id, item_id, bank name, and add_connection_url. This distinguishes it from sibling list tools (e.g., list_accounts, list_transactions) which cover different resources.

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

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

The description implicitly indicates usage by stating 'for this install', but does not explicitly contrast with alternatives. However, the tool name and context make it clear this is for listing bank connections, not for other list operations.

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

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

Annotations declare readOnlyHint and idempotentHint, but the description adds critical behavioral context: payment status derivation, payment cycle logic, open bill fallback, and connector limitations. 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 very detailed but overly verbose. It contains multiple paragraphs and nested explanations. While front-loaded with purpose, the length could be reduced for better conciseness.

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

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

Given the complexity (payment semantics, open bill, connector asymmetry) and absence of output schema, the description thoroughly covers all behavioral aspects, edge cases, and derived fields. It is complete enough for correct tool 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 must compensate. It explains account_id, account_ids (bulk support), and include_open_bill (opt-in, derived fields). However, it does not describe page and page_size parameters for pagination, which is a minor gap.

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

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

The description clearly states the tool returns CLOSED credit card bills for CREDIT-type accounts. It distinguishes itself from sibling tools like openfinance_get_credit_card_bill and openfinance_list_transactions by specifying scope and directing to other tools for 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 guidance on when to use (get closed bills), when not to assume payment status, and alternatives: use openfinance_list_transactions for itemized purchases, use open_bill derived fields instead of balance. Also cautions about connector asymmetry and bulk support.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool returns a structured fallback response on errors (403 or upstream errors) and lists fields like balance, amount, dueDate. It lacks details on pagination or rate limits.

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 a list of asset types, followed by a second sentence on error handling. It front-loads the purpose and is relatively concise, though the list of asset types could be abbreviated.

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

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

The description explains the return structure ({ total, results, warning }) and lists fields, fulfilling part of the output need. However, it does not explain how the parameters (page, page_size) affect results or provide full parameter guidance, which is needed given no schema descriptions.

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 the parameters (item, page, type, page_size) beyond mentioning 'connection' for item. The type parameter enum values are not mapped to asset types listed in the 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 an investment portfolio for a connection with INVESTMENTS product enabled, listing specific asset types. However, it does not explicitly differentiate 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?

The description indicates this tool is for connections with the INVESTMENTS product enabled and mentions handling of errors. It does not provide guidance on when not to use it or alternatives among 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 provide readOnlyHint, idempotentHint, destructiveHint. The description adds value by detailing output fields (e.g., quantity, value, expenses breakdown) and transaction types, 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?

Two short paragraphs clearly convey purpose, output details, usage order, and bulk support. No wasted words; front-loaded with key 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?

Given lack of output schema, the description compensates by listing output fields. However, missing parameter descriptions (page, page_size) and no mention of error handling or rate limits. Annotations cover safety, but parameter info is incomplete.

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. It explains investment_id and investment_ids, but omits page and page_size parameters, which are important for bulk operations. Partial coverage leaves gaps.

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 movement history for a specific investment position and lists transaction types (BUY, SELL, etc.). It differentiates from siblings like openfinance_list_investments by specifying the unique resource and output.

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 after openfinance_list_investments to get investment_id, and mentions bulk support via investment_ids. It does not explicitly state when not to use or compare with similar tools like openfinance_list_transactions, but provides clear context.

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

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

Beyond annotations (readOnlyHint, etc.), describes sequential querying with rate-limit spacing and per-connection return format. 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?

Concise, front-loaded with main purpose, followed by essential 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?

Complete for a simple tool with one optional parameter and no output schema. Covers purpose, parameter usage, behavioral traits, and return structure.

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 fully explains the `items` parameter as connection selectors (uuid, connector_id, or connector_name) and the behavior when omitted.

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

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

Clearly states it lists loan contracts per bank connection, distinguishing it from sibling tools like list_accounts or list_transactions. Uses specific verb and 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?

Provides clear instructions: use `items` for specific connections or omit for all. Implicitly distinguishes from other tools by resource type, but no explicit when-not-to-use or alternatives.

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

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

Beyond annotations (readOnlyHint, destructiveHint), the description adds substantial behavioral context: auto-pagination up to 5000 ceiling (truncated:true), search behavior (substring match, OR semantics, aggregation before filter), error handling (returns object with warning/error instead of throwing), and detail level trade-offs (coverage varies by bank, tokens per row). It also explains CREDIT PENDING vs POSTED variation by connector.

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

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

The description is long but well-structured: first paragraph covers credit card specifics, second covers date filters and search, third covers pagination and errors, fourth covers detail levels, final sentences cover other tools and bulk support. It is front-loaded with main purpose. While verbose, every sentence adds necessary detail given the tool's complexity.

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

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

Given the complexity (8 params, no output schema), the description is highly complete. It covers return format (truncated:true, warning, error), pagination behavior, error handling, search behavior, detail levels, credit card specifics, and references to related tools for missing info. It addresses edge cases like zero total for credit accounts and suggests checking connection health.

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. It explains all parameters: account_id (required), from/to (ISO YYYY-MM-DD), page and page_size (pagination logic, max 500), detail (enum with defaults and behavior), search_queries (array, substring match, OR semantics, pre-filter aggregation). It also explains the truncation warning and need to narrow from/to. No parameter lacks explanation.

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

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

The description clearly states the tool returns transactions for bank accounts of type BANK or CREDIT. It distinguishes from sibling openfinance_list_credit_card_bills by noting that for CREDIT accounts, this is the only way to get itemized transactions, and that credit card bills are linked via creditCardMetadata.billId. The verb 'returns' and resource 'transactions' 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 provides explicit when-to-use and when-not-to-use guidance: for credit card bills, suggests using openfinance_list_credit_card_bills for totals; for statement dates, suggests openfinance_list_accounts; for connection health, suggests openfinance_get_item_status. It details when to use different detail levels (compact, rich, raw) and when to narrow from/to if truncated. It also explains pagination options (omit page for auto, pass page for manual).

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

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

Annotations declare readOnlyHint=true and idempotentHint=true, which align with the description's read-only nature. The description adds beyond annotations: it notes a scan cap of 5000 transactions per account with a `truncated:true` flag, and describes the output structure (compact summary vs raw rows). 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 verbose and contains a lot of information, but it is well front-loaded with the core purpose. However, it could be more concise by breaking into shorter sentences or bullet points. Each sentence adds value, but the length may overwhelm an agent scanning for key details.

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 explains the output format in detail (fields like entradas, saídas, por_mes, etc.) and behaviors for different configurations (granularity, detail). For a tool with 7 parameters and no output schema, the description is quite complete, though it could mention error scenarios or limits more explicitly.

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

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

Input schema has 0% description coverage, but the description thoroughly explains all 7 parameters: `item`, `from`, `to`, `granularity`, `detail`, `type`, `top_n`. It specifies default values (e.g., `granularity:'monthly'`) and the meaning of each option (e.g., `detail:'rich'` enriches rows with merchantInfo). This fully compensates for the 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 provides consolidated cash-flow analysis for a bank connection over a period in one call. It distinguishes from siblings by explaining it resolves accounts internally, avoiding the need to call openfinance_list_accounts first. Specific use cases are listed (análise anual/mensal, fluxo de caixa, etc.).

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 when to use this tool (consolidated analysis) and provides alternatives implicitly (e.g., if you need per-account transactions without aggregation, you might use openfinance_list_transactions). It states that omitting the `item` parameter analyzes all linked banks, and specifies when to set `granularity: raw` for itemized rows. However, it lacks explicit 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?

Annotations declare readOnlyHint, idempotentHint, and non-destructive. Description adds return fields (global indicator, degraded components, incidents, your_banks_affected) and explains interpretation, exceeding annotation coverage.

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

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

Well-structured, front-loaded purpose and usage, with each sentence providing unique value. Length appropriate for the detail.

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 all key return fields and provides usage context. Complete for a zero-parameter status check tool.

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

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

No parameters; schema coverage 100%. Description doesn't need to add param info, but baseline for zero parameters is 4.

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

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

Clearly states it checks the LIVE operational status of the Open Finance provider, distinguishing from sibling tool openfinance_get_item_status. Specific verb+resource with explicit differentiation.

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

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

Explicitly states when to use (when data looks incomplete/stale despite updated connection) and what it reveals (upstream outage vs connection issue), with clear alternative reference.

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 non-destructive. The description adds important behavioral traits: some connectors have a caveat about manual reconnection, and the tool honors the user's plan (PF hides PJ banks). These details go beyond what annotations provide and are crucial for correct tool use.

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

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

The description is a single, well-structured paragraph of about 5 sentences. It front-loads the main purpose, then covers return fields, special caveats, plan-based filtering, and usage instruction. Every sentence adds value with no redundancy.

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

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

Despite no output schema, the description explains all return fields per match: connector id, access, audience, linked connections, accounts (when include_accounts=true), and connect_url. It also covers edge cases like caveats and plan-based filtering. For a tool with two parameters and search functionality, this is fully complete.

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

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

Schema description coverage is 0%, so the description must explain parameters. It does so effectively: keywords[] is explained with examples and noted as REQUIRED (returns hint if omitted), and include_accounts is explained as returning accounts when true. This fully compensates for the lack of schema descriptions.

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

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

The description clearly states the tool searches bank connectors by name, returns specific fields including connector id, access type, audience, linked connections, and a connect_url. It distinguishes itself from siblings by explicitly stating it should be called BEFORE connecting and that it never dumps the whole catalog, making its purpose 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?

It provides explicit usage guidance: 'Call this BEFORE connecting to hand the user a one-click link to the right bank.' It also specifies that keywords[] is required and warns against dumping the catalog, giving clear when-to-use and when-not-to-use instructions.

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 goes beyond annotations by detailing the side effect: recategorizing creates a Category Rule that affects future similar transactions. It also explains batch behavior, including partial success with per-item errors not failing the whole batch, and the response format. This provides comprehensive insight into what happens when the tool is invoked.

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 core action and then logically flows to parameter details, side effects, and error handling. Every sentence adds value, though it is slightly wordy. It could be trimmed slightly, but remains well-organized.

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 (batch update with side effects) and absence of an output schema, the description covers all necessary aspects: input requirements, ID sources, behavioral side effects, response format, and error handling. An agent can correctly select and invoke this tool without ambiguity.

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?

Though the input schema has no descriptions (0% coverage), the description fully compensates by explaining the 'items' array structure, each item's required fields (transaction_id, category_id), and their origins. It also describes the response shape for the batch, 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 the action: 'Corrects the category of one or more transactions' with a specific HTTP method and endpoint. It distinguishes from sibling tools like openfinance_list_transactions and openfinance_list_categories by referencing them as sources for IDs. The purpose is unequivocal and actionable.

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 where to obtain the required IDs (from openfinance_list_transactions and openfinance_list_categories) and states the use case: fixing miscategorized transactions and improving future categorization. It does not explicitly list when not to use it, but the side effect of creating a Category Rule is explained, helping agents decide appropriateness.

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 (idempotentHint: true, destructiveHint: false) already indicate the tool is safe and non-destructive. The description adds no behavioral context beyond 'report a bug', such as rate limits, confirmation, or state modification details.

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 short sentences, front-loading the core purpose and key parameter guidance. It is concise and avoids unnecessary detail.

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 bug report tool with 3 parameters and no output schema, the description covers the purpose and one parameter. Missing details on the context parameter and what happens after reporting (e.g., confirmation) reduce completeness.

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

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

Schema coverage is 0%, so the description must compensate. It explains the conversation parameter's purpose ('with recent messages for reproduction') and implies message is the bug report text. However, it does not clarify context or output 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 the tool reports bugs, missing features, or feedback. It distinguishes itself from sibling tools (e.g., authentication, finance management) by being the only feedback mechanism.

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

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

The description advises to include the conversation array with recent messages for reproduction, providing specific usage guidance. However, it does not specify when to use this tool versus alternatives or exclude cases, but given no direct alternatives, clarity is high.

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. The description adds context by specifying that both platform and adapter versions are shown, which is not in 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 sentence that is concise, front-loaded with the action, and contains 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?

Given no parameters and no output schema, the description sufficiently explains the tool's purpose and output (versions). It could mention the return format, but it is not essential for a simple version info 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?

There are no parameters, and schema coverage is 100%. The description does not need to add parameter meaning, but it clearly states what the tool does without parameter details, which 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 'Show the current MCP platform and adapter versions' uses a specific verb ('Show') and clearly identifies the resource (current versions). It distinguishes from sibling tools, none of which provide version information.

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 retrieving version info, which is clear given no parameters and no alternative among siblings. However, it does not explicitly state when or when not to use it, but this is less critical for a simple read-only 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?

Description adds specific details about returned content beyond annotations (readOnly, idempotent, non-destructive). It confirms the tool is a read-only state check, enhancing transparency without contradiction.

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

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

Single, front-loaded sentence covering purpose and content. Every word adds value; no redundancy or 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?

For a zero-parameter, no-output-schema tool, the description fully captures what the tool does and returns. No missing information given its simplicity.

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 correctly omits parameter details, and schema coverage is 100%, leaving no gaps.

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

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

Description clearly states the tool returns current toolkit state, specifying installed MCPs, connection status, and catalog tool counts. This distinguishes it from sibling tools like authenticate or show_version, which serve different purposes.

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 versus alternatives. However, the nature of an info tool implies use for initial inspection, but lacks clear context or exclusions.

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