Bradescard MCP

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

Annotations already indicate idempotentHint=true and readOnlyHint=false. The description adds behavioral context by explaining the two login modes and that calling with no args returns a link. 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 front-loaded with a clear purpose and then details two methods. It is slightly wordy but every sentence adds value. Could be streamlined slightly without losing information.

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

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

For a simple 1-parameter auth tool with no output schema, the description adequately covers usage. However, it omits details about return values (e.g., success/error responses), which would improve completeness.

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

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

Schema has 0% description coverage for the single 'token' parameter. The description fully compensates by explaining that the token is a JWT for session login and that omitting it provides a login link. This adds essential meaning beyond the schema.

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

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

The description clearly states the tool is for authentication in IDE agents, explaining two distinct methods (permanent config vs session token). This distinguishes it from sibling tools like 'connect' and 'marketplace'.

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 each method (permanent vs session) and how to call with no args vs token. However, it does not explicitly state when not to use this tool or mention alternatives among siblings.

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

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

Adds value beyond annotations by describing the response shape (authenticated:true vs connect_urls). Annotations already declare readOnlyHint, so the description's behavioral detail is appropriate.

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 clear sentences with no wasted words. Front-loaded with the key purpose and then details.

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

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

Given no parameters and no output schema, the description fully explains the two return scenarios, making it complete for a simple status check tool.

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

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

No parameters; schema coverage is 100%. Description does not need to add parameter info, so baseline 4 is appropriate.

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

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

Clearly states it returns connection status and URLs, explaining the two scenarios. However, it does not explicitly differentiate from siblings like 'authenticate' or 'openfinance_list_connections'.

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

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

Implies use to check connection status based on response descriptions, but no explicit when-to-use or when-not-to-use guidance nor 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 include readOnlyHint=false, destructiveHint=false, but the description adds significant context: invoke runs tools without installing, may require auth (returns connect link) or payment (checkout link), and writes require owner/admin. It explains the behavior of each action and how invoke works differently from install. 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 somewhat long but packed with valuable information. It is well-structured, starting with the core purpose, then the main flow, followed by key points about invoke vs install, and ending with administrative notes. Every sentence earns its place, but could be slightly more concise without losing meaning.

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, no output schema, multiple actions), the description covers the complete workflow, important edge cases (auth/payment links, owner/admin requirements), and distinguishes between actions. It provides enough context for an agent to select the correct action and parameters, making it highly complete.

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

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

Schema coverage is 0%, meaning no parameter descriptions exist in the schema. The description provides contextual meaning for key parameters like action, mcp_id, tool_id, arguments, and explains their roles in the workflow (e.g., action=search discovers, describe returns profile, invoke runs). However, it does not explicitly detail all 13 parameters (e.g., limit, message, conversation, immediate) and their defaults, leaving some ambiguity. Overall, it adds substantial value but is not exhaustive.

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 official mcp.ai marketplace, describing its core flow of search, describe, invoke, and install. It identifies itself as the primary tool for discovering and running MCPs, distinguishing it from siblings by stating 'use THIS tool FIRST' and listing specific actions like search, describe, invoke, install, etc. The verb+resource is specific: it's a marketplace tool for MCPs and tools.

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

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

The description provides explicit guidance on when to use this tool versus alternatives, stating 'use THIS tool FIRST, before any external/generic registry.' It contrasts invoke (one-off use) with install (permanent addition) and explains when to use other actions like subscribe/cancel, report_bug, request_mcp. It also clarifies prerequisites like workspace owner/admin for writes and handling of auth/payment links.

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 destructiveHint=true and readOnlyHint=false, and the description details effects (data no longer available, returns add_connection_url). Adds context beyond annotations.

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

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

Three sentences, no filler. Front-loaded with the action, efficient and clear.

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

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

Describes outcome and return value, but lacks parameter explanation. Without output schema, the return format is vague. Adequate for a simple tool but incomplete.

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 required string parameter 'item' with 0% coverage. Description does not explain what 'item' represents (e.g., bank identifier), leaving agents to guess.

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 action: revokes Open Finance consent and deletes connection data for a specific bank. Differentiates from sibling tools by specifying the bank disconnection 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?

