Neon MCP

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

Annotations indicate idempotentHint=true, and the description aligns by describing token submission as idempotent. It explains the two modes (permanent vs session) and that calling without args returns a link, adding 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?

Description is slightly verbose but well-structured: starts with purpose, then best practice, then alternative. Every sentence adds value, but could be tightened.

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 one optional parameter and no output schema, the description covers all needed behavior: how to authenticate permanently or session-only, and how to get the login link.

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 the 'token' parameter usage: pass a JWT after user pastes, or omit to get login link. This compensates well 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 is for authentication, explaining how to log in and retrieve an access token. It distinguishes itself from sibling tools (e.g., connect, openfinance_*) by focusing solely on 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?

Provides explicit guidance: best to add token to server config, or paste for session, or call with no args to get the link. Clearly separates two use cases with clear when-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?

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context by specifying the exact return values (authenticated, pending, connect_url) and how they vary by connection state, 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 extremely concise with two sentences that efficiently convey the tool's behavior in two key states. 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?

The description covers the main scenarios (all connected vs missing credentials) adequately for a status check tool with no input parameters and no output schema. It could potentially mention error states or edge cases, but overall it is complete enough for most use cases.

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

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

The tool has no parameters, so the schema coverage is 100%. The description does not need to add parameter information; it correctly focuses on the return behavior. Baseline score of 4 is appropriate.

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

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

The description clearly states that the tool returns connection status and URLs, and distinguishes two scenarios (all providers connected vs missing credentials). While it doesn't explicitly differentiate from sibling tools, the purpose is clear and 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 implies usage by describing what is returned under different conditions, but it does not provide explicit guidance on when to use this tool versus alternatives like 'authenticate' or 'openfinance_provider_status'.

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

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

The description discloses important behaviors beyond annotations: invoke works even for uninstalled MCPs, returns connect/checkout links on credential/payment needs, and writes require workspace owner/admin. It also mentions installed flags and the prompt library's shareable links. No contradiction with annotations.

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

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

The description is a single dense paragraph containing substantial useful information. All sentences carry value, but the lack of structure (bullets/sections) and inclusion of a Portuguese word ('pontualmente') reduce scannability. It is appropriately sized for the tool's complexity but could be better 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 (23 parameters, 14 actions, no output schema), the description provides a comprehensive and actionable picture: core workflow, authentication/payment handling, permission requirements, and the prompt library. It covers critical paths and edge cases thoroughly, leaving little ambiguity 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?

With 0% schema description coverage, the description compensates by explaining the meaning of the 'action' parameter and related fields like tool_id, arguments, and tier_slug through the core flow. However, not all 23 parameters are explicitly covered (e.g., immediate, prompt_targets), leaving some ambiguity, though the most critical ones are addressed.

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 role as 'the official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them,' covering discovery, description, installation, and invocation. It distinguishes itself from sibling tools (e.g., openfinance_*) by being the central marketplace platform.

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

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

Provides explicit core flow (search → describe → invoke), and contrasts invoke vs install: 'Use install only to make an MCP PERMANENT in the active toolkit... prefer invoke for a single/occasional use.' It also explains when to use subscribe/cancel, report_bug, and request_mcp, and notes permission requirements for writes.

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

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

Annotations already indicate the tool is destructive (destructiveHint=true). The description adds value by explaining that connection data is deleted and data becomes unavailable, and it mentions the return of an 'add_connection_url' for reconnection. This provides 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?

The description is concise (two sentences, 25 words) and front-loaded with the core action. Every sentence adds essential information 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 simplicity (one parameter, destructive action, no output schema), the description covers the main effect and return value. However, it lacks explanation of the required 'item' parameter and any prerequisites (e.g., must be connected). The presence of sibling tools like 'openfinance_list_connections' suggests a context, but the description does not leverage that.

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

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

The input schema has one required parameter 'item' with no description (0% coverage). The description does not explain what 'item' represents (e.g., a bank identifier or connection ID), only implying 'a specific bank'. With low schema coverage, the description should compensate by clarifying the parameter, but it fails to do so.

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

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

