Clear MCP

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

The description discloses behavioral traits beyond annotations: it explains the two authentication modes (permanent config vs session-only token), and that calling with no args returns a link. Annotations already indicate idempotent and non-destructive, and the description adds useful context about token expiry and session lifetime, though it doesn't detail error cases or response format.

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 and about 70 words, which is appropriately sized for the information it conveys. It is front-loaded with the purpose ('MCP.AI for IDE agents'), though the second sentence is a bit run-on and could be broken into clearer steps. Still, every sentence earns its place and there is no fluff.

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

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

Given this is a simple auth tool with only one optional parameter and no output schema, the description is quite complete: it covers the auth flow, the two modes, and even alternative configuration. It could be slightly more explicit about what the tool returns after a token is provided, but overall it gives sufficient context for an agent to invoke 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 only parameter `token` has 0% schema description coverage, but the description fully compensates. It explains that `token` is a JWT to be pasted for session-only login, and that omitting it triggers the link retrieval. This adds complete semantic 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 the tool's purpose: authenticating IDE agents to MCP.AI via a browser login and access token. It identifies the resource (MCP.AI) and the action (log in / authenticate), and it stands apart from sibling tools which are mostly finance-related.

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

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

The description gives explicit when-to-use guidance: it recommends the permanent config-based header approach as the best practice, and describes the session-only token paste alternative. It also instructs when to call with no args (to get the link) vs with a token, which is effectively usage guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds valuable behavioral detail beyond annotations by specifying conditional output states, including the presence of connect_url and per-install URLs when credentials are missing. It does not contradict annotations.

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

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

The description is two sentences, with the primary purpose front-loaded: 'Returns connection status and URLs.' The second sentence efficiently adds conditional detail without unnecessary elaboration. Every word contributes to understanding the tool's behavior.

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

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

Given the tool has zero parameters, rich annotations, and no output schema, the description is sufficiently complete. It explains the two meaningful states (all connected vs. missing credentials) and what the response will contain. No critical information for invoking or interpreting this simple tool is missing.

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 zero parameters, so there is nothing for the description to explain. The baseline of 4 applies because no parameters exist, and the description appropriately focuses on return behavior rather than parameter details.

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

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

The description clearly states the tool returns connection status and URLs, with specific behaviors for connected versus missing credentials. It is a clear verb+resource statement, but it does not explicitly differentiate from sibling tools like openfinance_provider_status or authenticate, which may also report connection-related state.

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 the tool is used to check connection status by describing output conditions (authenticated:true, pending[], connect_url), but it provides no explicit when-to-use guidance or mention of alternatives. Sibling tools exist that could serve similar purposes, yet no exclusions or comparisons are given.

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 well beyond the annotations (readOnlyHint=false, openWorldHint=true), detailing one-off invocation behavior without installation, credential/connect links, checkout/top-up flows, permission requirements for writes (workspace owner/admin), and the prompt library behavior. 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 dense paragraph but well-organized: core flow, then invoke vs. install, then billing/feedback, then prompt library. It front-loads key points and highlights the 'KEY' invoke behavior. Some sentences are long and could be split, but the structure is logical.

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 covers major return behaviors (profile with tool_id/params/pricing/auth, connect/checkout links, prompt full text). It does not spell out every return value for every action, but for a 23-param, multi-action tool it is fairly complete.

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

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

Schema description coverage is 0%, and the description compensates by explaining the core parameters and flow: action=search, describe returns profile with tool_id, invoke takes tool_id and arguments. However, many parameters (prompt_title, cancel_reason, request_details, etc.) remain unexplained, leaving the 23-param schema to carry the burden. The enums for action and cancel_reason are self-documenting.

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 defines the tool as the mcp.ai marketplace — the in-platform catalog and the way to run MCPs. It enumerates specific actions (search, describe, invoke, install, etc.) and distinguishes itself from domain-specific sibling tools like openfinance and authenticate by describing the marketplace as the platform-wide catalog and runner.

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 invoke vs. install: prefer invoke for one-off/occasional use, use install to make an MCP permanent. It also directs request_mcp when nothing fits, and distinguishes list_tools as listing currently callable tools. It does not explicitly name sibling tools as alternatives, but the high-level role 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?

