Inter MCP

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

Discloses behavior beyond annotations: explains two invocation modes (with/without token), persistence (permanent vs session). Annotations already indicate idempotency, and description aligns. No contradiction.

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

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

Description is informative and front-loaded with purpose. Each sentence adds value. Slightly long but well-structured for a simple tool.

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

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

Covers key aspects: purpose, invocation methods, token source. No output schema exists, so missing return value details is acceptable. Lacks error handling notes, but overall complete for a simple auth tool.

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

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

Schema coverage is 0%, but description explains the token parameter: a JWT access token. Also explains that omitting it returns a link. Adds full meaning to the only parameter.

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

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

Clearly states the tool is for authentication of MCP.AI for IDE agents. Describes two methods: permanent via config or session via token parameter. No explicit differentiation from sibling tools, but the purpose is unambiguous.

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

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

Provides clear usage guidance: best method (config) and alternative (token parameter). Also mentions calling with no args to get a link. However, no comparison with sibling tools or when not to use this tool.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context about the return values based on connection state (authenticated:true vs connect_urls), providing additional value beyond annotations.

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

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

The description is a single, well-structured paragraph of two sentences with no unnecessary words. Every sentence adds meaningful information.

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

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

For a tool with no parameters and simple behavior, the description adequately covers the two main states and return values. No output schema exists, but the description explains what to expect. Complete for this level of 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?

No parameters exist, so schema coverage is effectively 100%. Baseline for 0 parameters is 4 per instructions. Description adds nothing about parameters, but none are 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 it returns connection status and URLs, with specific details on return values based on connection state. It distinguishes itself from siblings like 'authenticate' by focusing on status checking.

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 such as 'authenticate' or 'openfinance_list_connections'. The description implies it's for checking connection status but does not specify when other tools would be more appropriate.

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 many behavioral traits beyond the annotations: invoke works even when the MCP is not installed, invoke returns connect/checkout links for credentials or payment, install/uninstall/subscribe/cancel require owner/admin, and prompt links open without login. These details add valuable context not present in the sparse annotations, and there is no contradiction.

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

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

The description is a dense single paragraph of about 300 words, covering a wide range of behaviors in a continuous flow. Every sentence is informative and earns its place, but the lack of bullet points or visual structure makes it harder to scan quickly. It is appropriately detailed but not optimally concise.

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

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

Given the tool's complexity (14 actions, 23 params, no output schema), the description covers many important contexts: the search→describe→invoke flow, auth and billing edge cases, install-vs-invoke tradeoffs, and the prompt library. However, it does not specify the return format of most actions or enumerate all parameters, leaving a few 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 23 parameters and zero schema description coverage, the description carries the burden. It does explain key parameters contextually (e.g., action, tool_id, mcp_id, prompt_slug) via the core flow and action descriptions, but many parameters (limit, query, conversation, immediate, tier_slug, cancel_reason, etc.) remain implicit and unexplained. The description adds some meaning beyond the schema but is not a comprehensive parameter reference.

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 explains the core flow: search discovers MCPs by intent → describe returns a full profile → invoke runs the tool. It distinguishes itself from siblings (openfinance_*, toolkit_info) by being the universal discovery/invocation hub rather than a domain-specific data tool.

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

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

The description gives explicit when-to-use vs alternatives: 'prefer invoke for a single/occasional use' vs 'Use install only to make an MCP PERMANENT', plus actions like 'list_tools lists what is callable right now' and 'request_mcp asks us to build a NEW MCP when nothing fits'. It also includes auth requirements ('Writes ... require workspace owner/admin') and distinguishes the prompt library from MCP usage.

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

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

Annotations already mark the tool as destructive. The description adds value by specifying that connection data is deleted and a reconnection URL is returned, aligning with and expanding on the destructive hint.

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 comprised of three short, front-loaded sentences with no unnecessary information, achieving high conciseness.

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

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

For a simple tool with one parameter and no output schema, the description covers the main action and return value. It lacks error scenarios or prerequisites but is largely complete for its 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?

The single required parameter 'item' has no schema description and the tool description only vaguely refers to 'a specific bank', without clarifying the expected format or source (e.g., bank ID, connection ID). Given 0% schema coverage, more detail 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 explicitly states the tool revokes consent and deletes connection data for a specific bank, clearly distinguishing it from sibling tools like openfinance_list_connections or openfinance_force_sync.

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

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

