Toro MCP

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

Adds behavioral context beyond annotations: explains permanent vs session usage, token as header. No contradiction with idempotentHint=true (multiple calls give same link).

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, front-loaded with purpose, efficiently describes both methods. Could be slightly more structured but concise enough.

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?

Simple tool with one optional param, description covers both usage modes and authentication flow. No output schema needed; complete for the use case.

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

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

Schema has 0% coverage, but description fully explains the 'token' parameter: optional JWT for session login, or no args to get link. Adds full meaning.

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's purpose: authenticate by browser login and token. Distinguishes from siblings (mostly finance tools) and explains both permanent config and session token methods.

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 when to use permanent config vs session token, and calling with no args to get link. Lacks explicit 'when not to use' 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?

Annotations indicate read-only, idempotent, and non-destructive. The description adds details about the response structure (authenticated, pending, connect_url), which goes beyond the annotations. No contradictions.

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

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

Two sentences with no redundancy. Every clause provides useful information about the tool's output in different scenarios.

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 two main states (all connected vs. missing credentials) but does not elaborate on other potential states like partial connections or errors. Given no output schema, this is adequate but not exhaustive.

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

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

The input schema has no parameters, so the description does not need to add parameter information. The baseline for 0 parameters is 4, and the description appropriately focuses on behavior rather than parameters.

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

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

The description clearly states it returns connection status and URLs, specifying the behavior when all providers are connected versus when credentials are missing. This distinguishes it from sibling tools like 'authenticate' or 'toolkit_info'.

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

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

The description explains when to use the tool (to check connection status) and describes two distinct states. It doesn't explicitly mention when not to use or provide alternatives, but the context is sufficient for an agent to decide.

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 extensive behavioral context beyond annotations: invoke runs one-off without installing, returns connect/payment links, and writes require owner/admin. Annotations are minimal, so the description carries the full burden and does so excellently.

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

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

The description is comprehensive and well-structured, starting with the core purpose and flow, then diving into key distinctions. It is slightly long but every sentence adds value. Minor redundancy could be trimmed, but overall it is efficiently organized.

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) and no output schema, the description covers the major behavioral aspects and usage patterns. However, it lacks details on return values for different actions and does not handle all edge cases. Still, it is fairly complete for agent use.

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

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

Schema description coverage is 0%, and while the description explains the flow and how parameters relate to actions (e.g., query for search, tool_id for invoke), it does not systematically describe each of the 13 parameters. The agent can infer usage but missing explicit documentation for parameters like limit, message, immediate, etc.

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

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

The description clearly states the tool is the official mcp.ai marketplace for discovering and running MCPs. It uses specific verb-resource combinations like 'search', 'describe', and 'invoke', and distinguishes from sibling tools by being the primary entry point for MCP discovery.

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 this tool first when the user wants a capability. It provides detailed guidance on when to use invoke vs install, how to handle auth/payment links, and references other sibling actions like list_tools, subscribe/cancel, report_bug, and request_mcp.

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

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

Annotations already mark destructiveHint as true. The description adds behavioral context: data will no longer be available and a re-connect URL is returned. No contradiction with annotations.

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

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

Two sentences with no wasted words. Clearly states action, consequence, 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?

For a simple tool with one parameter and no output schema, the description covers purpose, effect, and return. Missing parameter format details but overall adequate given low complexity.

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

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

The single 'item' parameter is required but lacks description. Schema coverage is 0%. The description hints that 'item' identifies a bank, but does not clarify expected format or source. Minimal guidance beyond schema.

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

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

The description clearly states the tool revokes Open Finance consent and deletes connection data for a specific bank, with a return of an add_connection_url. It distinguishes from sibling tools like openfinance_list_connections or openfinance_force_sync by focusing on disconnection.

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

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

The description implies usage when you want to disconnect a bank, but does not explicitly state when not to use it or mention alternatives. However, it provides clear context for the primary use case.

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

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

Discloses key behaviors beyond annotations: polls up to ~60s, returns specific status fields (status, executionStatus, lastUpdatedAt, synced), and explains timeout and needs_action scenarios. Annotations are readOnlyHint=false, consistent with modification.

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 front-loaded with key action and use case, then covers parameters and return values. Each sentence adds value, though could be slightly more streamlined.

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

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