Implied usage: when you need to disconnect a bank and revoke consent. No explicit when-not-to-use or alternatives mentioned, but the description is adequate for basic understanding.

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 mark readOnlyHint=false (mutation) and destructiveHint=false. The description details the sync behavior, waiting up to 60s, possible terminal states (needs_action, timed_out), and return 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?

The description is detailed yet reasonably concise, front-loaded with the core action. Every sentence adds value, though slightly dense; could be slightly more streamlined but effective.

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

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

Despite no output schema, description fully defines return shape ({ results, errors }) with key fields (status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out). Covers both usage modes and behavior for 2-parameter tool.

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

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

Schema coverage is 0%, but description fully compensates: explains items as 'array of selectors (item_id, connector_id, or connector_name)' and that omitting syncs all; explains wait with 'Set wait: false for fire-and-forget'.

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 forces a sync and waits for completion, using specific verbs and resources. It uniquely distinguishes from sibling tools like openfinance_get_item_status (for checking status) and openfinance_disconnect_bank (for disconnecting).

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

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

Explicitly states when to use ('when a balance or transaction list looks stale'), what it does without disconnecting/reconnecting, and provides guidance on alternatives: 're-check with openfinance_get_item_status' for timed out results, and 'set wait: false for fire-and-forget'.

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

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

Adds significant context beyond annotations: real-time nature, error behavior for CREDIT accounts (structured warning instead of throw), and response shape. No contradictions with readOnlyHint, idempotentHint, or destructiveHint.

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?

Four sentences, each adding value: purpose, input constraint, error behavior, response shape. Front-loaded and 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 simple input, annotations covering safety, and description providing response shape, it is complete. No output schema but description explains results/errors structure. No missing context for typical 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?

Only parameter account_ids has 0% schema description coverage, but the description compensates by specifying 'as an array (1–50)', providing constraints and format guidance 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 returns real-time balance payload per account ID using a specific endpoint. It includes constraints (array of 1-50) and distinguishes from siblings like get_accounts_detail by focusing on balance retrieval.

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

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

Provides clear context on input format (array of account_ids) and error handling for CREDIT accounts. Does not explicitly state when not to use or mention alternatives, but the usage is straightforward for a read-only balance retrieval.

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 read-only, idempotent, and non-destructive behavior. The description adds valuable details about return shape ({ results, errors }) and extended data, enhancing transparency 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?

Two sentences, no wasted words. The first sentence states the core function, the second covers parameter and return shape. Extremely concise and 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?

Given no output schema, the description sufficiently conveys return shape and parameter constraints. Lacks details on error handling but is adequate for a read-only batch fetch 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 coverage, the description compensates by specifying the parameter 'account_ids' as an array of size 1–50, adding crucial semantic info beyond the bare schema.

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

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

The description clearly states it returns full account objects with extended creditData by ID. It hints at batch fetching but does not explicitly differentiate from sibling tools like openfinance_list_accounts, which is a minor gap.

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 provide when-to-use or when-not-to-use guidance. It implies usage via IDs but lacks explicit alternatives or context for selecting this tool over 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 provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds significant behavioral context: batch shape { results, errors }, Pluggy's lack of paid/status field, payments[] nuance. No contradictions.

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

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

Description is moderately lengthy but well-organized. Front-loaded purpose and key details. Could be slightly more concise, but every sentence adds value, including caveats and usage notes.

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

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

No output schema, but description explains return fields and batch shape. Addresses main usage caveats (paid status, payments meaning). Lacks details on error handling or pagination, but sufficient for the tool's simplicity.

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

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

Schema has one parameter (bill_ids) with 0% description coverage. Description adds meaning by clarifying format ('Pass as array') and providing context ('use list function first to discover ids'). This goes beyond schema-only information.

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?

Purpose is clearly stated: returns bill-level detail for credit card bills by id, specifying exact fields (financeCharges, payments). Description distinguishes from siblings like openfinance_list_credit_card_bills and openfinance_list_transactions by noting what it does NOT return.

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

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

