Inter MCP

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

Annotations already provide idempotentHint=true and destructiveHint=false, and the description adds behavioral context: calling with no args returns a link, and with token sets session. No contradictions. It lacks details on error handling or side effects, but overall transparent.

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, front-loads the target audience (IDE agents), and efficiently explains three usage scenarios in three sentences. No wasted words, though slightly dense.

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 lack of output schema, the description doesn't explain return values or behavior after authentication. While annotations cover safety, the description could mention what the tool returns (e.g., success message or token). It is adequate but not 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 schema has 0% coverage for parameter description, but the description explains the 'token' parameter is a JWT from browser login and how to use it for session-only login. This adds meaning beyond the schema's bare definition.

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

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

The description clearly states the tool authenticates the user to the server, explaining two methods: permanent config-based token or session-only token paste. It also describes calling with no args to get a login link. This distinguishes it from siblings like 'connect' by focusing on credential setup.

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 usage guidance: best to add token to config for permanent connection, or paste token for session, or call with no args to get link. It does not explicitly mention when not to use or alternatives, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context beyond annotations by detailing the conditional return values (authenticated:true with empty pending[] vs connect_url), which is valuable 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 is two sentences, front-loaded with the core purpose ('Returns connection status and URLs'), and includes necessary details without any wasted words.

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

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

Given no output schema and zero parameters, the description fully explains the tool's behavior and return values. Annotations cover safety, and the description adds all necessary context for an agent to use it 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?

The input schema has 0 parameters, so schema_description_coverage is 100%. With no parameters, the baseline is 4, and 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 connection status and URLs, specifying two distinct scenarios (all connected vs credentials missing). It uses the verb 'Returns' and identifies the resource, distinguishing it from siblings like 'authenticate'.

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 for when to use the tool (checking connection status) and what the response indicates, but does not explicitly state when not to use it or mention alternatives among siblings.

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

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

The description discloses numerous behavioral traits beyond annotations: that invoke works even without installation, that it may return connect or checkout links, that writes are permission-sensitive, and that install makes MCPs permanent. Annotations already indicate non-readOnly, non-destructive but mutable, and the description adds rich context 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 lengthy but well-structured: it opens with purpose, proceeds through core flow, then details special cases. Every sentence adds value, though slight condensation could improve readability. It is front-loaded with the most critical information.

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

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

Given the tool's complexity (13 parameters, multiple actions, no output schema), the description covers the major use cases comprehensively: search, describe, invoke, install, list, subscribe, cancel, report, request. Some parameter details are missing, but an agent can likely use the tool correctly with this description.

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 13 parameters and 0% schema coverage, the description compensates somewhat by explaining the roles of action, mcp_id, tool_id, and arguments in the core flow. However, many parameters like limit, query, immediate, tier_slug, conversation, request_name, report_context, and request_details are left unexplained, leaving gaps for an agent.

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 central catalog and execution platform for MCPs. It explicitly states the primary use case: discover and run MCPs, and contrasts with sibling tools by positioning itself as the first tool to use for capability seeking.

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

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

The description provides explicit guidance on when to use this tool (e.g., 'use THIS tool FIRST'), distinguishes between invoke (one-off) and install (permanent), explains the search→describe→invoke flow, and notes that writes require workspace owner/admin. It also mentions alternatives like external registries and when to use other tools (e.g., report_bug).

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 destructive behavior; the description adds value by stating data will no longer be available and returns a re-connection URL, which is helpful 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?

Two concise, front-loaded sentences that convey all key aspects 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?

While annotations and description cover the core behavior, the lack of parameter documentation and missing details on execution (e.g., synchronous vs async) leave gaps for a simple tool.

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

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

The single parameter 'item' has no schema description (0% coverage) and the tool description only hints it identifies a bank, but does not clarify its format, type, or source.

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, distinguishing it from sibling tools like list or sync operations.

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

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

The description implies usage for disconnecting a bank but provides no explicit guidance on when to use it versus alternatives, nor mentions prerequisites or conditions.

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

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

Disclosures waiting behavior, timeout, that it does not disconnect/reconnect, return structure with status fields, and common error states. Annotations are minimal, so description carries full burden and exceeds expectations.

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 logical flow: action, use case, parameters, return values, error handling. Slightly verbose but every sentence adds value. Could tighten minor wording.

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?