Comprehensive for a tool without output schema: covers return structure, edge cases (timed_out, needs_action), and polling behavior. Describes all aspects needed for correct invocation.

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

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

Schema coverage is 0%, but description fully explains both parameters: wait (boolean with usage guidance when false) and items (array of selectors with omit-to-sync-all behavior). Adds meaning well beyond raw schema.

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

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

Clearly states the tool forces a re-sync of bank connections, with specific verb 'forces' and resource 'connections'. Distinguishes from sibling retrieval tools by emphasizing it pulls fresh data when lists look stale.

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 ('when a balance or transaction list looks stale') and notes it does not disconnect/reconnect. Does not name specific sibling tools as alternatives, but provides context for when to use wait: false.

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 annotations (readOnlyHint, idempotentHint), the description discloses a specific error mode for CREDIT accounts (BALANCE_FETCH_ERROR with structured warning) and the response shape. 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?

Two efficient sentences cover purpose, parameter details, error behavior, and response format with no redundant information.

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

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

Given the simple parameter and no output schema, the description adequately covers purpose, constraints, error handling, and response shape. Missing info on account ID source is minor and can be inferred from 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 schema has 0% description coverage, but the description adds crucial constraint: account_ids must be an array of 1-50 strings. This compensates for the lack of schema descriptions, though it does not explain the origin of account IDs.

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

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

The description clearly states the tool retrieves real-time balance per account ID, specifies the HTTP endpoint, and distinguishes from siblings like openfinance_list_accounts or openfinance_get_accounts_detail by focusing on balance 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 constraints for the account_ids parameter (array of 1-50) and mentions error handling for CREDIT accounts. Lacks explicit guidance on when to choose this tool over alternatives, but the context of balance retrieval 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 and destructiveHint=false. Description adds that it returns extended creditData and batch shape with results/errors, which is additional behavioral context. No contradiction.

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

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

Two sentences, front-loaded with purpose, then usage. No wasted words.

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

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

Given no output schema, description explains return shape (results/errors) and mentions extended creditData. Parameter constraints are clear. Could add more on error handling but sufficient.

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

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

Schema has 0% coverage; description adds array type requirement, batch size 1-50, and implied batch fetch semantics. This compensates well for missing schema descriptions.

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

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

Description clearly states it returns full account objects with extended creditData per ID and batch shape. Differentiates from siblings like openfinance_list_accounts (list without details) and openfinance_get_account_balance (balance only).

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: pass account_ids as array (1-50) and batch shape. Implicitly suggests when to use (for detailed account objects) but lacks explicit when-not-to-use or alternatives beyond sibling list.

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

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

Discloses key behavioral traits beyond annotations: does not return individual transactions, batch shape { results, errors }, notes on Pluggy's missing paid/status field, and warnings about payments[] representing previous bill payments. Annotations already indicate readOnly/idempotent/non-destructive, but description adds crucial 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 thorough but slightly verbose. It front-loads the main purpose and uses bullet-like lists for fields. While every sentence adds value, it could be slightly more concise by combining related notes. Still well-structured.

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

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

Without an output schema, the description fully explains returned fields and their meaning, covers edge cases (payments[] interpretation), and links to companion tools. It provides complete context for an agent to use this tool effectively.

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 (bill_ids) has no schema description (0% coverage), but the description clearly explains it as an array of bill IDs and tells the agent to use the list tool to discover them. This fully compensates for missing schema documentation.

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 bill-level detail for credit card bills by ID, explicitly listing returned fields (financeCharges, payments[]). It distinguishes from siblings by noting what it does NOT return (individual transactions) and recommending openfinance_list_transactions for itemized data.

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

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

Provides explicit guidance: use openfinance_list_credit_card_bills first to discover IDs, use openfinance_list_transactions for itemized transactions, and cautions about interpreting payments[] in Brazilian Open Finance. Clearly states when to use this tool vs 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, destructiveHint=false, and idempotentHint=true. The description adds context about the specific status values returned, executionStatus, connector metadata, and the structure when querying all banks. This supplements the annotations without contradiction.

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

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