The description explicitly states the tool revokes Open Finance consent, deletes connection data, and makes bank data unavailable. It uses specific verbs ('revokes', 'deletes') and clearly identifies the resource ('a specific bank'). This distinguishes it from sibling tools like 'openfinance_list_connections' or 'openfinance_get_item_status', which do not perform disconnection.

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 the tool should be used when wanting to disconnect a bank and delete its data, but does not explicitly state when not to use it or mention alternatives among sibling tools. However, the context is clear enough for an agent to infer appropriate usage.

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

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

Discloses sync process (PATCH, polling up to 60s), return fields (status, executionStatus, lastUpdatedAt, synced, needs_action, reconnect_url, timed_out), and behavior of wait parameter. Annotations only indicate non-read-only and non-destructive; description adds critical behavioral 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?

Description is somewhat lengthy but packs essential information. Each sentence adds value, though it could be more structured (e.g., separating parameters and return values) 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 no output schema, description covers all return fields and error scenarios (needs_action, timed_out). It also explains edge cases (reconnect_url, no disconnect) and provides fallback guidance. Highly complete.

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

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

Schema coverage is 0%, but description fully explains both parameters: 'wait' as boolean for fire-and-forget, 'items' as array of selectors with explanation of allowed values and omission behavior (sync all).

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 action: force re-sync of connections with waiting. It uses specific verbs and resources, and distinguishes from sibling tools like openfinance_disconnect_bank by emphasizing 'WITHOUT disconnecting/reconnecting'.

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

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

Explicitly says 'Use this when a balance or transaction list looks stale', providing clear context. It also advises to use openfinance_get_item_status if timed out, but does not list all alternatives.

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

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

The description adds significant context beyond annotations: details about CREDIT account errors (BALANCE_FETCH_ERROR), degradation to last-synced balance with warnings, and non-throwing behavior, which is not present in the readOnly/idempotent 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?

Every sentence provides distinct value: endpoint specification, parameter format, error/degradation scenarios, and response shape. No redundancy, well-organized for agent consumption.

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

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

Given the lack of output schema, the description fully describes the response shape and edge cases (errors, degradation), providing complete information for an agent to invoke and interpret results.

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

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

With 0% schema description coverage, the description adds valuable constraint: array size limit of 1-50. However, it does not explain where the account_ids come from or their format, which would further assist the agent.

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

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

The description clearly states the tool returns real-time balance payload per account id via a specific endpoint, distinguishing it from sibling tools like openfinance_list_accounts which list accounts rather than retrieve balance.

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 specifies the parameter requirement (array of 1-50 account_ids) and describes error conditions, but does not explicitly compare with alternative tools; however, the purpose is clear enough that agents can infer when to use it.

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

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

The description adds critical behavioral context beyond annotations: it warns about a provider_incident block that may make credit limits and balances unreliable, and instructs not to present those values as real. This is transparent and useful.

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

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

The description is well-structured and front-loaded with the purpose, but slightly verbose with the provider_incident detail. However, every sentence adds value, so it remains concise enough.

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

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

For a tool with one parameter and no output schema, the description fully explains the batch shape ({ results, errors }) and important edge cases (provider_incident), making it sufficiently complete.

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

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

The description adds the constraint that account_ids must be an array of 1–50 strings, which compensates for the 0% schema description coverage by providing semantic constraints not present in 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 tool returns full account objects including extended creditData per ID, referencing the specific endpoint GET /accounts/:id. It distinguishes from sibling tools like openfinance_list_accounts by focusing on detailed data for specific accounts.

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

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

The description implies usage for retrieving detailed account data but does not explicitly state when to use this tool over alternatives like openfinance_list_accounts. It provides no guidance on when not to use it.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. The description adds critical behavioral context: the batch shape {results, errors}, the absence of a paid/status field from Pluggy, the meaning of payments[] (payment of previous bill), and the sparse/inconsistent nature of creditCardMetadata.billId. 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 longer than average but every sentence serves a purpose: stating the function, what it does not do, how to use parameters, and caveats. It is front-loaded with the main purpose. Minor trimming could improve readability, but given the complexity, it is 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?

