RecargaPay MCP

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

Disclosures about token types and session vs permanent connection. No contradiction with annotations (idempotentHint true, etc.). Adds 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?

Well-structured with key info upfront. Slightly verbose but all sentences are valuable.

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?

Missing return value or confirmation of successful authentication. Though not critical, a brief note on response would improve completeness.

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

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

Schema coverage is 0%, but description explains the 'token' parameter is a JWT pasted by user. Adds crucial meaning the raw schema lacks.

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

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

The description clearly states the tool is for authentication, distinguishing between browser login and token paste, and differentiates from sibling tools which are unrelated.

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 instructions on how to use: via config for permanent connection or calling with token for session. Lacks explicit when-not-to-use 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral details about what the tool returns in different states (authenticated vs. missing credentials), which goes beyond 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 concise, containing only two sentences with no superfluous information. It front-loads the core purpose ('Returns connection status and URLs') and then elaborates succinctly.

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, no output schema, and comprehensive annotations, the description fully explains the tool's behavior, including return values in both possible scenarios. 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?

The tool has no parameters, so schema coverage is effectively 100%. The description does not need to add parameter semantics. Per guidelines, 0 parameters yields a baseline of 4.

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

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

The description clearly states the tool returns connection status and URLs, and explains the two distinct scenarios (all providers connected vs. missing credentials). This distinguishes it from siblings like 'authenticate' and 'openfinance_list_connections', which have different purposes.

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

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

The description implies usage for checking connection status but does not explicitly mention when to use this tool versus alternatives like 'authenticate' or 'openfinance_list_connections'. No exclusions or when-not-to-use guidance is provided.

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=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description expands by detailing write operations (install, uninstall, subscribe, cancel), the one-off install behind invoke, and the requirement for workspace owner/admin. It does not contradict any annotation.

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

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

The description is verbose and combines multiple concepts (purpose, workflow, edge cases) in a single paragraph. It is front-loaded with the primary purpose but could be more concise or structured (e.g., bullet points). Every sentence is informative, but the length reduces readability.

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

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

Given the complexity (15 params, many actions, no output schema), the description thoroughly covers the tool's core flow, major behaviors (search, describe, invoke, install), and edge cases (credentials, wallet). It provides enough context for an agent to select and use the tool effectively, despite minor gaps in parameter details.

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 15 parameters and 0% schema description coverage, the description compensates by explaining the purpose of each action value and the overall workflow (e.g., action=search, describe, invoke). It also clarifies the behavior of install vs invoke. However, it does not detail all parameters (e.g., arguments, immediate, tier_slug), leaving some ambiguity. The description adds significant meaning but not full parameter-level coverage.

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

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

The description clearly states this is the official marketplace for MCPs, distinguishing it as the primary entry point for discovering and running tools. It uses specific verbs like 'search', 'describe', 'invoke', and contrasts with external registries. The hierarchical relationships with siblings (e.g., openfinance tools) are clear.

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

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

The description explicitly tells when to use this tool first ('use THIS tool FIRST'), describes the core flow (search → describe → invoke), and explains when to prefer invoke over install. It also covers edge cases like missing credentials or empty wallet with actionable instructions (return connect/checkout link, retry).

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 destructiveHint=true. The description adds that data becomes unavailable and returns an add_connection_url for reconnection, providing useful behavioral context beyond annotations.

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

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

Two sentences with no unnecessary information. Front-loaded with the main action and outcome, then additional detail on reconnection. Every sentence earns its place.

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

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

Given a single required parameter with no schema description and no output schema, the description covers purpose and outcome but lacks parameter guidance. Complexity is low, so the description is minimally adequate but incomplete for parameter semantics.

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

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

The input schema has one required parameter 'item' of type string with no description. The description mentions 'specific bank' but does not clarify what 'item' should be (e.g., bank ID, name). With schema description coverage at 0%, the description fails to compensate.

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 revokes consent and deletes connection data for a specific bank, differentiating it from other openfinance tools like list_connections or force_sync. The verb 'disconnect' and resource 'bank' are specific.

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

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

The description implies usage when needing to disconnect a bank and remove its data. It does not explicitly state when not to use it or mention alternatives, but the context is clear given no sibling tool does the same.

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 that it waits up to ~60s, returns results with status, executionStatus, lastUpdatedAt, synced, and possible needs_action states. Annotations show readOnlyHint=false and destructiveHint=false, consistent with description. 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 thorough but slightly verbose. Every sentence adds value, and the structure is logical with examples. Could be trimmed slightly 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 no output schema, description explains return format with results and errors, and key fields. Covers edge cases like timeout and needs_action. Completely addresses what the tool does and returns.

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

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

