Neon MCP

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

Annotations already indicate idempotentHint=true and destructiveHint=false. Description adds context about token handling and non-expiring connections, but omits details like error responses or side effects like token validation.

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?

Front-loaded with purpose, efficient sentences. Slightly verbose but every sentence adds value. Could combine some phrases.

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 moderate complexity and no output schema, description covers the main authentication flows. Lacks details on return values or error scenarios, but sufficient for an authentication tool.

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

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

Schema has 0% description coverage for the single parameter 'token'. Description compensates by explaining the token is a JWT and how to use it with or without the argument.

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

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

The description clearly states the tool authenticates the user via a browser login and token. It distinguishes from siblings like 'connect' by focusing on token-based auth, but could be more explicit about scope.

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

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

Provides clear when-to-use guidance: permanent config vs session-only. Does not list exclusions or alternatives like 'connect', but context signals and sibling list help.

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 behavior. Description adds value by detailing the different response states (authenticated vs. missing credentials) and the URLs returned.

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, zero waste. Front-loaded with purpose, then explains key states. Extremely concise and informative.

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 adequately covers return values for all relevant states. Simple tool, complete description.

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

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

No parameters exist, so schema coverage is 100%. Description does not need to add param info but effectively explains the behavior expected from a parameterless call.

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 connection status and URLs, with examples of successful and missing credential scenarios. Distinguishes from siblings like authenticate and provider_status by focusing on connection check.

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?

Explains when to use (checking connection status) and what the return values mean in different states. Does not explicitly exclude sibling tools 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 are limited (readOnlyHint=false, openWorldHint=true, etc.). The description adds critical behavioral details: invoke works even if MCP is not installed, does not bloat toolkit, returns connect/checkout links when needed, and writes require owner/admin. This goes well beyond the annotations, though some details about idempotency or destructiveness could be clearer.

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

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

The description is a single dense paragraph containing all information. It lacks structure like bullet points or sections, making it hard to parse quickly. While it is front-loaded with the main purpose, the volume of details reduces conciseness.

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

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

Given the tool's complexity (13 params, no output schema, multiple actions), the description covers core workflow, action purposes, permission levels, and error scenarios. It does not describe the response format or parameter constraints, but overall completeness is high for an AI agent's invocation needs.

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 13 parameters. The description explains the 'action' enum and the roles of 'mcp_id', 'tool_id', 'arguments', etc., but does not provide detailed descriptions for each parameter. For a tool with many parameters, this is insufficient to guide correct parameter usage without additional schema documentation.

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

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

The description clearly states the tool is the MCP marketplace catalog and execution platform. It lists multiple actions (search, describe, install, invoke, etc.) and specifies that it should be used FIRST for capability discovery, distinguishing it from sibling tools like authenticate or connect.

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

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

Provides explicit when-to-use guidance: 'use THIS tool FIRST' before external registries. Outlines the core flow (search → describe → invoke) and differentiates between permanent install and one-off invoke. Also mentions permission requirements for write actions and error handling for credentials/payment.

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 destructiveHint: true. Description adds specific behaviors: revokes consent, deletes data, returns reconnection URL. 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, efficient and front-loaded. Every sentence provides essential info without redundancy.

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

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

Covers purpose, outcome, and return value (reconnection URL). Lacks explanation of the input parameter format, but overall sufficient for a simple destructive tool.

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

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

Schema has 1 required parameter 'item' with 0% description coverage. Description implies it identifies the bank but does not explicitly define the parameter format. Adequate but lacking explicit mapping.

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 revokes consent and deletes data for a specific bank. Distinguishes from sibling tools like openfinance_list_connections (listing) and openfinance_force_sync (syncing).

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

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

Implies usage for disconnecting a bank, mentions return of reconnection URL, but does not explicitly state when not to use or list alternatives among siblings.

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

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

The description fully discloses the tool's behavior: it modifies data (readOnlyHint=false), waits and polls for up to ~60s, and returns statuses like timed_out and needs_action. It aligns with annotations (no contradictions) and adds context beyond them.

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

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