All necessary information is present: what the tool returns (bill-level details including financeCharges and payments), how to use the parameter, what it does not do (itemized transactions), and warnings about data interpretation. No output schema exists, but the description adequately covers the return shape and important limitations.

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 bill_ids should be passed as an array and that IDs come from openfinance_list_credit_card_bills. It does not provide additional type or format details beyond the schema, but the usage context adds value. Could be slightly more explicit about valid ID formats.

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

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

The description clearly states it returns bill-level detail for one or more credit card bills by ID, and explicitly distinguishes from openfinance_list_transactions which returns itemized transactions. It also contrasts with openfinance_list_credit_card_bills for discovering IDs and checking payment status.

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

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

The description provides explicit guidance on when to use this tool: after discovering IDs via openfinance_list_credit_card_bills, and when not to use it (for itemized transactions). It also warns against reconstructing bill totals from transactions and clarifies the meaning of payments[].

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

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

Beyond annotations (readOnly, idempotent, non-destructive), the description discloses behavioral details: reconnect_url reopens widget in UPDATE mode without disconnecting or consuming a slot, and bulk mode returns {count, items}. This adds significant value.

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 and well-structured, starting with the core functionality and layering details efficiently. 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 no output schema and sparse input schema, the description comprehensively covers return formats, fields included, and special behavior of reconnect_url. It provides sufficient context for an agent to invoke the tool correctly.

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

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

With 0% schema coverage, the description fully explains the meaning and effect of each parameter: omitting 'item' returns all banks, passing 'item' returns a single bank, and 'item_ids' enables batch execution. This is essential for correct 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?

The description clearly states it returns the current status of a bank connection, listing specific status values and additional fields like executionStatus and reconnect_url. It distinguishes between single and bulk modes and implies differentiation from sibling tools that focus on other aspects like accounts or 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 explains when to omit or include the 'item' parameter for single vs. all banks, and mentions bulk support with item_ids. It implicitly guides usage but does not explicitly contrast with alternative tools or state when not to use.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds valuable behavioral details beyond annotations: batch shape ({ results, errors }) and array size limits. 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 that front-loads the purpose and then lists key subfields. It is concise but could be slightly better structured (e.g., bullet points for fields). Still, it earns its place.

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

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

Given the complexity of a loan detail tool with many subfields and no output schema, the description clearly enumerates all major return fields (interestRates, contractedFinanceCharges, installment schedule, CET, etc.) and explains the batch shape. It is comprehensive 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?

Schema description coverage is 0%, so the description must compensate. It does so by specifying that loan_ids is an array of 1-50 items and mentioning the batch result shape. This adds meaningful usage guidance beyond the schema type definition.

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

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

The description clearly states the tool returns full loan contract details by ID, enumerating specific fields (interestRates[], etc.). It distinguishes from sibling tools by explicitly recommending use after openfinance_list_loans for deep-dive.

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 this tool after openfinance_list_loans and provides constraints on the loan_ids array (1-50). It does not list when-not-to-use or alternatives but gives 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?

Annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral context beyond annotations: it explains that provider incidents may cause unreliable balances/limits, and identity notices indicate duplicate accounts with different owners. It also clarifies the connector-dependent meaning of credit balance. 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 lengthy but well-structured: it begins with the core purpose, then elaborates on key nuances in separate paragraphs, and ends with bulk support. Every sentence adds value, though it could be slightly more concise without losing essential guidance.

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

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

Given no output schema, the description thoroughly explains the return fields (bank, connector_id, balance, creditData, etc.) and covers edge cases like provider incidents and duplicate accounts with identity notices. It also mentions batch execution. This is comprehensive for a tool handling sensitive financial data.

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%, meaning the description does not explicitly document parameters. However, it explains the usage of `item` (omit vs. pass) and `item_ids` for bulk execution, and indirectly discusses the `type` parameter by describing BANK and CREDIT accounts. This adds meaning beyond the schema names, compensating for the lack of explicit parameter 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 it returns accounts for a bank connection, distinguishing between BANK (checking/savings) and CREDIT (credit card) with specific fields like balance, number, type, subtype, bankData, and creditData. It also mentions returning `bank` (brand) and `connector_id`, which differentiates it from sibling tools like openfinance_list_credit_card_bills and openfinance_get_accounts_detail.

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

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

