ASA MCP

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

Annotations provide idempotentHint=true, and the description adds behavioral context: permanent vs. session login, and the two modes of operation (with or without token). No contradictions. It could mention side effects or response, but overall adds value beyond annotations.

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

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

The description is a single paragraph but is dense and front-loaded with the main purpose. Every sentence adds value, though slightly more structured formatting (e.g., bullet points) could improve readability. Still, it is concise and to the point.

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 tool has low complexity (one optional parameter, no output schema). The description covers the main usage scenarios (with and without token, permanent vs. session). It does not describe the return value, but for an authenticate tool the response is somewhat implied. Overall, it is functionally 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 has 0% coverage with no description for the 'token' parameter. The description fully explains that the token is an optional JWT for session login, and that omitting it returns a link. This adds essential meaning beyond the bare schema.

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

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

The description clearly states the tool is for authentication of IDE agents via browser login and token capture. It specifies the verb 'log in' and the resource 'access token', and distinguishes from siblings like 'connect' by focusing on token-based 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 explicitly explains when to use the tool (to get a login link or pass a token) and gives a best practice (adding to config for permanent connection). It lacks explicit when-not-to-use guidance but the context is clear enough.

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

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

Adds behavioral context beyond annotations: explains that when all providers are connected, returns authenticated:true and empty pending[]; when credentials missing, returns connect_url and per-install URLs. This informs the agent about possible outcomes and the meaning of the returned fields.

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

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

Two sentences, front-loaded with the main purpose. Every sentence adds value—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?

Sufficiently complete for a simple status tool with no output schema. It covers the two main states and what is returned. Could potentially mention error cases, but not necessary given 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?

No parameters, so baseline of 4 applies. The description adds no parameter info, but that's acceptable since there are none to describe.

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?

Specifically states 'Returns connection status and URLs', clearly distinguishing from sibling tools like authenticate and openfinance_list_connections. It names the resource (connection status) and the action (return status/URLs).

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?

Describes when to use by detailing two states: all providers connected vs. missing credentials. Though it doesn't explicitly say when not to use alternatives, the context makes it evident that this is for checking overall connection status, not per-provider details.

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 works for uninstalled MCPs, returns connect links for auth or checkout links for payment, and requires retry. Annotations marked readOnlyHint=false and destructiveHint=false, and the description aligns with that, adding 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?

The description is lengthy but well-structured with clear flow and key points highlighted. Every sentence adds value, though it could be slightly more condensed without losing information. The front-loading of purpose and usage aids agent comprehension.

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

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

Given the tool's complexity (13 parameters, multiple actions, no output schema), the description is comprehensive. It covers core flow, edge cases for auth and payment, and distinguishes invoke from install. It addresses what the tool does, when to use, and how to use it, leaving no critical gaps.

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

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

With 0% schema coverage and 13 parameters, the description compensates well by explaining actions, their roles, and implying parameter usage (e.g., query for search, mcp_id for describe, arguments as JSON). However, some parameters like limit, tier_slug, or immediate are not explicitly detailed, leaving minor gaps.

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

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

The description clearly states it is the official marketplace for MCP tools, explaining its role as the primary catalog and execution platform. It distinguishes from siblings by positioning itself as the first tool to use for finding and running MCPs, while siblings like authenticate or openfinance_* 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 explicitly instructs to use this tool first before any external registry. It provides a core flow (search → describe → invoke) and differentiates between invoke (one-off) and install (permanent). It also notes that writes require workspace owner/admin, giving clear when-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?

The annotations already indicate destructiveHint=true, so the agent knows it is destructive. The description adds specific behavioral context: it revokes consent, deletes data, and returns a re-connect URL. This goes beyond the annotations and provides useful details about the mutation's effects and recovery option.

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, concise and front-loaded. Every sentence adds essential information: first states the action, second describes return 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?

The description covers the tool's purpose, effect, and return value adequately, given the destructive annotation and single parameter. However, it fails to explain the 'item' parameter, which is a significant gap. For a simple tool with no output schema, the description is mostly complete but lacking parameter documentation.

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

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

The input schema has one required parameter 'item' with type string and no description. Schema description coverage is 0%. The tool description mentions 'specific bank' but does not explicitly state that 'item' identifies the bank or provide any format or examples. Thus, the description adds no meaningful parameter semantics.

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. It specifies the consequence (data no longer available) and the return value (add_connection_url). This distinguishes it from sibling tools like connect or authenticate.

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

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

