Rede Celcoin MCP

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

Description explains idempotent behavior (calling with token repeatedly same effect) and notes permanent vs session nature. Annotations show idempotentHint=true, destructiveHint=false, readOnlyHint=false – no contradictions. Adds context about config-based login being non-expiring.

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 fairly concise and front-loaded with the tool's purpose. Every sentence adds value, though the structure could be slightly clearer (e.g., splitting config vs session). Still, no waste.

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

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

Does not describe the return value or output schema, which is missing. For an authentication tool, the response format (e.g., success message, token status) would be helpful. However, it covers the core flow adequately for an agent to invoke.

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

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

Schema has 0% description coverage for the single parameter 'token'. Description explains that it's a JWT and that omitting it returns a login link, adding essential meaning beyond the schema.

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

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

The description clearly states the tool is for authentication with two methods: permanent config-based and session-based token paste. It specifies the verb 'authenticate' and the resource (MCP.AI for IDE agents). Siblings like 'connect' do not overlap in purpose.

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

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

Provides clear guidance on when to use each method (permanent vs session), including calling with no args to get a link. Does not explicitly compare to siblings, but the context is sufficiently directed for an agent.

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, providing safety profile. Description adds value by disclosing conditional behavior: returns authenticated:true/pending[] when all providers connected, or connect_url when credentials missing. This context beyond annotations.

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

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

Two concise sentences, zero waste. Front-loaded with purpose, then conditional details. Every sentence 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 no output schema, description explains return values in two scenarios (all connected vs missing credentials). Complete enough for a simple status check tool, but might benefit from mentioning whether other states exist or format of URLs.

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?

Tool has 0 parameters, so baseline score is 4. Description adds no parameter info (not needed), and schema coverage is 100%.

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 verb 'returns' and resource 'connection status and URLs'. It distinguishes from siblings like 'authenticate' (auth flow) and 'openfinance_get_item_status' (specific item status), positioning itself as the overall connectivity check.

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?

Usage is implied: use to check connection status. However, no explicit guidance on when to use vs siblings (e.g., when to prefer authenticate or specific status tools). No when-not-to-use or alternatives mentioned.

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

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

Annotations are minimal (readOnlyHint false, openWorldHint true, etc.), so the description carries the burden. It discloses many behaviors: invoke works without installation, returns connect/checkout links when needed, install makes permanent, writes require owner/admin, and prompt links open without login. These go beyond annotations and are not contradicted by 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 long but the tool is complex (multi-action marketplace + prompt library). It is front-loaded with the main purpose and uses clear flow markers ('Core flow', 'KEY'). The occasional verbal clutter (e.g., 'pontualmente') and dense first sentence slightly reduce conciseness, but all content 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?

The description is comprehensive given the tool's complexity: it covers all major action categories, edge cases (auth, payments), permission requirements, and the prompt library. Without an output schema, it gives partial output descriptions (e.g., 'returns a connect link', 'returns a shareable link') but not for every action. Overall, it is robust enough for an agent to use correctly.

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

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

With 0% schema_description_coverage, the description meaningfully explains the `action` enum and key parameters like `tool_id` and `query` through the core flow. However, many parameters (e.g., `immediate`, `tier_slug`, `prompt_vars`, `cancel_reason`) are not explicitly described, though some are inferable from defaults/enums. It substantially compensates but not fully exhaustively.

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 identifies the tool as 'the official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them,' and outlines its core functions (search, describe, invoke) and prompt library. It distinguishes this from sibling tools by its broad catalog/execution role versus the specific openfinance tools.

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

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

The description gives explicit guidance on when to use each action ('Core flow: action=search → describe → invoke'), contrasts invoke versus install ('Use install only to make an MCP PERMANENT... prefer invoke for a single/occasional use'), and lists alternatives like request_mcp for new MCPs and prompt library for prompts. It also 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 declare destructiveHint=true; description reinforces and adds that data is irrevocably removed and a reconnection URL is returned, which provides useful behavioral context.

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

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

Three concise sentences front-loaded with the primary action, no redundant phrasing, every sentence adds value.

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

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

For a simple destructive action with one parameter and no output schema, the description covers the key outcomes (data deletion, return URL). Could mention irreversibility, but annotations already signal destructiveness.

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

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

