Íon MCP

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

Annotations indicate idempotentHint=true and destructiveHint=false. The description adds context about permanent vs. session login and token handling, which is consistent with annotations. It does not contradict any annotation.

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

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

The description is well-structured and front-loaded with context, but slightly verbose. Each sentence adds value, though some redundancy could be trimmed. Still, it remains clear and 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?

While the description covers authentication flow well, it does not mention what the tool returns (e.g., a success message or error). No output schema exists, so the description should ideally specify the return value for completeness.

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

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

Schema coverage is 0% with no description on the 'token' parameter. The description compensates by explaining the token parameter's purpose (JWT access token) and the two usage modes, providing necessary semantic 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 the tool handles authentication for MCP.AI IDE agents, specifying two methods: permanent token via config or session token via parameter. It distinguishes itself from sibling tools as the dedicated auth tool.

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

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

Provides explicit guidance on when to call with a token (session login) and when to call without args (to get login link). It also explains the permanent configuration approach, though it lacks explicit 'when not to use' or alternative tools.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds useful behavioral specifics: returns authenticated:true or connect_urls, enhancing transparency beyond annotations.

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

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

Two sentences, front-loaded with the core purpose, no wasted words. Highly 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?

For a zero-parameter read-only tool, the description sufficiently explains the two main output states. Missing error handling or partial connection cases, but adequate.

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

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

No parameters, so schema coverage is 100%. The description correctly adds no parameter information; baseline 4 applies.

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, distinguishing it from sibling tools like authenticate. It explains two scenarios, which is 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?

No explicit guidance on when to use this tool versus alternatives like authenticate or other status tools. The description describes behavior but doesn't set context for selection.

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

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

The description adds key behavioral details beyond annotations: 'invoke works even when the MCP is NOT installed — it runs the tool pontualmente (one-off), without adding the MCP to the toolkit'; if credentials needed, 'invoke returns a connect link'; if paid and wallet empty, 'invoke returns a checkout/top-up link.' It also states permission requirements for writes. No contradiction with annotations.

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

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

The description is front-loaded with the key purpose, but it is a dense run-on paragraph covering many details. While every sentence adds value, a more structured presentation would improve readability.

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 complex tool with 14 actions and no output schema, the description covers the main workflow, edge cases (connection, payment), permissions, and the prompt library, providing an agent with actionable context to choose and invoke it.

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 explains the core parameter 'action' with its enum semantics ('action=search discovers MCPs by intent', etc.) and clarifies that 'tool_id' is selected from a describe profile. However, given the 0% schema coverage and 23 parameters, many params like 'tier_slug', 'cancel_reason', and 'prompt_vars' are not described, leaving some gaps despite the rich narrative.

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

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

The description clearly defines the marketplace as 'the official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them,' and details a core flow (search → describe → invoke). This distinguishes it from sibling OpenFinance tools, which are specific financial operations, by establishing it as a meta-catalog and execution layer.

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 explicitly says 'Core flow: action=search discovers MCPs by intent → describe returns one MCP's full profile ... so you pick the right tool_id → invoke RUNS that tool.' It also says 'Use install only to make an MCP PERMANENT ... prefer invoke for a single/occasional use,' and 'Writes ... require workspace owner/admin.' It provides clear 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 indicate destructiveHint=true, and description adds context: data will no longer be available, and returns a reconnection URL. This enriches the behavioral understanding beyond annotations.

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

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

Two concise sentences that front-load the primary action and then state consequence and return value. No unnecessary words, though a structured format could improve scannability.

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

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

For a simple tool with one parameter and no output schema, it covers the return value (add_connection_url) but misses explaining the parameter. Adequate but not fully complete.

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

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

The only parameter 'item' is a required string, but the description provides no explanation of what it represents (e.g., bank identifier). With 0% schema coverage, the description should compensate but fails to do so.

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

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

Description explicitly states it revokes consent and deletes connection data, using specific verbs and resource. It distinguishes from sibling tools like openfinance_list_connections by focusing on 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?