The description implies the tool is used to disconnect a bank, which contrasts with sibling 'connect'. However, it does not explicitly state when to use or not use this tool, nor does it mention alternatives or prerequisites. The guidance is present but not fully explicit.

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 only set readOnlyHint=false, so the description carries full burden. It discloses that the tool triggers a sync, polls up to ~60s, returns results with status fields, and explains outcomes like needs_action and timed_out. 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 well-structured with front-loaded action and clear separation of details. It is moderately long but every sentence adds value. Minor redundancy (e.g., 'NOW' emphasis) but not wasteful.

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

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

Given two parameters and no output schema, the description fully explains return structure and key statuses. It fits well within the context of sibling tools. A bonus point for covering timeouts and error conditions, but no mention of authentication or error handling beyond status codes.

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 add meaning. It explains both parameters: wait (fire-and-forget) and items (array of selectors, can be omitted for all). It adds context on how to use items but does not detail exact selector formats, which keeps it from a 5.

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 action: 'Forces the bank to re-sync one or more connections NOW and WAITS for it to finish'. It uses specific verbs and resources ('re-sync', 'connections', 'polls'), and distinguishes from sibling tools like openfinance_get_item_status by noting when to use that alternative.

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 when-to-use guidance ('when a balance or transaction list looks stale'), explicitly says what to pass (omit for all banks, or provide selectors), and mentions the wait=false option for fire-and-forget. It also tells when to use an alternative ('re-check with openfinance_get_item_status').

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds real-time behavior, error handling for credit accounts (returns warning instead of throwing), and response shape. This adds valuable behavioral context beyond annotations.

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

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

Three concise sentences covering purpose, usage constraints, error behavior, and response shape. No filler, well-structured for quick parsing.

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 set and absent output schema, the description covers the essential behavior (balance retrieval, error handling, response structure). Lacks detail about response fields (e.g., currency, date) but provides a reasonable overview.

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 specifies account_ids as an array (1-50) and implies they are account identifiers. This adds meaning beyond the bare schema type, though it could clarify the ID format.

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

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

The description clearly states it returns real-time balance per account ID, mentions the REST endpoint, and distinguishes it from sibling tools like list_accounts or get_accounts_detail which cover different functionality.

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: use when you have account IDs and need balances. Provides constraints (1-50 IDs) and error handling for credit accounts. However, no explicit when-to-use or alternatives guidance, leaving the agent to infer from 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=true and idempotentHint=true. Description adds batch return shape { results, errors } and endpoint method, but no additional behavioral traits beyond what annotations imply.

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 fluff. First sentence states purpose, second gives usage and output shape. Efficiently 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?

For a simple retrieval tool with one parameter and no output schema, the description covers input constraints, endpoint, and return format. Complete given the context.

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

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

Schema has 0% description coverage. Description adds that account_ids is an array with 1-50 items, which provides necessary semantic guidance 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 returns full account objects including extended creditData for specific IDs. It distinguishes from sibling tools like openfinance_list_accounts by specifying detailed per-ID 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?

Describes input constraints (array of 1-50 IDs) but does not explicitly compare with siblings or state when not to use it. However, the context is clear enough for a retrieval 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 provide readOnlyHint: true, idempotentHint: true, destructiveHint: false. Description adds valuable behavioral context: batch shape {results, errors}, no paid/status field, and detailed explanation of payments array semantics (do NOT assume this bill was paid). 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 a dense paragraph but front-loads the purpose. No wasted words, but could be slightly more structured (e.g., bullet points). Still concise given the wealth of information.

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

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

Given no output schema, description thoroughly covers output shape, fields (financeCharges, payments with subfields), and critical behavioral notes about Brazilian Open Finance. Integrates well with sibling tools (list_credit_card_bills, list_transactions) for a complete picture.

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. Clearly explains the single parameter bill_ids: an array of strings, how to discover valid ids, and that it must be passed as an array. Provides complete 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?

Clearly states it returns bill-level detail for credit card bills by id, explicitly distinguishes from sibling tools by specifying it does NOT return individual transactions and directs to openfinance_list_transactions for that. Includes fields (financeCharges, payments) and batch shape.

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

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

