99Pay MCP

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

The description adds behavioral context beyond annotations: explains permanent vs session login, how to use token, and that calling with no args gives a link. 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 detailed and front-loaded but slightly verbose; still, 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?

The description covers authentication fully: purpose, usage modes, and behavioral details. No output schema, but return values are implicit.

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 explains the 'token' parameter: it's a JWT, and describes two modes of use (config vs session paste).

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 authenticates MCP.AI IDE agents, explains login process and token usage, and is distinct from sibling tools like 'connect' and 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 explains when to use it (for login, with or without token) but does not explicitly mention when not to use it or provide alternatives. However, the context is clear.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds concrete response behavior (authenticated:true vs connect_url), which is beyond annotations.

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

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

Two sentences, no fluff, front-loaded with key purpose and examples.

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 parameterless tool with no output schema, description covers main states. Could mention if other states exist, but adequate.

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

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

No parameters; schema coverage is 100%. Description adds value by explaining return values, compensating for lack of output schema.

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

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

Description clearly states it returns connection status and URLs, and distinguishes from siblings like 'authenticate' which likely performs authentication. The examples of response states add specificity.

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

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

Implied usage for checking connection status, but no explicit when-to-use or when-not-to-use guidance. No 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?

The description goes far beyond the annotations by revealing key behaviors: invoke runs tools even when not installed, one-off without bloating the toolkit, returns connect links for missing credentials and checkout links for empty wallets. It also clarifies that install/uninstall/subscribe/cancel and the one-off install behind invoke are write operations requiring admin, aligning with readOnlyHint=false. 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 long but well-structured, front-loaded with purpose and organized around the core flow, special invoke behavior, permissions, and prompt library. While not concise, every sentence adds necessary value for a tool of this complexity, making the length justified.

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 massive scope (14 actions, 23 optional parameters), no output schema, and minimal annotations, the description is exceptionally complete. It covers all action categories, explains key return behaviors (profile lists, connect links, shareable links), and provides operational context (permissions, retry logic). No significant 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?

With 0% schema coverage, the description compensates substantially by explaining the action enum values (search, describe, invoke, install, etc.) and the meaning of core parameters like tool_id and mcp_id in context. However, several parameters (limit, immediate, tier_slug, conversation, prompt_vars) remain under-specified, though their purpose can be inferred from 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 identifies the tool as the official mcp.ai marketplace, a catalog and runner for MCPs/tools. It uses specific verbs like 'search', 'describe', and 'invoke' to define distinct capabilities, and its scope is clearly differentiated from sibling finance tools by covering the entire MCP lifecycle and prompt library.

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 is provided: the core flow (search → describe → invoke) is spelled out, with a clear recommendation to prefer invoke for one-off use and install only for permanent toolkit additions. It also states that writes require owner/admin and explains what happens with credentials or empty wallets, giving actionable context for when to use 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?

Annotations already mark destructiveHint=true. The description adds context beyond this: revokes consent, deletes data, and provides a reconnection URL. 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?

Two concise sentences front-load key actions and results with 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?

For a simple tool with one parameter, no output schema, and annotations present, the description covers effects and return value adequately.

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

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

Only one parameter 'item' with 0% schema coverage. The description implies it identifies the bank, but does not explicitly explain the parameter meaning or allowed values.

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 revokes consent and deletes connection data for a specific bank, specifying a return value. It uses specific verbs and resource, and distinguishes from siblings like 'connect'.

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 context (when disconnecting a bank) and the return of a reconnection URL, but does not explicitly state when not to use it or list 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?

Detailed disclosure of sync behavior, polling up to 60s, meanings of status fields, needs_action handling, and reconnect_url. Annotations indicate readOnlyHint: false, consistent with mutation. 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?

Well-structured and front-loaded, but somewhat verbose. Every sentence adds value, but could be slightly more concise for an AI agent. 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?

No output schema, but description thoroughly explains return structure (results, errors, fields like status, executionStatus, synced, needs_action, reconnect_url). Covers error scenarios and timeout handling.

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 fully: explains items as array of selectors with examples, clarifies omitting items syncs all, explains wait parameter with fire-and-forget behavior.

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

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

The description clearly states the tool forces a sync of bank connections and waits for completion. It distinguishes itself from siblings like openfinance_get_item_status by mentioning that tool for re-checking timed-out syncs.

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?