Three sentences, no filler. The first sentence states purpose and return type, the second explains usage modes. Every sentence adds value, and the structure is front-loaded.

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

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

Given the lack of an output schema, the description adequately covers return values for both modes: status, executionStatus, connector metadata for single bank, and { count, items } for all banks. It could be more explicit about the exact shape of the single bank response, but the examples provide 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?

The schema has only one parameter `item` with no description (0% coverage). The description compensates by explaining its role: omit for all banks (returns { count, items }) or pass for a single bank. This adds essential meaning beyond the schema, though the format of `item` is not clarified beyond being a string.

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 status of a bank connection with example values (UPDATED, UPDATING, LOGIN_ERROR) and distinguishes between single and all banks. It uses a specific verb and resource, and differentiates from sibling tools like openfinance_list_connections by focusing on status rather than listing.

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 guidance on when to omit or pass the `item` parameter, explaining the two modes of operation. However, it does not compare this tool to alternatives like openfinance_list_connections or openfinance_provider_status, missing explicit 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.

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

Beyond annotations (readOnlyHint, idempotentHint), description discloses that credit card balance is connector-dependent, warns not to treat as 'this month's bill', and explains the open billing cycle fields. 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?

While long, every sentence adds value. Front-loaded with main purpose, then efficiently covers edge cases, parameter behavior, and cross-tool references. No redundant or vague statements.

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 complex domain, description fully covers return fields (balance, number, type, subtype, bankData, creditData, bank, connector_id), parameter behavior, and credit balance nuance. Directs to sibling for further detail.

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 compensates fully: explains item param's effect (omit vs pass) and type param (BANK/CREDIT). Also describes how response structure changes (root vs results array) based on 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 accounts for bank connections, specifying types (BANK, CREDIT) and fields. It distinguishes between listing all accounts (omit item) vs a single bank (pass item), differentiating it from sibling tools like 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?

Explicitly explains when to omit item ('my accounts/cards' without naming a bank) vs pass item to target a single bank. Also references sibling tool openfinance_list_credit_card_bills for standardized credit card billing, providing clear 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.

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: caching per adapter session, single aggregated response, no batch ids. 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 sentences, front-loaded with the main purpose. Every sentence adds value: caching, response structure, fields, and usage note. No wasted words.

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

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

Given no output schema and zero parameters, the description is nearly complete. It explains the response fields and caching. It could be more explicit about the output being a list/array, but the mention of 'each entry' implies it.

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 coverage, the baseline is 4. The description goes beyond by explaining the structure of each entry (id, description, descriptionTranslated, parentId, parentDescription) and the response's aggregated nature.

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

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

The description clearly states it returns Pluggy's transaction category taxonomy. It distinguishes from siblings by specifying the output structure and mentioning the sibling openfinance_update_transaction_category that uses the categoryId.

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

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

The description implicitly guides usage by noting that the `id` field is used by openfinance_update_transaction_category. However, it does not explicitly state when not to use this tool or provide alternatives, but given the specificity, it's 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, and destructiveHint=false, so the description's job is light. It adds useful context: the tool returns an add_connection_url that enables linking additional banks, which is a behavioral trait not captured by annotations. No contradictions.

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

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

The description is a single sentence that front-loads the core purpose and lists key details. Every word adds value, and there is no redundancy or verbosity.

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 that the tool is simple with no parameters, the description fully covers the return value structure (connector_id, item_id, bank name, add_connection_url) and its purpose. No output schema exists, so the description adequately fills that gap.

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

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

The tool has zero parameters and schema description coverage is 100%. Per guidelines, the baseline score is 4, and the description does not need to add parameter info. The description provides context about what is returned, which is helpful beyond the schema.

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

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

The description clearly states that the tool returns saved bank connections for the install, listing specific fields (connector_id, item_id, bank name, add_connection_url). This differentiates it from sibling tools such as openfinance_list_accounts or openfinance_list_transactions, which serve different purposes.

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

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