The description implies usage (when you want to disconnect a bank) but provides no explicit guidance on when to use it versus alternatives or when not to use it. No mention of prerequisites or context.

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

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

Annotations are minimal (no readOnly, destructive, or idempotent hints). The description richly details behavior: polls up to ~60s, fire-and-forget with wait:false, return fields (status, executionStatus, lastUpdatedAt, synced, needs_action, reconnect_url, timed_out), and error handling. This fully compensates for lack of annotation detail.

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

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

The description is a single dense paragraph, but it is front-loaded with the core action and adds essential details. Every sentence adds value, though it could be slightly more structured (e.g., separate sections for parameters and return values). Not overly 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?

Despite lacking an output schema and having simple parameters, the description covers purpose, usage, parameters, return value semantics, error states (needs_action, timed_out), and even an alternative usage (wait:false). It is comprehensive for a tool of this complexity.

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

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

Schema coverage is 0%, so the description carries full burden. It thoroughly explains both parameters: 'wait' as fire-and-forget vs. wait, and 'items' as an array of selectors (item_id, connector_id, connector_name, custom_label) with omission syncing all. No parameter is left undocumented.

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

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

The description explicitly states the tool's purpose: 'Forces the bank to re-sync one or more connections NOW and WAITS for it to finish'. It uses a specific verb (force, sync) and resource (connections), and distinguishes from siblings by explaining it avoids disconnecting/reconnecting.

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

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

Provides clear when-to-use guidance: 'Use this when a balance or transaction list looks stale'. It also explains what it avoids and gives a fire-and-forget option. However, it does not explicitly state when not to use or compare to specific sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes well beyond that by explaining sync anchoring, the meaning of updateDateTime/updatedAt, structured warnings instead of thrown errors, degradation when the provider is unavailable or the connector is not Open Finance, and consent-related failure modes.

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

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

The description is longer than average, but it earns its length by covering freshness semantics, error conditions, and recovery steps. The core behavior is front-loaded, and the caveats are ordered by relevance. A slightly tighter sentence around the snapshot concept would improve it, but there is 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?

For a read-only tool with no output schema, the description does a solid job: it tells the agent what fields to expect (updateDateTime, updatedAt, warning), how rows behave on error, and how to recover. It does not describe the exact top-level response envelope, which would be helpful, but the operational context is strong enough for correct invocation.

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

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

The input schema only gives the type (array of strings) with zero description coverage, so the description must carry the meaning. It states that account_ids should be passed as an array and constrains it to 1–50 items. It does not explicitly say the IDs come from a list_accounts call, but the tool name and sibling context make that reasonably inferable.

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 names the exact operation (returns latest available balance per account id), identifies the endpoint, and immediately clarifies an important nuance: this is a snapshot from the last upstream sync, not a live read. That specificity distinguishes it from transaction-listing or account-detail 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?

It explicitly warns against treating the balance as a live read and gives a concrete decision path: if the balance is stale or disagrees with the sum of openfinance_list_transactions, run openfinance_force_sync and re-read. It also explains when credit accounts may return specific errors and how to recover, leaving no ambiguity about when this tool is appropriate.

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

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

The description goes beyond annotations by disclosing the batch response shape, a provider_incident block that may indicate unreliable credit limits, and warns not to present those values as real. This fully informs the agent of important behavioral traits.

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 (3 sentences), front-loaded with the main action, and contains no unnecessary information. 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?

Given the simple input schema and no output schema, the description adequately covers input constraints, response shape, and a critical caveat about data reliability. It could optionally describe account object fields in more detail, but it is sufficient for an agent.

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

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

The description adds meaning beyond the schema by specifying the allowed range (1–50) for the account_ids array and that the response is a batch with results and errors. Since schema coverage is 0%, this is valuable context.

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

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

The description clearly states the tool returns full account objects including extended creditData per ID. It uses specific verbs and distinguishes from siblings like openfinance_list_accounts (which likely returns summaries) and openfinance_get_account_balance.

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

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