Explicitly instructs to first use openfinance_list_credit_card_bills to discover ids. Guides to use openfinance_list_transactions for itemized transactions. Warns about the meaning of payments[] and paid status interpretation.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it's a safe, non-mutating operation. The description adds behavioral context: it returns executionStatus and connector metadata, and details the response structure when omitting item ({ count, items }). This goes beyond annotations, justifying a 4.

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 and status examples, followed by usage variants. Every word is informative with no redundancy. Ideal conciseness for a tool with one parameter.

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 single-parameter schema, presence of annotations, and no output schema, the description is complete. It covers both modes, response structure hints, and the set of status values. An agent can confidently select and invoke this tool without ambiguity.

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

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

Schema coverage is 0%, so the description must compensate. It fully explains the only parameter 'item': omitting it returns all banks, passing it returns a single bank. This adds essential meaning beyond the schema's type definition. The description also hints at the response format, enhancing parameter understanding.

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 the current status of a bank connection, listing specific status values (UPDATED, UPDATING, LOGIN_ERROR), executionStatus, and connector metadata. It distinguishes two use cases: omit item for all banks, pass item for a single bank. This specificity and differentiation from sibling tools (like openfinance_list_connections, which lists connections but not status) earns a 5.

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 omit vs. pass the 'item' parameter, with response format examples. It does not mention when not to use or compare with alternatives, but the two-mode usage is clearly explained. The context is sufficient for an agent to decide based on need.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: the meaning of credit balance is connector-dependent, explains the difference between `name` (legal entity) and `bank` (brand), and describes aggregation behavior when `item` is omitted. 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 lengthy (multiple paragraphs) with detailed explanations. While the complexity justifies the length, some sentences could be streamlined. Front-loading is reasonable, but overall conciseness suffers due to necessary 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?

No output schema, but the description covers the return structure (fields like balance, number, type, bank, connector_id, etc.). It explains edge cases (credit balance dependency, aggregation) and provides enough context for a read-only list tool. Minor gaps like pagination or sorting are not mentioned, but the tool is simple.

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 explains `item` usage (omitting vs passing) and indirectly covers `type` by mentioning BANK and CREDIT. However, it does not explicitly state that `type` filters accounts by that enum value, leaving some ambiguity. Adequate but could be more precise.

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 accounts for a bank connection, listing BANK and CREDIT types with specific fields. It distinguishes from sibling tools like openfinance_list_credit_card_bills, which handles bills, by mentioning that tool for standardized open-bill amounts.

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

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

Explicitly tells when to omit `item` (for all banks) vs pass `item` (single bank). It also warns against treating credit `balance` as current month's bill and directs to another tool for standardized amounts, providing clear usage context and alternatives.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds valuable context: the response is cached for the adapter session, it's a single aggregated response with no batch ids, and it pairs with update transaction category. 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 concise (3 sentences) and front-loads the core purpose. Every sentence adds value: the source, caching, field details, and singular response. 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?

Despite no output schema, the description fully explains the return value structure with field names and semantics (including Portuguese translation). Annotations cover safety. The tool is simple (no params), so completeness is achieved.

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

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

No parameters exist, so schema coverage is 100%. The description adds meaning beyond the empty schema by detailing the structure of each category entry (id, description, parentId, etc.), which aids understanding of the return format. Baseline 4 is appropriate for no-parameter 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 clearly states it returns Pluggy's transaction category taxonomy, cached for the session. It specifies each entry's fields (id, description, descriptionTranslated, parentId, parentDescription) and explicitly connects to a sibling tool (openfinance_update_transaction_category). This distinguishes it from other list tools.

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

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

The description implies the tool should be used when needing the category taxonomy, especially for updating transaction categories. It mentions caching behavior and the single aggregated response. However, it does not explicitly state when not to use it or provide direct comparisons to alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds value by specifying return fields (connector_id, item_id, bank name, add_connection_url) and mentioning the widget integration. No contradictions.

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

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

Single sentence, front-loaded with core functionality, no wasted words. Efficient and clear.

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

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

Given no output schema, description adequately lists key return fields. For a simple list tool with no parameters, it provides sufficient context. Could optionally mention pagination or limits, but not 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?

Number of parameters is 0, and schema coverage is 100%. Description does not need to parameter semantics since there are none. Baseline 4 applies.

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

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