The description does not explicitly state when to use this tool versus alternatives. While its read-only nature and listing focus are implied, it provides no guidance on conditions to avoid using it (e.g., if you need filtered or detailed connection data). This is adequate but not fully instructive.

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 and idempotentHint=true. Description adds critical behavioral context: payment derivation logic, payment_status rules, open_bill derivation, connector asymmetry, and that results are bill-level summaries. 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 verbose but well-structured with front-loaded main fields and detailed subsequent explanations. Every sentence adds value given the domain complexity, but it could be more concise by grouping related information. Still, it is clear and logically organized.

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

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

Given the complexity of Brazilian Open Finance credit card bills and no output schema, the description is remarkably complete. It explains all return fields, derived values, optional features, edge cases (connector asymmetry), and relationship to other tools. The only minor gap is lack of explicit pagination description, but overall, it fully equips 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?

Schema description coverage is 0%, so description must explain parameters. It explains account_id, include_open_bill, and account_ids in detail, but does not explicitly describe page and page_size. However, pagination parameters are standard and partially implied by the bulk support mention. The description adds significant meaning beyond the schema for the explained parameters.

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

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

Description clearly states the tool returns CLOSED credit card bills for a CREDIT-type account, listing specific fields and derived values. It distinguishes from siblings like openfinance_get_credit_card_bill and openfinance_list_transactions, which are for single bills or transactions, respectively.

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

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

The description provides extensive usage guidance: warns about payment semantics and not assuming payment status, explains when to use include_open_bill and its default false for performance, covers connector asymmetry, and mentions fallback to openfinance_list_transactions for itemized charges. It also notes that the tool returns a warning instead of failing if CREDIT_CARDS is not enabled.

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

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

Annotations indicate read-only, idempotent, and non-destructive behavior. The description adds value by detailing the return fields and the fallback object on errors, which is 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 concise with two sentences, no redundant text, and front-loaded with the core functionality. Every part earns its place.

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

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

Given no output schema, the description explains the return structure (fields, fallback) sufficiently. It covers the essential behavioral aspects but could benefit from clarifying parameter usage.

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

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

The input schema has four parameters (item, page, type, page_size) with no descriptions (0% coverage). The description does not provide any meaning or constraints for these parameters, leaving the agent without guidance.

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 types and fields. It distinguishes from sibling tools by focusing on the portfolio overview rather than individual transactions or 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 indicates usage for connections with INVESTMENTS product enabled and mentions a fallback for errors, but does not provide explicit guidance on when not to use it or suggest alternative tools for other scenarios.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral details: transaction types, specific fields (including expenses), and bulk execution capability. 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?

Two tightly packed sentences plus a line on bulk support. No redundancy, front-loaded with purpose, 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?

For a read-only list tool without output schema, the description adequately covers return fields (quantity, value, amount, netAmount, agreedRate, brokerageNumber, itemized expenses), usage context, and bulk mode.

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

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

Schema coverage is 0% so description must explain all parameters. It covers investment_id and investment_ids, but omits page and page_size. The description adds value for two of four parameters but leaves half undocumented.

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

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

The description clearly states the tool returns movement history for investment positions with specific transaction types (BUY/SELL/TAX/INTEREST/AMORTIZATION/TRANSFER) and lists returned fields. It is distinct from siblings like openfinance_list_investments and openfinance_list_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 advises to 'Use after openfinance_list_investments to get the investment_id' and mentions bulk support via investment_ids. It lacks explicit when-not-to-use context but provides clear sequencing 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 indicate readOnlyHint=true and idempotentHint=true. The description adds behavioral details about sequential queries with rate-limit spacing and the return format per connection, which enriches transparency without contradicting 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, front-loaded with the purpose, and every sentence adds value. No unnecessary 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 tool has one optional parameter, no output schema, but the description covers parameter usage, default behavior, and return structure (results, errors). It also mentions rate-limit considerations, making it contextually complete for a list tool.

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

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

With 0% schema description coverage, the description provides crucial details: items is an array of connection selectors (item_id uuid, connector_id, or connector_name). It explains the effect of providing or omitting items, adding significant value beyond the schema.

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

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