Explicitly says when to use (with bill_ids) and when not to (for itemized transactions). Advises using openfinance_list_credit_card_bills first to discover ids. Provides caveat about payments array meaning and Pluggy behavior, and suggests alternative tool for paid status.

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

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

Annotations declare readOnlyHint, idempotentHint, destructiveHint. The description adds the return fields (status, executionStatus, connector metadata) and the different response shapes for single vs. all banks, with 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, no wasted words. Key information is front-loaded with return types and conditions for parameter use.

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

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

Given no output schema, the description provides reasonable shape for both modes ('{ count, items }' for all, implied single object for item). Somewhat brief but sufficient for agent invocation.

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

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

The input schema has one parameter 'item' with 0% coverage. The description fully explains its semantics: omitting returns all banks, passing returns a single bank. 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 specifies the verb 'Returns' and the resource 'status of a bank connection', listing example statuses. It clearly distinguishes between fetching all banks and a single bank, differentiating it from siblings like openfinance_list_connections.

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

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

The description explains when to omit vs. pass the 'item' parameter, which is a mode of operation. However, it does not provide guidance on when to use this tool over siblings such as openfinance_list_connections or openfinance_provider_status.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds valuable behavioral context: aggregation behavior when item is omitted, return of bank/connector_id/item_id, and the connector-dependent meaning of credit balance. No contradictions with annotations. Could mention pagination/limits, but not essential for a list tool with no schema.

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 main purpose and key details. It is long but every sentence adds value—no filler. Minor room for compression (e.g., combining some caveats) but still well-structured and easy to parse.

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

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

Even without an output schema, the description enumerates all return fields (balance, number, type, subtype, bankData, creditData, bank, connector_id, item_id) and explains their semantics. It also covers edge cases (credit balance interpretation, bank naming) and references alternative tool for further details. Complete for the tool's role.

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% with 2 parameters having no descriptions. Description fully compensates: explains that 'item' filters to a single bank (and response structure changes), and 'type' enum values (BANK/CREDIT) are explained. Also adds nuance about 'name' vs 'bank' field. Provides complete parameter semantics.

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 tool returns accounts for bank connections (BANK/CREDIT) with balance, type, and other fields. It distinguishes from sibling tools like openfinance_list_credit_card_bills by noting credit balance limitations and directing to that tool for standardized amounts. Also differentiates from openfinance_get_account_balance and openfinance_get_accounts_detail.

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

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

Explicitly tells when to omit 'item' (to list across all banks) vs pass it (target single bank). Warns against treating credit balance as this month's bill and directs to openfinance_list_credit_card_bills for standardized open-bill and total debt. Provides clear context for user intent.

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

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint, confirming safe side-effects. The description adds behavioral details: caching, single aggregated response, and field semantics. No contradiction with annotations.

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

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

The description is concise (3 sentences) and front-loaded with the main purpose. Every sentence adds value, though the field list could be tighter. 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?

Despite no output schema, the description explains the return format (id, description, etc.) and caching behavior. For a simple, zero-parameter tool, this is sufficient context 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?

No parameters exist; schema coverage is 100% trivially. The description adds no parameter info, which is acceptable. Baseline for zero parameters is 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 identifies the tool as returning Pluggy's transaction category taxonomy, specifying it is cached and includes key fields like id and description. It distinguishes from sibling list tools by highlighting its role in transaction category management.

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 before updating transaction categories via 'openfinance_update_transaction_category', referencing the id. It clarifies caching and lack of batch ids, but does not explicitly state when not to use it or compare 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=true, idempotentHint=true, destructiveHint=false. The description adds value by detailing the return fields and the add_connection_url for linking banks, enhancing transparency beyond annotations.

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

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

Single sentence, front-loaded with the main action ('Returns...'), no unnecessary 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?

For a simple list tool with no parameters and no output schema, the description covers the essential return information and the URL feature, making it complete for an 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?

There are no parameters; schema coverage is 100%. The description need not add parameter semantics, effectively fulfilling the dimension.

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

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

The description clearly states the tool returns saved bank connections and lists specific fields (connector_id, item_id, bank name, add_connection_url), distinguishing it from sibling list tools like openfinance_list_accounts.

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

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