The description is a single paragraph but efficiently packs all necessary information. It is front-loaded with the core action. Minor improvements could be structuring into bullet points, but it remains concise and readable.

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 structure (results, errors) and key fields (status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out). It also covers edge cases like timeout and user action required, making it complete for the tool's complexity.

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

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

The input schema provides only property names and types (0% description coverage). The description adds significant meaning: explains 'items' as an array of selectors (item_id, connector_id, or connector_name) and that omitting it syncs all. It also clarifies the 'wait' parameter's effect (fire-and-forget vs waiting).

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 forces a re-sync of one or more connections and waits for completion. It specifies the action (force sync) and resource (connections), distinguishing it from sibling tools like openfinance_list_connections and 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?

The description advises use when balances or transactions look stale, and explains the wait parameter for fire-and-forget usage. It references openfinance_get_item_status for re-checking timed out syncs, providing clear context. However, it does not explicitly state when not to use the 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 indicate readOnly=true, idempotent=true, destructive=false. The description adds that errors for credit accounts return a warning instead of throwing, and outlines the response shape with results and errors array.

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 with no redundant information. Each sentence adds value: endpoint overview, parameter guidance, and special case handling.

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 the single parameter, response shape, and error handling for credit accounts. Lacking output schema is compensated by described structure; missing details like pagination not needed here.

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

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

With 0% schema description coverage, the description compensates by explaining the account_ids parameter type (array of strings), size constraint (1-50), and its purpose for fetching balance.

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 per account ID, specifies the endpoint, and distinguishes it from sibling tools 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 explicit instructions on passing account_ids as an array of 1-50 and warns about potential BALANCE_FETCH_ERROR for credit accounts. Lacks explicit when-not-to-use but context is clear.

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

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

Annotations already indicate safe read-only and idempotent behavior. The description adds value by specifying the batch GET nature, the inclusion of extended creditData, and the '{ results, errors }' response shape. No contradictions with annotations.

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

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

Two sentences, front-loaded with purpose, no redundant words. Every sentence provides distinct value.

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

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

The description covers the parameter and response shape ('{ results, errors }'), but lacks details about the account object's fields beyond 'extended creditData'. Given no output schema, more detail 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?

The description adds meaning to the single parameter 'account_ids' by clarifying it should be an array of 1–50 items. This compensates for the 0% schema description coverage.

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

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

The description clearly states that the tool returns 'full account objects including extended creditData' per ID, differentiating it from sibling tools like openfinance_list_accounts (which likely returns summaries). It also explicitly mentions the HTTP endpoint pattern.

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 pass 'account_ids' as an array (1–50) and describes the batch shape. However, it does not explicitly compare with sibling tools or state when to use this vs alternatives like openfinance_get_account_balance.

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 critical context: batch shape {results, errors}, absence of paid/status field in Pluggy, and nuanced meaning of payments[]. This goes beyond annotations.

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

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

Description is moderately long but efficient; each sentence adds value. Could be slightly more concise, but structure is clear with usage notes and warnings.

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 provides field list, batch shape, and critical caveats. It fully covers what an agent needs to correctly invoke and interpret results.

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

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

Single parameter with 0% schema coverage; description adds context that bill_ids is an array and that IDs come from another tool. While not deep semantic detail, it compensates for 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 returns bill-level detail for credit card bills by ID, lists specific fields (financeCharges, payments[]), and distinguishes itself from the sibling tool for itemized transactions.

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

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

Provides explicit guidance: when to use, what it does not return, directs to openfinance_list_transactions for transactions, instructs to use openfinance_list_credit_card_bills first to discover IDs, and warns about payment interpretation in Brazilian Open Finance.

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 context about the response format (includes executionStatus, connector metadata) and the two operational modes. No contradiction. However, it does not mention any pagination or rate limits, but these are less critical for a status tool.

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, zero waste. Front-loaded with the main action ('Returns the current status...'). The conditional guidance is clear 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?

Given no output schema, the description adequately explains the response shape for both modes. It could mention possible error statuses more explicitly, but overall it provides sufficient context for an agent to use the tool correctly. Sibling tools are clearly distinguished.

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 fully compensates. It explains the optional 'item' parameter's behavior: omitting returns '{ count, items }', passing returns a single result. This adds crucial meaning beyond the schema's bare type definition.

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

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