The description clearly states the tool lists loan contracts per bank connection, using the GET /loans endpoint. It distinguishes from sibling tools like openfinance_list_accounts by specifying 'loans' and 'per bank 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 explains when to pass the `items` parameter (to specify connections) and when to omit it (list all loans across linked banks). It also mentions sequential querying with rate-limit spacing, but does not explicitly contrast with 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 annotations (readOnly, idempotent), the description reveals critical behavioral traits: credit card transaction behavior varies by connector (PENDING vs POSTED), search_queries aggregates up to 5000 transactions, error handling returns warning/error objects instead of throwing, and bulk support via account_ids. 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 thorough but slightly verbose. It is well-structured, starting with the main purpose, then detailed credit card behavior, parameter explanations, error handling, and bulk support. Every sentence is valuable, but it could be trimmed slightly for brevity without losing completeness.

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 (multiple account types, credit card nuances, pagination, filtering, error handling) and the absence of an output schema, the description covers all necessary aspects. It addresses how to interpret results (truncated flag, warning/error), links to related tools (openfinance_list_credit_card_bills, openfinance_get_item_status, openfinance_force_sync), and explains edge cases like zero results.

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

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

With 0% schema description coverage, the description fully compensates by explaining all 7 parameters: account_id, account_ids, from/to (ISO YYYY-MM-DD), page/page_size (max 500), and search_queries (case-insensitive substring match, OR semantics). It clarifies the aggregation limit and truncation behavior, which is essential 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 it returns transactions for BANK or CREDIT accounts. It distinguishes itself by specifying that for CREDIT accounts it's the only way to get itemized transactions, differentiating from sibling tools like openfinance_list_credit_card_bills and openfinance_list_transactions_by_item. The verb 'returns' is specific and the resource is clearly defined.

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

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

The description provides explicit guidance on when to use this tool (itemized transactions, especially for credit cards) and when not to (use openfinance_list_credit_card_bills for standardized totals). It includes troubleshooting for zero results (check connection health) and explains the behavior differences per connector for PENDING vs POSTED transactions. It also covers pagination and search semantics.

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

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

Description reveals internal resolution of accounts, behavior when item is omitted, default granularity's compact summary output, cap at 5000 transactions per account with truncation flag, and filtering capabilities. This adds significant context beyond annotations (readOnlyHint, etc.).

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

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

Description is informative but somewhat verbose (4 sentences). However, it is front-loaded with purpose and each sentence adds value. Could be slightly more concise by condensing examples.

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

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

Despite no output schema, description details return fields (entradas, saídas, saldo_liquido, por_mes, top_despesas, etc.) and truncation behavior. Missing default for top_n, but overall adequately covers tool's complexity.

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

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

With 0% schema description coverage, description explains all parameters except top_n, which is only implicitly referenced as 'largest N each.' It clarifies item types, date formats, granularity options, and type filter. Lacks explicit link between top_n and top_despesas/top_recebimentos.

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 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call.' It specifies verb (analyze/list), resource (consolidated transactions for a connection), and distinguishes from siblings by noting it resolves accounts internally, unlike list_transactions or other per-account 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 states that calling openfinance_list_accounts is unnecessary and provides when to omit item (all banks) or use granularity='raw' (when itemized rows needed). Also gives example use cases, guiding the agent on appropriate scenarios.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds behavioral context: returns global indicator, degraded components, open incidents, and flags affected banks. No contradictions.

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

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

Single paragraph with all necessary information, front-loaded. Could be slightly tighter but no superfluous 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 tool with no parameters and no output schema, description fully explains return value (global indicator, degraded components, incidents, affected banks) and use case.

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

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

No parameters in input schema (coverage 100%). Baseline 4 applies as description adds no parameter info but that's acceptable.

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 checks the LIVE operational status of the Open Finance provider's public status page, distinguishing it from the sibling tool openfinance_get_item_status. Specific verb and resource.

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 describes when to use (data looks incomplete/stale despite updated connection) and when not (connection issue), and mentions the alternative sibling 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds valuable behavioral context: plan filtering, hint returned when keywords omitted, and that connect_url is pre-selected. No contradiction with annotations.

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

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

Description is a single paragraph but information-dense. It covers purpose, return fields, usage order, constraints, and behavior. Could be slightly more structured with bullet points, but no unnecessary 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 2 parameters, no output schema, and annotations present, the description covers return fields, plan behavior, keyword requirement, and usage sequence. It does not mention error handling or edge cases, but for a search tool this is sufficient.

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

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