Gives explicit when-to-use (stale balance/transactions) and how to avoid disconnecting. Mentions fire-and-forget option with wait: false. Implicitly references sibling for status checks but doesn't name alternatives directly.

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 significant behavioral context: handling of CREDIT accounts with BALANCE_FETCH_ERROR, degradation to last-synced balance when institution is unavailable (5xx or non-Open Finance), and response structure with results/errors.

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

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

The description is moderately long but each sentence adds value. It is front-loaded with the main purpose, followed by constraints, error handling, and response shape. Could be slightly more concise but remains 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 one parameter, no output schema, and safety annotations, the description covers input constraints, error behavior, and response structure. It does not detail the fields in the results array, which is a minor gap, but overall complete for this 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 the description adds constraint: 'array (1–50)' and clarifies the parameter represents account IDs. This adds meaning beyond the schema's minimal type definition.

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

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

The description clearly states it returns real-time balance per account ID, specifies the endpoint, and distinguishes from siblings like openfinance_get_accounts_detail and openfinance_list_accounts by focusing specifically on 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 provides clear context on input format (array of 1-50 account IDs) and describes error handling behaviors (degradation to last-synced balance with warning). It does not explicitly state when to use vs alternatives, but 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 indicate read-only and idempotent behavior. The description adds critical context about the provider_incident block, warning that credit data may be unreliable during Open Finance incidents, which goes well 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?

Every sentence adds value: main action, usage, batch format, and a critical reliability warning. No wasted words, front-loaded with the core purpose.

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

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

Given no output schema, the description covers the return shape ({results, errors}) and the provider_incident block, which is sufficient for a single-parameter tool. It could mention authentication or error scenarios, but the existing details are adequate.

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

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

With 0% schema description coverage, the description must compensate. It explains the account_ids parameter's role and constraints (array size, batch shape). However, it could be more specific about the expected format of IDs (e.g., from list_accounts), so it's not a perfect 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 it returns full account objects with extended creditData per ID, and distinguishes from list operations. It includes the endpoint and batch shape, making the purpose unambiguous.

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

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

It specifies how to pass account_ids as an array of 1-50, which is clear usage. However, it does not explicitly contrast with sibling tools like openfinance_list_accounts or provide when-not scenarios, leaving some ambiguity.

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 batch shape { results, errors }, notes that Pluggy does not return paid/status field, explains that payments[] reflect payments of the previous bill cycle. Annotations already indicate readOnly and idempotent, but description adds critical behavioral context beyond that.

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 well-structured with front-loaded purpose. Each sentence adds value (e.g., caveats, usage notes). Could be slightly condensed but remains clear and informative.

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 thoroughly explains return content (financeCharges, payments fields), what is NOT included, batch shape, and important caveats about payment semantics and bill ID consistency. Provides comprehensive guidance 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?

Schema coverage is 0% for the single parameter bill_ids. Description compensates by explaining it is an array of string IDs and instructs to use openfinance_list_credit_card_bills first to discover IDs. Adds meaningful usage context 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?

Description clearly states it returns bill-level detail (financeCharges, payments) for one or more credit card bills by id. It distinguishes from sibling tools by specifying what it does NOT return (individual transactions) and directs to openfinance_list_transactions for itemized 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?

Explicitly provides when to use (bill-level detail), when not to use (for itemized transactions or reconstructing totals), and alternatives (openfinance_list_transactions, openfinance_list_credit_card_bills). Also guides on how to discover bill IDs and how to check paid status.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safe read-only nature is clear. The description adds valuable behavioral details: it returns executionStatus, connector metadata, and a reconnect_url that reopens the widget without disconnecting or consuming a slot. This provides extra 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 dense with information but remains readable and front-loaded. Every sentence adds value, covering main purpose, usage variants, and bulk support. It is slightly longer than necessary but still concise for the amount of detail 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 adequately explains what the tool returns (status, executionStatus, connector metadata, reconnect_url). It covers major behaviors like batch support and the reconnect functionality. It does not miss critical details for a status retrieval tool, though it could be more explicit about the output format for the 'all banks' case.

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 'item' (omit for all, pass for single) and 'item_ids' for batch, but does not mention the 'item_id' parameter. This is a gap. While it partially compensates for missing schema descriptions, it is not complete for all three 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?