No guidance on when to use this tool vs alternatives, nor prerequisites or when not to use. The description simply states the action without contextual decision-making cues.

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 fully discloses behavioral traits: it waits up to ~60s with polling, returns specific fields (final status, executionStatus, lastUpdatedAt, synced, needs_action, reconnect_url), and covers error conditions like MFA_REINTERACTION. The annotations are minimal, so the description carries the full burden and does so thoroughly.

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 information-dense yet well-structured. Every sentence adds value: purpose, usage context, parameter semantics, return values, error handling, and timeout behavior. It is appropriately sized for 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 2 parameters, no output schema, and the complexity of a sync operation with polling, the description covers all necessary aspects: what it does, when to use, how to use parameters, what to expect in the response, and how to handle errors (needs_action and reconnect_url). It is comprehensive.

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 parameter schema has 0% description coverage, but the description compensates by explaining the items parameter (array of selectors: item_id, connector_id, etc., and omitting syncs all) and the wait parameter (default behavior and fire-and-forget option). It could be more explicit about the default value of wait, but overall it adds significant semantic value.

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

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

The description clearly states the tool forces a re-sync of one or more connections and waits for completion. It uses a specific verb ('forces') and resource ('connections'), and distinguishes from sibling tools like openfinance_get_item_status (for checking status) and openfinance_disconnect_bank (for disconnecting).

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

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

The description explicitly says when to use it ('when a balance or transaction list looks stale') and clarifies it pulls fresh data without disconnecting. It also explains the wait parameter (true by default, false for fire-and-forget) and mentions re-checking with openfinance_get_item_status if timed_out. However, it does not explicitly list cases where the tool should not be used, which would improve clarity further.

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 well beyond the readOnlyHint/idempotentHint annotations by explaining that the balance is a snapshot tied to the last upstream sync, not a live read. It also discloses error/warning behavior for credit accounts, including specific error types and that failures surface as structured warnings rather than exceptions.

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 dense but well-organized: the main purpose and endpoint are front-loaded, followed by freshness caveats, sync guidance, and error behavior. A few details could be tightened, but every sentence contributes useful operational 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?

Since there is no output schema, the description partially compensates by mentioning relevant response fields (updateDateTime/updatedAt) and warning behavior. It does not fully describe the return payload structure, but for invoking the tool correctly the key behavior and error cases are covered.

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 reasonably by stating that account_ids is an array and adding the 1–50 size constraint that is absent from the schema. It could provide an example or clarify the meaning of each item further, but for a single parameter it is adequate.

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

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

The description uses a specific verb ('Returns') and resource ('latest available balance per account id'), names the REST endpoint, and clearly distinguishes its purpose from siblings like openfinance_list_transactions and openfinance_force_sync. An agent can tell exactly what this tool does.

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 concrete usage context: use this for the freshest balance the provider can serve, and if data seems stale or inconsistent with transactions, run openfinance_force_sync and re-read. It does not explicitly list 'when not to use' but it names the relevant alternative and the triggering conditions.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds critical context about the 'provider_incident' block, warning against presenting unreliable credit values. This goes beyond annotations and prevents misuse.

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

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

The description is two sentences long, front-loaded with the purpose, and every sentence adds value. No wasted words, and it remains comprehensive.

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

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

Given the single parameter and no output schema, the description covers the response shape (including the provider_incident scenario) and usage constraints. It could mention error cases or required authentication, but it is sufficiently complete for correct usage.

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 description for the single parameter, so the description bears full burden. It explains the parameter format (array of 1–50 strings), batch shape ('{ results, errors }'), and provides an input/output example. This adds significant meaning beyond the schema.

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

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

The description specifies the verb 'returns', the resource 'full account objects including extended creditData per id', and the endpoint '/accounts/:id'. It distinguishes from siblings like 'openfinance_list_accounts' by focusing on detail retrieval by IDs.

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 instructs to pass 'account_ids' as an array (1–50), which is a clear usage guideline. It does not explicitly state when to avoid using the tool or mention alternatives, but the context is sufficient for correct invocation.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and the description adds major behavioral context: transactions_basis can be estimate, returned totalAmount is authoritative and should not be rebuilt from transactions, the provider does not return a paid/status field, and payments[] may refer to the previous bill. These caveats are exactly what an agent needs to avoid wrong conclusions.

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 primary operation and returned fields and then logically builds through optional behavior, caveats, and related tools. It is long and repeats the total-amount-authoritative warning more than once, but that repetition is defensible for a high-stakes calculation risk.

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?