Schema coverage is 0%, so description must compensate. It explains keywords[] with example, states it is REQUIRED (contradicts schema required:0 but clarifies true behavior), and explains include_accounts affects whether accounts are returned. This adds significant 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?

Description clearly states it searches bank connectors by name, lists return fields (connector id, access type, audience, linked connections, connect_url), and explicitly says it should be called 'BEFORE connecting'. This differentiates it from siblings like openfinance_list_connections (existing connections) and openfinance_list_categories (categories).

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?

Description provides explicit usage guidance: 'Call this BEFORE connecting', explains that keywords[] is REQUIRED (no full catalog dump), and notes that the user's plan is honored (PF plan hides PJ banks). It implies when not to use (if no keywords given, returns a hint). No alternatives listed but context is sufficient.

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

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

The description adds significant behavioral context beyond annotations: it discloses the side effect of creating a Category Rule for future transactions, describes batch behavior (per-item errors do not fail the batch), and specifies the response structure. 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 compact and front-loaded with the purpose and HTTP method. It covers all key aspects in a single paragraph without wasted words, though bullet points could improve readability slightly.

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 (one parameter with nested objects, side effects, error handling) and no output schema, the description is complete: it covers purpose, parameter details, side effects, response structure, and error behavior.

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

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

Despite 0% schema description coverage, the description fully compensates by explaining the 'items' parameter format (array of objects with transaction_id and category_id), sources for IDs, and the response format. This adds complete meaning beyond the schema.

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

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

The description clearly states the tool corrects transaction categories with a specific verb 'Corrects' and resource 'transactions category', referencing the HTTP method PATCH. It distinguishes itself from sibling tools like openfinance_list_transactions and openfinance_list_categories by explaining where to obtain 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?

The description provides clear context on when to use the tool (to fix miscategorized transactions) and how to get required IDs from other tools. However, it does not explicitly state when not to use it or provide direct alternatives beyond implicit differentiation from list tools.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false, so the agent knows it's a safe, non-destructive operation. The description adds the detail about including conversation but does not contradict annotations. No additional behavioral context is provided.

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

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

Two sentences with no unnecessary words. The purpose and key usage instruction are front-loaded and 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?

The description covers the main purpose and one parameter (conversation) but lacks explanation for 'context' and the type mismatch for 'conversation' (string vs array). With no output schema, more detail on expected return or confirmation would be helpful.

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. It mentions 'conversation array' but the schema defines it as a string, causing potential confusion. The 'context' parameter is not explained. Only 'message' is implicitly clear.

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 is for reporting bugs, missing features, or feedback, with a clear verb and resource. It distinguishes from sibling tools which are focused on financial operations and authentication.

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

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

The description gives explicit guidance to include the conversation array with recent messages for reproduction, indicating when to use the tool. However, it does not mention when not to use it or provide alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety traits. The description adds specific content (MCP platform and adapter versions) but no additional 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 a single, efficient sentence with no wasted words. It is appropriately sized for the tool's simplicity.

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, no output schema, and a straightforward purpose, the description fully informs the agent of what the tool does.

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, and schema coverage is 100%. The description does not need to add parameter information, earning a baseline score of 4.

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

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

The description clearly states the tool shows current MCP platform and adapter versions, using a specific verb and resource. It distinguishes itself from sibling tools, none of which are version-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?

While no explicit when-to-use vs alternatives is given, the tool is self-explanatory. Its purpose is evident, and the context of a version display tool requires minimal guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context about the specific data returned (installed MCPs, connection status, catalog tools), which goes beyond the annotations.

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

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

The description is a single, complete sentence with no extraneous words. It front-loads the action ('Returns') and immediately specifies the 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 read-only tool with no output schema, the description adequately explains what is returned. It could benefit from mentioning the response format or structure, but it is sufficiently complete for an agent to understand the tool's purpose.

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, and schema description coverage is 100% (empty schema). The description does not need to add parameter info; it appropriately focuses on the output.

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 'Returns' and lists exact contents (installed MCPs, connection status, catalog tool counts). It clearly distinguishes from siblings like show_version which returns version info only.

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 does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. However, as a stateless read-only tool with no parameters, usage context is self-evident.

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