The single required parameter 'item' has 0% schema coverage and no description. The description does not explain what 'item' represents (likely the bank identifier), leaving the agent uninformed.

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 revokes consent and deletes connection data, specifying the outcome ('data will no longer be available') and a return value. It distinguishes from sibling tools like 'connect' or 'openfinance_list_connections' by its destructive nature.

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

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

The description implies usage for disconnecting a bank but does not provide explicit context on when to use or avoid this tool versus 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 goes beyond annotations to detail behavioral traits: waits up to ~60s, returns specific status fields, handles errors like MFA with reconnect_url, and explains needs_action. 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 informative but relatively long. It is front-loaded with key purpose and all sentences add value. Slightly longer than necessary but still clear.

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 output schema and the complexity of the tool (sync with polling, error states, reconnect_url), the description is complete. It covers return structure, timeout handling, and references sibling tools appropriately.

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

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

Schema coverage is 0%, but the description fully explains both parameters: items (array of selectors or omit for all) and wait (false for fire-and-forget). Adds meaning beyond schema types.

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 bank connections and waits for completion. It uses specific verbs ('forces sync') and identifies the resource ('connections'). It distinguishes from siblings like openfinance_get_item_status by mentioning it as a fallback for timeout.

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

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

Provides explicit guidance on when to use the tool (stale balance/transactions) and what it does (pulls fresh data without disconnecting). It also explains alternatives: set wait:false for fire-and-forget and re-check with openfinance_get_item_status on timeout.

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 far beyond the readOnly/idempotent/destructive annotations by disclosing snapshot semantics, sync anchoring, warning-vs-error behavior, degradation on upstream 5xx or non-Open Finance connectors, and the response envelope. No contradiction with annotations exists.

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?

Long but information-dense and well-structured: operation, freshness caveat, recovery path, parameter rule, credit errors, degradation behavior, response shape. Every section earns its place, though a slightly tighter wording 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?

With no output schema, the description still explains the response shape and error/degradation behavior. It covers normal results, credit-specific errors, consent failures, upstream 5xx, non-Open Finance connectors, and the warning field, making the tool callable without missing information.

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 full burden. It compensates by specifying that account_ids must be an array and by adding the 1–50 item limit. That is sufficient 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?

States a specific verb and resource: 'Returns the latest available balance per account id' and names the exact endpoint. It also distinguishes itself from related operations by contrasting with stale data and openfinance_list_transactions, so an agent can tell what this tool uniquely 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?

Explicitly tells the agent when to use openfinance_force_sync and re-read if the balance is stale or disagrees with transactions. It also gives recovery guidance for consent errors, naming the alternative action. This is strong conditional routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds critical behavioral context: the batch shape { results, errors }, inclusion of extended creditData, and a provider_incident block with warnings about unreliable limits/balances. This goes beyond annotations and is essential for correct usage.

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: first sentence states the main function and batch shape; second sentence warns about provider incidents. It is front-loaded, efficient, and every sentence adds value.

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

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

For a tool with one parameter and no output schema, the description covers the purpose, parameter constraint (1-50), batch shape, and a key edge case (provider incident causing unreliable values). This is sufficient for an agent to use the tool correctly 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?

The schema has 0% coverage (no parameter descriptions). The description compensates fully by specifying that account_ids must be an array with 1-50 items, and explains the batch shape and provider incident context. This adds meaning beyond the bare schema definition.

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

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

The description clearly states the tool returns full account objects including extended creditData per ID, distinguishing it from sibling tools like list_accounts (which likely returns summaries) and get_account_balance (which returns only balances). The verb 'returns' and resource 'accounts' are explicit.

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

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