The description implies usage for retrieving detailed account data when full objects are needed, but it does not explicitly state when to use this over siblings or provide exclusions. The context is clear but lacks explicit alternative 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=true, idempotentHint=true. The description adds substantial behavioral context beyond annotations: bill payloads lack transactions, account_id is required for opt-in, transactions_basis with exact vs estimate semantics, authoritative totalAmount, opt-in cost, batch shape, and the payments nuance. No contradiction.

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

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

The description is long but front-loaded with core purpose and structured around key caveats. Every sentence carries useful information (opt-in cost, basis logic, payment semantics). Some redundancy, such as repeating the need for account_id, but complexity justifies the length.

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?

Comprehensive guidance for a complex tool: covers transaction linking, cost, authoritative totalAmount, payments interpretation, batch shape, and discovery path. Even without an output schema, an agent has everything needed to call 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?

Schema coverage is 0%, so description must compensate. It explains bill_ids, include_transactions, and account_id clearly. However, it does not explain the `transactions_detail` enum (compact/rich/raw), leaving that parameter ambiguous. Partial coverage of the four parameters.

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

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

States a specific verb and resource: 'Returns bill-level detail for one or more credit card bills by id.' It clearly distinguishes from sibling tools like openfinance_list_credit_card_bills by explicitly advising to use the list tool first for discovery. The scope and primary action are unambiguous.

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

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

Provides explicit when-to-use guidance: discover ids via list tool, opt-in transactions only when needed (with cost warning), and offers an alternative to fetch transactions via openfinance_list_transactions. It also clarifies when payments[] should not be interpreted as paid status, reinforcing correct usage.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds useful behavioral details: what fields are returned (executionStatus, connector metadata, reconnect_url) and the specific behavior of the reconnect_url for re-authentication without consuming a slot. This goes beyond the annotations without contradiction.

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

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

The description is somewhat lengthy but well-structured, front-loading the main purpose and then providing detailed behavior. It balances completeness with clarity, though could be slightly more concise.

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

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

Given no output schema, the description adequately describes the return structure for both single and bulk modes. It covers the main fields and the reconnect_url functionality. Minor gaps like error handling or permissions are not critical for this read-only tool.

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

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

The input schema has no descriptions (0% coverage), but the description compensates by explaining the effect of omitting `item` (returns all), passing `item` (single result), and using `item_ids` for bulk. This adds meaning beyond the schema alone.

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

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

The description clearly states it returns the current status of a bank connection with specific fields like UPDATED, UPDATING, LOGIN_ERROR, executionStatus, and reconnect_url. This differentiates it from sibling tools like openfinance_list_connections which list connections rather than providing detailed status.

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

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

The description provides explicit guidance on usage: omit `item` to get all linked banks, pass `item` for a single bank, and accepts item_ids for bulk execution. It does not explicitly mention when not to use or compare to alternatives, but the usage patterns are 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 readOnly, idempotent, non-destructive. Description adds batch behavior and error structure, but no additional side effects, rate limits, or auth details. Adds moderate value beyond annotations.

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

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

Description is a single sentence that efficiently conveys purpose, usage context, fields, and batch shape. No wasted words, but could be slightly more structured (e.g., bullet points for fields).

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 lists key return fields (interestRates, charges, etc.) and batch result shape. Adequate for a retrieval tool with annotations covering safety. Minor omission: no error detail beyond {results, errors}.

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; description compensates by explaining loan_ids is an array of strings (1-50 items) and how it's used in batch. Adds meaning beyond schema structure.

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 returns full loan detail by ID, lists specific fields (interestRates, charges, etc.), and distinguishes from sibling openfinance_list_loans by saying 'Use after openfinance_list_loans to deep-dive on a specific contract.'

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 usage context: use after openfinance_list_loans for deep-dive. Specifies batch input (1-50 loan_ids) and output shape ({results, errors}). Lacks explicit when-not-to-use or alternatives, but context 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 annotations already mark this as read-only and idempotent, and the description adds substantial behavioral context beyond that: `balance` is connector-dependent for credit cards, `balance_notice` indicates a 0.00 balance may be misleading, `bankData` fields can lag after connection creation, `provider_incident` can make values unreliable, and `identity_notice` affects ownership attribution and dedup. 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?