Description clearly states the tool returns the current status of a bank connection, with specific fields (UPDATED, UPDATING, etc.) and additional metadata including reconnect_url. It distinguishes between querying all banks (omitting 'item') or a single bank (passing 'item'), and also mentions bulk support with item_ids. This 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?

Provides clear usage scenarios: omit 'item' for all banks, pass 'item' for a single bank, and mentions bulk support with item_ids. It also explains the reconnect_url use case for re-authentication. However, it does not explicitly discuss when not to use this tool or compare it to alternatives like openfinance_force_sync, so it's not a perfect 5.

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

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

Beyond annotations (readOnly, idempotent), the description adds details on return field structure, batch error handling, and parameter limits, enhancing 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?

Three focused sentences: first covers purpose and returns, second usage context, third parameter and output shape. No redundancy, efficiently front-loaded.

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

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

Given no output schema and moderate complexity, the description covers return fields, usage positioning, parameter constraints, and output shape. Adequately complete for an AI agent.

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

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

With 0% schema description coverage, the description fully compensates by specifying the array size limit (1-50) and clarifying batch semantics, adding significant meaning beyond raw schema.

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

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

The description clearly states it returns full loan contract detail by ID, lists key fields, and explicitly distinguishes itself from the sibling openfinance_list_loans by suggesting use after that.

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 instructs to use after openfinance_list_loans for deep-dive, specifies parameter constraints (array of 1-50 IDs), and mentions batch result shape, providing clear when and how.

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

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

Annotations already indicate readOnlyHint, idempotentHint, destructiveHint. Description adds critical behavioral context: provider_incident block making balances unreliable, identity_notice for deduplication, credit card balance meaning dependency. 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 lengthy but every sentence earns its place with essential detail and edge cases. Front-loaded with key purpose and parameters. Could be slightly more concise but justified by complexity.

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

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

No output schema, but description thoroughly documents return fields (balance, type, subtype, bankData, creditData, bank, connector_id, etc.) and special blocks (provider_incident, identity_notice). Complete for a listing tool with multiple nuances.

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 all parameters: item (omit for all vs per connection), type (BANK/CREDIT listed), item_id (single), item_ids (bulk). Adds 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?

Description clearly states the tool returns accounts for bank connections with specific types (BANK/CREDIT) and fields. Distinguishes between listing all accounts (omit item) vs single connection (pass item), differentiating from sibling tools like openfinance_get_accounts_detail.

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

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

Explicitly guides when to omit or pass item, and when to use openfinance_list_credit_card_bills for standardized billing. Warns about connector-dependent credit card balance meaning and provider incidents. Provides clear decision logic.

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

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

Annotations already mark the tool as read-only and idempotent. The description adds caching behavior ('cached for the adapter session'), which is valuable beyond the annotations. No contradictions.

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

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

Three concise sentences, front-loaded with the main purpose. Every sentence adds value: what it returns, caching, field explanations, and usage hint. 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?

Given no parameters and no output schema, the description sufficiently explains the return format and how it integrates with the update tool. It covers caching and localization. Could mention if pagination or limits exist, but for a taxonomy list it's adequate.

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

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

Input schema has no parameters, so schema coverage is 100%. The description adds meaning by explaining the output fields and their usage, including a hint for localization. Baseline 4 is appropriate.

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

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

The description clearly states it returns Pluggy's transaction category taxonomy, cached for the session. It specifies the fields included (id, description, descriptionTranslated, parentId, parentDescription) and how the output relates to another tool (openfinance_update_transaction_category), distinguishing it from siblings.

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

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

The description implies when to use the tool (to get category taxonomy for updating transactions) and provides guidance on preferring descriptionTranslated for pt-BR users. However, it does not explicitly state when not to use it or list alternative tools.

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

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

Annotations already indicate read-only and idempotent. Description adds that reconnecting does not consume a slot or require disconnecting, which is extra 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?

Single, well-structured paragraph that front-loads the key return 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 zero parameters and no output schema, the description fully explains the return fields and the purpose of URLs. It is complete 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?

No parameters exist, so baseline is 4. The description does not need to add parameter info.

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

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

The description clearly states the tool returns saved bank connections, listing specific fields. It distinguishes itself from siblings by focusing on connections and URLs, providing a clear 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?