Input schema has 2 parameters with 0% description coverage. Description fully explains both: items can be an array of selectors or omitted for all connections; wait controls synchronous vs fire-and-forget behavior. 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 it forces a re-sync of connections and waits for completion, using a PATCH endpoint and polling. It distinguishes from other tools like openfinance_get_item_status by specifying its purpose of pulling fresh data without disconnecting.

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

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

Explicitly says when to use: when balance/transaction list looks stale. Contrasts with alternative approach of disconnecting/reconnecting. Explains behavior of items parameter (omit for all banks) and wait parameter (true for synchronous, false for fire-and-forget). Suggests re-checking with openfinance_get_item_status on timeout.

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

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

Beyond annotations (readOnly, idempotent, non-destructive), the description adds real-time behavior, error handling patterns (errors array), and a structured warning for CREDIT accounts, providing meaningful 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?

The description is three sentences, front-loaded with the core purpose, then parameter details and behavioral notes, with 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?

Given no output schema, the description adequately explains the response shape and error handling. It could be slightly improved by listing typical fields in results, but it is sufficiently complete for a balance endpoint.

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

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

The input schema has 0% description coverage for the single parameter. The description fully compensates by specifying the parameter is an array of strings, required, with a size limit of 1-50, and explaining its purpose within the tool.

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

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

The description clearly states it returns real-time balance per account id, specifies the HTTP endpoint, and distinguishes from sibling tools like openfinance_list_accounts or openfinance_get_accounts_detail by focusing 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?

It mentions array size limits (1-50) and special behavior for CREDIT accounts but does not explicitly state when to use this tool versus alternatives. Usage is implied but not guided.

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 adds valuable behavioral context: batch processing shape, possible provider_incident block leading to unreliable values, and a clear directive not to present those values as real. 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 concise, consisting of four sentences that front-load the primary purpose and endpoint. Each sentence adds essential value without redundancy. The structure is clear and efficient.

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

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

Given the single parameter and no output schema, the description covers the purpose, parameter format, batch behavior, and a notable edge case (provider incident). It lacks a full description of the output object structure beyond creditData, but overall is adequate for the tool's 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 description coverage, the description compensates by specifying that account_ids is an array of strings with a limit of 1-50. It adds meaning beyond the schema alone, though it could be more detailed about the nature of the IDs.

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

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

The description clearly states the verb 'Returns' and the resource 'full account objects including extended creditData', and specifies the endpoint pattern and batch shape. It distinguishes from sibling tools like openfinance_list_accounts by focusing on detail per ID.

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 instructions on how to pass account_ids (array of 1-50) and warns about provider incidents affecting reliability. However, it does not explicitly contrast when to use this tool vs siblings like list_accounts or get_account_balance.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds critical behavioral details: batch response shape { results, errors }, Pluggy's missing paid/status field, and the nuanced meaning of payments[] (which may refer to previous bill's payment). 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?

Description is moderately long but every sentence adds value. It front-loads the core purpose and then provides necessary guidance. No fluff; 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?

Despite no output schema, the description explains return shape and key fields. It covers what the tool does not return and how to obtain missing information (transactions, payment status). Complete for a bill detail lookup tool with clear boundaries.

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% (parameter described only in schema). Description adds meaning: explains that bill_ids is an array, how to discover IDs via sibling, and the batch handling. Compensates for lack of schema coverage with practical usage advice.

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 bill-level detail (financeCharges, payments) for credit card bills by ID, distinguishes from itemized transactions, and specifies the endpoint. Purpose is specific and actionable.

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 use this tool vs. alternatives: use openfinance_list_transactions for itemized transactions, use openfinance_list_credit_card_bills first to discover IDs, and explains how to check payment status via a sibling tool. Provides clear when-to-use and when-not-to-use 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 already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not reiterate those. The description adds value by disclosing the return shape (status, executionStatus, connector metadata) and the conditional behavior (single vs. all), which goes beyond the annotations.

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

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