The description provides explicit when-to-use guidance: OMIT `item` to list accounts across all linked banks, PASS `item` to target a single bank. It also explains when not to rely on credit card balance and directs to openfinance_list_credit_card_bills for standardized open-bill amounts. Additionally, it warns about provider incidents and identity notices, giving clear context for when the output may be unreliable.

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 value by stating the response is cached for the adapter session, and that it's a single aggregated response with no batch IDs. This provides behavioral context beyond what annotations alone offer.

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 three sentences covering purpose, cache behavior, and field details. It is well-structured and front-loaded with the main purpose. Minor cut: could be even more streamlined, but overall 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?

Despite lacking an output schema, the description fully informs about the response structure: each entry's fields (id, description, descriptionTranslated, parentId, parentDescription) and their semantics. It also clarifies cache behavior and that it's a single aggregated result. This is complete for a category 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?

The input schema has zero parameters, so the description does not need to explain parameters. Per guidelines, a baseline score of 4 is appropriate when there are no parameters, as the description cannot add value in this dimension.

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

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

The description clearly states the tool returns the transaction category taxonomy from Pluggy. It specifies the source (GET /categories) and relates its output to another tool (openfinance_update_transaction_category). This is distinct from other sibling tools like openfinance_list_transactions, which deal with transactions rather than 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 implies that this tool should be used when category taxonomy is needed, especially to obtain categoryId for update_transaction_category. However, it does not explicitly state when not to use it or mention alternatives among siblings. The context makes it clear enough for an agent to infer usage, but lacks explicit 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?

The description discloses behavioral traits beyond the annotations: it explains the reconnect_url behavior (reopens widget in UPDATE mode for existing connections) and states that no connection slot is consumed and no disconnection is needed. Annotations already indicate readOnlyHint, idempotentHint, destructiveHint, so the description adds valuable context 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?

The description is concise (three sentences) and front-loaded with the most important information (what is returned). Every sentence adds value: the first states the output, the second explains the reconnect_url, and the third clarifies usage constraints.

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, the description adequately explains the returned fields and the crucial reconnect_url behavior. It covers all necessary aspects for an AI agent to understand and 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?

There are no parameters, so schema coverage is 100%. The description does not need to add parameter details; it provides full context about what the tool returns. Baseline of 4 is appropriate for zero parameters.

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

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

The description clearly states that the tool returns saved bank connections with specific fields (connector_id, item_id, bank name, reconnect_url, add_connection_url). It distinguishes from sibling tools like openfinance_list_accounts by focusing on connections rather than accounts or transactions.

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

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

The description provides explicit guidance on when to use the reconnect_url for re-authentication needs (MFA connectors, LOGIN_ERROR, stale data) and clarifies that it does not consume a connection slot or require disconnecting first. However, it does not explicitly state when to use the main list functionality versus alternatives, but the list's basic purpose is clear.

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

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

The description discloses extensive behavioral traits beyond annotations: payment_status derivation, connector asymmetry, open bill availability conditions, bill grouping reliability warnings, and the fact that payments on one bill may relate to another. No contradiction with annotations (readOnlyHint, idempotentHint).

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

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

The description is front-loaded with the core function and then dives into necessary details. While lengthy, every sentence adds value, covering complex semantics. It is well-structured with logical sections, though it could benefit from slight condensation.

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 complexity of the domain (Brazilian Open Finance, payment status logic, connector differences), the description is remarkably complete. It covers return fields, derived statuses, limitations, and cross-references to sibling tools, leaving little ambiguity 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?

With 0% schema description coverage, the description adds meaning for account_id, account_ids, and include_open_bill, explaining their roles and the bulk execution support. However, it does not explain page and page_size parameters, which are standard but still undocumented.

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

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