Description clearly states it returns saved bank connections and lists specific fields (connector_id, item_id, bank name, add_connection_url). This effectively distinguishes it from sibling tools like openfinance_list_accounts or openfinance_get_item_status.

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

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

No explicit guidance on when to use this tool versus alternatives, but given it's the only tool for listing connections, the usage is implied. No exclusions or context 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?

Adds extensive behavioral context beyond annotations: payment cycle semantics, derived payment_status logic, open bill opt-in behavior, connector asymmetry, and return warning if product not enabled. No contradiction with readOnlyHint or idempotentHint annotations.

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

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

Well-structured: starts with main purpose, then detailed semantics, caveats, and options. Some redundancy (e.g., repeated explanations of derived payment_status), but overall each section adds value. Could be slightly more concise without losing clarity.

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 high complexity, no output schema, and 0% parameter coverage, the description is remarkably complete. Covers derived fields, edge cases (connector asymmetry, product not enabled), usage scenarios, and links to other tools. Leaves no major ambiguity for an AI agent.

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

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

Schema coverage is 0%, so description must compensate. It describes include_open_bill (opt-in) and account_ids (bulk support), and implicitly account_id. However, page and page_size parameters are not described, leaving gaps for 2 of 5 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 CLOSED credit card bills for a CREDIT-type account, listing specific fields and the derived payment_status. It distinguishes itself from sibling tools like openfinance_get_credit_card_bill (single bill) and openfinance_list_transactions (itemized purchases).

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: when to use derived payment_status vs assume from payments[], when to opt-in for open_bill, connector asymmetry cases, and alternatives (e.g., openfinance_list_transactions for transactions). Includes warnings like 'NEVER call such a bill vencida categorically'.

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

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

Annotations already indicate readOnly and idempotent. Description adds value by detailing the return format including error structure and fields returned (balance, amount, rates, etc.), which annotations don't cover.

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 purpose and concise overall, though slightly verbose in listing fields. Each sentence serves a purpose.

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

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

Provides good context on return values and error handling but lacks parameter documentation. Given no output schema and 4 parameters, it is partially complete but missing important details 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?

Input schema has 4 parameters with 0% description coverage. Description does not explain what each parameter does, only mentions output fields. Fails to add meaning beyond schema definitions.

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

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

Description clearly states it returns investment portfolio for a connection, listing specific types like FIIs, stocks, ETFs, etc. Distinguishes from sibling tools by specifying it's for portfolio listing, not 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?

Implies usage for listing investments when INVESTMENTS product enabled, and mentions error handling. However, does not explicitly state when to use vs alternatives like openfinance_list_investment_transactions.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds value by detailing the returned fields (quantity, value, expenses breakdown) 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?

Three concise sentences: first defines purpose and output, second provides usage prerequisite, third mentions bulk support. Front-loaded with key information, 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?

The description covers the main functionality, prerequisite, and bulk support. Missing details on pagination parameters (page, page_size) but otherwise adequate for a read-only list tool without output schema.

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

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

Schema description coverage is 0%. The description explains the purpose of investment_id and mentions investment_ids for batch, but does not describe page or page_size parameters, leaving their meaning and usage unclear.

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 a specific investment position, enumerates transaction types (BUY/SELL/TAX etc.), and specifies the prerequisite of calling openfinance_list_investments first, distinguishing it from sibling tools like 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 tells the agent to use after openfinance_list_investments to get the investment_id, and mentions bulk support. However, it does not explicitly exclude other use cases or compare to similar sibling tools like openfinance_list_transactions.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. The description adds that multiple connections are queried sequentially with rate-limit spacing and returns {results, errors} per connection, which is beyond annotation info.

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 three sentences, front-loaded with the main purpose. Minor verbosity could be trimmed, but overall efficient.

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

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

Given no output schema, the description explains the return format ({results, errors}). It covers the two usage modes. Missing details on error types or exact rate-limit behavior, but adequate 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?

The input schema only says items is an array of strings (0% coverage). The description adds meaning: each string is a connection selector (item_id, connector_id, or connector_name). This compensates for the lack of 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?