The description is very concise: two sentences that are front-loaded with the core purpose and then detail the parameter usage. No extraneous information; every sentence serves a 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 the tool's simplicity (single optional param, no output schema), the description covers the core functionality and response structure adequately. It could be slightly improved by mentioning the exact structure for the single-bank response, but overall it is sufficiently complete.

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

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

The input schema has a single optional `item` parameter with no description (0% coverage), so the description must compensate. It does so excellently, explaining exactly what happens when the parameter is omitted (returns all banks) versus passed (returns single bank), including the response structure for the all case ({ count, items }).

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 it returns the current status of a bank connection, listing possible status values (UPDATED, UPDATING, LOGIN_ERROR, etc.) and mentions executionStatus and connector metadata. It also explains two distinct usage modes (all banks vs. single bank), which differentiates it from sibling tools like openfinance_list_connections.

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

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

The description explicitly explains when to omit or pass the `item` parameter to achieve different behaviors (all linked banks vs. a single bank). However, it does not explicitly compare this tool to siblings or state when it is preferred over alternatives, though the context is clear enough.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds that it returns a batch with { results, errors } shape, and the array length limit, which is behavioral context beyond annotations. No contradictions.

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

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

The description is a single dense paragraph but front-loaded with purpose and fields. It could be more structured (e.g., bullet points) but contains no fluff and efficiently conveys key information.

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

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

Given no output schema, the description covers return fields in detail, usage context after listing, parameter semantics, and error batch shape. It is 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?

Schema has 1 parameter with 0% description coverage. The description explains that loan_ids is an array of strings, with a size limit of 1-50, and implies they are loan contract IDs. This adds significant meaning beyond the schema.

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

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

The description clearly states it returns full loan contract detail by ID, listing specific fields like interestRates, amortizationScheduled, etc. It 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?

Explicitly says to use after openfinance_list_loans and mentions batch shape and array size limit (1-50). However, it does not describe when not to use or provide alternatives beyond the sibling.

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?

Description discloses behavioral traits beyond annotations (readOnlyHint, idempotentHint): explains aggregation behavior, connector-dependent credit card balance, and provider incident implications. No contradiction with annotations. Adds context on response structure (root-level vs nested fields).

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

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

Description is fairly long but well-structured with logical flow: purpose, field explanations, usage guidance, warnings, and pointer to alternative tool. Every sentence adds value; no redundancy. Slightly verbose 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?

With no output schema, description explains response fields (balance, number, type, subtype, bankData, creditData, bank, connector_id, item_id, provider_incident, name). Covers core behavior and edge cases. Lacks mention of pagination or sorting, but overall complete for a list endpoint given sibling tools exist for details.

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

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

Schema has 0% description coverage, but description fully explains the two parameters: `item` (effect of omit vs pass) and `type` (BANK/CREDIT). Adds meaning about how `item` affects response structure and clarifies that `type` filters accounts. Goes beyond schema by explaining behavior and field relationships.

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 accounts for a bank connection with specific fields (BANK, CREDIT). Distinguishes between `name` (legal entity) and `bank` (brand). Explains behavior when omitting or passing `item` parameter, differentiating from siblings like openfinance_list_credit_card_bills and openfinance_get_accounts_detail.

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

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

Explicit guidance on when to omit `item` (list all banks) vs pass it (single bank). Warns about connector-dependent credit card balance meaning and advises against using `balance` as monthly bill. Points to alternative tool openfinance_list_credit_card_bills for standardized bill amounts. Also warns about provider incident block affecting reliability.

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

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

Annotations already declare readOnlyHint and idempotentHint, so description's addition of caching behavior and response structure adds value 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?

Single sentence with key info front-loaded. Every clause adds value: endpoint, caching, field descriptions, linkage to sibling. 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?

No output schema, so description fully covers the return structure (five fields explained). No missing behavioral aspects for a read-only, idempotent 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. Schema coverage is 100%. Description still adds value by detailing the output fields and their meaning, which compensates for the lack of 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 Pluggy's category taxonomy, cached. Mentions each entry's fields and explicitly connects to sibling tool openfinance_update_transaction_category via the id field, differentiating its 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?

Implies use for retrieving categories before updating transaction categories, but does not explicitly state when to use or when not to use this tool over alternatives. Lacks direct usage exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds info about returned fields and add_connection_url, which is consistent but does not disclose additional behavioral traits 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?

Single sentence, no wasted words, front-loaded with key information. Efficient and clear.

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

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