Fully describes return format with all key fields, error states, and follow-up actions. No output schema exists, so description must be self-contained; it succeeds admirably.

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 adds thorough meaning: items accepts selectors (item_id, connector_id, name) and omitting syncs all; wait enables fire-and-forget. This fully compensates for missing schema details.

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

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

The description clearly states the tool's purpose: forces a bank to re-sync connections and waits for completion. It includes the underlying HTTP method and polling behavior, and distinguishes from sibling tools like openfinance_get_item_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 (stale balance/transactions), how to invoke (items array, wait parameter), and what to do on specific outcomes (needs_action, timed_out). Lacks explicit 'when not to use' but is otherwise thorough.

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, non-destructive), describes error handling for CREDIT accounts with structured warnings instead of throwing. Also specifies response shape with results and errors arrays.

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: main action, constraint, special case, response shape. Front-loaded and efficient. 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?

Complete description for a simple balance retrieval: input constraints, behavioral edge cases with credit accounts, response structure provided. No missing elements.

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 account_ids as an array with size constraint (1–50). Adds meaningful constraints beyond schema type.

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 real-time balance per account ID. Mentions HTTP endpoint. Distinguishes from sibling tools like list_accounts or get_accounts_detail by focusing on balance retrieval.

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 guidance on passing account_ids as an array (1–50). Mentions handling of CREDIT accounts with error warnings. Could be more explicit about when to use this vs alternatives, but 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?

Adds critical behavioral context beyond annotations: batch shape { results, errors }, provider_incident block, and unreliability warning. Aligns with readOnlyHint and idempotentHint annotations.

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

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

Two concise sentences that efficiently convey purpose, usage, and a critical warning. No redundant or unnecessary text.

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 all essential aspects: return value shape, batch behavior, error handling, and provider incident conditions. No output schema but description compensates sufficiently.

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 sole parameter account_ids is explained with a usage constraint (1-50) and role in the HTTP endpoint. Despite 0% schema description coverage, the description adds 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 it returns full account objects with extended creditData per ID, distinguishing it from sibling tools like openfinance_list_accounts which likely provide summary lists.

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 guidance to pass account_ids as an array (1-50) and warns about provider incidents affecting data reliability. However, it does not explicitly contrast with alternatives or state when not to 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?

Annotations (readOnlyHint, idempotentHint, destructiveHint) already indicate a safe read operation. The description adds valuable behavioral context: batch shape ({ results, errors }), the note that Pluggy does not return a paid/status field, and the interpretation of payments array. 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 longer than necessary but every sentence adds value. It is front-loaded with the main purpose and structured logically. Minor redundancy could be trimmed, but overall efficient.

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

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

Given no output schema and the tool's complexity (batch result, specific semantics), the description is very complete: covers return shape, what is not returned, usage instructions, and important caveats about payment interpretation. Leaves minimal ambiguity.

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

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

Schema has 0% description coverage for the single parameter `bill_ids`. The description compensates by explaining it is an array of IDs to be discovered from openfinance_list_credit_card_bills, adding meaning beyond the schema's type and required flag.

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 bill-level detail for credit card bills by id, listing included fields (financeCharges, payments with subfields) and explicitly excluding individual transactions. This distinguishes it from sibling tools like openfinance_list_transactions and openfinance_list_credit_card_bills.

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: use openfinance_list_credit_card_bills first to discover bill_ids, and use openfinance_list_transactions for itemized transactions. Also warns about the meaning of payments array in Brazilian Open Finance and how to check paid status via the list tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds useful behavioral context by explaining the dual response format based on parameter presence: returns `{ count, items }` when omitted and a single status object when provided. This 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 extremely concise: two sentences front-loading the purpose and status examples, followed by crisp usage guidance. Every word adds value, and there is no extraneous information.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description fully covers what the tool does, the different behaviors based on the parameter, and the return structure. It mentions key output fields (status, executionStatus, connector metadata). No gaps are evident given the tool's limited scope.

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 optional string parameter `item` with no description (0% schema description coverage). The description compensates by explaining that omitting `item` returns status for all linked banks and passing it returns status for a single bank. Although it does not specify the expected format of `item` (e.g., bank ID), the meaning is clear enough for correct usage.

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

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