The description clearly states the tool returns the current status of a bank connection, listing possible values (UPDATED, UPDATING, LOGIN_ERROR, etc.) and other data (executionStatus, connector metadata). It distinguishes between omitting vs passing the 'item' parameter, which differentiates it from sibling tools 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?

Provides explicit guidance: omit 'item' to get status of all linked banks, pass 'item' for a single bank. This tells the agent exactly when to use each variant, and implies that for listing connections a different tool should be used.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds critical behavioral context: the 'name' field is the legal entity not the brand, 'balance' for CREDIT cards has connector-dependent meaning, and the presence of 'bank' and 'connector_id'. It also notes the aggregation behavior when omitting 'item'.

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 quite verbose, mixing purpose, guidance, and warnings in a single paragraph. It is front-loaded with the core purpose but could benefit from structured formatting (e.g., bullet points) to improve readability.

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

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

Although there is no output schema, the description lists key return fields (balance, number, type, bankData, creditData, bank, connector_id, item_id) and explains the differences in 'name' vs 'bank'. It also references another tool for credit card bills, providing sufficient context for an agent to use the tool effectively.

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

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

With 0% schema description coverage, the description carries full burden. It explains that 'item' targets a single bank and 'type' filters by account type. However, it does not specify the format of the 'item' parameter (e.g., a string ID), which leaves a small gap in 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 it returns accounts for bank connections, listing specific fields like balance, number, type, etc. It distinguishes itself from siblings by focusing on accounts and even references a sibling tool for credit card bills, making the purpose unambiguous.

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

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

The description provides explicit guidance on when to omit vs. include the 'item' parameter, and warns about the connector-dependent meaning of 'balance' for CREDIT cards. It also directs users to openfinance_list_credit_card_bills for standardized amounts, making usage clear.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. The description adds valuable context: the response is cached for the session, single aggregated (no batch ids), and lists fields. This goes beyond annotations.

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

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

Four sentences, no filler. First sentence states purpose, second describes cache, third details entry fields, fourth clarifies response type. Efficient and front-loaded.

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

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

Given the tool's simplicity (no params, good annotations), the description provides sufficient detail: cache behavior, return structure, and relationship to another tool. It is complete for an agent to understand and use correctly.

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

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

Input schema has no parameters (0 params, 100% coverage). Baseline is 3. The description does not add information about parameters (none exist), but it describes the output fields, which is not parameter semantics. Thus, score 3 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 the tool returns Pluggy's transaction category taxonomy (GET /categories), specifying it's cached. The description includes details about the entry fields (id, description, parentId). However, it does not explicitly differentiate from sibling list tools, though the unique resource itself distinguishes it.

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 by mentioning that the categoryId from this tool is used in openfinance_update_transaction_category, which provides a usage clue. However, there is no explicit guidance on when to use this tool vs alternatives, though few alternatives exist for category taxonomy.

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 the behavioral detail that an 'add_connection_url' is returned, providing context about linking additional banks. It does not contradict annotations and is consistent.

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 (22 words) that front-loads the purpose and lists returned fields. Every part contributes essential information with 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?

Given no parameters, no output schema, and thorough annotations, the description provides sufficient information about the tool's behavior and output. It covers what is returned without missing critical details.

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 does not need to explain any parameters. Baseline 4 is appropriate as there is nothing to add 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 'Returns the saved bank connections' and specifies the returned fields (connector_id, item_id, bank name, add_connection_url). It distinguishes this list tool from siblings like openfinance_list_accounts or openfinance_list_transactions by the resource type.

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 no guidance on when to use this tool vs alternatives. It does not mention when not to use it or contrast with other list tools such as openfinance_search_bank_connectors or openfinance_get_item_status. Usage context must be inferred.

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, but the description adds extensive behavioral details: payment semantics, derived payment_status, cross-bill matching, connector asymmetry, open_bill derivation, and error handling. This significantly exceeds annotation coverage.

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 sections and front-loaded purpose, but it is verbose. Some details could be condensed without losing meaning, though it remains clear and well-organized.

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

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

Given no output schema, the description thoroughly explains all output fields (dueDate, totalAmount, etc.), payment_status legend, connector asymmetry, and returns a warning on failure. It is fully self-contained.

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

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