There is no output schema, yet, the description covers the main return fields, the batch shape, the transaction-basis estimate/open-bill distinction, and the absence of paid status. It is still missing any description of transactions_detail enum semantics, and it does not fully specify what the errors part of the batch shape contains, so a small completeness gap remains.

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

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

Schema description coverage is 0, so the description carries the parameter burden. It explains bill_ids as an array for one or more bills, account_id as needed when include_actions is enabled, and include_actions as the switch for returning matched transactions. However, transactions_detail is never described, leaving the meaning of compact, rich, and raw enum values to inference.

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 a specific verb and resource: returns bill-level detail for one or more credit card bills by id, and it names the HTTP endpoint GET /bills/:id. It also enumerates the returned fields and points to the sibling list tool for discovering ids, which makes its purpose distinct.

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 gives explicit when-to-use guidance for the optional transaction inclusion, tells the agent to discover ids with openfinance_list_credit_card_bills, and warns against using openfinance_list_transactions_by_item for credit card transactions. It also directs the agent to the sibling list tool for derived payment_status, which is strong alternative-routing.

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

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

The description adds significant behavioral context beyond the annotations: it explains the reconnect_url's function (re-authenticate without disconnecting), and the difference in response structure between single and bulk calls. It does not contradict annotations (readOnlyHint, idempotentHint, destructiveHint are all consistent).

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 moderately concise, front-loading the main function before expanding on usage details. Every sentence adds value, but it could be slightly tighter without losing information. Still well-structured for quick comprehension.

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

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

While the description covers the core functionality and usage patterns, it fails to document all parameters (item_id is missing) and does not fully describe the return structure for cases like errors or the bulk response format. For a tool with no output schema, more detail would be beneficial.

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 explains 'item' and 'item_ids' clearly, but the 'item_id' parameter is not mentioned, leaving its purpose ambiguous. This incomplete coverage prevents a higher score.

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 current status of a bank connection, including specific properties like executionStatus, connector metadata, and reconnect_url. It distinguishes from sibling tools by specifying the resource (bank connection status) and the action (retrieving status, not modifying).

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 'item' parameter (single bank) vs omitting it (all banks), and mentions bulk support with 'item_ids'. However, it does not explicitly state when not to use this tool or compare it to sibling tools like 'openfinance_list_connections'.

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

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

Annotations already provide readOnlyHint: true, destructiveHint: false, and idempotentHint: true. The description adds the batch response shape ('{ results, errors } batch shape') and confirms it is a read operation. No behavioral contradictions exist, but the description does not add significant behavioral context beyond the annotations and the batch shape.

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

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

The description is concise with three sentences. It front-loads the purpose and key details. Every sentence adds value, though a more structured format could improve readability.

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 single-parameter read tool with annotations, the description covers the purpose, usage context, parameter details, and the batch response shape. It is sufficient to guide the agent, though error or edge-case behavior is not addressed.

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 0% description coverage, so the description must compensate. It explains the parameter 'loan_ids' as an array of strings and adds a range constraint '1-50'. This provides meaningful guidance beyond the raw 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 'Returns full loan contract detail by id' with a specific verb and resource. It distinguishes this tool from its sibling 'openfinance_list_loans' by explicitly stating 'Use after openfinance_list_loans to deep-dive on a specific contract.' The list of returned fields adds specificity.

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 clear context: 'Use after openfinance_list_loans to deep-dive on a specific contract.' It also specifies the batch input format 'Pass `loan_ids` as an array (1-50).' However, it does not explicitly state when not to use it or provide alternatives beyond the sibling mentioned.

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

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