The description clearly states it lists loan contracts per bank connection, specifies the HTTP method (GET /loans), and distinguishes two modes (with items for specific connections or omit for all linked banks). This is specific and differentiates from sibling list tools.

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

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

The description explains when to pass 'items' (for specific connections) and when to omit (for all linked banks). It does not explicitly mention when not to use or compare to alternatives, but the two modes provide clear usage context.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds extensive behavioral context: CREDIT PENDING/POSTED variance, auto-pagination up to 5000 with truncation warning, error handling (returns error object), detail levels, and upstream behavior. 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?

Long but well-structured: main purpose first, then CREDIT specifics, pagination, error handling, detail options, bulk support. Each sentence adds value. Could be slightly shorter but given complexity, 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?

Comprehensive for a complex tool: covers two account types, pagination nuances, error handling, detail levels, linking to bills, and fallback to other tools. No output schema, but description implies return structure. Addresses edge cases like truncated and isUpdated false.

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 carries full burden. It explains all 8 parameters: account_id (required), to/from (ISO dates), page (pagination control), detail (enum with behavior), page_size (max 500), account_ids (bulk), search_queries (case-insensitive substring OR semantics). Adds meaning beyond schema.

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

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

The description clearly states it returns transactions for bank accounts (BANK or CREDIT type) and explicitly distinguishes from sibling tools like openfinance_list_credit_card_bills, noting that for CREDIT accounts it's the only way to get 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 (e.g., for CREDIT accounts), when-not (use openfinance_list_credit_card_bills for standardized totals), and alternatives (openfinance_list_accounts for closing dates). Also gives pagination guidance and connection health checks.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral details: it resolves accounts internally and fans out transactions, caps scanning at 5000/account with truncated:true flag, and explains default vs raw granularity with detailed output structure. No contradictions with annotations.

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

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

The description is well-structured with front-loaded purpose, but it is somewhat lengthy. It packs many details in a dense paragraph, making it harder to scan quickly. However, every sentence adds value and no information is redundant, so it earns a 4 rather than a 5.

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 thoroughly explains the response: 'total entradas, saídas, saldo_liquido, monthly evolution (por_mes), top_despesas/top_recebimentos, per-account breakdown'. It also covers edge cases like truncation and different detail levels. Everything an agent needs to understand the tool's behavior and output is present.

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 fully compensates. It explains every parameter: 'item' accepts connector_id/connector_name/item_id or omit for all; 'from'/'to' are ISO dates; 'granularity' defaults to monthly; 'detail' options 'compact', 'rich', 'raw' are described; 'top_n' is implied as 'largest N each'; 'type' filters BANK or CREDIT. This adds complete meaning beyond the minimal 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 uses specific verb 'Consolidated cash-flow analysis' and explicitly states the resource: 'whole bank CONNECTION over a period, in ONE call'. It distinguishes from siblings by noting it resolves accounts internally, avoiding the need to call openfinance_list_accounts, which sets it apart from more granular tools.

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

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

The description clearly states when to use: for 'annual/monthly analysis', 'cash flow', 'entradas and saídas', 'largest expenses/receipts'. It also explicitly says when NOT to call other tools: 'you do NOT need to call openfinance_list_accounts first'. It provides guidance on parameter choice, such as using granularity:'raw' only when itemized rows are needed, and omitting 'item' to analyze all linked banks.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. Description adds valuable context: it checks a public status page, returns global indicator, degraded components, 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, front-loaded with purpose, then usage guidance, then return details. 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?

Tool has no parameters or output schema; description fully covers purpose, usage, and return structure, making it complete for this simple status-check tool.

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

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

No parameters exist, so description doesn't need to add parameter info. Baseline 4 for zero params; description remains focused on return value 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 checks the LIVE operational status of the Open Finance provider, distinguishes it from sibling 'openfinance_get_item_status', and specifies when to use it (when data seems incomplete despite updated 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?

Explicitly tells when to use the tool (data incomplete/stale despite updated connection) and contrasts with an alternative tool. Does not explicitly state 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 already indicate read-only and idempotent behavior. The description adds that keywords are required (with a hint if omitted), honors user plan, and surfaces caveat warnings for certain connectors, providing valuable extra 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 detailed but well-structured, front-loading the core functionality. Each sentence adds useful information, though slightly verbose.

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

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