The description is long and dense, but every paragraph addresses a real behavioral nuance that affects correct tool use. It is front-loaded with the core return contract before moving to caveats and alternatives. It could be tightened, but it is not padded or repetitive.

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 complex connector-dependent behavior, this description is remarkably complete. It covers the returned fields, how to distinguish bank brand from legal entity, how to handle unreliable balance values, deduplication guidance, provider incidents, identity notices, and bulk execution. An agent has enough context to invoke the tool and interpret its results correctly in nearly all cases.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It clearly explains `item` (single bank vs. omission for all banks), `type` semantics through the BANK/CREDIT distinction, and `item_ids` for bulk execution. The `item_id` parameter is not explicitly described, and the relationship between `item` and `item_id` is left implicit, which prevents a perfect 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 opens with a precise verb and resource: 'Returns accounts for a bank connection' and enumerates BANK/CREDIT account types and key fields (balance, number, type, subtype, bankData, creditData). It further distinguishes itself from siblings by explicitly deferring standardized bill amounts to openfinance_list_credit_card_bills, so an agent can tell this tool apart from related account/bill 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 usage rules: omit `item` to list accounts across all linked banks, or pass `item` to target a single bank. It also provides routing guidance for alternatives, such as using openfinance_list_credit_card_bills for standardized open-bill amounts and total debt, and openfinance_force_sync to reconcile stale derived fields. This leaves little to inference.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral details: cached for the session, single aggregated response, no batch ids, and field structure. This provides useful 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?

The description is concise at three sentences, front-loaded with the main action, and every sentence adds value by describing the output fields and caching behavior.

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

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

Given no output schema, the description adequately explains the return structure (fields: id, description, descriptionTranslated, parentId, parentDescription). It also covers caching and aggregation behavior. Slightly missing explicit mention that it returns a list, but 'taxonomy' implies it. Overall complete for a simple read-only tool.

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

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

There are zero parameters, and schema coverage is 100%. The description does not need to add parameter info; baseline for 0 params is 4. The description effectively explains what the tool returns without parameter details.

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 Pluggy's transaction category taxonomy', specifying the verb and resource. It mentions caching and links the categoryId to the sibling tool openfinance_update_transaction_category, distinguishing its purpose from other tools.

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

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

The description implies usage before calling openfinance_update_transaction_category via the mention of categoryId. It also notes caching and single aggregated response. However, it does not explicitly state when to avoid using it or provide alternatives, but given its simplicity and read-only nature, the context is adequate.

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 safe read operation. Description adds that reconnect_url does not consume a slot or require disconnecting, which is non-obvious. 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?

Single paragraph with clear front-loading of purpose and output fields. Every sentence is informative with no redundancy.

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

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

Describes output structure and reconnect/add URLs. Lacks mention of error cases or pagination, but given no parameters and typical use, adequate. Could mention that list is all saved connections.

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; schema coverage is 100%. Baseline score of 4 applies as description adds no extra parameter info nor 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?

Clearly states the tool returns saved bank connections and lists specific fields (connector_id, item_id, etc.). Differentiates from sibling tools like openfinance_list_accounts and connection-related 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?

Provides explicit when to use reconnect_url (re-authentication, LOGIN_ERROR) and what it does not require. Lacks direct comparison to all siblings but gives sufficient context for the main use case.

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, destructiveHint=false. Description adds critical behavioral context: complex payment_status derivation, connector asymmetry, bill_grouping_reliability warning, and open_bill availability nuances. 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 very long and dense, covering many edge cases. While front-loaded with main result, it could be more concise and better structured with sections or bullet points. Some redundancy (e.g., repeating 'do not assume' multiple times).

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

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

Despite no output schema, the description meticulously details return fields, derived values (payment_status, open_bill, future_bills), warnings, and limitations. Completeness is high for a complex financial tool.

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

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

Schema coverage 0% means description must compensate. It deeply explains include_open_bill, account_id, account_ids, but page and page_size are not described. Main parameters are well-covered, but minor gap prevents a 5.

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

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

The description clearly states the tool returns closed credit card bills for CREDIT-type accounts, listing specific fields. It distinguishes from siblings like openfinance_get_credit_card_bill (single bill) and openfinance_list_transactions (transactions vs bills), and mentions bulk support via account_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?