Beyond the readOnly/idempotent/destructive annotations, the description discloses substantial behavioral nuances: connector-dependent 'balance' semantics, 'balance_notice' meaning zero balance while an amount is outstanding, bankData fields that can lag after connection creation, provider_incident unreliability, and identity_notice consent-holder deduplication guidance. 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 long but every major block carries operational value: response fields, naming caveat, selection guidance, and multiple correctness warnings. It front-loads the core result and selection behavior before caveats. It could be more scannable with structured bullets, but it is not padded.

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 and four parameters, the description fully covers the return contract, field interpretation, selection modes, failure/notice conditions, and hand-offs to sibling tools. An agent has enough information to invoke the tool correctly and interpret the response safely.

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 key parameters: item targets a bank, omitting it aggregates all banks, and item_ids enables bulk execution. It also explains BANK/CREDIT semantics. However, the singular item_id parameter is not explicitly distinguished from item_ids, and the type parameter is implied rather than directly described as a filter.

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 a specific verb and resource: it 'Returns accounts' for bank connections, covering both BANK and CREDIT types, and lists the key returned fields (balance, number, type, subtype, bankData, creditData, bank, connector_id). It clearly distinguishes the aggregate cross-bank mode from single-bank mode, so the tool's purpose is unambiguous relative to 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 explicitly tells the agent when to omit item ('when the user asks for my accounts/cards without naming a bank') and when to pass item to target a single bank. It also names the alternative openfinance_list_credit_card_bills for standardized open bill amounts and closed bills, and openfinance_force_sync for stale derived fields.

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 behavioral context beyond annotations: it mentions caching for the adapter session, that it is a single aggregated response with no batch ids, and details the structure of each entry. Annotations already declare readOnlyHint and idempotentHint, so the description complements them.

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 well-structured. Every sentence provides useful 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 no parameters and no output schema, the description fully explains what the tool returns, including each field's meaning and usage with sibling tools. It is complete for the tool's 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?

The input schema has zero parameters, so schema coverage is 100% vacously. The description does not need to explain parameters but adds value by describing the response fields (id, description, etc.). Baseline for 0 params is 4.

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

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

The description clearly states what the tool does: returns the Pluggy transaction category taxonomy, cached for the session. The verb 'returns' and the resource 'taxonomy' are specific, and it distinguishes from siblings like 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?

The description indicates that this tool provides categories used by openfinance_update_transaction_category and notes that descriptionTranslated should be preferred for pt-BR users. It implies usage context but does not explicitly state when to use or when not to use alternatives.

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

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

The description adds significant behavioral detail beyond annotations: it explains that reconnect_url opens in UPDATE mode, does not consume a slot, and does not require disconnecting. Annotations already indicate read-only and idempotent, which aligns with description.

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

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

The description is two sentences, front-loaded with the main purpose, and every sentence adds essential information. No wasted words.

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

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

For a list tool with no parameters, the description covers all relevant aspects: what is returned, the special URLs, and their behavioral implications. No output schema exists, but the description adequately explains the output.

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

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

No parameters exist, so baseline is 4. The description adds value by explaining the structure of the output (connector_id, item_id, etc.) and the significance of reconnect_url and add_connection_url, which are not 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 saved bank connections, listing specific fields like connector_id, item_id, bank name, reconnect_url, and add_connection_url. It distinguishes from sibling tools by focusing on listing connections and explaining the reconnect functionality.

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 explicitly explains when to use the reconnect_url (for re-authentication due to MFA, LOGIN_ERROR, stale data) and notes it does not consume a connection slot or require disconnecting. However, it does not contrast directly with alternative tools like openfinance_get_item_status or openfinance_force_sync.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds rich behavioral context: payment status derivation logic, connector asymmetry for open bills, bill grouping reliability warnings, and bulk support. No contradiction with annotations.

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

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

The description is lengthy but necessary given domain complexity. It is structured well, starting with core purpose then detailing payment status, open bill, connector asymmetry. Could be more concise with bullet points or sections, but every sentence adds essential information.

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

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

Given no output schema and 5 parameters, the description is exhaustive: covers return fields (results, open_bill, future_bills, payment_status_legend), parameter behavior, usage guidelines, error handling (returns warning instead of failing), and cross-tool comparisons. Sufficient for an agent to use the tool correctly.

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

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