The description clearly states the tool returns the current status of a bank connection, listing example statuses (UPDATED, UPDATING, LOGIN_ERROR, etc.) and specifying the output includes executionStatus and connector metadata. It distinguishes two modes (all vs single bank), making the purpose specific and differentiating it from sibling tools like openfinance_provider_status or 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 the `item` parameter (to get status of all linked banks) and when to pass it (for a single bank). This is clear usage guidance. While it does not mention alternatives to using this tool vs siblings, the guidance within the tool is sufficient for its simple operation.

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 readOnly, idempotent, and non-destructive. The description adds the batch shape {results, errors} but no additional behavioral traits (e.g., authentication, rate limits). This is adequate but not exceptional.

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

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

The description is a single sentence listing key fields and a usage note. It is informative and free of fluff, though it could be broken into smaller sentences for 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 no output schema, the description lists many return fields (interestRates, charges, schedule, etc.) and the batch shape. It covers the main components, but lacks definitions for abbreviations like CET and ipocCode.

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 specifies that loan_ids is an array of strings (1-50) and mentions the batch shape. This adds useful constraints beyond the schema's empty definition, though the format of loan IDs is not described.

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

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

The description clearly states the tool returns full loan contract details by ID, listing specific fields (interest rates, charges, schedule, etc.). It distinguishes itself from siblings like openfinance_list_loans by indicating it is a deep-dive tool.

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

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

The description explicitly says to use after openfinance_list_loans and specifies that loan_ids must be an array of 1-50 items. This provides clear context, though it does not mention when not to use or alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds crucial behavioral details: the meaning of CREDIT balance is connector-dependent (so do not treat as current bill), the provider_incident block indicates when balances/limits may be unreliable, and the billing cycle is defined by creditData fields. These go beyond annotations to prevent misinterpretation.

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 starts with the core function, then explains usage variations, then caveats about credit balance and provider incidents. Every sentence adds value, though the length could be slightly trimmed without losing clarity. Still, it efficiently conveys complex 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 return structure (accounts with fields, bank, connector_id, item_id) and the provider_incident block. It covers the main data points and references the sibling tool for standardized bills. However, it does not detail all subfields of bankData or creditData beyond the billing cycle dates, but for an AI agent this is sufficient context.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining both parameters: 'item' (optional string, omit for all banks, pass for specific bank) and 'type' (enum BANK/CREDIT). It also describes the effect on response structure (root-level vs. per-account tagging), adding meaning beyond the raw schema.

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

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

The description clearly states that the tool returns accounts (BANK and CREDIT) with detailed fields like balance, number, type, subtype, bankData, creditData, bank, and connector_id. It also distinguishes between listing all accounts (omit item) and targeting a single bank (pass item), and implicitly differentiates from sibling tools like openfinance_list_credit_card_bills by noting that tool provides standardized bill amounts.

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

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

Explicitly tells when to use 'item' (to target a single bank) and when to omit it (to list all linked banks, e.g., 'my accounts/cards' without naming a bank). It also warns not to treat CREDIT balance as 'this month's bill' and directs to openfinance_list_credit_card_bills for a standardized amount, providing clear usage boundaries and alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds the caching behavior ('cached for the adapter session'), which is valuable 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?

Three concise sentences. The first sentence states the core purpose and source. The second details the response fields. The third clarifies that it's a single aggregated response. No extraneous content.

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 provides a complete understanding of the tool's behavior: cached, taxonomy with fields, and link to sibling tool. No missing 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?

There are no parameters; the input schema has no properties. The description explains what the tool returns, compensating for the lack of parameter information. Baseline of 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 the tool returns Pluggy's transaction category taxonomy, cached. It specifies each entry's fields (id, description, etc.) and links to the sibling tool openfinance_update_transaction_category, making its purpose distinct from other 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?

It mentions caching for efficiency and indicates the id's use in another tool, providing context for when to call this tool. However, it does not explicitly state when not to use it or give alternatives among siblings, though the sibling tools are for different resources.

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, and non-destructive. The description adds value by specifying the returned fields and the add_connection_url, providing additional 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?

The description is a single sentence, concise and front-loaded with the main action. Every part is informative without 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?