Extensive guidance on when to use, including opt-in for open_bill, connector asymmetry, and when not to use (e.g., not to reconstruct total by summing transactions). Provides alternatives like openfinance_list_transactions for itemized purchases.

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

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

Annotations indicate read-only and idempotent. The description adds crucial behavioral traits: error handling for 403 when investments not enabled, and a detailed data integrity mechanism for mass zeroing (cross-checks transaction history, flags suspect_zeroed). This exceeds what annotations provide.

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

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

The description is front-loaded with purpose and structured in clear sections (return values, error handling, data integrity, bulk). It is somewhat lengthy but every sentence adds value. Could be slightly more concise while retaining detail.

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

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

Given no output schema, the description thoroughly explains return format (total, results, warning) and data integrity flags. It covers edge cases (suspect zeroed), error handling, and bulk execution, making it complete for an agent to understand behavior and outputs.

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 6 parameters with 0% description coverage. The description only partially adds context by listing investment types that align with the 'type' enum, and mentions item_ids for bulk. It does not explain page, page_size, item, or item_id individually, leaving agents uninformed about their usage.

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

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

The description clearly states the tool returns an investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.) and details (balance, rates, issuer). This distinguishes it from siblings that handle accounts, transactions, or 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?

Usage is clear: for investment portfolio retrieval. The description mentions graceful error handling (returning warning instead of throwing) and bulk support via item_ids. However, it does not explicitly state when not to use it or suggest alternatives, though the purpose is specific 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 already declare readOnlyHint and idempotentHint. Description adds useful context like return field details and bulk capability, which augments without contradiction.

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

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

Efficient two-paragraph structure with key info front-loaded. Could be slightly leaner but contains 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?

Covers purpose, prerequisite, and bulk support, but lacks details on pagination parameters, error handling, and response format.

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

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

Schema description coverage is 0%, so description must compensate. It explains investment_id and investment_ids, but does not describe page or page_size parameters.

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

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

Clearly states it returns movement history for a specific investment position, listing types and fields, and distinguishes from sibling openfinance_list_investments by mentioning prerequisite.

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 a clear prerequisite ('Use after openfinance_list_investments to get the investment_id') and mentions bulk support, but does not explicitly state when not to use or compare to 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?

Adds significant context beyond annotations: sequential queries with rate-limit spacing, return format as '{ results, errors }' per connection, and behavior when 'items' is omitted. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint 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?

Two sentences front-load the purpose and then provide usage and details. Every sentence adds value with no redundancy or wasted words.

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

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

Given no output schema, the description explains the return structure ('{ results, errors }' per connection). Does not detail the fields within results or mention pagination, but for a list tool with one parameter, this is largely 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?

With 0% schema coverage, the description fully explains the 'items' parameter: an array of connection selectors (item_id uuid, connector_id, or connector_name) and the effect of omitting it. However, it does not explicitly state the parameter is optional, though implied by schema having no required.

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

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

The description clearly states the tool lists loan contracts per bank connection, specifying the endpoint 'GET /loans'. It distinguishes from sibling 'openfinance_get_loan_detail' by focusing on listing, not retrieving 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?

Provides explicit guidance on when to pass 'items' (specific connections) and when to omit it (all banks). Does not mention when to use alternatives like 'openfinance_get_loan_detail', but the context is clear enough for typical use.

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

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

The description vastly exceeds the annotations, disclosing auto-pagination behavior, the 5000-row ceiling, error-shape returning {total:0, results:[], warning, error}, ordering of future-dated rows, per-connector variations in billId population, and the behavior of `scheduled_count` and `notice`. Nothing here contradicts the annotations; the safety profile is already declared but the description adds deep contextual behavior.

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, well-organized by topics like PAGINATION and CREDIT PENDING/POSTED, but it is extremely long and repeats some warnings, most notably the `billId` sparse/inconsistent caveat (Nubank) appearing twice. It uses sentences economically almost everywhere and earns its length for a complex tool, but the redundancy and volume keep it slightly short of the highest standard.

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 8 parameters, no output schema, and 0% schema coverage, the description covers everything an agent needs: parameters, page limits, filtering semantics, response shape, echo identification, connection-health troubleshooting, provider incidents, and differentiation from sibling tools. No significant contextual 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%, but the description compensates comprehensively: `from`/`to` are explained as ISO YYYY-MM-DD date filters; `search_queries` semantics (case/accent-insensitive OR-substring match) are detailed; `page`/`page_size` manual pagination is distinct from auto-paginated default; `detail` values compact/rich/raw are fully described; even `account_ids` bulk support is noted. The description makes every parameter actionable despite the empty schema coverage.

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

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