Schema description coverage is 0% (no parameter descriptions in schema). The description thoroughly explains include_open_bill (including sub-objects, confidence levels, availability) and mentions account_ids for bulk. However, it does not explain page and page_size parameters (pagination). Still, adds significant value beyond bare schema.

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

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

The description clearly states the verb 'Returns' and the resource 'CLOSED credit card bills for a CREDIT-type account'. It distinguishes from siblings like openfinance_get_credit_card_bill (singular) and openfinance_list_transactions (itemized purchases) by specifying that this tool returns bill-level summaries.

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 this tool (for closed bills, bill-level summaries) and when to use alternatives (openfinance_list_transactions for individual transactions). Provides warnings about payment status interpretation and advises against using account balance due to varying meanings across connectors.

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 the annotations (readOnlyHint, idempotentHint), the description details error behavior (returning a structured response instead of throwing), data integrity checks, and the special handling of mass zeroing with warnings. This adds significant transparency.

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

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

The description is front-loaded with the main purpose and provides detailed but relevant information. It could be slightly more concise, especially regarding the data integrity explanation, but it remains 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?

The description adequately covers the output structure, error handling, and the data integrity warning, but it omits explanations for most input parameters. Given the lack of output schema, the output description is good, but input parameter documentation 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?

The input schema has 0% description coverage for its 6 parameters. The description only briefly mentions 'item_ids' and does not explain 'item', 'page', 'page_size', or 'type'. Without schema descriptions, the description fails to compensate adequately.

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 the investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, fixed income, etc.) and output fields. It differentiates from siblings like 'openfinance_list_investment_transactions' and mentions bulk support with item_ids.

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 about when the tool is applicable (for connections with INVESTMENTS enabled) and error handling, but it does not explicitly compare with alternative tools or state when not to use it. The guidance is implicit rather than direct.

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. Description adds detail about output fields but does not disclose additional behavioral traits like authentication needs, rate limits, or error conditions. 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 concise paragraphs: first explains output, second gives usage hint and bulk support. No redundant information, purpose is front-loaded.

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

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

No output schema, so description must explain return values; it does so by listing movement types and fields. Also provides usage prerequisite and bulk support hint. However, it does not mention pagination behavior, error cases, or limits, leaving some gaps given the tool's moderate complexity.

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

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

Schema description coverage is 0%; description explains the key parameters investment_id and investment_ids, but ignores page and page_size. Partially compensates for the lack of schema descriptions but 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?

Description clearly states the tool returns movement history for an investment position, lists specific types (BUY/SELL/TAX/etc.) and fields (quantity, value, etc.), and distinguishes from sibling tools by recommending use after openfinance_list_investments.

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

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

Explicitly says to use after openfinance_list_investments to get the investment_id, and mentions bulk support. Does not explicitly state when not to use or provide alternatives, but the context is clear.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds valuable context about sequential querying with rate-limit spacing for multiple connections and the return format of `{ results, errors }` per connection. 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 informative and structured in four sentences, each adding value. It is not verbose, but could be slightly more condensed without losing clarity.

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

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

Given no output schema and single parameter with no schema descriptions, the description covers all essential aspects: what the tool does, how to use the parameter, rate-limit handling, and return format. It is complete 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 fully compensates by detailing that `items` is an array of connection selectors (item_id uuid, connector_id, or connector_name), one per connection, and explains 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?

The description clearly states the tool lists loan contracts per bank connection, specifying the HTTP endpoint GET /loans. It distinguishes the tool's purpose from siblings by focusing on listing multiple loans per connection, as opposed to get_loan_detail which retrieves a single loan.

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 pass the `items` parameter (to list loans for specific connections) versus when to omit it (to list across all linked banks). It also mentions sequential querying with rate-limit spacing, but does not explicitly state when not to use the tool or alternatives among siblings.

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

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