With 0% schema description coverage, the description must explain all parameters. It only explicitly covers include_open_bill and account_ids (bulk support), but does not explain page, page_size, or account_id. While some are inferable, the lack of explicit documentation for two parameters leaves a gap.

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 first sentence clearly states it returns closed credit card bills for a CREDIT-type account, and lists key fields. It distinguishes from sibling tools by directing to openfinance_list_transactions for itemized purchases and noting bulk support with account_ids.

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

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

The description explicitly tells when to use this tool (for bill-level summaries) and when not (use openfinance_list_transactions for itemized purchases). It explains the include_open_bill parameter and warns about payment status interpretation, providing clear context for usage.

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, destructiveHint), the description adds behavioral context: it returns a structured object {total, results, warning} on errors instead of throwing, and lists available fields (balance, amount, rates, etc.). This provides transparency beyond what annotations alone convey.

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

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

The description is moderately concise but could be shorter. It front-loads the main purpose and then lists many details inline. Some information could be structured or omitted without loss of clarity. Still, it remains readable.

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 (4 parameters with no schema descriptions, no output schema, many sibling tools), the description is incomplete. It fails to document parameters or provide full output structure (only mentions example fields). The tool seems simple, but the missing parameter documentation hurts completeness.

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

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

The input schema has 4 parameters (item, page, type, page_size) with 0% schema description coverage. The description does not explain any parameter's meaning, usage, or constraints. This is a critical gap; the agent receives no guidance on how to populate these fields.

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 'the investment portfolio' for a connection, listing specific investment types (FIIs, stocks, ETFs, etc.). The verb 'list' and resource 'investments' are precise, and it distinguishes from related siblings like `openfinance_list_investment_transactions` by focusing on portfolio data.

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

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

The description implicitly guides usage by specifying it's for connections with INVESTMENTS product enabled. It mentions handling of errors (403) with a safe response, but does not explicitly state when not to use it or compare to alternatives among the many sibling tools. However, the context is clear enough for an agent.

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 detailed output fields (quantity, value, netAmount, expenses breakdown) and transaction types, providing 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?

Two paragraphs, no redundant sentences. First paragraph states purpose and output fields; second gives usage prerequisite and bulk feature. Front-loaded with key 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?

No output schema, so description details return fields. Includes prerequisite and bulk support. For a moderate-complexity tool with rich annotations and sibling context, it is sufficiently 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%, so description must compensate. Describes investment_id and investment_ids but omits page and page_size. Partially explains parameters, providing some meaning but not complete coverage.

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

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

Clearly states it returns movement history for a specific investment position, listing transaction types (BUY/SELL/TAX/INTEREST/AMORTIZATION/TRANSFER). Distinguishes from sibling tool openfinance_list_investments by specifying to use after that to get investment_id.

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 provides prerequisite: 'Use after openfinance_list_investments to get the investment_id.' Mentions bulk support via investment_ids. Does not compare with openfinance_list_transactions but gives sufficient guidance for when to use.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, indicating safe read behavior. The description adds valuable behavioral context: sequential querying with rate-limit spacing for multiple connections, and the return format `{ results, errors }` per connection, which goes beyond the annotations.

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

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

The description is three sentences, front-loaded with the core purpose, and every sentence provides necessary detail. No wasted words—clear, 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 the tool's simplicity (one optional parameter, no output schema), the description covers all necessary aspects: purpose, parameter usage, edge cases (omit items), return format, and rate-limiting behavior. Annotations cover safety. Nothing critical is missing.

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

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

With schema description coverage at 0%, the description fully compensates by explaining that `items` is an array of connection selectors (item_id uuid, connector_id, or connector_name), one per connection, and that omitting it queries all banks. This adds essential meaning beyond the raw schema.

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

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

The description explicitly states 'Lists loan contracts per bank connection (GET /loans).' This clearly identifies the verb (list), resource (loan contracts), and scope (per bank connection), distinguishing it from sibling tools like openfinance_list_accounts or 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 provides clear guidance on when to use the `items` parameter (for specific connections) and when to omit it (for all banks), and notes sequential querying with rate limiting. However, it does not explicitly mention when not to use this tool in favor of alternatives, such as openfinance_list_accounts for account details instead of loans.

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

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