Given no parameters and no output schema, the description fully explains what the tool returns, making it complete for its 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?

There are no parameters, so the description inherently covers the parameter semantics. With zero parameters, the baseline is 4, and the description adds no unnecessary param 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 verb 'Returns' and the resource 'saved bank connections', listing specific fields. It distinguishes from sibling tools like 'openfinance_list_accounts' by specifying bank connections.

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

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

The description provides implicit context that this tool is for retrieving bank connections, but does not explicitly state when to use this tool vs. alternatives or when not to use 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?

The description goes far beyond the annotations (readOnlyHint, idempotentHint, destructiveHint) by detailing complex payment cycle logic, payment_status derivation, open bill availability depending on connector, and the effect of bulk support. It also explains why a bill might be PAST_DUE_UNCONFIRMED and how to handle it, providing rich 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 long but appropriately front-loaded, starting with the core function and key fields. While verbose, every sentence serves a purpose given the complexity of the tool. The structure is logical, though could be slightly tighter for quick scanning.

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, the description is exceptionally complete. It covers return fields, payment status derivation, open bill mechanics, connector asymmetry, bulk support, and even includes a warning if the CREDIT_CARDS product is not enabled. No gaps are evident.

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 by explaining the purpose and behavior of parameters like include_open_bill (opt-in, default false, what it returns), account_ids (bulk support), and implicitly page/page_size for pagination. It adds meaning that the schema alone does not provide.

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 CLOSED credit card bills for CREDIT-type accounts, listing many specific fields. It explicitly distinguishes itself from sibling tools like openfinance_list_transactions (for itemized purchases) and openfinance_get_credit_card_bill (for a single bill). The verb 'returns' and resource 'closed credit card bills' are specific and 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 provides guidance on when to use this tool versus alternatives, e.g., 'To see itemized purchases/charges per bill, use openfinance_list_transactions...' It also explains opt-in behavior for open_bill and warns about connector asymmetry. However, it does not explicitly state when not to use this tool or provide a comprehensive list of 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?

Discloses error handling behavior (returns { total, results, warning } instead of throwing on 403). Annotations already show readOnlyHint and idempotentHint, so description adds context about non-exceptional error responses.

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

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

Description is a single paragraph, fairly long but well-structured with a clear primary purpose and list of asset types. It front-loads the main function. Slight verbosity but acceptable.

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 0% parameter coverage and no output schema, the description should explain input parameters. It only details output fields. Missing parameter semantics makes it incomplete for the agent to invoke correctly.

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

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

Schema description coverage is 0%. The description does not explain any of the 4 parameters (item, page, type, page_size). With no param documentation in schema or description, the agent has no guidance on how to use 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 investment portfolio for a connection, listing specific asset types like FIIs, stocks, ETFs, etc. It distinguishes from siblings like openfinance_list_investment_transactions by specifying it's the full portfolio, not just 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?

Explicitly states it's for investment portfolio of a connection. However, it doesn't provide when-not-to-use or alternatives among many list siblings. Still, the purpose is clear enough for selection.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description does not need to reiterate safety. It adds behavioral context: bulk support via investment_ids and details of returned fields (e.g., netAmount, expenses). 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 two short paragraphs, front-loading purpose and output details. Every sentence adds value; no fluff or repetition.

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

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

No output schema exists, so the description adequately covers return fields (movement types, financial attributes, itemized expenses). It also provides a usage prerequisite. Pagination parameters are not explained, but they are common and self-explanatory.

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 explains investment_id (required) and investment_ids (bulk support), but does not mention page or page_size parameters. The explanation adds meaning beyond the schema for two of four parameters.

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

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

The description clearly states the tool 'Returns the movement history for a specific investment position' and lists specific transaction types (BUY/SELL/TAX etc.), distinguishing it from sibling tools like openfinance_list_transactions which cover general 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 explicitly recommends 'Use after openfinance_list_investments to get the investment_id,' providing a clear prerequisite. It implies this tool is for investment-specific transactions but does not explicitly exclude alternatives like openfinance_list_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?

Adds behavioral details beyond annotations: return format per connection, sequential querying, and rate-limit spacing. 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?

Three sentences, front-loaded with purpose, then parameter behavior, then omission handling, and return format. Slightly wordy but 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?