The description provides usage context for the reconnect_url, but does not explicitly compare with siblings or state when not to use. It gives enough guidance 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 discloses behavioral traits beyond annotations, such as the derived payment_status logic, connector asymmetry, reliability warnings, and performance implications of include_open_bill. 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 detailed, covering many edge cases. While thorough, it could be more concise; some explanations (e.g., payment_status derivation) are lengthy. It is front-loaded with the main purpose.

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

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

The description is extremely comprehensive, covering all aspects: return fields, derived fields, opt-in behavior, connector asymmetries, cross-bill payment attribution, warnings, and bulk support. It leaves no major gaps given 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?

With 0% schema coverage, the description compensates by explaining include_open_bill, account_ids, and account_id in detail, but does not explicitly describe page and page_size parameters, leaving a small gap.

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

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

The description clearly states it returns CLOSED credit card bills for a CREDIT-type account and lists specific fields. It distinguishes from sibling tools by stating it returns bill-level summaries, not individual transactions, and implicitly contrasts with openfinance_get_credit_card_bill.

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

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

It provides explicit when-to-use guidance, including opt-in for open_bill, how to interpret payment_status, and when to use openfinance_list_transactions instead. It advises against misattributing bills to wrong banks and warns about cross-bill payment behavior.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description details error handling (returns {total:0, results:[], warning} on 403), data integrity checks (cross-checks with transaction history), and flagging suspect zero balances. 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 detailed and well-structured, starting with the core purpose, then field details, error handling, and data integrity. It is slightly long but 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 complexity (6 parameters, no output schema), the description covers main behavior, error handling, data integrity, and bulk support. It lacks explanation of paging parameters (page, page_size) but remains 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?

Schema coverage is 0%, and the description only explains 'item_ids' for bulk support. Other parameters (item, page, type, item_id, page_size) are not elaborated, but the overall context of listing investments helps infer their purpose.

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.) and detailed fields. It clearly distinguishes from sibling tools like openfinance_list_investment_transactions.

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

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

The description specifies when to use the tool (for connections with INVESTMENTS product enabled) and what happens when it's not enabled (returns a warning instead of error). It provides guidance on handling data integrity warnings, but does not explicitly name alternative tools for 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, idempotentHint, and non-destructive. The description adds behavioral details such as the types of movements returned, the specific fields in each row, and bulk support, which are not in annotations. No contradictions; the tool's behavior is transparent and well-described.

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

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

The description is concise: two sentences with no fluff. Purpose is front-loaded, and the structure efficiently conveys what the tool does, what it returns, and usage notes.

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

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

Given no output schema, the description provides detailed output fields. It covers prerequisite, bulk usage, and transaction types. However, it does not mention pagination behavior or result ordering, which would be helpful for a list tool. Overall, it is mostly complete for effective use.

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

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

Schema coverage is 0%, so description must explain parameters. It explains investment_id (required) and investment_ids (bulk support), but omits page and page_size parameters. The output fields are detailed but input parameter semantics are partially lacking.

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

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

The description clearly states the verb 'Returns' and the resource 'movement history for a specific investment position', listing transaction types. It distinguishes from sibling tools by focusing on investment transactions and referencing the prerequisite openfinance_list_investments.

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

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

Explicitly instructs to use after openfinance_list_investments to obtain investment_id, providing clear usage context. Also mentions bulk support with investment_ids. Does not explicitly state when not to use or compare to alternatives like openfinance_list_transactions, but the guidance is sufficient for correct invocation.

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

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

Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds sequential query behavior with rate-limit spacing and return format ({results, errors} per connection). 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?

Three sentences: purpose, parameter usage, return format. No unnecessary words, front-loaded with main action.

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, parameter semantics, optional behavior, rate-limit handling, return format. No output schema needed since return described. Complete for agent to use 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?

Input schema has one optional array parameter with 0% description coverage. Description fully explains 'items' as connection selectors (item_id, connector_id, connector_name) and behavior when omitted.

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

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

Description clearly states 'Lists loan contracts per bank connection' with endpoint (GET /loans). Distinguishes between listing specific connections and all connections. Differentiates from sibling tools like openfinance_get_loan_detail and openfinance_list_accounts.

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

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

Explicit guidance: pass 'items' for specific connections, omit for all. Mentions rate-limit spacing for multiple connections. Lacks explicit exclusion of alternatives, but parameter guidance is clear.

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

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