The description explains how to use the tool (pass account_ids array 1-50, batch shape) and provides context about provider incidents. However, it does not explicitly state when to use this tool versus alternatives (e.g., when only balance is needed, use get_account_balance). The guidance is implied but not comprehensive.

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 far beyond the readOnly/idempotent/hints by disclosing that the bill payload carries no transactions by default, that transaction matching may be a low-confidence estimate, that totalAmount should not be rebuilt from transactions, and that a non-empty payments[] does not mean the bill was paid. These are essential behavioral warnings an agent cannot infer.

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 dense and every sentence earns its place by adding a behavior, caveat, or workflow detail. It is front-loaded with the core purpose and return fields, then proceeds through optional transaction detail, matching caveats, and payment-status cautions in a logical order.

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, so the description carries the burden of explaining the return shape and it does so well: bill fields, transaction arrays, transaction_count, transaction_sum, reconciles_with_total, a transactions_basis explanation, a batch shape, and a payment-status warning. The main behavioral warnings are included, making the tool safe to call correctly even though one param is not explicitly described.

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 thoroughly explains bill_ids, account_id, and include_transactions, including why account_id is needed when transaction inclusion is used. However, it does not document the transactions_detail enum (compact/rich/raw). With 0% schema description coverage, that is a real but minor gap, so the description needs to compensate less than a perfect 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?

The description opens with a clear action and resource: returns bill-level detail for credit card bills by id (GET /bills/:id), and lists the specific returned fields. It also distinguishes itself from sibling tools like openfinance_list_credit_card_bills and openfinance_list_transactions, which avoids selection ambiguity.

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 is explicit about when to use this tool vs alternatives: call openfinance_list_credit_card_bills first to discover bill IDs, and prefer the same sibling list for paid status because it derives payment_status. It also offers openfinance_list_transactions as an alternative for self-fetching transactions, giving clear routing guidance.

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

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

Annotations already mark readOnlyHint, idempotentHint, destructiveHint. The description adds valuable behavioral context: it reveals that the tool can return a reconnect_url that opens a widget in update mode without disconnecting or consuming a connection slot. This goes beyond annotations and clarifies 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 two sentences, front-loaded with the main purpose. It efficiently covers single, bulk, and reconnect_url without redundancy. Slightly dense but well-structured.

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

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

Given no output schema, the description partially explains return format for bulk ({ count, items }) and mentions reconnect_url. It does not detail the exact fields for a single item response. For a read-only status tool, this is reasonably complete. Could add example structure, but not critical.

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

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

Schema has 3 params with 0% description coverage, so the description must compensate. It explains the effect of omitting item vs passing it, and the bulk behavior of item_ids. However, item_id is not explicitly described; it might be an alias. Overall, adds meaningful guidance beyond the schema.

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

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

The description clearly states it returns the status of a bank connection with specific statuses like UPDATED, UPDATING, etc. It also distinguishes between single and bulk usage, and mentions reconnect_url. This specificity differentiates it from sibling tools like openfinance_list_connections.

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

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

The description provides clear guidance: omit item for all banks, pass item for a single bank, and supports item_ids for batch. It implicitly advises against using it for non-status queries, but does not explicitly list when not to use it or compare to alternatives like openfinance_list_connections. Still, the guidelines are actionable.

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 that it's a GET request, returns batch shape with results/errors, and lists returned fields. No contradictions.

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

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

Description is front-loaded with purpose, then list of fields, then usage. Slightly long but every sentence adds value. Could be slightly more concise but still effective.

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

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

Given 1 required param, no output schema, and sibling tools context, the description covers what the tool does, how to use it, and what to expect (batch shape). Complete for the 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 has 0% description coverage, but description adds meaning by specifying loan_ids as an array with size 1-50 and batch shape context. It doesn't detail ID format but provides adequate 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?