Discloses error handling (returns objects instead of throwing), search behavior (aggregates up to 5000, case-insensitive substring), CREDIT PENDING vs POSTED nuances, and bulk support. 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-organized with front-loaded purpose and structured sections. Though lengthy, each sentence adds value. Could be slightly more concise but maintains 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?

Thorough on error handling, pagination, and sibling differentiation. However, no output schema exists and description does not detail the result shape (e.g., transaction object fields), which is a gap for 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?

Adds meaning beyond schema: explains date format (ISO YYYY-MM-DD), pagination max (500/page), search_queries semantics (case-insensitive, OR). Covers most parameters but lacks explicit defaults for page and page_size.

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 'Returns transactions for a bank account (BANK or CREDIT type)' with specific verb and resource. Distinguishes CREDIT account behavior and contrasts with sibling tools like openfinance_list_credit_card_bills.

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

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

Explicitly states when to use this tool vs alternatives: for CREDIT accounts it's the only way to get itemized transactions, for standardized open-bill total use openfinance_list_credit_card_bills. Provides troubleshooting guidance for zero results.

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 behavioral details beyond annotations: scanning caps at 5000 transactions per account with a truncated flag, default granularity returns a compact summary, and raw returns all rows. 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 information-dense and front-loaded with the core purpose. While every sentence adds value, it is somewhat verbose; 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 the complexity (6 params, no output schema), the description is very complete. It explains the response structure (total entradas/saídas, por_mes, top_despesas, by_account), truncation behavior, and granularity trade-offs. No gaps identified.

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 the purpose and allowed values for each parameter: item accepts connector_id/connector_name/item_id, from/to are ISO dates, granularity defaults to 'monthly' and affects response format, type filters to BANK or CREDIT, and top_n influences top expenses/receipts.

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 this tool provides consolidated cash-flow analysis for a whole bank connection in one call. It distinguishes from siblings by explicitly mentioning that it resolves accounts internally and fans out transactions, eliminating the need to call openfinance_list_accounts first.

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

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

The description gives explicit usage scenarios ('análise anual/mensal', 'fluxo de caixa'), explains how to target a single bank vs all, and explains the granularity options with trade-offs. It also contrasts with other tools by stating what is not needed.

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

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

Discloses return value structure (global indicator, degraded components, open incidents, affected banks) beyond the readOnlyHint and idempotentHint annotations. No contradictions.

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

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

The description is well-structured and front-loaded, but slightly verbose. Every sentence adds value, but could be tightened 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 zero parameters and no output schema, the description fully covers what the tool does, when to use it, and what it returns. No gaps.

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

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

No parameters, so schema coverage is trivially 100%. The description adds value by explaining the tool's output context, which helps an AI agent understand the input-free nature.

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

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

The description clearly states 'Checks the LIVE operational status of the Open Finance provider' with a specific verb and resource. It explicitly distinguishes itself from the sibling tool `openfinance_get_item_status`, avoiding confusion.

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

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