The description clearly states it returns closed credit card bills for a CREDIT-type account, listing specific fields. It distinguishes from sibling tools like openfinance_list_transactions by mentioning when to use that tool for itemized purchases.

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

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

The description provides explicit guidance on when to use this tool vs alternatives, such as using openfinance_list_transactions for itemized purchases, and explains the opt-in include_open_bill parameter and when to rely on it over account balance. It also warns against reconstructing bill totals from 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?

Beyond annotations (readOnlyHint, etc.), the description discloses error handling behavior (returns warning on 403), data integrity checks for mass zeroing, and flags suspect rows. This adds significant context for safe invocation.

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 purpose but becomes verbose with the data integrity warning, which could be more concise. It is not overly long but could be streamlined.

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

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

The description covers error handling and data integrity well, but fails to document most parameters. Given the complexity (6 params, no output schema), the missing parameter info leaves the tool 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 description coverage is 0%, so description should explain all parameters. It only mentions 'item_ids' for bulk support. 'item', 'page', 'type', 'item_id', 'page_size' are undocumented, leaving their purpose unclear.

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 connections with INVESTMENTS product enabled, listing specific asset types. It distinguishes from sibling tools like openfinance_list_investment_transactions which focus on transactions.

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

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

The description provides context on when to use (connections with INVESTMENTS enabled) and handling of errors (403 return format). It does not explicitly state when not to use or compare with alternatives, but the sibling list and tool name provide implicit differentiation.

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 and idempotentHint. The description adds value by detailing output fields (quantity, value, netAmount, etc.) and the variety of transaction types, which is not in the annotations or schema. It also mentions bulk support. It does not address pagination behavior or error handling, but these are less critical given the annotations.

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

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

The description is concise, with two short paragraphs. The first paragraph explains the core functionality and output; the second addresses bulk support. It is front-loaded with key information. A bulleted list might improve readability, but overall structure is efficient.

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

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

Given no output schema, the description provides substantial detail about return fields and transaction types. It also covers the prerequisite (use after openfinance_list_investments) and bulk capability. It does not explain pagination or potential errors, but for a read-only listing tool with clear annotations, this is fairly complete.

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

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

Schema coverage is 0%, so description must compensate. It explains the required investment_id and the bulk investment_ids parameter ('Bulk support: accepts investment_ids for batched execution'). However, it does not describe page and page_size parameters, which are left entirely to the schema. This is adequate but incomplete, as pagination parameters are common but their meaning could be clarified.

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

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

The description clearly states the tool returns movement history for a specific investment position, listing transaction types (BUY/SELL/etc.) and output fields. It distinguishes itself from sibling openfinance_list_investments by requiring the investment_id obtained from that tool, and implies it is specific to investment transactions rather than general 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 explicitly says to use this tool after openfinance_list_investments to get the investment_id, providing sequential guidance. It also mentions bulk support for batched execution. However, it does not directly compare to alternatives like openfinance_list_transactions, though context implies differentiation.

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 readOnly and non-destructive; description adds GET method, return structure { results, errors }, and concurrency behavior (sequential spacing). No contradictions.

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

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

Two sentences, front-loaded purpose, efficient parameter details. No redundancy or unnecessary information.

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

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

With no output schema, description includes return structure. Could specify format of results/errors, but sufficient for simple list tool given annotations.

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

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

Only parameter `items` is described in detail: array of connection selectors (item_id, connector_id, or connector_name), one per connection. Schema coverage is 0%, so description provides essential meaning.

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

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

The description clearly states 'Lists loan contracts per bank connection' with the API endpoint, and distinguishes from siblings like openfinance_get_loan_detail by specifying the scope (per connection vs. single item).

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

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

Explicit guidance: pass `items` for specific connections or omit for all banks, with behavior for multiple connections (sequential with rate-limit spacing). Helps agent decide when to use.

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

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

Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds critical behavioral context: auto-pagination up to 5000 ceiling with truncated flag, error returns {total:0, results:[], warning, error} instead of throwing, provider incident block, and credit card pending/posted variability per connector. No contradictions.

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

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