Description clearly states it returns full loan contract detail by ID, lists many specific fields, and distinguishes from sibling openfinance_list_loans. Verb 'Returns' plus resource and endpoint.

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_loans, specifies batch shape and array size (1-50), providing clear when and how 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 goes far beyond the annotations by revealing important behavioral nuances: connector-dependent `balance` semantics, lagging `bankData` fields, `provider_incident` unreliability, and `identity_notice` deduplication requirements. It also warns against presenting unreliable or stale values as real. This is rich behavioral 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 core purpose, but it is extremely long and unstructured, almost wall-of-text style. Every sentence carries valuable caveats, but the density and lack of bullet points or section breaks makes it harder for an agent to parse efficiently.

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 no output schema and a complex response involving multiple account types, connector-specific behaviors, and reliability notices, the description is remarkably complete. It covers return fields, filter behavior, bulk execution, semantic pitfalls, and alternatives, leaving very little for an agent to guess.

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, and it largely does. It explains `item` (omit for all connections, pass to target one), the `type` semantics via BANK/CREDIT categories, and `item_ids` for bulk execution. However, `item_id` is not explicitly documented as a parameter—it is only indirectly inferable from the output row tagging and `item_ids`.

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 opens with a specific, unambiguous statement: it returns accounts for a bank connection (BANK and CREDIT) with detailed fields. It clearly differentiates itself from siblings like openfinance_list_credit_card_bills, which the description explicitly references for standardized bill data.

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 when-to-use guidance: omit `item` for accounts across all linked banks, pass `item` for a single bank, and use openfinance_list_credit_card_bills when a standardized open-bill amount or total debt is needed. It also explains how to handle edge cases like `balance_notice` and provider incidents.

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 caching behavior and aggregated response. Annotations already indicate safe read operation; description adds useful context about session caching and response structure.

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 paragraph with all essential information: endpoint, caching, field details, and note about no batch ids. 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?

Describes return fields sufficiently since no output schema. Caching and endpoint details provided. Complete for a zero-parameter list tool with simple taxonomy 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?

No parameters. Baseline 4 for 0 parameters; no additional param info needed.

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

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

Clearly states it returns Pluggy's transaction category taxonomy with details on fields like id, description, parentId. Distinguishes from siblings as the only category listing 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?

Implied usage: before updating transaction categories. No explicit when-to-use or alternatives, but context from sibling names suggests unique purpose.

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 destructiveHint=false. The description adds valuable behavioral details: what data is returned, the purpose of reconnect_url (opens widget in UPDATE mode), and that it does not consume a slot or require disconnecting. This goes beyond the annotations' basic safety profile.

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

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

The description is a single paragraph but is information-dense without waste. It could be slightly more structured (e.g., separating the reconnect_url explanation), but every sentence earns its place. It is appropriately sized for the tool's simplicity.

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 the return values (fields) and the special URLs. Annotations provide safety context, and the description is complete for a read-only listing tool. No gaps remain.

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 (0 params, 100% schema coverage). Per guidelines, 0 parameters have a baseline of 4. The description does not need to add parameter details, and it correctly omits them.

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 saved bank connections for this install' and lists specific fields (connector_id, item_id, bank name, reconnect_url, add_connection_url). This verb+resource pairing is distinct from sibling tools like openfinance_list_accounts, which lists accounts, not connections.

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

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

The description provides usage context for the reconnect_url (use when a connection needs re-authentication due to MFA, LOGIN_ERROR, stale data) and clarifies that it does not consume a slot or require disconnecting. However, it does not explicitly state when to choose this tool over other list tools (e.g., list_accounts), though the tool name makes its purpose clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, which align with the description's read-only operation. The description adds deep behavioral context: derived payment_status logic, connector asymmetry, bill grouping reliability warnings, open_bill derivation details, and the fact that the tool returns a warning instead of failing if CREDIT_CARDS product is not enabled. 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 long but well-structured. It is front-loaded with the main purpose, followed by important notes (IMPORTANT), optional parameter details, connector asymmetry, and additional warnings. While somewhat verbose, the length is justified by the complexity of Brazilian Open Finance semantics. Each section adds essential information, and the use of bullet-like formatting (e.g., `PAID` | `OPEN` | ...) improves 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?

Given the complexity of the domain and the absence of an output schema, the description comprehensively explains the response fields: dueDate, totalAmount, minimumPaymentAmount, allowsInstallments, payments array with fields, counts, totals, finance charges aggregates, derived payment_status, and open_bill structure. It also covers edge cases like connector asymmetry and bill grouping reliability. The agent has enough information 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%, so the description must compensate. It explains account_id (echo block context), account_ids (bulk support), and include_open_bill (extensive details on optional behavior, default false). However, page and page_size are not explicitly described, though their role in pagination is inferable from the listing context. A minor gap, but overall the description adds significant meaning beyond the schema.

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

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