For a simple list tool with no parameters, description lists all returned fields and notes the add_connection_url. No output schema, so description adequately covers return value. Complete enough for 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?

No parameters, schema coverage 100%. Description adds value by listing returned fields, which compensates for lack of output schema. Baseline 4 for zero parameters.

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

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

Description clearly states it returns saved bank connections with specific fields (connector_id, item_id, bank name, add_connection_url). It distinguishes from siblings like openfinance_list_accounts by focusing on 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?

No explicit when-to-use or alternatives given. Usage is implied as a list operation before other actions, but no guidance on when not to use or comparison to siblings.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. Description adds deep behavioral details: payment cycle assignment, derived status logic, connector asymmetry, bulk support, and warning about payment reflection delays.

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

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

Description is comprehensive but slightly verbose; front-loaded with main output, then caveats, optional behavior, and warnings. Could benefit from tighter structuring but remains efficient given complexity.

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

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

No output schema, but description fully explains return fields (payments, statuses, open_bill, etc.), includes error/warning behavior, and directs to related tools for more detail. Covers all necessary aspects 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?

With 0% schema description coverage, description compensates by explaining each parameter's purpose: account_id/account_ids for bulk, page/page_size for pagination, include_open_bill with detailed effect on output and performance.

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 CLOSED credit card bills for a CREDIT-type account' with detailed fields. Distinguishes from sibling tool openfinance_list_transactions for itemized purchases, though not explicitly from 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?

Provides explicit guidelines: when to use include_open_bill (opt-in due to extra scan), warns against assuming payments mean bill paid, explains derived payment_status usage, and notes connector asymmetry. Directs to list_transactions for itemized data.

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. The description adds valuable context about error handling (returns {total:0, results:[], warning} instead of throwing 403) and the types of data included, which goes 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 run-on sentence combining purpose and return fields. It could be more structured (e.g., separate sections for purpose and parameters), but it is information-dense without being 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?

Given no output schema and moderate parameter count, the description covers return format (fields like balance, amount, dueDate, etc.) and error handling, which is sufficient for an agent. No missing critical info.

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 4 parameters with 0% description coverage. The description does not explain the parameters (item, page, type, page_size) or their meaning, leaving the agent to infer from names. It lists return fields but not parameter 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 it returns investment portfolio for a connection, listing asset types (FIIs, stocks, ETFs, etc.) and fields. It doesn't explicitly differentiate from sibling tools like openfinance_list_investment_transactions, but the purpose is well-defined.

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

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

No guidance on when to use this vs. alternatives. It does not specify prerequisites or conditions (e.g., connection must have INVESTMENTS product enabled is implied but no when-not statements).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so safety profile is covered. The description adds value by detailing the data returned (rows, fields, expenses) and bulk execution capability. Does not mention pagination behavior or error conditions, but overall adds useful behavioral context.

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

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

Two concise paragraphs, front-loaded with purpose and data details. No redundant 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 no output schema, the description explains return fields and transaction types adequately. However, it lacks details on pagination behavior, default page size, ordering, error handling, or limits. Adequate but with clear gaps.

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

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

Schema coverage is 0%, so description must compensate. It explains investment_id (linked to list_investments) and investment_ids (bulk support). However, page and page_size parameters are not described, leaving ambiguity about pagination. Partial coverage of 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 it returns movement history for a specific investment position, listing transaction types (BUY/SELL/TAX/INTEREST/AMORTIZATION/TRANSFER) and the fields included. It distinguishes from sibling tools like openfinance_list_investments by specifying it requires an investment_id.

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

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

Explicitly advises to use after openfinance_list_investments to obtain the investment_id. Also mentions bulk support with investment_ids. Does not provide explicit 'when not to use' or alternatives, but the context is clear given the sibling tool list.

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 key behavioral details beyond annotations: sequential querying with rate-limit spacing, return format `{ results, errors }`. No contradiction with annotations.

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

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

Two sentences, front-loaded with purpose, no unnecessary words. Efficient and clear.

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

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

Complete for a single-parameter, read-only tool. Covers usage, return format, and behavioral constraints.

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?

Compensates for 0% schema description coverage by explaining `items` as connection selectors (item_id uuid, connector_id, connector_name) and omission 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?

Clearly states 'Lists loan contracts per bank connection (GET /loans)', specifying verb and resource. Distinct among sibling list 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?