Annotations indicate readOnlyHint, idempotentHint, and non-destructive. The description adds crucial behavioral details beyond annotations: auto-pagination up to 5000, truncated flag, upstream error handling (returns error object), provider_incident block, and explicit warnings about not summing transactions by billId. It fully characterizes the tool's 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 long but well-structured. It is front-loaded with the core purpose and key distinctions, then covers credit card nuances, pagination, detail levels, edge cases, and bulk support in a logical order. While verbose, every section adds value. Could be slightly more concise, but it's not wasteful.

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 (8 parameters, credit card-specific behavior, pagination modes, error handling, bulk execution) and the lack of an output schema, the description is remarkably complete. It covers all critical usage aspects, edge cases, and caveats. An agent can use this tool correctly without needing additional 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?

With 0% schema description coverage, the description compensates fully. It explains from/to as ISO YYYY-MM-DD, search_queries as case-insensitive substring match, the detail enum (compact, rich, raw) with detailed effects, pagination parameters (page, page_size) with defaults and max values, and bulk support via account_ids. Every parameter is given meaningful 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 that the tool returns transactions for bank accounts, specifically BANK or CREDIT types. It distinguishes itself from siblings like openfinance_list_credit_card_bills by noting that for CREDIT accounts, this is the only way to get itemized transactions. The verb 'Returns' and resource 'transactions' 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 provides extensive usage guidelines: when to use this tool (for credit card transactions, as the only source), when not (for bill totals, use the billing tool), how to handle pagination (default auto-paginate vs manual), how to narrow date ranges if truncated, and how to check connection health if results are empty. It also warns about cross-checking account echoes 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds critical behavioral details: truncation at 5000 transactions per account with a 'truncated' flag, potential 'provider_incident' block affecting data completeness, and the default granularity behavior. 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 well-structured with front-loaded key information (purpose, key features) followed by parameter details and edge cases. It is relatively long but each sentence adds value given the tool's complexity. Minor opportunity to tighten some phrasing.

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

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

Given the tool has 9 parameters, no output schema, and supports multiple granularities and details, the description is remarkably thorough. It covers all parameter behaviors, return structure, truncation, provider incidents, and bulk support. No gaps remain for effective usage.

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

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

With 0% schema description coverage, the description fully compensates by explaining every parameter: 'item' accepts connector_id/connector_name/item_id, 'from'/'to' are ISO dates, 'granularity' monthly vs raw, 'detail' compact/rich/raw, 'type' BANK or CREDIT, 'top_n' for largest N, and 'item_ids' for batch. This adds significant meaning beyond the enum values in the schema.

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

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

The description clearly states the tool provides consolidated cash-flow analysis for a whole bank connection over a period in one call. It distinguishes itself from siblings like openfinance_list_accounts by noting it resolves accounts internally and fans out transactions, and from openfinance_list_transactions by offering aggregated monthly summaries.

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

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

The description explicitly says when to use this tool: for 'análise anual/mensal', 'fluxo de caixa', etc., and notes that you do not need to call openfinance_list_accounts first. It also mentions that omitting 'item' analyzes all linked banks. However, it does not explicitly state when not to use it or name alternative tools for specific cases.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds behavioral details about the return values (global indicator, degraded components, incidents, affected banks) and emphasizes it reads from a public status page, providing 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 well-structured and front-loaded with the core purpose. It contains multiple sentences, but each adds value (usage guidance, return details, differentiation). 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 the tool has no output schema, the description fully explains the return values (global indicator, degraded components, open incidents, your_banks_affected). This is sufficient for an agent to understand what to expect without additional documentation.

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

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

No parameters exist, so schema coverage is 100% vacuously. With 0 parameters, the baseline is 4 per guidelines. The description adds meaning about what the tool does, but there is nothing to add about individual 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?

Description clearly states the tool checks the provider's LIVE operational status and distinguishes itself from openfinance_get_item_status, which checks the connection's own status. The verb 'checks' and resource 'operational status' 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?

Explicitly says when to use: when data looks incomplete/stale despite a connection showing UPDATED, to identify upstream outages. It also contrasts with reconnecting the connection, 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?

Beyond annotations (readOnly, idempotent), the description adds key behaviors: caveat warning for credential connectors, plan-based filtering, and that keywords are required (returns hint otherwise). These enrich agent understanding.

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 comprehensive but somewhat verbose; it packs many details in a single paragraph. It could be structured into clearer sections, but each 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?