Covers parameter usage, return format, and rate-limit behavior. Lacks mention of pagination or error details, but adequate for a simple list tool with no output schema.

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

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

With 0% schema coverage, description fully explains the `items` parameter: it accepts connection selectors (item_id uuid, connector_id, or connector_name) and clarifies omitting lists all. Adds 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?

Clearly states the tool lists loan contracts per bank connection, specifying the HTTP endpoint and resource. Distinguishes from sibling list tools by explicitly mentioning 'loans'.

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

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

Provides clear context for when to use the `items` parameter vs omitting it. Explains sequential querying with rate-limit spacing, but doesn't compare with sibling tools.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral context: credit card pending/posted variation by connector, auto-pagination with 5000 ceiling and truncated flag, error handling (returns warning/error instead of throwing), detail parameter effects, and provider incident impact. 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 lengthy but well-structured into logically grouped paragraphs covering different aspects (credit card specifics, pagination, detail levels, etc.). It front-loads the core purpose. While some redundancy exists (e.g., repeating that CREDIT accounts are for itemized transactions), the detail is necessary given the tool's complexity.

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

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

Given the tool's 8 parameters, no output schema, and annotations that only cover safety/idempotency, the description provides comprehensive context: it explains the variant behavior per bank, error handling, pagination limits, bulk support, provider incidents, and references to sibling tools for other information. No gaps are apparent.

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: account_id (implied), from/to (ISO YYYY-MM-DD), page (auto vs manual), page_size (max 500), detail (three modes with behavior), search_queries (case-insensitive substring OR semantics), and account_ids (bulk). It adds meaning well beyond the schema names.

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 transactions for bank accounts (BANK or CREDIT type) and that for CREDIT accounts it is the only way to get itemized transactions. It distinguishes itself from sibling tools like openfinance_list_credit_card_bills by pointing to that tool for bill totals, and mentions openfinance_list_accounts for closing/due dates.

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

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

The description provides explicit guidance on when to use this tool (e.g., for CREDIT itemized transactions) and when not (e.g., for standardized bill totals, use openfinance_list_credit_card_bills). It also covers date filters, keyword searches, pagination options, detail levels, and actions if total is zero. Bulk support is noted, and provider incidents are mentioned.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so description adds value by disclosing truncation at 5000 transactions per account, provider incident impact, and the structure of the return (compact vs raw). 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, starting with purpose, then parameter details, use cases, and edge cases. Every sentence adds value, but could be slightly more concise.

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

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

Given the complexity (7 parameters, no output schema), the description covers return format, truncation, provider incidents, enrichment options, and filtering. No gaps.

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

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

Schema has zero description coverage (0%), but the description fully explains all 7 parameters: item (connector_id/name/item_id or omit for all), from/to (ISO dates), granularity (monthly vs raw), detail (compact/rich/raw), type (BANK/CREDIT), top_n (implied by top_despesas).

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 does consolidated cash-flow analysis for a whole bank connection in one call. It contrasts with needing to list accounts first, and differentiates from sibling tools like openfinance_list_transactions by emphasizing consolidation and compact 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?

Provides explicit use cases ('análise anual/mensal', 'fluxo de caixa') and conditions for setting granularity to 'raw' or detail to 'rich'/'raw'. However, it does not explicitly state when to use an alternative sibling tool like openfinance_list_transactions instead.

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. The description adds significant context: it checks a public status page, returns global indicator, degraded components, open incidents, and flags incidents affecting your banks. No contradiction; it enhances understanding beyond annotations.

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

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

The description is longer but every sentence earns its place, starting with the main purpose, then usage guidance, then return elements. It is front-loaded and well-structured, though could be slightly more concise.

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

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

Despite having no output schema, the description fully explains what the tool returns (global indicator, degraded components, open incidents, your_banks_affected). It is complete for a parameterless tool with this complexity.

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

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

There are no parameters; baseline is 4. The description explains what the tool returns in detail, compensating for the lack of an output schema. It adds meaning beyond the input schema, which is empty.

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

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

The description clearly states it checks the LIVE operational status of the Open Finance provider (its public status page), distinguishing it from the sibling tool 'openfinance_get_item_status' which checks your own connection. The verb 'checks' and resource 'provider status' are specific and unambiguous.

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

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