Given no output schema, the description explains essential return fields and caveats. It covers usage context, plan integration, and the required nature of keywords, making it sufficient for effective use.

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

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

Schema coverage is 0%, but the description explains both parameters: keywords array with example values and include_accounts for including accounts. It clarifies that keywords is required despite schema not marking it required.

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 searches bank connectors by name, returns specific fields like id, access, audience, and connect_url. It distinguishes from sibling tools like openfinance_list_connections by focusing on search with keywords.

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 instructs to call this before connecting, provides keyword usage with examples, and mentions plan-based filtering. It does not explicitly state when not to use, but the context is clear.

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

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

Discloses key behaviors beyond annotations: PATCH non-idempotent, overrides automatic categorization, teaches Pluggy via Category Rule creation, and batch error handling (per-item errors do not fail whole batch). 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?

Well-structured and front-loaded. Every sentence adds value. Slightly long but justified given the complexity of batch behavior and side effects. Could be trimmed slightly without losing meaning.

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

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

Given no output schema, the description covers the response shape and error handling. Addresses parameters, behavior, return values, and side effects. Fully sufficient for an agent to select and invoke the tool.

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

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

Despite 0% schema description coverage, the description fully explains both parameters: transaction_id source and category_id source. Also details the batch request structure and response shape, compensating 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?

Clearly states the verb (corrects), resource (category of transactions), and HTTP method (PATCH). Distinguishes from sibling tools by referencing input sources (openfinance_list_transactions, openfinance_list_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?

Provides clear when-to-use guidance ('fix miscategorized transactions') and explains the side effect of creating a Category Rule. References related tools for obtaining IDs. Could explicitly state when not to use, but context is sufficient.

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

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

Annotations already indicate idempotent (idempotentHint=true) and non-destructive (destructiveHint=false). The description adds that the conversation array should be included for reproduction, which is useful behavioral context, but does not fully describe side effects or constraints.

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

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

The description is concise (two sentences) with no fluff. It front-loads the core purpose. The only minor issue is that the second sentence could be integrated, but overall efficient.

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

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

Given the complexity (3 params, no output schema), the description is incomplete. It focuses on only one parameter (conversation) and does not mention return value or confirmation of submission. The required 'message' parameter is not elaborated.

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 explains the 'conversation' parameter (array of recent messages) but does not describe 'context' or 'message' beyond their presence in the schema.

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

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

The description clearly states the tool's purpose: reporting bugs, missing features, or sending feedback. It uses a specific verb ('Report') and resource ('bug'), and is distinctly different from sibling tools, which are unrelated.

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

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

The description does not provide guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites beyond including the conversation array.

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. Description adds resource detail but no behavioral traits beyond that.

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

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

Single, front-loaded sentence with no extraneous words. Every word 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 parameters and comprehensive annotations, the description fully covers what the tool does. Output schema is unnecessary for a version display.

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; description adds no param info, but baseline is 4 for zero-param tools.

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

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

Clearly states verb 'show' and resource 'current MCP platform and adapter versions', distinguishing it from siblings like 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?

Implicit context for version retrieval, but no explicit guidance on when to use versus alternatives. Still clear for a simple tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by specifying the exact content of the state (installed MCPs, connection status, catalog tool counts), enhancing understanding 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 sentence that is front-loaded with the verb 'Returns' and the resource 'current toolkit state'. Every word is necessary and there is no redundancy.

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

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

For a zero-parameter tool with comprehensive annotations, the description fully covers what the tool returns. No additional information is needed for correct selection and 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?

There are no parameters, and schema coverage is 100%. Per guidelines, baseline for 0 params is 4. Description does not need to add parameter info.

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

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

The description clearly states the tool returns the current toolkit state, including installed MCPs, connection status, and catalog tool counts. It is specific and distinguishes itself from siblings (e.g., authenticate, connect) that 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 provides clear context for when to use (e.g., to inspect toolkit state) but does not explicitly mention when not to use or list alternatives. However, given the sibling tools are unrelated, the need for exclusions is low.

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