The description clearly states the tool returns CLOSED credit card bills for a CREDIT-type account, listing specific fields. It distinguishes itself from the sibling tool openfinance_list_transactions by noting that this tool provides bill-level summaries, not individual transactions. The verb 'Returns' and resource 'CLOSED credit card bills' are precise, and the scope is well-defined.

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 includes extensive usage guidance: it explains when to use the tool (listing closed bills), when not to assume payment status, how to use openfinance_list_transactions for itemized purchases, and provides alternatives for total debt. It also warns about connector asymmetry and when the open bill is unavailable, ensuring the agent can decide appropriately.

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 thoroughly discloses critical behaviors: data integrity checks for mass zeroing (with cross-referencing), structured error responses instead of exceptions, and flags like `integrity:'suspect_zeroed'`. Annotations already mark it as read-only/idempotent, and the description adds significant operational context.

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

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

The description is lengthy but highly informative, with key information front-loaded (purpose, return types) and edge cases well detailed. Some redundancy could be trimmed, but it efficiently conveys complex behavior without unnecessary fluff.

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

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

Given the tool's complexity (multiple asset types, pagination, bulk, data integrity) and no output schema, the description covers the return format, error handling, and integrity warnings. It could be improved by detailing the structure of each position object, but overall it provides a robust understanding of the tool's behavior.

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 6 parameters and 0% schema description coverage, the description fails to explain each parameter individually. It mentions `item_ids` for bulk support and implies pagination (`page`, `page_size`) and filtering (`type`), but does not define `item`, `page`, `item_id`, or provide complete semantics. The description adds some value but is insufficient for full parameter understanding.

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

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

The description explicitly states it returns the investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.). It distinguishes from sibling tools like openfinance_list_investment_transactions by focusing on portfolio positions, not 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 clearly indicates the tool is for retrieving investment portfolios and mentions behavior when INVESTMENTS is not enabled. However, it does not explicitly contrast with alternatives like openfinance_list_investment_transactions for when to use which, but the context is clear enough.

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

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

Annotations indicate readOnly, destructive false, idempotent. Description adds detailed row fields (quantity, value, expenses, etc.) and bulk support, going beyond annotations.

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

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

Two concise paragraphs, front-loaded with purpose, then details. No unnecessary words.

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

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

Explains row contents and prerequisite despite no output schema. Lacks pagination details but overall comprehensive for a list tool.

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

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

Description covers investment_id and investment_ids but omits page and page_size. With 0% schema description coverage, partial compensation is provided.

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

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

Clearly states it returns movement history for investment positions, listing specific transaction types and fields. Differentiates from sibling tools like openfinance_list_investments and openfinance_list_transactions.

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

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

Provides explicit prerequisite: use after openfinance_list_investments to get investment_id. Also mentions bulk support. Does not explicitly state when not to use, 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?

Discloses sequential querying with rate-limit spacing and return format ({ results, errors }) beyond annotations (readOnlyHint, idempotentHint, destructiveHint). 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?

Concise, front-loaded with purpose, each sentence adds value. 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?

Covers usage, behavior, and return format. No output schema needed; description is complete for correct tool invocation.

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

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

Schema has no description for `items`; description explains it as connection selectors (uuid, connector_id, or connector_name) and omission behavior. Adds significant meaning despite 0% 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?

Clearly states the tool lists loan contracts per bank connection (GET /loans), with specific verb and resource. Distinguishes from siblings like openfinance_get_loan_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?

Explains when to pass `items` (for specific connections) vs omit (all banks), including sequential querying and rate-limit spacing. Does not explicitly mention alternatives but provides sufficient 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?

The description discloses far more than the annotations already provide: results are date-descending, top rows may be future scheduled installments, `scheduled:true`, `scheduled_count`, `truncated:true` at 5000, automatic upstream pagination, error response shape, provider_incident behavior, and per-connector credit card data inconsistency caveats. The read-only/idempotent annotations are not contradicted.

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 and every sentence is informative, but it is quite long and repeats some warnings, such as the billId-is-a-hint caveat and the per-connector inconsistency point in more than one place. It is well organized and thorough enough for a complex tool, but it could be condensed slightly without losing 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 that the tool has no output schema in the context and eight parameters, the description does a very strong job of describing what fields appear, what the response shape is, how returns signal truncation or errors, and which sibling tools cover adjacent needs. Important edge cases such as multiple banks, shared accounts, and pending/installment transactions are all 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?