Annotations already mark the tool as read-only and idempotent, and the description adds extensive behavioral details: auto-pagination behavior, scheduled row ordering, truncation at 5000, error return shapes, per-connector inconsistencies, and the provider_incident block. No contradictions with the annotations are present.

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 dense and front-loaded with the core purpose, but it is also very long and interleaves multiple warnings and caveats. Each sentence provides useful operational information, though the length and dense formatting make it harder to scan quickly.

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

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

Given the tool has no output schema and eight parameters, the description is remarkably complete: it covers return fields, account echo, truncation, pagination semantics, credit-specific pitfalls, failure behavior, and related tool fallbacks. An agent has enough guidance to select and call this tool correctly in complex banking scenarios.

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 0% description coverage, but the tool description compensates thoroughly. It explains the semantics of from/to, search_queries, page/page_size, detail levels, account_id/account_ids, and the consequences of combining parameters like page_size plus page.

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 immediately identifies the tool as returning transactions for a BANK or CREDIT account, which is a clear verb+resource pairing. It also differentiates this tool from openfinance_list_credit_card_bills and other siblings by explaining that it is the ONLY way to get itemized credit card 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 routing guidance: use openfinance_list_credit_card_bills for standardized bill totals, openfinance_list_accounts for closing/due dates, and openfinance_get_item_status when credit transactions appear missing. It also explains when manual pagination is appropriate versus relying on auto-pagination.

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

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

Beyond annotations (readOnlyHint, idempotentHint), description discloses internal account resolution, transaction cap of 5000/account with truncation flag, and provider incident block indicating potential data incompleteness.

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 comprehensive but somewhat verbose; could be more structured with bullet points. However, it is front-loaded with main purpose and covers all necessary details without 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?

Given 9 parameters, no output schema, and complexity, description covers all aspects: parameter usage, return structure (compact summary fields), truncation, provider incidents, bulk support, and filtering options. No gaps.

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

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

With 0% schema description coverage, description fully compensates by explaining each parameter's purpose, acceptable values (including ISO date format, enum meanings), and how they interact (e.g., detail levels with granularity).

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 performs consolidated cash-flow analysis for a whole bank connection in one call, resolving accounts internally. It distinguishes from sibling tools like openfinance_list_accounts and openfinance_list_transactions by noting that no prior account listing is needed.

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 provides use cases (e.g., 'análise anual/mensal', 'fluxo de caixa'), explains when to use 'raw' granularity vs 'monthly', and suggests when to omit item for all banks. Also warns about provider incident impacts.

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. Description adds context about accessing public status page, returning global indicator, degraded components, incidents, and your_banks_affected. No contradictions.

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

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

Single paragraph with high information density; covers purpose, usage, and return details. Slightly verbose but well-structured and front-loaded.

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

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

Despite no output schema, description lists all relevant return values (global indicator, degraded components, incidents, your_banks_affected). Sufficient for a 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 does not need to explain parameters. Baseline 4 for zero-param tool.

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

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

Clearly states it checks the Open Finance provider's LIVE operational status, distinguishing from openfinance_get_item_status. Specific verb 'Checks the... operational status' and resource 'Open Finance provider'.

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: when data is incomplete/stale despite connection showing UPDATED, and provides specific scenarios (accounts/transactions missing). Distinguishes from sibling tool openfinance_get_item_status.

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

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

Annotations declare readOnlyHint, idempotentHint, non-destructive. The description adds critical context: plan-based filtering (PF vs PJ), caveat for non-Open-Finance connectors, and that it never dumps the full catalog.

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 efficient—each sentence adds value, though at 4 sentences it is slightly long but not verbose.

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 details return values (connector id, access, audience, connections, accounts, connect_url) and includes plan behavior and caveats. Sufficient for an agent to understand usage.

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 keywords are passed as array examples, notes it is REQUIRED, and describes include_accounts effect (returns accounts when true). Also clarifies behavior without keywords.

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 key information (id, access, audience, connections, connect_url), and distinguishes it from siblings like list_connections or list_accounts by focusing on search and one-click connection.

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

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