No explicit when-to-use or when-not-to-use guidance is given. The purpose is clear but does not mention alternatives or exclusions; usage is implied by the description.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds significant behavioral context: payment timing, cross-bill matching, derived payment_status logic, and connector asymmetry for open_bill.

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

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

The description is very long and dense with detailed caveats and logic. While necessary for the complex domain, it could be more structured 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?

Despite missing output schema, the description comprehensively covers return fields (payments, payment_status, open_bill), including fallback behavior and error cases, making it complete for the domain.

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

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

Schema has 0% description coverage, but the description compensates by detailing include_open_bill and account_ids. Page and page_size are not explained, but their meaning is standard.

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

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

The description clearly states the tool returns CLOSED credit card bills for CREDIT-type accounts with specific fields, and distinguishes from siblings like openfinance_get_credit_card_bill 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?

Provides explicit when-to-use guidance, including the Brazilian Open Finance payment semantics, when to use derived payment_status, the include_open_bill opt-in, and alternatives for 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by describing error handling behavior: it returns { total:0, results:[], warning } instead of throwing errors when INVESTMENTS is not enabled or on upstream errors. This 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 paragraph but efficiently conveys the main purpose, return fields, and special behavior. It front-loads the essential verb and resource. Slightly dense but still 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 the tool has 4 parameters with no schema descriptions, no output schema, and moderate complexity, the description covers the return structure and error handling but lacks parameter documentation and output format details. It is adequate but not complete.

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

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

The input schema has four parameters (item, page, type, page_size) with 0% description coverage in the schema. The description does not explain any parameter; it only lists the possible values for the 'type' enum implicitly through the asset type list. No parameter-level guidance is provided.

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 (FIIs, stocks, ETFs, etc.) and fields like balance, amount, rates, etc. This makes the purpose immediately clear and distinguishes it from siblings such as openfinance_list_investment_transactions.

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

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

The description explains what the tool does but does not explicitly state when to use it versus alternatives like openfinance_list_investment_transactions or openfinance_list_accounts. There is no mention of prerequisites or context for usage, only a list of asset types.

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, idempotentHint=true, destructiveHint=false. The description adds useful behavioral context by detailing the output fields (quantity, value, expenses, etc.) and bulk execution capability, but does not mention pagination behavior or error handling.

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 and front-loaded with the core purpose and transaction types, followed by output details and usage hints. No redundant sentences, though it could be slightly more structured with bullet points.

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 4 parameters and no output schema, the description provides good detail on returned fields and bulk support, but lacks explanation of pagination, error conditions, or limits on batch size. This gap reduces completeness for a tool of moderate 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?

Schema coverage is 0%, so the description must compensate. It explains the investment_id and investment_ids parameters (via usage hint and bulk support note) but does not describe page and page_size, which are essential for pagination. This partial coverage leaves room for agent confusion.

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, listing transaction types (BUY, SELL, TAX, etc.). It distinguishes from siblings by specifying it is for investment transactions and referencing the prerequisite tool openfinance_list_investments.

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 guides usage by stating 'Use after openfinance_list_investments to get the investment_id' and mentions bulk support via investment_ids. However, it does not compare with other transaction-listing tools to specify when to use this one.

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), description reveals sequential querying with rate-limit spacing and return format '{ results, errors }' per connection. Adds valuable 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?

Three sentences, front-loaded with purpose, no wasted words. Efficient 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, description explains return format and parameter behavior comprehensively. Rate-limit spacing adds important operational context. Fully informative 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?

Adds complete meaning to the only parameter 'items': explains it's an array of connection selectors (item_id uuid, connector_id, or connector_name). With 0% schema coverage, description fully compensates.

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?

States 'Lists loan contracts per bank connection' with specific verb and resource, and includes HTTP method. Clearly distinguishes from sibling tools like openfinance_list_accounts or openfinance_list_transactions by targeting 'loans'.

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

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

Provides clear context on when to pass 'items' (for specific connections) vs omit (for all linked banks). Mentions sequential fetching with rate-limit spacing but does not explicitly compare to alternative 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 provide readOnly and idempotent hints; description adds extensive behavioral details: pending vs posted varies by bank, search aggregates up to 5000 transactions, error handling returns object with warning/error, bulk support, and correlation to bills via creditCardMetadata.billId.

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 long but each sentence adds value. It's structured with main purpose first, then specific behavior for CREDIT, then details on filtering, error handling, and bulk. Could be slightly more concise, but appropriate for a complex tool.

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

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