Provides explicit guidance on when to use (when data seems incomplete/stale despite updated connection) and when not to (it's separate from connection status). Offers concrete scenarios like missing accounts or 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 safe read-only operation. The description adds significant behavioral details: returns a hint if no keywords, honors user's plan (hides PJ banks for PF plans), and explains the return fields including connect_url. 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 moderately long but each sentence adds value. It is well-structured: first the action, then return details, then usage context. Could be slightly more concise but is not 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 covers the main return fields and key behaviors (plan filtering, hint on empty keywords). Minor gaps such as unspecified behavior when no matches are found, but overall adequate for a search tool.

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

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

Schema has 0% description coverage, but the description compensates by explaining keywords[] as search terms with examples, and include_accounts to include accounts. It also notes that keywords is functionally required, though the schema lists 0 required parameters, which could cause slight 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 it searches bank connectors by name and returns specific fields including a connect_url. It distinguishes itself from siblings like openfinance_list_connections by being a keyword search tool, not a listing tool.

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

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

The description provides clear context: call this BEFORE connecting to get a one-click link. It explains that keywords[] is required (or returns a hint). However, it does not explicitly mention alternatives or when not to use it.

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

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

The description goes beyond annotations by disclosing that this tool overrides automatic categorization, creates Category Rules for future similar transactions, and provides batch behavior with per-item error handling that doesn't fail the 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?

The description is front-loaded with the core action, then elaborates on side effects and error handling. While longer than ideal, every sentence adds value. Could be slightly more concise but overall 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 fully covers return shape ('{ updated, results, errors }'), error behavior, and side effects. It provides sufficient context for an agent to use this tool correctly without additional documentation.

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

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

The input schema has no descriptions (0% coverage), but the description compensates by explaining that 'items' is an array of { transaction_id, category_id } and mapping each field to the source tool. This adds meaningful context beyond the raw schema.

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

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

The description clearly states it corrects transaction categories ('Corrects the category of one or more transactions') with a specific API endpoint (PATCH /transactions/:id). It distinguishes from sibling tools like openfinance_list_transactions and openfinance_list_categories by explaining the tool's unique purpose and side effects.

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

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

The description explains when to use this tool: to fix miscategorized transactions and improve future categorization. It specifies where to get the required ids (from list tools). While it provides good context, it lacks explicit guidance on when NOT to use it or alternatives.

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

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

Annotations already indicate idempotentHint=true (safe to retry) and destructiveHint=false. The description adds that the conversation array is needed for reproduction, which is useful behavioral context. However, it does not disclose what happens after reporting (e.g., ticket creation, email). With annotations covering safety, a 3 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?

The description is very concise: two sentences that front-load the purpose and then provide a usage hint. Every sentence adds value with 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?

For a simple feedback tool with no output schema, the description covers the essential purpose and one key parameter (conversation). It does not describe return values or success behavior, but for a non-critical tool this is acceptable. The contextual completeness is good but not exhaustive.

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

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

The input schema has 3 parameters (message required, context and conversation optional) with 0% description coverage in the schema, so the description must compensate. It explains that 'conversation' should be an array of recent messages, adding meaning beyond the schema's string type. However, it does not explain the 'context' parameter or the format of the conversation array, so some gaps remain. Baseline 3 is suitable.

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 a bug, missing feature, or sending feedback. It uses specific verbs and resources, and the mention of 'conversation array' for reproduction adds specificity. The tool is distinct from its siblings, which are all related to Open 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?

The description provides a clear usage hint: 'Include the conversation array with recent messages for reproduction.' This tells the agent when and how to use the tool effectively. However, it does not explicitly state when not to use it or provide alternatives, but given the sibling tools are unrelated, no exclusion is needed.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the specific output (platform and adapter versions) but no further behavioral details. This is adequate given 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?

Single sentence, no filler, perfectly sized for the tool's simplicity.

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

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

Given no parameters, rich annotations, and straightforward purpose, the description is fully complete. No output schema needed for such a simple return.

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 the description inherently adds no parameter info. With 0 parameters, baseline score is 4 per rubric.

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

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

The description clearly states the verb 'show' and resource 'versions', specifying both MCP platform and adapter versions. It is distinct from sibling tools like authenticate or connect.

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 tool is self-explanatory with no parameters and a simple read operation. No explicit when-not-to-use guidance is needed, though it could be slightly more explicit about being informational.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds specific details about the returned data (MCPs, connection status, catalog tool counts), complementing the annotations without contradiction.

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

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

Single sentence that is front-loaded with the main action ('Returns the current toolkit state') and follows with specific details. No redundant words.

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

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

Given no output schema, the description adequately conveys the return information. It could benefit from mentioning the output format (e.g., JSON structure), but the listed elements are sufficient for an agent to understand the tool's output.

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 the input schema is fully covered (100%). The description correctly adds no parameter information, meeting the baseline score of 4 for parameter-free 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?

Description clearly specifies the verb 'Returns' and the resource 'current toolkit state', detailing the exact information provided: installed MCPs, their connection status, and catalog tool counts. This distinguishes the tool from siblings like show_version 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?

No explicit guidance on when or when not to use the tool, nor any mention of alternatives. However, the purpose is straightforward and the tool has no parameters, making its use context obvious.

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