Explicitly instructs to call this BEFORE connecting, highlights that keywords is REQUIRED and omitting it returns a hint, and advises preferring Open Finance connectors for automation due to caveats.

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 key behavioral traits beyond annotations: the operation overrides automatic categorization and creates a Category Rule that affects future similar transactions, and outlines batch error handling (per-item errors don't fail the batch). This is critical for an AI agent to understand 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 front-loaded with the action and endpoint, then details parameters, side effects, and response shape. It is somewhat lengthy but every sentence adds value. Could be slightly 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?

The description covers the endpoint, required fields, ID sources, side effects, and response structure. It does not mention authentication or error codes, but given the complexity and absence of output schema, it provides sufficient context for an AI agent to use the tool effectively.

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

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

With schema description coverage at 0%, the description adds necessary meaning by explaining each field (transaction_id, category_id) and their origins. It lacks explicit types or constraints, but provides enough context for correct invocation.

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 starts with 'Corrects the category of one or more transactions (PATCH /transactions/:id),' using a specific verb and resource. It clearly distinguishes from sibling listing tools like openfinance_list_transactions and openfinance_list_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?

It instructs to pass items as an array with transaction_id and category_id sourced from specific sibling tools, and explains the side effect of creating a Category Rule. While it doesn't explicitly state when not to use it, the context implies fixing miscategorized transactions. Slight room for more explicit 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 indicate idempotentHint=true and destructiveHint=false, which align with reporting. The description adds that the conversation array is needed for reproduction, providing behavioral context beyond annotations. No contradictions.

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

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

The description is concise with two sentences, no fluff. It is front-loaded with the purpose. However, it could be slightly more structured to list parameters.

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 feedback tool with no output schema and 3 parameters, the description covers the core purpose but lacks details on the 'context' parameter and what happens after reporting (e.g., confirmation). It is minimally adequate.

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

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

Schema coverage is 0%, so the description must explain parameters. It only mentions the 'conversation' parameter, ignoring 'message' (required) and 'context'. The description does not compensate 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's purpose: report a bug, missing feature, or send feedback. It specifies the verb (report) and resource (bug/feedback), and given sibling tools are mostly openfinance or authentication, it stands out as a distinct 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 including the conversation array for reproduction, which is useful context. While it doesn't explicitly state when not to use it or compare with alternatives, the sibling tools provide no similar functionality, making the usage context clear.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering safety. The description adds no new behavioral traits, but it is consistent with annotations and does not contradict them.

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

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

One concise sentence that fully conveys the tool's purpose with no extraneous information.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is fully complete. It tells exactly what the tool does and what it returns.

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 schema description coverage is 100%. According to rubric, baseline for 0 parameters is 4. Description appropriately does not add parameter info.

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

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

The description uses a specific verb ('show') and clearly identifies the resource ('current MCP platform and adapter versions'). It distinguishes itself from sibling tools, which are primarily about OpenFinance, authentication, and connection management.

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 purpose is self-evident and no alternative tools serve the same function, so explicit usage guidelines are not critical. The description implicitly indicates this is for checking version information.

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

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

The annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds valuable context by detailing exactly what 'toolkit state' includes, giving the agent a clear expectation of the return payload. No behavioral 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 well-structured sentence that front-loads the action ('Returns') and immediately specifies the resource and key details. Every phrase adds value without redundancy.

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

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

Given the tool's low complexity, zero parameters, and clear annotations, the description fully covers the tool's purpose and output. The lack of an output schema is mitigated by the detailed enumeration of return contents. There are no gaps that would confuse 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?

The tool takes zero parameters, and the schema reflects this with an empty properties object. The description appropriately focuses on the return value rather than non-existent inputs, exceeding the baseline for parameter-semantic guidance.

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

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

The description clearly states the tool's function with a specific verb ('Returns') and defines the resource as 'current toolkit state,' enumerating the exact contents (installed MCPs, connection status, accounts, catalog tool counts). This distinguishes it from sibling tools that focus on specific operations or individual account details.

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 is for obtaining a high-level system overview but provides no explicit guidance on when to prefer it over alternatives like openfinance_list_connections or show_version. There are no stated exclusions or usage scenarios.

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