The description states a specific verb and resource ('Returns transactions for a bank account (BANK or CREDIT type)') and immediately distinguishes itself from siblings by noting this is the ONLY way to get itemized credit card transactions, while also explicitly routing standardized bill totals to openfinance_list_credit_card_bills. It is unambiguous about what the tool does and how it differs from nearby 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?

Usage guidance is explicit with when/when-not and named alternatives: it says when to use openfinance_list_credit_card_bills, when to use openfinance_list_accounts for closing/due dates, when to use openfinance_get_item_status, and even when to pass `to`=today to list only what already happened. It also warns against reading the first row without checking `scheduled` and against reconstructing bill totals by summing transactions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds important behaviors: truncation at 5000 transactions/account with truncated:true flag, and provider_incident block when provider has open incident, affecting data completeness.

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?

Front-loaded with purpose, well-structured with separate notes on bulk support and provider incidents. Some redundancy (e.g., 'in ONE call' repeated) but overall efficient for a complex tool.

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 return types (compact summary fields, per-account breakdown, top lists), truncation, provider incidents, and bulk execution. Missing exact structure of nested fields, but adequate given no output schema.

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

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

Schema coverage is 0%, but description explains parameters: item (accepts connector_id, connector_name, or item_id), from/to as ISO dates, granularity and detail enums with meanings, and top_n implied by top_despesas/recebimentos. Adds significant meaning beyond schema.

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

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

The description clearly states it provides consolidated cash-flow analysis for a whole bank connection in one call, resolving accounts internally. It distinguishes from sibling tools by noting it avoids separate calls to list_accounts and individual transaction endpoints.

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

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

Explicit guidance on when to use (e.g., for annual/monthly analysis, cash flow, top expenses) and when not to use alternatives (no need to call list_accounts first). Details granularity options and bulk support.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds value by detailing return structure (global indicator, degraded components, incidents, and `your_banks_affected`), but does not mention potential rate limits or authentication specifics, which are minor gaps.

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 well-structured with front-loaded purpose followed by usage context and return details. While slightly verbose, each sentence adds value and no redundant 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?

Despite lacking an output schema, the description comprehensively explains return values and usage context. It covers the tool's role relative to siblings and provides enough detail for effective 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?

No parameters exist, and schema coverage is 100%. Baseline for zero parameters is 4. Description does not need to add parameter info, so this score reflects adequate handling.

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 'Checks the LIVE operational status of the Open Finance provider' with specific verb and resource, and distinguishes it from the sibling tool `openfinance_get_item_status`, making purpose unambiguous.

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

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

Explicitly explains when to use: 'whenever data looks incomplete or stale... connection shows UPDATED', and contrasts with alternative (`openfinance_get_item_status`), providing clear situational 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 readOnly, idempotent, non-destructive. Description adds behavioral context: returns connect_url, honors user plan, caveat warnings for manual reconnection, and never dumps full catalog without keywords. 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 relatively long but each sentence adds value. It front-loads the main action and return items. Could trim some redundant phrasing, but overall efficient for the complexity.

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

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

Given no output schema, the description adequately lists returned fields (connector id, access, audience, linked connections, connect_url). It also covers caveats and plan behavior. Might miss structure of linked connections, but sufficient for a search tool.

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

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

Schema has 0% description coverage; the description compensates by explaining 'keywords' as an array of bank names (with examples) and noting it is REQUIRED behaviorally. It also explains 'include_accounts' returns linked connections and accounts when true.

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

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

The description clearly states it searches bank connectors by name and returns key details including a connect_url. It explicitly says to call this BEFORE connecting, distinguishing it from sibling 'connect'. The verb 'searches' and resource 'bank connectors' are specific.

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

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