Covers parameter semantics, error handling, bulk support, relationship to sibling tools, and troubleshooting. Missing detailed return structure (e.g., fields of transaction objects), but still fairly complete given no output schema.

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

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

Input schema has 0% description coverage, so description bears full burden. It explains from/to as ISO YYYY-MM-DD date filters, pagination with max 500/page, search_queries as case-insensitive substring OR match, and account_ids for batch. This adds meaning to all 7 parameters.

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

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

Clearly states it returns transactions for BANK or CREDIT accounts. Distinguishes from sibling tools like openfinance_list_credit_card_bills by noting it's the only way to get itemized transactions for CREDIT accounts, and for standardized totals use the bills tool.

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

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

Explicitly says when to use this tool (for CREDIT itemized transactions, for BANK accounts) and when to use openfinance_list_credit_card_bills instead. Also advises checking openfinance_get_item_status if total is 0 for CREDIT accounts.

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 destructiveHint=false. The description adds rich behavioral details: internal account resolution, transaction fan-out, scanning cap at 5000/account with truncation flag, and default compact summary with monthly evolution and top expenses/revenues. 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 fairly long but front-loads the main purpose. It is packed with useful information, though a more structured format (e.g., bullet points) could improve readability. Still, every sentence contributes 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?

Despite no output schema, the description explains the response structure (total entradas/saídas, saldo_liquido, monthly evolution, top expenses/revenues, per-account breakdown) and the truncation flag. It covers most aspects but could mention error handling or invalid item cases.

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

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

Schema description coverage is 0%, but the description thoroughly explains all 6 parameters: item (connector_id/connector_name/item_id or omit for all), from/to (ISO dates), granularity (monthly vs raw), type (BANK or CREDIT), and top_n (largest N). It also states defaults like monthly granularity.

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 provides 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call' and distinguishes it from siblings like openfinance_list_transactions by noting that it internally resolves accounts, eliminating the need for prior account 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 explicitly lists use cases ('análise anual/mensal', 'fluxo de caixa', etc.), provides guidance on when to use raw granularity ('only when itemized rows are needed'), and contrasts with the alternative of calling openfinance_list_accounts first.

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 explaining the tool checks a public status page (live but safe) and detailing what it returns (global indicator, degraded components, incidents). No contradictions; the description enriches the behavioral context beyond the annotations.

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

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

The description is slightly long but front-loaded with purpose and usage. It efficiently communicates key information in three sentences. Minor redundancy in the last sentence could be tighter, but overall it is well-structured and avoids unnecessary content.

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

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

Given no output schema, the description fully explains return values: global indicator, degraded components, open incidents, and your_banks_affected. It also covers when to use the tool. No additional information is needed for a simple, no-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?

The tool has no parameters, so schema coverage is 100%. The description does not need to add parameter info. It instead explains the output and usage, which is sufficient for a no-parameter tool. Baseline score of 4 is appropriate.

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

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

The description clearly states the tool checks the provider's live operational status, using the verb 'Checks' and specifying the resource as the provider's public status page. It explicitly distinguishes itself from the sibling tool 'openfinance_get_item_status' by stating this is the provider's health separate from the connection's 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?

The description provides explicit when-to-use guidance: 'Use it whenever data looks incomplete or stale even though a connection shows UPDATED...'. It also clarifies that it helps differentiate provider-side problems from connection issues, giving clear context for choosing this tool over alternatives like reconnecting.

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 valuable context: honor user's plan, behavior when keywords empty, and that it returns a connect_url. 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 dense information, front-loaded purpose. No filler words, but the first sentence is long and could be slightly clearer with punctuation.

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

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

No output schema, but description fully explains return fields per match, plan filtering, and behavior without keywords. Enough for an agent to use confidently.

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 parameters. It explains keywords[] as array of bank names (required, though schema says not required) and include_accounts as flag to include accounts. Good compensation for missing schema docs.

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 and returns specific fields (id, access type, audience, linked connections, connect_url). It distinguishes from sibling tools like openfinance_list_connections by focusing on searching available connectors for pre-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 says 'Call this BEFORE connecting' and explains that keywords[] is required and without it returns a hint. Mentions plan filtering but does not explicitly state when not to use it or compare 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?