Explains when to use `items` and when to omit, with sequential querying and rate-limit spacing. Lacks explicit exclusion of alternatives, but context with siblings makes it clear.

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

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

The description goes beyond annotations (readOnlyHint=true, idempotentHint=true) by detailing behaviors such as auto-pagination with truncation warning, varying credit card transaction coverage by bank, upstream error handling returning structured error objects, and provider incident blocks. No contradiction with annotations.

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

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

The description is quite long (multiple paragraphs) but every sentence adds value given the complexity of credit card behaviors, pagination, and detail levels. It is front-loaded with the primary purpose and then expands logically. A slightly more structured layout might improve scannability, but it is 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?

With no output schema, the description thoroughly explains return values: error handling, truncation warning, provider_incident block, and detail-level fields. It also covers bulk support and references sibling tools for related information (closing/due dates, connection health). Complete for a complex tool.

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

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

Despite 0% schema description coverage, the description fully explains each parameter: from/to format (ISO YYYY-MM-DD), page omission for auto-paginate, page_size max 500, detail options (compact, rich, raw) with use cases, account_id and account_ids for bulk, and search_queries (substring match with OR semantics). It adds significant meaning beyond the schema types/enums.

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 transactions for a bank account (BANK or CREDIT type)' and immediately distinguishes from siblings by noting it's the only way to get itemized credit card transactions and contrasts with openfinance_list_credit_card_bills for standardized totals. This provides specific verb and resource with sibling differentiation.

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

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

The description provides explicit when-to-use and when-not-to-use guidance: e.g., for credit card transactions, use this tool; for standardized bill totals, use openfinance_list_credit_card_bills. It also explains pagination options (omit page for auto-paginate, explicit page for manual) and when to check item status if total is 0. Highly practical.

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), the description discloses important behaviors: internal account resolution, a 5000-transaction-per-account cap with a truncated flag, and a provider_incident block that warns of potential incompleteness. These details significantly aid agent decision-making.

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

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

The description is front-loaded with the core purpose and structured with parentheses for extras. It is somewhat verbose, repeating 'connection' and 'account' redundantly, but every sentence adds value without 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?

Despite no output schema, the description thoroughly explains the return structure: total entradas/saídas, monthly evolution, top expenses/revenues, per-account breakdown, and raw transaction rows with enrichment options. It also covers truncation and provider incident flags, making it fully complete for agent understanding.

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

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

With 0% schema coverage, the description carries the full burden and explains most parameters well: item (connector_id/name or omit), from/to (ISO dates), granularity (monthly vs raw), detail (compact/rich/raw), and type (BANK/CREDIT). The top_n parameter is only implied via 'largest N each' and lacks an explicit link, missing a clear 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 that this tool provides consolidated cash-flow analysis for a whole bank connection in one call, resolving accounts internally and eliminating the need to call openfinance_list_accounts first. This distinctly separates it from sibling tools like openfinance_list_transactions 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 usage guidance is provided: use for annual/monthly analysis, cash flow, top expenses/revenues; omit item for all linked banks; set granularity to 'monthly' for summary or 'raw' for itemized rows; combine detail options accordingly. This covers when and how to use the tool effectively.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by detailing the output (global indicator, degraded components, incidents, 'your_banks_affected'). No contradiction, but could mention any limitations like rate limiting.

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

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

The description is a single well-structured sentence that front-loads the purpose, then usage guidance, then output details. It is reasonably concise but slightly dense; every sentence earns its place.

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

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

Given no output schema, the description adequately explains what is returned (global indicator, degraded components, incidents, affected banks). Complexity is low (no parameters), and the description covers all needed context for correct tool selection and expectation.

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

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

The tool has zero parameters and schema coverage is 100%. The description adds meaning about the tool's purpose and return data, though there are no parameters to describe. 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 specifies the tool's action: checking the LIVE operational status of the Open Finance provider. It explicitly distinguishes from the sibling tool 'openfinance_get_item_status' by noting that this checks provider health, not the connection 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?

Provides explicit guidance on when to use the tool (when data looks incomplete/stale despite an updated connection) and what it reveals (upstream outage, known incidents). It tells the agent how to differentiate provider-side problems from connection issues.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds return fields (connector id, access, audience, linked connections, accounts conditionally, connect_url) and warns about caveats for non-Open-Finance connectors, exceeding annotation 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?