Input schema has no descriptions, but the description compensates comprehensively: it explains `from`/`to` ISO formats, `search_queries` substring and OR semantics, `page`/`page_size` auto vs manual pagination defaults, `detail` compact/rich/raw modes, and the meaning of account echo semantics. This lets an agent call the tool without needing extra documentation.

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 opens by saying exactly what the tool does: returns transactions for a bank account, explicitly including BANK or CREDIT type accounts. It also distinguishes itself by stating that for CREDIT accounts this is the ONLY way to get itemized transactions, which separates it clearly from related billing or account 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?

It gives unusually specific when-to-use guidance: use openfinance_list_credit_card_bills for a standardized bill total, use openfinance_list_accounts for closing/due dates, use openfinance_get_item_status when a credit account returns zero, and pass `to` = today to list only already-occurred transactions. It also explains the default pagination vs manual pagination decision explicitly.

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, so the burden is low. The description adds valuable context: truncation at 5000/account with a 'truncated' flag, and a 'provider_incident' block warning about potential incomplete data. 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 quite long but front-loaded with the main purpose. Every sentence adds value, and it is well-organized with logical flow. A minor reduction could be made, but overall it is appropriately detailed and structured.

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

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

Given no output schema, the description thoroughly explains the return structure: compact summary with totals, monthly evolution, top expenses/revenues, per-account breakdown, and raw rows with optional enrichment. It also covers truncation, provider incidents, and bulk support, leaving 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?

Schema coverage is 0%, but the description compensates fully. It explains all 9 parameters: 'item' accepts multiple identifiers, 'from'/'to' are ISO dates, 'granularity' defaults to 'monthly' and details its effect, 'detail' options, 'type' filter, 'top_n', and 'item_ids' for bulk. Defaults and values are clearly defined.

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 as consolidated cash-flow analysis for a bank connection over a period, resolving accounts internally. It distinguishes itself by noting that you don't need to call openfinance_list_accounts first, which differentiates it from sibling tools.

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

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