Provides clear usage context: call before connecting, pass keywords (required), and surfaces caveats about non-Open-Finance connectors and plan behavior. Does not explicitly state when not to use, but the required keywords condition implies it should not be used without them.

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 important behavioral details beyond annotations: it overrides automatic categorization, creates category rules for future transactions, and describes batch behavior (per-item errors do not fail the whole batch). This adds significant value since annotations only mark readOnlyHint as false.

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 provides necessary details. While it is somewhat long, every sentence serves a purpose. Minor redundancy could be trimmed, but overall it is well-structured.

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

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

Given the complexity (batch update with side effects) and lack of output schema, the description covers all essential aspects: how to call it, side effects (rule creation), response format, and error handling. It is complete and leaves no significant 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?

Despite 0% schema description coverage, the description fully explains the parameter semantics: the items array structure, required fields (transaction_id and category_id), and how to obtain these from other tools. It also details the response shape, thoroughly compensating 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 action ('Corrects the category of one or more transactions') and the resource (transactions). It distinguishes from sibling tools by specifying the use of IDs from openfinance_list_transactions and openfinance_list_categories, making it unique among transaction-related 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?

Provides clear context for use: to fix miscategorized transactions and improve future categorization accuracy. It explains the input structure and source of IDs, but does not explicitly state when not to use this tool or mention alternatives, which is acceptable given the specificity of the tool.

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

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

The annotations set idempotentHint=true, but reporting a bug is inherently non-idempotent (each call creates a new report). This is a contradiction. The description does not clarify the behavioral traits beyond the action itself, and fails to disclose important details like what happens after reporting (e.g., confirmation, no 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 concise with two sentences. The first sentence states the purpose, and the second provides a usage hint. No unnecessary words. However, it could be more structured by listing all parameters briefly.

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 low schema coverage, no output schema, and the annotation contradiction, the description is incomplete. It fails to explain the return value, what happens after the report is sent, and the 'context' parameter. The agent lacks sufficient information to understand the full 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?

Schema coverage is 0%, so the description must compensate. It adds meaning for the 'conversation' parameter (include recent messages) but does not explain the 'context' field or the format/content of the required 'message'. This is insufficient for a tool with 3 parameters.

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

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

The description clearly states the tool is for reporting bugs, missing features, or feedback, using a specific verb and resource. It distinguishes from sibling tools which are primarily openfinance utilities or authentication 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 a clear usage hint to include the conversation array for reproduction. Since there are no sibling tools with overlapping functionality, it implicitly tells when to use this tool. However, it does not explicitly state when not to use it or provide alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds no further behavioral traits beyond specifying the versions returned. No contradiction.

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

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

Single sentence, no wasted words, clearly communicates purpose.

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

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

For a simple version info tool with no output schema, the description is complete and sufficient.

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 description does not need to add param info. Baseline 4 per schema coverage rules.

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

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

Description uses specific verb 'Show' and resource 'current MCP platform and adapter versions'. Clearly distinguishes from sibling tools which handle authentication, financial data, etc.

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

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

No explicit when-to-use or alternatives, but the tool's function is self-evident and simple. Context implies use when version info is needed.

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 it as read-only, idempotent, and non-destructive, which covers the safety profile. The description adds that it returns 'current toolkit state', but does not disclose whether connection status checks incur network latency or whether the data could be stale. No contradiction 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?

The description is a single, tightly written sentence that front-loads the main action and lists the key data components. Every word adds value, with no filler or redundant 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?

There is no output schema, but the description enumerates the four key data categories returned: installed MCPs, connection status, connected accounts, and catalog tool counts. This gives the agent sufficient expectation of the return structure. Combined with rich annotations, the tool is fully contextualized.

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, so there is no parameter semantics to explain beyond the schema's empty object. Per rubric, a tool with 0 params receives a baseline 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 states a specific verb ('Returns') and resource ('current toolkit state'), and enumerates exactly what is included: installed MCPs, connection status, accounts, and catalog tool counts. This clearly distinguishes it from sibling tools like openfinance_list_connections or show_version, which focus on narrower subsets of information.

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

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

The description provides clear context that this is the go-to tool for a high-level overview of the toolkit's state. It doesn't explicitly list alternatives or exclusion scenarios, but the context is unambiguous: when you need a summary of installed MCPs and their status, this is the tool. Sibling tools are more specific, so the usage context is clear.

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