The description is lengthy but front-loaded with the core purpose. It is well-structured with sections on credit-specific behavior, pagination, detail levels, and error handling. Some repetition (e.g., creditCardMetadata billId warning appears twice) could be trimmed, but overall it earns its length given the complexity.

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

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

No output schema exists, yet the description thoroughly explains the response structure: account echo block, result array, truncated flag, warning/error, provider_incident block. It also covers what each detail level ('compact','rich','raw') contains and when to use them. Covers edge cases like zero results on CREDIT accounts and connection health checks.

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

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

Schema description coverage is 0%, but the description provides detailed semantics for every parameter: date format (ISO YYYY-MM-DD), enum options for detail with meaning, search_queries behavior (case/accent insensitive, OR semantics), pagination modes (auto vs manual with page/page_size), and bulk via account_ids. Fully compensates for missing schema descriptions.

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

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

The description clearly states the tool returns transactions for a bank account, and distinguishes between BANK and CREDIT accounts. It explicitly says for CREDIT accounts this is the only way to get itemized transactions, and references sibling tools like openfinance_list_credit_card_bills for standardized bill totals. This is a specific verb+resource with clear scope.

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

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

Extensive guidance: warns against reconstructing bill totals via billId, recommends openfinance_list_credit_card_bills for standardized totals, explains when to use openfinance_get_item_status for credit sync issues, provides bulk support via account_ids, and clarifies pagination modes (auto vs manual). Explicit when-to-use and 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, idempotentHint, and destructiveHint false. The description adds critical behavioral traits: a cap of 5000 transactions per account with a truncated flag, potential provider_incident block explaining incomplete data, and that it resolves accounts internally. These go beyond annotations.

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

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

The description is thorough but somewhat lengthy. It is well-structured with key sections (bullets in original? but here as prose). Every sentence adds value, but could be more concise by combining some sentences. Still, it remains readable and front-loaded with the main purpose.

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

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

Given no output schema, the description thoroughly explains the return structure: totals, monthly evolution, top expenses/revenues, per-account breakdown, and the optional raw rows with detail levels. It also covers edge cases like truncation and provider incidents. This is complete for a complex tool.

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

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

Schema description coverage is 0%, so the description must compensate. It explains every parameter: item (connector_id/connector_name/item_id), from/to (ISO dates), granularity (monthly/raw), detail (compact/rich/raw with explanation of each), type (BANK/CREDIT), and item_ids for bulk. The meaning of top_n is implied by 'largest N'.

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 provides 'consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call.' It distinguishes from sibling tools like openfinance_list_accounts by explicitly saying you don't need to call them first. The verb 'analyze' and resource 'connection 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 gives explicit guidance: when to set granularity to monthly vs raw, when to use detail options, and filters. It states usage scenarios like 'análise anual/mensal, fluxo de caixa'. It also advises that for all linked banks you omit the item parameter.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint; the description adds behavioral context about what the tool returns (global indicator, degraded components, incidents) and how it flags incidents affecting connected banks, 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?

The description is well-structured with purpose first, then usage guidance, then return details. It is slightly verbose but every sentence adds value; could be tightened slightly without loss.

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 tool with no output schema, the description fully covers purpose, usage context, return data, and how it helps diagnose provider-side problems. It is complete and actionable.

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 in the schema, so baseline 4 applies per guidelines. The description adds no parameter information, which is appropriate given zero parameters and 100% schema coverage.

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, explicitly distinguishing it from the sibling tool openfinance_get_item_status by explaining the provider health vs. connection status difference.

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 even though a connection shows UPDATED, and it names the alternative openfinance_get_item_status for connection-level issues.

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

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

Annotations indicate read-only and idempotent. The description adds context: returns connector details, caveat warnings for non-Open-Finance connectors, and plan-based filtering. 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 quite detailed and somewhat lengthy, but each sentence adds value. It is front-loaded with the main purpose, but could be slightly more 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?

Covers key behaviors: what is returned, caveat warning, plan handling, and when to call. No output schema, but the description provides sufficient information for an agent to invoke correctly.

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

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