The description explicitly says when to use the tool (for annual/monthly analysis, cash flow, etc.) and provides context for omitting 'item' to analyze all connections. It does not explicitly contrast with sibling tools like openfinance_list_transactions, but it gives clear use cases and defaults.

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. Description adds valuable behavioral details (returns global indicator, degraded components, open incidents, flags for user's banks) 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?

One paragraph, front-loaded with purpose. Every sentence adds value, though slightly 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?

Thorough explanation of output components and usage context despite no output schema. Fully addresses a simple health-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 in JSON schema; description adds no parameter info, but baseline 4 for 0-param tools is appropriate.

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

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

The description clearly states it checks the LIVE operational status of the Open Finance provider, distinguishing it from the connection-specific `openfinance_get_item_status` 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 use: when data appears incomplete or stale despite a connection showing UPDATED, with concrete examples. Lacks explicit 'do not use' scenarios.

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

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

Annotations indicate readOnlyHint and idempotentHint, so the tool is non-destructive. The description adds valuable context: caveat warnings for non-Open-Finance connectors, plan-specific filtering, and that it returns a connect_url. 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 fairly long but well-structured, front-loading the main purpose. Every sentence adds value, though some details could be slightly more compact. Overall, it's efficient for the information provided.

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 covers return fields (id, access, audience, linked connections, accounts, connect_url, caveat) and plan behavior. It doesn't mention error handling or rate limits but is sufficiently complete for a search tool with read-only semantics.

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

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

Schema has 0% description coverage, but the description explains both parameters: keywords as required array with examples, and include_accounts as boolean to include accounts. This fully compensates for missing schema descriptions, adding meaning beyond the bare types.

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 and lists the returned fields (id, access, audience, etc.). It distinguishes from siblings by specifying to call before connecting to get a one-click link. The verb 'searches' and resource 'bank connectors' are specific and unambiguous.

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

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

Explicitly says to call BEFORE connecting, implying when to use. It discusses plan behavior (PF vs PJ) and notes that without keywords it returns a hint rather than dumping the catalog, providing clear when-not guidance. It also hints at preferring Open Finance connectors over credential ones.

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 critical behavioral traits beyond annotations: it overrides automatic categorization, teaches Pluggy by creating Category Rules, and explains per-item error handling in batch. This adds substantial context that annotations alone do not provide.

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

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

The description is well-structured and front-loaded with the main purpose. It could be slightly shortened, but every sentence adds value. Minor redundancy in explaining the side effect, but overall efficient.

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

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

Given the complexity of a batch update with side effects and error handling, the description is comprehensive. It covers how to use, behavioral implications, return shape, and error details. No output schema exists, so the description fills that gap 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 0% schema description coverage, the description fully compensates by explaining the 'items' array structure, required fields (transaction_id, category_id), and their sources. It also describes the response shape, aiding parameter understanding. No enums or nested objects, but coverage is complete.

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 corrects the category of transactions via PATCH /transactions/:id. It distinguishes from siblings by referencing openfinance_list_transactions and openfinance_list_categories as sources for IDs, making 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?

The description explains when to use: to fix miscategorized transactions and improve categorization. It mentions the side effect of creating Category Rules, implying future benefit. While it doesn't explicitly state when not to use, the context is clear. It could be slightly improved with direct exclusions, but is 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?

The description does not disclose behavioral traits beyond the obvious (sending a report). Annotations indicate idempotentHint=true, which is not addressed. No contradiction, but the description provides minimal behavioral context.

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

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

Two concise sentences front-load the purpose and provide a key instruction. Every word adds value with no fluff.

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

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

With no output schema and 3 parameters with 0% schema coverage, the description inadequately explains return values or outcomes. It only covers one parameter partially, leaving the agent without complete context.

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

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

Schema coverage is 0%, so the description must compensate. It clarifies the conversation parameter's purpose but does not explain the context or message parameters beyond the obvious. Partial compensation, leaving gaps.

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

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

The description clearly states the tool's purpose: reporting bugs, missing features, or feedback. It is specific and distinct from the sibling tools, which are mostly related to open finance operations.

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

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

The description gives guidance on including the conversation array for reproduction, but does not explicitly state when to use this tool vs alternatives or any exclusions. The context signals show no similar sibling tools, so the usage is implied.

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, and destructiveHint, covering the safety profile. The description adds no new behavioral details beyond 'show versions', so it meets the baseline but does not enhance 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 a single sentence with no unnecessary words, perfectly front-loaded with the verb 'show' and the resource 'versions'. Every word earns its place.

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

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

For a tool that simply returns version info without an output schema, the description is reasonably complete. It states what information is provided (platform and adapter versions). While the exact format is unspecified, the simplicity of the tool makes this acceptable.

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

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

The tool has no parameters, and the schema coverage is 100%. Per rubric, 0 parameters gives a baseline of 4. The description adds no parameter info, but that is acceptable as there are none to describe.

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 shows platform and adapter versions, which is a specific verb-resource pair. It distinguishes from siblings like openfinance tools or authenticate since those have different purposes.

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

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

As a simple version checker, explicit usage guidance is not critical. The description implies the tool is for retrieving version info, and the context of sibling tools makes it clear this is distinct. Lacking explicit 'when to use vs alternatives', but still clear.

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

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

Annotations already declare readOnlyHint and destructiveHint, so safety is covered. The description adds behavioral context by specifying what the returned state includes and that it reflects the current toolkit status, which goes beyond the annotations.

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

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

Single sentence, front-loaded with 'Returns the current toolkit state', followed by a specific list. No filler.

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

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

Given zero parameters and no output schema, the description adequately covers the tool's purpose and return content. It lists the information categories, making it sufficient for agent understanding.

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

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

No parameters; schema is empty with 100% coverage. Baseline of 4 applies, and no parameter explanation is needed.

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 current toolkit state and enumerates specific contents (installed MCPs, connection status, accounts, catalog tool counts), distinguishing it from sibling tools focused on specific finance operations.

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

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

The description implies usage for checking toolkit state, but does not explicitly mention when to prefer this over alternatives or any exclusions. Context is clear but lacks explicit comparison to siblings.

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