Dense single paragraph that front-loads purpose and adds relevant details. Could benefit from brevity or bullet points, 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 no output schema and a search tool with conditional returns, the description fully covers behavior, return fields, special cases (caveat, plan honor), and required usage pattern. No gaps identified.

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

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

Schema coverage is 0%, so description must compensate. It explains keywords with examples (e.g., ['nubank','btg']) and notes include_accounts=true adds accounts. While clear, it lacks explicit type constraints or default behavior for include_accounts.

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 'Searches the available bank connectors by name' and enumerates specific returned fields. It distinguishes itself from sibling tools by being a pre-connect search, not a connection management or listing tool.

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

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

Explicitly instructs 'Call this BEFORE connecting' and notes that keywords[] is REQUIRED, returning a hint if omitted. Also advises surfacing caveat from non-Open-Finance connectors so users can prefer Open Finance for automation.

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

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

The description discloses important behavioral traits beyond annotations: overrides automatic categorization, teaches Pluggy by creating a Category Rule for future similar transactions, and details batch error handling (per-item errors do not fail the whole batch). No contradiction with annotations.

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

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

The description is a single paragraph that efficiently conveys all necessary information without redundancy. Each sentence adds value, though slightly more structure (e.g., bullet points) could improve readability.

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

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

Given the complexity (batch update with side effects, no output schema), the description covers purpose, parameters, side effects (rule creation), error handling, and return format. It is fully self-contained for an AI agent.

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

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

Schema has no descriptions (0% coverage), but the description fully explains the parameter structure: items as an array of { transaction_id, category_id }, and clarifies the sources of these IDs. This adds essential meaning beyond the schema.

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

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

The description clearly states it corrects the category of one or more transactions, specifies the HTTP method and endpoint, and distinguishes from siblings like openfinance_list_transactions and openfinance_list_categories by detailing the input IDs and the resulting rule creation.

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 (fix miscategorized transactions) and where to obtain required IDs, and notes the side effect of creating a Category Rule. It does not explicitly state when not to use or list alternatives, but the context is clear given 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?

The description adds behavioral context beyond annotations: it requires the conversation array for reproduction. Annotations already indicate idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description aligns with these and adds the expectation of providing conversation data, which is useful for the agent.

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 consists of two short, direct sentences with no unnecessary words. It front-loads the purpose and follows with a key usage instruction, making it easy to parse.

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 bug-reporting tool with no output schema and only three parameters, the description is mostly complete. It covers the core purpose and a critical usage detail (conversation). However, it could mention the expected response or confirmation, but this is not essential given the simplicity.

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

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

With schema description coverage at 0%, the description must compensate. It explains the purpose of the conversation parameter (for reproduction) but does not clarify the message (required) or context (optional) parameters. This leaves ambiguity about what to provide beyond the conversation.

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. This is a specific verb-object combination that distinguishes it from the sibling tools, which are focused on authentication, marketplace, and openfinance operations.

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

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

The description provides a clear usage guideline: include the conversation array with recent messages for reproduction. This implies when to use the tool (to report issues with context) but does not explicitly contrast with alternatives. However, given the sibling tools are all different domains, it is sufficiently clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. Description adds version context but doesn't disclose further behaviors (e.g., return format or 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?

Single clear sentence with no wasted words. Front-loaded with the action and scope.

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?

Tool has no parameters and no output schema; description sufficiently defines its purpose. No additional context needed given simplicity.

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

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

No parameters exist; schema coverage is 100% vacuously. Description adds no param info but none is needed. Baseline 4 for zero-param tools.

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 shows current MCP platform and adapter versions. No ambiguity, and it uniquely identifies its function among sibling tools.

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

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

No explicit when-to-use or alternatives guidance, but the tool's purpose is self-explanatory and no sibling tool overlaps. Usage is implied for version checks.

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 value by specifying the exact returned data (installed MCPs, connection status, catalog tool counts), providing behavioral 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?

Single sentence of 15 words, front-loaded with key information, 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 stateless query with no output schema, the description adequately communicates return value. Complete information for agent to use 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, so schema coverage is 100%. Baseline 4 for zero-param tools; description adds no param info but none 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?

Description clearly states the tool returns toolkit state: installed MCPs, connection status, and catalog tool counts. This is specific and distinct from siblings that handle finance operations or authentication.

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

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

No explicit guidance on when to use this tool versus alternatives, but its purpose as a state query is self-evident. Could mention it's for debugging or setup verification.

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