Beyond annotations (readOnlyHint=false, etc.), the description details that the tool overrides automatic categorization and creates Category Rules, and explains that per-item errors do not fail the batch. This provides rich behavioral context.

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

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

The description is efficient, conveying purpose, parameters, side effects, and error behavior in a single paragraph. While it could benefit from slight restructuring (e.g., bullet points), it remains clear and not overly verbose.

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

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

Given the simple parameter schema and absence of output schema, the description fully covers input requirements, output shape, side effects, and error handling, making it 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?

Despite 0% schema description coverage, the description fully explains the 'items' parameter structure, sources for transaction_id and category_id, and the expected response shape, adding far more meaning than the schema alone.

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: correcting transaction categories via PATCH /transactions/:id. It distinguishes itself by referencing related tools for obtaining transaction IDs and category IDs, and explains the side effect of creating Category Rules.

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

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

The description provides explicit usage context: fix miscategorized transactions and improve future categorization. It explains batch behavior and side effects, but does not explicitly state when not to use or mention alternative 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 indicate readOnlyHint=false, openWorldHint=false, idempotentHint=true, destructiveHint=false. The description adds that this tool sends feedback, which aligns with idempotent and non-destructive behavior. No contradictions, but it does not elaborate on side effects or communication process.

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

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

The description is two sentences, front-loaded with the core purpose, and contains no redundant information. 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?

For a simple bug-reporting tool with no output schema, the description adequately covers the main usage and provides a key instruction (include conversation array). It could mention return behavior or confirmation, but is mostly 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?

With 0% schema coverage, the description partially compensates by explaining that 'conversation' should hold recent messages for reproduction. However, it does not describe the 'context' parameter, leaving its meaning unclear. The 'message' parameter is implied by context.

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

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

The description clearly states the tool's purpose: 'Report a bug, missing feature, or send feedback.' It uses a specific verb (report) and resource (bug/feature/feedback), distinguishing it from siblings focused on authentication and financial operations.

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

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

The description implies when to use (when reporting issues) and instructs to include the conversation array, but it does not explicitly state when NOT to use or suggest alternatives. The guidance is limited to the reproduction hint.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds context by specifying what versions are shown (platform and adapter). No behavioral contradictions; safe and idempotent nature is implied.

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

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

Single sentence of 9 words, front-loaded with the verb, and no superfluous information. Every word contributes to 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?

The description is adequate for a simple tool with no parameters and annotations covering safety. However, without an output schema, a hint about the return format (e.g., object or string) 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?

With 0 parameters and 100% schema coverage, baseline is 4. The description adds meaning by specifying the tool's output scope (platform and adapter versions), compensating for the lack of an output 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 shows version information, with specific verb 'show' and resource 'MCP platform and adapter versions'. It is distinct from sibling tools which focus on authentication, connection management, or finance operations.

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

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

No explicit guidance on when to use this tool versus alternatives like toolkit_info. The context implies it is for retrieving version info, but differentiation from similar info tools is missing.

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, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds value by specifying what the returned state includes (MCPs, connections, catalog counts), going beyond the structured annotations. No contradictions.

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

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

Single sentence of 18 words, front-loaded with 'Returns the current toolkit state'. Every word earns its place, no fluff or redundancy. Highly efficient.

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

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

For a zero-parameter info retrieval tool with comprehensive annotations and no output schema, the description fully states what the tool returns. No additional context is needed for correct 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?

There are no parameters (schema coverage 100%), so the description doesn't need to add parameter details. Baseline for zero parameters is 4, and the description does not repeat schema information, maintaining clarity.

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 current toolkit state, specifying three distinct pieces of information: installed MCPs, connection status, and catalog tool counts. It uses a specific verb ('Returns') and resource ('toolkit state'), and the information distinguishes it from sibling tools which are almost all action-oriented (authenticate, connect, etc.).

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

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

The description implies usage for inspecting toolkit state due to its read-only nature and the details it promises. It doesn't explicitly mention when not to use or alternatives, but the sibling tool names (all actions like authenticate, connect) make it clear this is a diagnostic/status tool. A brief 'Use this to inspect the current toolkit configuration' would be stronger, but the context is sufficient.

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