With no output schema, the description covers return fields (id, access, audience, connections, connect_url, caveat) and behavior (plan, required keywords). It is complete enough for an agent to use correctly.

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

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

Despite 0% schema coverage, the description explains both parameters: 'keywords' is required (with examples) and 'include_accounts' controls linked accounts. This compensates for the schema's lack of descriptions.

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

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

The description clearly states the tool searches bank connectors by name, returns specific fields, and provides a connect_url. It distinguishes from siblings like 'connect' and 'authenticate' by focusing on search and pre-selection.

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

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

The description advises calling this before connecting to get a one-click link, and explains plan behavior and caveats. It could more explicitly contrast with other tools, but the 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?

Annotations only provide hints; the description adds critical behavioral details: it overrides automatic categorization, teaches Pluggy by creating a Category Rule, and describes batch error handling (per-item errors do not fail the whole batch).

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 informative paragraph that front-loads the purpose, but is slightly dense; 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 complexity of a batch update with side effects (rule creation) and no output schema, the description provides comprehensive context including behavior, required inputs, and error handling.

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 compensates by explaining where transaction_id and category_id come from, the batch shape, and that errors are per-item, adding rich 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 explicitly states it corrects the category of transactions via PATCH /transactions/:id, clearly distinguishing it from sibling tools like listing or syncing.

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

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

It explains when to use (fix miscategorized transactions) and references openfinance_list_transactions and openfinance_list_categories for input IDs, but lacks explicit when-not-to-use or alternative tools.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds the reproduction hint but doesn't disclose what happens after reporting (e.g., ticket creation) or return behavior. With annotations covering safety, the description adds moderate value.

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

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

Two sentences, front-loaded purpose, and a concise usage instruction. No wasted words; 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?

The description lacks information on expected input formats (e.g., JSON array for conversation), output/return value (no output schema), and error handling. For a 3-parameter tool, this is insufficient for full 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?

Schema coverage is 0%, so the description must compensate. It provides meaning for 'conversation' (include recent messages) but gives no detail about 'message' or 'context'. Only one of three parameters gets useful elaboration, 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 sending feedback. The name 'report_bug' aligns, and it stands distinct from sibling tools (mostly openfinance_*).

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 a clear usage tip: 'Include the conversation array with recent messages for reproduction.' It implies when to use the tool but doesn't explicitly exclude alternatives or provide when-not-to-use guidance, though siblings are unrelated.

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, fully covering behavioral traits. The description adds no additional behavioral context beyond restating the obvious. It does not contradict 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?

A single, precise sentence with no extraneous words. Every word contributes to the 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 zero-parameter, read-only tool with no output schema, the description sufficiently explains what the tool returns (versions). No additional information is needed.

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, so schema description coverage is trivially 100%. Per rubric, baseline is 4. The description adds no parameter info because none exist.

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

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

The description clearly states the tool's function: showing current MCP platform and adapter versions. The verb 'show' and specific resource 'platform and adapter versions' leave no ambiguity. It is distinct from sibling tools like toolkit_info or 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?

While no explicit when-to-use or alternatives are given, the tool's simplicity (no parameters, straightforward purpose) makes usage obvious. The context is clear enough that an agent would know when to invoke it.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable detail about the return content (installed MCPs, statuses, accounts, tool counts) that goes beyond the annotations, giving the agent a concrete expectation of the output. It does not mention any potential side effects or caveats, but for a read-only state inspection tool, this is sufficient.

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 packed sentence that front-loads the primary purpose and then enumerates specific data points. Every word contributes meaning, with no redundancy or extraneous 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 the tool's simplicity (zero parameters, read-only semantics, no output schema), the description fully captures what the tool does and what it returns. Since the return value is explicitly described in the description, the absence of an output schema does not create a completeness gap.

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 the schema already fully defines the input (an empty object). The description adds no parameter semantics, but with no parameters, a baseline of 4 is appropriate per the rubric.

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

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

The description clearly states the tool's function with a specific verb ('Returns') and resource ('current toolkit state'), enumerating exactly what information is provided (installed MCPs, connection status, accounts, catalog tools count). This distinguishes it from sibling tools that focus on specific financial operations, making its purpose unambiguous.

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

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

The description implicitly conveys that this tool is for inspecting the toolkit's overall state rather than performing specific actions, which is clear context for an agent. However, it does not explicitly state when to use this over alternatives or provide exclusion criteria, so it falls short of the top score.

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