Explicitly tells when to use: 'whenever data looks incomplete or stale even though a connection shows UPDATED'. It contrasts with 'openfinance_get_item_status' and explains what it reveals (upstream outage, known incident), helping the agent decide between 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?

Adds context beyond annotations: explains plan filtering (PF hides PJ banks), caveat for credential connectors, and that missing keywords returns a hint. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint false).

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

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

Single paragraph covers multiple aspects efficiently, but could benefit from structured formatting like bullet points. No wasted sentences.

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 search tool with 2 parameters and no output schema, description covers behavior, return fields, caveats, and usage context comprehensively.

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 keywords as array of strings with examples and clarifies include_accounts. Adds meaning beyond schema properties.

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 connector id, access type, audience, linked connections, and connect_url. It distinguishes from sibling tools by specifying the search functionality and the one-click connect URL feature.

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 calling before connecting, notes keywords[] is required, and indicates behavior when omitted. However, it does not explicitly state when not to use it or mention alternatives among siblings.

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

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

Discloses key side effects beyond annotations: overrides automatic categorization, teaches Pluggy by creating a Category Rule, and details batch error handling. Annotations only indicate non-read-only, so the description adds substantial 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?

Description is a single paragraph but well-organized: purpose, parameter guidance, side effect, batch behavior. Slightly verbose with redundant phrasing but overall efficient.

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

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

Given only one parameter, no output schema, and low schema coverage, the description provides all necessary details: parameter format, ID sources, side effect, and error handling. Sufficient for correct tool invocation.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining the structure of the 'items' array, required fields, and sources for transaction_id and category_id. Also describes the batch response shape.

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

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

The description uses a specific verb 'Corrects' and clearly identifies the resource 'transaction category'. It distinguishes itself from siblings by referencing specific tools (openfinance_list_transactions, openfinance_list_categories) for obtaining required IDs.

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

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

Explicitly states when to use: to fix miscategorized transactions and improve future categorization. Provides context on side effects (creating a Category Rule). While it doesn't specify when not to use, the guidance is sufficient for appropriate invocation.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false; the description adds the need for conversation context but does not elaborate on side effects or error behavior, offering moderate additional 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 with no waste: the first states purpose, the second provides a key usage guideline. Front-loaded 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?

For a simple feedback tool with 3 parameters and no output schema, the description should explain parameter formats and return values. It does not cover the 'context' parameter or what happens after submission, leaving gaps.

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

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

With 0% schema description coverage, the description only mentions the conversation parameter, leaving 'message' and 'context' unexplained. It fails to add sufficient meaning beyond the bare schema.

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

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

The description clearly states the tool reports bugs, missing features, or feedback, distinguishing it from sibling tools that focus on financial data 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 explicitly instructs to include the conversation array for reproduction, providing practical guidance. It does not mention when not to use, but sibling tools are unrelated, making usage 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, covering safety. The description adds that the tool shows platform and adapter versions, but no additional behavioral traits are disclosed beyond what annotations provide.

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

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

The description is a single, concise sentence with no unnecessary words. It is front-loaded with the action and resource.

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 no parameters, the description fully specifies what the tool does: it shows platform and adapter 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?

With zero parameters and 100% schema description coverage, the description doesn't need to explain parameters. A baseline of 4 is appropriate per guidelines.

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

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

The description explicitly states the verb 'Show' and the resource 'current MCP platform and adapter versions', clearly differentiating from sibling tools like authenticate, connect, 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?

Although no explicit when-to-use or alternatives are stated, the tool's simplicity and lack of parameters make its usage self-evident. The description implies it should be used when version information is needed.

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

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

Annotations already declare readOnlyHint and idempotentHint as true. The description adds the specific data points returned, providing useful context 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?

A single, well-structured sentence that front-loads the key information with no extraneous content.

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, no-output-schema tool with strong annotations, the description is fully adequate. It covers all necessary 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?

No parameters exist, and schema coverage is 100%. The description doesn't need to add parameter information, and it correctly omits any.

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 toolkit state including installed MCPs, connection status, and catalog tool counts. The verb 'returns' and specific resources make 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?

The description implies use for retrieving status, which is clear given the sibling tools are mostly for openfinance operations or authentication. No explicit exclusions or alternatives are needed for a unique info tool.

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