With 0% schema description coverage, the description compensates by explaining the purpose of 'keywords' (with examples) and 'include_accounts'. It also clarifies that 'keywords' is required in practice.

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 searches bank connectors by name and returns specific fields including a connect_url. It distinguishes from sibling tools by advising to call this before connecting.

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

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

Explicitly advises 'Call this BEFORE connecting' and explains that keywords are required (without it returns a hint). Mentions plan behavior, but does not explicitly contrast with all siblings.

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

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

Discloses critical side effect: creates Category Rule affecting future transactions. Also explains batch error behavior. Annotations are minimal, so description carries full burden.

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 paragraph but dense; covers all necessary information. Could be slightly more structured (e.g., separate side effects) but remains concise relative to 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?

No output schema, but description fully specifies batch return shape (updated, results, errors) and explains error handling. Covers all behavioral aspects for a write 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 schema descriptions (0% coverage), but description explains items array structure, required fields, and sources (list_transactions, list_categories). Adds essential meaning.

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

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

Clearly states it corrects transaction categories (PATCH /transactions/:id), specifies parameters from sibling tools, and explains side effect of creating category rules. Distinguishes from list/get 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?

Explicitly for fixing miscategorized transactions; mentions side effect of creating rules which informs when not to use. Could add more contrast with siblings but sufficient.

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

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

Annotations indicate idempotentHint=true and non-destructive, but the description does not clarify the idempotent behavior or other traits (e.g., what happens after reporting). It adds minimal behavioral context 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 a single sentence, concise and front-loaded. However, it could be more structured (e.g., separate lines for each usage aspect) without losing 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?

The tool has no output schema and sparse descriptions. For a feedback tool, it lacks information on expected response or behavior after submission, making it incomplete for agents to fully understand consequences.

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 should compensate. It only addresses the 'conversation' parameter ('include the conversation array'), but does not explain 'context' or 'message' parameters, leaving them undefined.

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 states the tool reports bugs, missing features, or sends feedback (specific verb+resource). It distinguishes from siblings which are primarily OpenFinance or general connectivity tools, but does not explicitly differentiate from alternatives.

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 instructs to 'include the conversation array with recent messages for reproduction', providing one usage guideline. However, it lacks explicit guidance on when to use this tool vs alternatives or exclusions.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds what versions are shown, which is consistent. No extra behavioral details needed; no contradiction.

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

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

Single sentence that directly states the tool's action, front-loaded, no extraneous information.

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

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

For a simple version display tool with zero parameters and no output schema, the description is nearly complete. Could hint at return format but not required.

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 zero parameters, so description carries no burden. Baseline score 4 applies because there is nothing more to add.

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 resource 'current MCP platform and adapter versions,' which is specific and distinguishes from sibling tools focused on authentication, Open Finance operations, 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?

Although no explicit when-to-use or alternatives are given, the tool is trivial (no parameters, no side effects) and its sole purpose is obvious; the guidance is implicit and sufficient for this simplicity.

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 a safe read-only operation. The description adds value by specifying the returned fields (installed MCPs, connection status, accounts, catalog tool counts), which is behaviorally informative. 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 a single sentence that front-loads the action ('Returns') and lists the key outputs. Every phrase contributes meaningful information, with no wasted words or redundancy.

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

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

Given the simplicity of the tool (no params, no output schema), the description fully covers the return value by enumerating the components of the toolkit state. It is sufficiently complete for an agent to understand what to expect without additional documentation.

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

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

The tool has zero parameters, and the schema is empty with 100% coverage. The baseline for 0-param tools is 4, and the description does not need to elaborate on parameters. No additional parameter explanation is required.

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: 'Returns the current toolkit state' and specifies the exact contents (installed MCPs, connection status, accounts, catalog tool counts). The verb 'returns' is specific, the resource is 'toolkit state,' and the details distinguish it from sibling tools like show_version 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?

The description implies clear usage: to get an overview of the toolkit's current state. It does not explicitly mention alternatives or exclusionary conditions, but the context is unambiguous and matches typical diagnostic tools. The lack of explicit 'use when' phrasing is offset by the clarity of purpose.

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