While annotations already indicate destructiveHint=true, the description adds important context: what gets deleted (connection data), the consequence (bank's data no longer available), and the return of an add_connection_url for re-connection. This goes beyond the structured 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 three sentences, front-loaded with the primary action, and contains no unnecessary filler. Every sentence adds relevant information about the action, effect, and return value.

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

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

The description covers the action and consequence but omits critical information about the sole parameter. Without knowing what 'item' refers to, the tool cannot be correctly invoked. Even for a simple tool, this is a major gap that undermines 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?

The schema has one required parameter 'item' with no description, and the description provides zero explanation of what 'item' is (e.g., bank ID, connection ID). With 0% schema coverage, the description completely fails to clarify the parameter, making it impossible for an agent to know what value to supply.

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

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

The description clearly states the action: 'Revokes the Open Finance consent for a specific bank and deletes the connection data.' It specifies the resource (bank connection) and the effect (data no longer available), distinguishing it from sibling tools like listing or syncing.

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

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

No explicit guidance on when to use this tool vs alternatives. It does not mention that this should be used for permanently removing a bank connection or mention any alternatives. The mention of re-connect is a consequence, not usage guidance.

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

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

Annotations are sparse (readOnlyHint=false, no idempotent/destructive hints), so the description carries the full burden. It discloses blocking behavior ('WAITS for it to finish', '~60s'), polling, timeout semantics, and the `needs_action` re-authentication flow with reconnect_url — rich, actionable 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 dense — every sentence earns its place: action, use-case, parameter details, response format, error states, and timeout behavior. It is well-structured and front-loaded, with no filler 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?

With no output schema and minimal annotations, the description alone provides a complete picture: return shape (`results`, `errors`, `status`, `executionStatus`, `lastUpdatedAt`, `synced`), `needs_action` handling, `timed_out` behavior, and polling mechanics. It is self-contained for correct invocation.

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

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

Schema offers 0% description coverage for its 2 parameters. The description compensates fully by explaining `items` accepts item_id/connector_id/connector_name/custom_label selectors and may be omitted to sync all. It also clarifies `wait: false` for async invocation, going 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?

Description uses a specific verb ('Forces the bank to re-sync') and identifies the exact resource ('connections'), with a clear distinction from sibling tools like list/status tools. It anchors the purpose with the underlying API call (PATCH /items/:id) and polling behavior.

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

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

Provides explicit when-to-use guidance ('Use this when a balance or transaction list looks stale') and contrasts with alternatives by noting it works 'WITHOUT disconnecting/reconnecting' and directs users to openfinance_get_item_status for ongoing syncs. Also explains the `wait: false` fire-and-forget case.

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

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

Even with annotations indicating readOnly and idempotent, the description adds valuable behavioral details: CREDIT accounts may return a structured warning instead of throwing, and downstream failures degrade to last-synced balance with realtime:false. This significantly exceeds what annotations provide.

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

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

The description is well-structured and compact: each sentence adds essential information (behavior, error handling, degradation, response shape). It is front-loaded with the primary purpose and uses precise technical language without 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 the lack of output schema and multiple sibling tools, the description fully explains the tool's behavior, including edge cases and the exact response structure. It is complete for a read-only balance lookup with one parameter.

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 parameter with no description (0% coverage), so the description compensates by specifying the array format and the 1–50 length constraint. It clearly refers to account_ids, giving adequate meaning beyond the bare 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?

The description clearly states the tool returns real-time balance payloads per account ID, including the specific endpoint. It distinguishes itself from sibling tools by focusing on per-account balance lookup rather than listing accounts or details.

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 clear context for when to use the tool (real-time balance per account ID) and includes usage constraints (array of 1–50 account_ids). It does not explicitly name alternatives or state when not to use it, but the context is sufficient.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral context: the `{results, errors}` batch shape, the possibility of a `provider_incident` block, and explicit instructions that credit limits/balances may be unreliable and should not be presented as real. This goes well 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 front-loaded with the core purpose, then efficiently covers parameter bounds, batch response shape, and the provider incident caveat. Every sentence adds critical information, with no wasted words or repetition of annotation data.

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 explains the batch shape and the potential incident block, making the return behavior clear. It covers the essential constraints (array size 1–50) and reliability warnings, so the tool is fully usable without additional documentation.

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

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

Schema coverage is 0% for the single parameter, but the description fully compensates by explaining 'Pass `account_ids` as an array (1–50)', adding the array size constraint and clarifying the parameter's role. This provides meaning beyond the bare schema definition of an array of strings.

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

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

The description clearly states the tool 'Returns full account objects including extended creditData (additional cards, limits) per id', with a specific verb and resource. It distinguishes itself from siblings like openfinance_list_accounts by focusing on per-id detail, and from openfinance_get_account_balance by mentioning extended creditData.

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

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

The description implies usage context: pass account_ids as an array (1–50) for batch detail, and the 'per id' wording suggests it is for specific accounts rather than a list-all operation. However, it does not explicitly name alternative tools (e.g., openfinance_list_accounts) or state 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?

Annotations already declare readOnlyHint and idempotentHint, but the description adds critical behavioral context: Pluggy does not return a paid/status field, payments[] may refer to the previous bill's payment, and creditCardMetadata.billId is sparse/inconsistent. This goes far 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?

Although long, every sentence serves a purpose. The description is front-loaded with the core definition, then systematically covers exclusions, usage steps, and caveats. The density of critical nuances justifies the length.

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

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

No output schema exists, but the description discloses the return fields (financeCharges, payments[] with their subfields) and the batch shape `{ results, errors }`. Combined with annotations and sibling context, it is fully complete for a complex financial tool.

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

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

Schema has one param (bill_ids) with 0% description coverage. The description compensates by explaining it is an array, that it can contain one or more IDs, and instructs to discover IDs via openfinance_list_credit_card_bills. This adds meaningful usage guidance that is absent from 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 opens with a clear verb+resource+scope: 'Returns bill-level detail for one or more credit card bills by id.' It also explicitly distinguishes itself from sibling tools by stating what it does NOT return and pointing to openfinance_list_transactions for itemized transactions.

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

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

Provides explicit when-to-use and when-not-to-use guidance: use openfinance_list_credit_card_bills to discover IDs, use openfinance_list_transactions for itemized transactions, and prefer openfinance_list_credit_card_bills for paid status. It also warns against reconstructing totals from 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?

While annotations already indicate read-only and idempotent behavior, the description adds valuable context: the reconnect_url behavior (reopens widget in UPDATE mode, no slot consumption) and bulk execution with item_ids. It goes beyond the annotation basics to explain what the tool actually does.

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 and every sentence adds value. It is front-loaded with the core purpose, followed by parameter usage and bulk support. No redundant or filler 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 no output schema, the description provides a good overview of return values for the 'all' case (`{ count, items }`) and lists key fields for single items. It lacks explicit error or edge-case information, but for a read-only status tool, this is adequate.

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

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

Schema coverage is 0%, so the description must explain all parameters. It explains `item` and `item_ids` well, but does not clearly explain `item_id` (singular) or how it relates to `item`. This ambiguity is a gap given the zero schema coverage.

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

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

The description clearly states the tool returns the current status of a bank connection with specific details (status, executionStatus, connector metadata, reconnect_url). The 'Omit item vs pass item' distinction clearly defines its scope and distinguishes it from a simple list operation.

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

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

Provides clear guidance on when to use with or without the `item` parameter and explains the bulk use case via `item_ids`. Also gives context about the reconnect_url for re-authentication. However, it does not explicitly compare to alternative tools like openfinance_list_connections.

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, which the description aligns with. The description adds meaningful behavioral context beyond the annotations by documenting the batch response shape `{ results, errors }` and the specific fields returned. It does not cover error details or rate limits, but given the strong annotation coverage, this is acceptable.

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

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

The description is dense but well-organized, front-loading the primary action and then enumerating return fields and usage notes. The long field list is arguably necessary given the tool's complex output and the absence of an output schema. It remains efficient by using compact notation like 'interestRates[] (taxType, ratePercentage, indexer)' rather than lengthy prose.

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

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

For a read-only detail endpoint with no output schema, the description covers all essential context: the exact input format, batch limits, return payload structure (fields and nested objects), and placement in the workflow. The `{ results, errors }` shape and installments breakdown leave no major ambiguity about what the agent can expect.

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 provides only the parameter name `loan_ids` with no description (0% coverage). The description compensates by explaining to pass `loan_ids` as an array and noting the 1-50 limit. This adds practical semantics that the schema alone does not provide, though it could have explained the meaning of the IDs further.

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

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

The description opens with a clear verb+resource: 'Returns full loan contract detail by id'. It also names the exact endpoint and enumerates the returned fields, making the tool's purpose unmistakable. The phrase 'Use after openfinance_list_loans to deep-dive on a specific contract' explicitly distinguishes it from its list sibling.

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

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

The description gives explicit usage guidance: 'Use after openfinance_list_loans to deep-dive on a specific contract.' It also specifies the batch size (1-50) and how to pass loan_ids as an array. This directly tells the agent when to use this tool relative to its 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 goes far beyond the readOnly/idempotent hints by explaining the `bank` vs `name` distinction, the connector-dependent meaning of `balance`, the `provider_incident` reliability warning, and the `identity_notice` dedup requirement for joint accounts. These are critical behavioral nuances that annotations alone cannot convey.

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 each paragraph addresses a real complexity: bank vs legal-entity name, `item` scoping, connector-dependent balance, incident/identity notices, and bulk support. It is logically structured and front-loaded with a summary, though it could be slightly tightened without losing value.

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

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

With no output schema, the description does an excellent job of explaining return fields, aggregation behavior, and edge cases (incidents, identity notices). It misses explicit mention of the `type` parameter's filtering effect and the singular `item_id`, but overall it is highly complete for a complex read-only tool.

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

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

The description thoroughly explains `item` (omit for all connections, pass for a single bank) and mentions `item_ids` for bulk, but it does not explicitly state that `type` filters results by account type or what `item_id` (singular) does. Since schema description coverage is 0%, these gaps leave some parameters ambiguous.

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 bank/credit accounts with specific fields (balance, number, type, subtype, bankData, creditData) and distinguishes between listing all accounts vs a single bank via the `item` parameter. It differentiates itself from sibling tools by focusing on account listing rather than transactions, connections, or 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?

The description explicitly tells when to use openfinance_list_credit_card_bills for standardized billing data instead of relying on the connector-dependent `balance`. It gives clear guidance for omitting or passing `item` to scope to all banks or a single bank, and mentions bulk support via `item_ids`. This is a model of usage clarity.

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 meaningful behavioral context beyond annotations: results are cached for the adapter session, the response is a single aggregated object (no batch ids), and the structure of entries is detailed. This is valuable supplementary information with 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 two sentences: the first front-loads the core purpose, and the second packs essential field details and caveats without redundancy. Every clause earns its place, and the structure is highly scannable.

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

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

With no output schema and no parameters, the description fully compensates by specifying the exact fields returned (id, description, descriptionTranslated, parentId, parentDescription), the caching behavior, and the single-aggregated-response format. This is complete for an agent to understand what to expect.

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 the description has no parameter semantics to add. Per the rubric, 0 params earns a baseline 4. The description correctly mentions there are no batch ids, which indirectly clarifies the lack of input 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 explicitly states the tool returns 'Pluggy's transaction category taxonomy (GET /categories)', clearly identifying the resource and action. It also distinguishes this from sibling tools by referencing the categoryId used in openfinance_update_transaction_category, making its role in the taxonomy ecosystem 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 implies when to use this tool (when transaction categories are needed) and provides a specific usage nuance: prefer descriptionTranslated for pt-BR users. It lacks explicit 'when not to use' or alternative tool references, but no alternative category-listing tool exists among siblings, so 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 mark it as read-only and idempotent, but the description goes further by explaining the behavior of the returned reconnect_url (UPDATE mode, MFA re-entry, no slot consumption) and the add_connection_url. This adds significant 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?

The description is three sentences with high information density. It is front-loaded with the core purpose, then adds meaningful details about the reconnect_url and slot consumption. 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?

With no output schema, the description enumerates the return fields and explains the add and reconnect URL behaviors. It gives a complete picture for a parameterless read-only list operation.

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 zero parameters, so the baseline is 4. There is no parameter information to add; the description appropriately focuses on output semantics instead.

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

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

The description clearly states the tool returns saved bank connections for the install, listing specific fields. It is a specific verb+resource combination, but it does not explicitly distinguish itself from sibling list tools like 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?

The description provides clear usage context for the reconnect_url (re-authentication scenarios, MFA, LOGIN_ERROR) and clarifies that disconnecting is not required. It does not explicitly name alternatives among sibling tools, but the tool's purpose is self-evident for listing connections.

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 annotations, explaining important behavioral quirks like the payment redistribution across bills, the derived payment_status logic, open_bill availability fallbacks, and the bill_grouping_reliability warning. It also discloses performance implications of include_open_bill (extra scan). 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 long but logically structured into sections (semantics, open bill, connector asymmetry, bulk support). Every section carries critical operational warnings, though there is some redundancy in the payment_status explanation and the repeated caution about not misinterpreting payments. The length is justified by complexity, but slight tightening could improve conciseness.

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

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

For a tool with no output schema and high complexity, the description is exceptionally complete. It specifies all return fields, derived parameters, edge cases (e.g., past-due unconfirmed), fallback behavior, and how to handle multi-bank scenarios. It even covers error behavior (warning instead of failure). This fully prepares an agent to use the tool correctly.

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

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

With schema coverage at 0%, the description compensates strongly by thoroughly explaining include_open_bill (including default false and its effects) and mentioning account_ids for bulk execution. However, page and page_size receive no description, leaving their behavior unclear. Since the most critical parameters are covered but pagination is not, a 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 CLOSED credit card bills for a CREDIT-type account' and enumerates the fields and derived metrics. It explicitly distinguishes this tool from openfinance_list_transactions, noting it provides bill-level summaries, not individual transactions. This meets the standard of a specific verb+resource+scope.

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, such as using openfinance_list_transactions when itemized purchases/charges are needed, and using the derived open_bill/total_pending_debt instead of the CREDIT account's balance. It also explains when include_open_bill should be enabled and warns about connector asymmetry, giving clear when-to-use 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?

Beyond the readOnlyHint and idempotentHint annotations, the description adds critical behavioral context: the fallback to { total:0, results:[], warning } instead of throwing, and the detailed data integrity handling for mass zeroing, including how to treat suspicious rows. This goes far beyond what annotations alone convey.

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 densely packed with valuable information. It is front-loaded with the core purpose, then structured into fallback behavior, data integrity warnings, and bulk support. Every sentence adds meaningful detail, so the length is justified.

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

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

The description covers the return shape, fallback behavior, and data integrity in detail, which is impressive for a tool without an output schema. However, it omits pagination semantics for page/page_size and does not clarify the relationship between item, item_id, and item_ids, so it's not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate, but it only explicitly addresses item_ids (bulk support) and vaguely references type via asset class names. Parameters like item, page, page_size, item_id, and the precise meaning of type are not explained.

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 investment portfolio for a connection, listing specific asset classes (FIIs, stocks, ETFs, fixed income, mutual funds, retirement, COE). This specific verb+resource+scope makes it easy to distinguish from siblings like openfinance_list_investment_transactions.

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

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

The description gives clear context: use it for connections with INVESTMENTS enabled, with a graceful fallback when the product isn't enabled. It also mentions bulk support via item_ids. However, it doesn't explicitly name alternatives or say when NOT to use this tool in favor of other investment-related 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 cover read-only/idempotent/non-destructive behavior, so the description adds value by detailing return row contents (quantity, value, netAmount, expenses breakdown) and bulk execution support. It does not disclose pagination defaults or limits, but with strong annotations this is acceptable.

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-loaded with the core purpose, followed by return-field details and a bulk note. Every sentence adds information without fluff or repetition. It is efficiently structured 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 absence of an output schema and sparse parameter docs, the description covers essential details: what data is returned, how to obtain the required ID, and bulk capability. Small gaps include pagination behavior and mutual exclusivity of parameters, but these are not critical for basic invocation.

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

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

The schema has no parameter descriptions (0% coverage), so the description is the primary source. It explains the meaning behind investment_id and investment_ids, but leaves page and page_size implicitly clear only by name. It also doesn't clarify whether investment_id and investment_ids are mutually exclusive. Partial compensation for a low-coverage 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 a specific verb+resource: 'Returns the movement history for a specific investment position' and enumerates the movement types (BUY/SELL/TAX/INTEREST/AMORTIZATION/TRANSFER). It also distinguishes itself from sibling tools by referencing openfinance_list_investments and focusing on investment-specific history rather than 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 gives an explicit prerequisite: 'Use after openfinance_list_investments to get the investment_id.' This provides clear usage context. It does not explicitly list alternative tools to avoid, but the positive guidance effectively scopes the intended workflow. Bulk support is also mentioned as an additional usage mode.

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, setting a positive safety baseline. The description adds meaningful behavioral context: multiple connections are processed sequentially with rate-limit spacing, and the return shape is { results, errors } per connection. This goes beyond the annotations without contradicting them.

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

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

The description is compact and front-loaded, starting with the core purpose and then providing usage details. All three sentences carry essential information with no filler 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?

Given there is no output schema, the description usefully provides the per-connection return shape { results, errors } and explains both invocation modes. It does not detail pagination or the individual loan contract fields, but for a list operation with a single optional parameter, this is reasonably 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 only defines `items` as an array of strings with zero description coverage. The description compensates by explaining that each string is a connection selector (item_id uuid, connector_id, or connector_name), that one entry represents one connection, and that omitting the parameter lists all banks. This is a substantial semantic addition, though it leaves the exact string format for selector types implicit.

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

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

The description clearly states the tool lists loan contracts per bank connection and includes the GET endpoint. It distinguishes from sibling get_loan_detail by focusing on listing versus detail, and clarifies the two operating modes (specific connections vs all banks).

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 pass `items` (for specific connections) and when to omit it (for all linked banks), and notes sequential querying with rate-limit spacing. However, it does not explicitly mention alternatives like get_loan_detail for single-loan details, so it lacks a full when-not/alternatives comparison.

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 it as read-only/idempotent/non-destructive, but the description goes far beyond by explaining per-connector variability (Nubank sparse billId), auto vs. manual pagination semantics, the 5000-transaction ceiling, error behavior (returns zero result with warning instead of throwing), provider incident blocks, and the account echo block. 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 exceptionally long but dense with necessary operational information. It loses a point due to repetition (the billId sparse/inconsistent caveat appears twice) and the lack of any visual hierarchy or sectioning, which hurts scannability for a quick-reading agent. Still, nearly every sentence adds value.

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

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

Given the tool's complexity (8 parameters, no output schema), this description is exhaustive. It covers return values, error responses, performance limits, data quality caveats, cross-tool references, and failure recovery steps. The absence of an output schema is fully compensated by the description's detailed explanation of what the response contains, including total, truncated, warning, and provider_incident blocks.

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

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

Schema description coverage is 0%, so the description carries full responsibility. It details from/to as ISO date filters, search_queries as case/accent-insensitive OR substring matching, page/page_size switching between auto and manual pagination, detail enum meanings (compact/rich/raw), and bulk account_ids support. This fully compensates for the schema's bare parameter list.

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 or CREDIT accounts and explicitly identifies itself as the ONLY way to get itemized credit card transactions. It distinguishes itself from sibling tools like openfinance_list_credit_card_bills and openfinance_list_accounts by specifying exactly what each alternative is used for.

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

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

Provides explicit when-to-use and when-not-to-use guidance: it warns against reconstructing bill totals and directs users to openfinance_list_credit_card_bills for authoritative totals and openfinance_list_accounts for closing/due dates. It also recommends checking openfinance_get_item_status when a CREDIT account returns zero transactions, and points to force sync as a remedy.

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 the read-only and idempotent annotations, the description discloses critical behavior: truncation at 5000 transactions per account with a truncated flag, potential provider_incident blocks with data integrity caveats, and the heavier cost of 'raw' granularity. This substantially enriches 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?

Though lengthy, the description is densely packed with necessary information for a complex tool. It is front-loaded with the primary purpose, uses clear formatting, and every sentence adds practical value without 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?

The description provides a complete picture: return structure (totals, monthly evolution, top transactions, per-account breakdown), handling of provider incidents, truncation behavior, and use-case guidance. Given no output schema exists, this fully compensates and exceeds the minimum required.

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

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

With 0% schema description coverage, the description fully compensates by explaining the meaning and usage of nearly every parameter: `item` accepts various identifiers or omission for all banks, `from`/`to` are ISO dates, `granularity` controls summary vs raw rows, `detail` controls enrichment levels, `type` filters account categories, and `item_ids` enables batch execution. Only `top_n` is implied but clear from 'largest N'.

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 performs consolidated cash-flow analysis for a connection, resolving accounts internally and aggregating transactions. It distinguishes itself from siblings by explicitly noting it does not require prior account listing calls and targets whole connections, not individual 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?

It provides explicit use cases ('análise anual/mensal', 'fluxo de caixa', etc.) and explains when to choose 'raw' granularity versus the default. It also tells users they do not need to call openfinance_list_accounts first, effectively steering them away from an alternative.

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 meaningful behavioral context beyond the annotations: it accesses a public status page, returns a global indicator, lists degraded components and open incidents, and flags incidents affecting connected banks. This gives the agent a clear picture of the tool's external dependency and output, without contradicting the readOnly/idempotent annotations.

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

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

The description is dense but well-structured: it opens with the core purpose, immediately differentiates from a related tool, provides concrete usage scenarios, and lists return elements. Every sentence contributes actionable information without redundancy or fluff.

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

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

Given the tool has no parameters and no output schema, the description fully compensates by enumerating the return fields (global indicator, degraded components, open incidents, `your_banks_affected`) and providing troubleshooting context. It is complete for an agent to select and interpret the tool correctly without additional documentation.

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

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

The tool has zero parameters, so there is no parameter schema to explain. The description still adds value by describing what the return payload contains and how connected banks factor into the output, aligning with the baseline 4 for parameterless 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?

The description uses a specific verb ('Checks') and resource ('LIVE operational status of the Open Finance provider'), making the tool's purpose immediately clear. It also explicitly distinguishes this tool from the sibling `openfinance_get_item_status` by noting it checks the provider's health rather than the user's own connection.

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 guidance: when data looks incomplete or stale despite a connection showing UPDATED. It also clarifies the alternative (`openfinance_get_item_status`) and explains how to differentiate provider-side problems from connection issues, giving the agent a clear decision path.

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 read-only and idempotent, but the description adds key behaviors: empty keywords returns a hint rather than the full catalog, plan-based filtering (PF hides PJ, PJ covers both), and caveat warnings for non-auto-updating connectors. These go beyond annotation data and are essential for correct usage.

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

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

All five sentences carry unique information with no filler. Purpose and return values lead, followed by caveat, plan, and invocation guidance in logical order.

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

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

For a search tool with no output schema, the description thoroughly covers return values, conditional behaviors, usage order, and required inputs. It is self-contained and sufficiently distinct from sibling tools.

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

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

Schema has 0% description coverage, but the description fully explains both parameters: keywords[] is REQUIRED with examples and hint behavior, include_accounts=true adds accounts to returned connections. This fully compensates for the schema's lack of detail.

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 opens with 'Searches the available bank connectors by name', specifying the exact verb and resource. It enumerates returned fields (connector id, access, audience, linked connections, connect_url), clearly distinguishing it from sibling list/connect 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?

Explicitly instructs 'Call this BEFORE connecting to hand the user a one-click link to the right bank', giving a clear when-to-use. It also advises preferring Open Finance connectors over caveated credential connectors, though it does not name alternative tools directly.

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

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

Discloses a significant side effect: recategorizing automatically creates a Category Rule for future similar transactions. Also describes batch error handling (per-item errors do not fail the whole batch). This goes beyond the false annotations and gives valuable behavioral insight.

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 thorough but efficiently structured, starting with purpose, then input format, side effects, and response shape. Each sentence contributes unique information, though it is 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?

Despite having no output schema and only one nested parameter, the description covers the input format, source of IDs, side effects, and complete response structure. It is fully self-contained for an agent to use the tool correctly.

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

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

The schema has no descriptions, but the description fully explains the 'items' parameter: an array of { transaction_id, category_id } with clear sourcing from list tools. This adds critical meaning beyond the structural 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's function: 'Corrects the category of one or more transactions' with the HTTP endpoint. It uses a specific verb and resource, distinguishing it from sibling tools that list or fetch data.

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

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

Provides explicit usage context: 'use this to fix miscategorized transactions and improve categorization accuracy going forward.' Also tells where to source transaction_id and category_id from sibling tools. It does not explicitly mention when not to use it, but the guidance is clear.

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

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

Annotations already indicate non-read-only, non-destructive, and idempotent behavior. The description adds useful context by instructing to include the conversation array for reproduction, which is not covered by annotations. This provides additional behavioral guidance beyond the safety profile.

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

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

The description is two sentences, front-loaded with the primary action ('Report a bug...') and no filler. Every word contributes to understanding the tool's purpose and key usage detail.

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

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

For a simple bug-reporting tool with annotations and no output schema, the description is largely complete. However, it does not clarify the 'context' parameter or the JSON-string format of 'conversation' (schema says string, description says array), which could lead to minor invocation confusion.

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% parameter description coverage. The description explains the 'conversation' parameter's purpose ('Include the conversation array with recent messages for reproduction') and implicitly covers 'message' as the bug/feedback content, but does not explain 'context'. This leaves a gap for one of three parameters, so the description only partially compensates for schema gaps.

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

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

The description clearly states 'Report a bug, missing feature, or send feedback' with a specific verb and resource, distinguishing it from all sibling tools which are financial operations. The title 'Report Bug' and description align perfectly.

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 (reporting issues or feedback) but does not explicitly mention alternative tools or exclusions. Since no sibling tool handles bug reporting, the usage context is unambiguous.

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, covering the safety profile. The description adds minimal behavioral context beyond stating what versions are shown; it does not mention return format or authentication, but annotations mitigate these gaps.

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

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

The description is a single, front-loaded sentence that conveys the entire purpose without any wasted words. It is appropriately sized for a trivial version-check tool.

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

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

Given the absence of parameters, output schema, and complex behavior, the description fully covers what the tool does. No additional information is needed for an agent to select and invoke 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 tool has zero parameters, so per the rubric, the baseline is 4. The description does not need to explain any parameter semantics, and no ambiguity exists.

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

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

The description clearly states the tool's function with a specific verb ('Show') and resource ('current MCP platform and adapter versions'). It distinguishes itself from siblings like toolkit_info by focusing specifically on version information.

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

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

The context of when to use this tool is clear: to retrieve version information. While it does not explicitly mention alternatives or exclusions, the simplicity of the tool makes the usage self-evident. No conflicting 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?

The description adds value beyond the annotations by revealing exactly what the return payload includes (installed MCPs, connection status, accounts, catalog tool counts). It confirms a read-only, non-destructive operation without contradicting the annotations. It could go further by describing edge cases (e.g., empty state), but the provided detail is strong.

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 fully describes the tool's purpose and output. Every word contributes meaning, with no redundancy or filler. It is front-loaded with the verb 'Returns' and immediately specifies the resource 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?

For a parameterless info tool with no output schema, the description is highly complete: it explains what the tool returns in enough detail for an agent to decide when to invoke it. It does not list specific fields or return types, but given the tool's simplicity, the description covers the essential 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?

The tool has zero parameters, so the baseline of 4 is appropriate. The description does not need to elaborate on parameters, and the schema covers everything (100% coverage with no properties). The description's focus on output is suitable for a parameterless 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 the tool returns the current toolkit state, listing specific components (installed MCPs, connection status, connected accounts, catalog tool counts). This distinctively differentiates it from sibling tools, which are all focused on specific OpenFinance operations or authentication/connectivity.

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 makes the tool's purpose obvious but does not explicitly state when to use it versus alternatives like openfinance_list_connections or openfinance_provider_status. It provides clear context for a general toolkit overview but lacks explicit when-to-use or when-not-to-use guidance.

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