Nubank MCP

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

Disclosed behavioral traits beyond annotations: describes session vs permanent authentication, token format (JWT), and that calling with no args returns a link. 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?

Description is clear and packed with information, but slightly verbose. Could be tightened while retaining all guidance. Still well-structured.

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

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

Given context (single optional param, no output schema, annotations), the description is complete. Covers input, usage scenarios, and best practices.

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

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

Schema has one undocumented optional 'token' parameter. Description adds critical semantics: token is a JWT, and explains the effect of providing it vs omitting it. Compensates fully for 0% schema coverage.

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

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

The description clearly states the tool authenticates users, providing a login link or accepting a token. It distinguishes from siblings by focusing on authentication, which no other tool does.

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

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

Explicitly explains when to use (to get a login link or paste a token) and provides best practice for permanent vs session login. Also mentions alternative setup via config.

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 (readOnlyHint, idempotentHint) already indicate safe, read-only behavior. Description adds value by explaining the response content (authenticated, pending[], connect_url) and states, without contradicting annotations.

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

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

Two sentences, front-loaded with main purpose, no filler. 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 parameters and no output schema, description fully explains tool output and behavior for both states. Complete for a status-checking tool.

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

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

No parameters exist, so baseline of 4 applies. Description correctly doesn't add unnecessary parameter info.

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

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

Description clearly states it returns connection status and URLs, with specific details about different states (all connected vs. missing credentials). Distinguishes from sibling tools like 'authenticate' by focusing on status rather than initiating 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?

No explicit when to use or alternatives, but the description implies it's for checking connection status. Could benefit from mentioning that 'authenticate' is used when credentials are missing, but it's not required.

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 substantial behavioral context beyond annotations: it explains that invoke works without installation, returns connect links for missing credentials or checkout links for insufficient wallet, and states that write actions require workspace owner/admin. It also describes search/describe flags for installed status, which is not covered by annotations.

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

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

The description is well-structured with front-loaded intent and a clear flow, but it is relatively long. While every sentence adds value, some redundancy exists (e.g., repeated mention of invoke behavior). It is efficient but not maximally 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 the tool's complexity (13 parameters, 10 actions, no output schema), the description covers the main actions and important behaviors like auth and billing, but lacks details on return values for many actions and does not explain all parameters. The missing output schema heightens the need for more complete return 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?

With 0% schema coverage, the description partially compensates by explaining the purpose of key parameters like action, query, mcp_id, tool_id, and arguments through the core flow. However, it fails to document parameters such as limit, immediate, conversation, and others, leaving gaps in understanding for agents.

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 is 'THE official mcp.ai marketplace' used for discovering and running MCPs/tools, and it distinguishes itself from external registries by emphasizing to use this tool first. It provides a specific verb-resource relationship and contrasts with sibling tools like openfinance which are domain-specific.

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

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

The description explicitly says 'use THIS tool FIRST, before any external/generic registry' and outlines the core flow (search → describe → invoke), with conditions for install vs invoke. It also mentions when to use list_tools, subscribe, etc., providing clear context for when to use this tool vs alternatives.

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

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

The description confirms the destructive nature (delete connection data) aligning with the destructiveHint annotation. It adds the behavioral detail that the tool returns a reconnect URL, providing useful information 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 two sentences with no wasted words. It front-loads the purpose and includes the key return value, achieving high efficiency.

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 is destructive and returns a reconnect URL, the description covers the main action and output. It lacks mention of error conditions or authentication needs, but for a simple destructive tool with no output schema, it is largely complete.

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

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

The schema has one required 'item' parameter with no description. The description specifies that 'item' refers to a 'specific bank', adding semantic context. However, it lacks details on the expected format or identifier type, which would be helpful given 0% schema coverage.

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

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

The description clearly states that the tool revokes Open Finance consent and deletes connection data for a specific bank, making data unavailable. It uniquely identifies the action (disconnect) and distinguishes from sibling tools like connect or 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 implies usage for disconnecting a bank but offers no explicit guidance on when to use this tool versus alternative tools (e.g., connect, force_sync). It lacks context on prerequisites 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?

Annotations indicate readOnlyHint=false and destructiveHint=false, and the description aligns by stating it pulls fresh data without disconnecting/reconnecting. It fully discloses the polling mechanism (up to ~60s), potential outcomes (needs_action, timed_out), and the return fields (status, executionStatus, lastUpdatedAt, synced). 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 comprehensive but slightly lengthy. Every sentence adds value, such as explaining return object fields and timeout behavior. It front-loads the core action and outcome, but could be tightened by removing some redundancy (e.g., both 'waits' and 'polls until...'). Still effective.

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

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

Given no output schema, the description fully documents the return value { results, errors } with key fields and meanings. It covers timeout, polling, and error states. For a tool with two parameters, no required params, and complex behavior, the description is exceptionally 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 add meaning. It does so excellently: explains 'items' as an array of selectors (item_id, connector_id, or connector_name) and that omitting it syncs all. For 'wait', it clarifies that default waits for completion, but false gives fire-and-forget. This is critical context missing from the schema.

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

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

The description clearly states the action ('forces re-sync'), the resource ('one or more connections'), and the behavior ('waits for it to finish'). It distinguishes from sibling tools like openfinance_get_item_status and openfinance_list_transactions by explicitly indicating its purpose for stale data without disconnecting.

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

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

The description explicitly says when to use ('when a balance or transaction list looks stale') and mentions an alternative for checking status (openfinance_get_item_status). It also explains the wait parameter for fire-and-forget. However, it does not explicitly list all sibling tools or provide a comprehensive when-not-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?

Adds context beyond annotations: explains that CREDIT accounts may return a BALANCE_FETCH_ERROR with a warning instead of throwing, and documents the response shape. 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?

Three sentences, each purposeful: main action, parameter constraint, error behavior, response shape. No wasted words, front-loaded with core function.

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 single-parameter tool with no output schema, the description covers all essential aspects: behavior, parameter constraints, error handling, and response format. Fully sufficient.

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

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

With 0% schema description coverage, the description compensates by specifying array type and size constraint (1-50). Adds meaning beyond just the schema property name.

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 real-time balance payload per account id' with specific endpoint GET /accounts/:id/balance. Distinct from sibling tools like openfinance_get_accounts_detail or 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?

Provides usage hint: pass account_ids as array (1-50). However, does not explicitly state when to use this tool vs 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?

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds behavioral context: the HTTP endpoint (GET /accounts/:id), the return shape `{results, errors}`, and the inclusion of extended creditData. No contradiction with annotations.

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

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

Two sentences: first describes output, second describes input and return shape. No extraneous information. Front-loaded with purpose.

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

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

For a simple read-only tool with one parameter and no output schema, the description covers what it returns, the data included, how to call it, and the result format. It is complete given 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?

Schema coverage is 0%; description partially compensates by stating 'Pass account_ids as an array (1–50).' This provides type (array of strings) and size constraint but does not explicitly state the IDs are account identifiers (though implied by context). Additional semantic detail would improve this.

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

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

Description clearly states the tool returns full account objects with extended creditData, distinguishing it from siblings like openfinance_list_accounts (likely summary) and openfinance_get_account_balance (balance only). The verb 'Returns' and resource 'account objects' are specific.

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

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

Description indicates usage: pass an array of 1-50 account_ids to get details. However, it does not explicitly contrast with alternatives like openfinance_list_accounts for when to use this over listing. The batch constraint provides clear context for 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 provide readOnlyHint, idempotentHint, destructiveHint. Description adds critical behavioral caveats: Pluggy does not return paid/status field, payments array reflects previous bill payment, and recommends using openfinance_list_credit_card_bills for payment status. 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?

Well-structured with front-loaded purpose and subsequent caveats. Every sentence adds value, though slightly lengthy. Could be trimmed without losing 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 single parameter and no output schema, description sufficiently explains input, output shape (results, errors), cross-tool relationships, and important caveats. No missing critical information.

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 no parameter descriptions (0% coverage). Description explains that bill_ids should be an array of strings, obtained from openfinance_list_credit_card_bills, and mentions batch shape. Provides meaningful guidance but does not detail 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?

Clearly states the tool returns bill-level detail for credit card bills by id, distinguishes from sibling tools openfinance_list_credit_card_bills and openfinance_list_transactions, and specifies what is returned (financeCharges, payments) and what is not (individual 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?

Explicitly states when to use (get bill detail) and when not (for transactions, use openfinance_list_transactions). Recommends using openfinance_list_credit_card_bills first to discover ids, and explains batch shape and payment interpretation.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying returned fields (status, executionStatus, connector metadata) and the behavior difference between omitting and passing 'item', which is beyond the annotations.

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

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

The description is two sentences long, front-loaded with the core purpose, and every word adds value. No redundancy or filler.

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 read-only tool with one optional parameter and no output schema, the description covers what the tool returns, how to use it for single vs bulk, and the result format. It is complete for its complexity.

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

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

With 0% schema description coverage, the description fully compensates by explaining the meaning of the optional 'item' parameter: omitting returns all banks with count/items structure, passing 'item' returns single bank status.

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 statuses (UPDATED, UPDATING, LOGIN_ERROR, etc.). It distinguishes between single and bulk queries but does not differentiate 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?

The description explains when to omit or include the 'item' parameter, but does not provide explicit guidance on when to use this tool versus alternatives 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?

The description discloses important behavioral traits: account 'name' is the legal issuer, not the brand (so use 'bank' for user-facing text); credit balance meaning varies by connector; recommends another tool for standardized data. The annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false, and the description adds substantial context 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?

The description is somewhat lengthy but well-structured: it starts with the core return fields, then explains the 'item' parameter usage, followed by detailed notes on credit balance and billing cycles. Every sentence adds value, though slight trimming could improve conciseness.

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

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

Given the complexity (multiple account types, multiple bank connections, credit balance nuances), the description covers most aspects. It lists key return fields and explains behavior for both 'item' scenarios. However, some fields like bankData and creditData are mentioned but not detailed, and there is no output schema to compensate. The description is still quite complete for a read-only list tool.

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

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

The input schema has 2 parameters with 0% description coverage, but the description fully explains both: 'item' (optional, omitting aggregates across all banks, passing targets one bank) and 'type' (optional enum filtering to BANK or CREDIT). This adds significant meaning beyond the schema.

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

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

The description clearly states the tool returns accounts for a bank connection with specific fields (balance, number, type, subtype, bankData, creditData, bank, connector_id). It distinguishes between BANK and CREDIT types and explains how to use the 'item' parameter to list across all banks or target a single bank. This specificity differentiates it from sibling tools.

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

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

The description explicitly advises when to omit 'item' (when user asks for 'my accounts/cards' without naming a bank) and when to pass it (target a single bank). It also warns about the connector-dependent meaning of credit card balance and directs users to openfinance_list_credit_card_bills for standardized bill amounts. This provides clear usage context.

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

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

Annotations already provide readOnly, idempotent, and non-destructive hints. The description adds caching behavior ('cached for the adapter session'), the single aggregated response nature, and the specific fields returned. This supplements the annotations well.

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 concise sentences, front-loaded with the core purpose. Every phrase adds value: the caching detail, the field explanations, and the connection to another tool. No fluff.

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

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

Given zero parameters, no output schema, and the tool's simplicity, the description fully covers what the agent needs: what the tool does, what the response contains, and how it relates to other tools. The caching and single-response notes are 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 no parameters and 100% schema coverage, the baseline is 3. The description adds value by explaining the output fields and their meaning (e.g., 'parentId' and 'parentDescription' indicating the tree parent), which helps the agent understand the response beyond the schema.

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

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

The description clearly states the tool returns Pluggy's transaction category taxonomy, cached. It specifies the output fields and mentions the connection to openfinance_update_transaction_category, distinguishing it from sibling tools that deal with transactions or accounts.

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

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

The description implies read-only, idempotent usage via caching and single aggregated response. It lacks explicit when-to-use or when-not-to-use guidance but is clear in its context. The connection to update_transaction_category helps agents understand its role.

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 context about output fields and add_connection_url, 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?

Single sentence, 24 words, front-loaded with verb and object. No redundancy or waste.

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

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

Tool is simple with no parameters or output schema. Description covers returned fields and a key use (linking banks). Could mention pagination or limits, but not critical.

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

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

No parameters in schema (schema coverage 100%). Baseline for 0 params is 4. No parameter info needed.

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

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

Description clearly states it returns saved bank connections with specific fields (connector_id, item_id, bank name, add_connection_url). Distinguished from sibling list tools by focusing on connections rather than accounts or 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?

No explicit when-to-use or alternatives provided, but the simple nature and clear description imply usage. For a parameterless list tool, this is adequate.

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 details payment status derivation, cross-bill payment matching, the opt-in open_bill logic, and connector limitations. It fully discloses behavioral traits without contradicting annotations.

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

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

While comprehensive, the description is slightly lengthy but well-structured: front-loaded purpose, then detailed semantics. Every paragraph adds necessary context for a complex domain, though it could be 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 no output schema, the description thoroughly explains return fields (dueDate, payments[], payment_status, open_bill structure), functional behavior (cross-bill payment), and edge cases (connector asymmetry). It references sibling tools for further detail, making it fully self-sufficient.

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

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

With 0% schema coverage, the description compensates by explaining include_open_bill thoroughly and mentioning bulk support via account_ids. However, page and page_size parameters are not described, relying on naming convention. Overall adds significant meaning beyond the schema.

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

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

The description clearly states it returns CLOSED credit card bills for CREDIT-type accounts, specifying key fields. It distinguishes from sibling tools like openfinance_get_credit_card_bill and openfinance_list_transactions, noting the latter for itemized purchases.

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

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

Explicit guidance on when to use this tool vs. alternatives, including when to use openfinance_list_transactions for per-bill transactions. Also explains when to opt-in for include_open_bill and warns about connector asymmetry and product unavailability.

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 readOnlyHint, idempotentHint, and destructiveHint. The description adds context by detailing the error response structure (returns total, results, warning on 403) and lists specific fields returned (balance, rates, etc.), which 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?

The description is front-loaded with the main purpose and then provides detailed output field enumeration and error behavior. It is somewhat lengthy but each sentence adds value. A slight improvement would be to structure parameter info.

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

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

Given the lack of output schema, the description does well by listing many result fields and handling error conditions. However, it omits explanation of pagination parameters (page, page_size) and does not fully describe the shape of each result item.

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%, yet the description provides no explanation of the four parameters (item, page, type, page_size). It only describes output fields, leaving agents to infer parameter meaning from names 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 verb ('Returns'), the resource ('investment portfolio for a connection'), and scope (specifies asset types: FIIs, stocks, etc.). It distinguishes from sibling tools like openfinance_list_investment_transactions by focusing on portfolio view rather than 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 implies when to use: for connections with INVESTMENTS product enabled. It also explains behavior when the product is not enabled (returns a structured response instead of throwing). However, it does not explicitly state when not to use or mention alternatives among siblings.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context by detailing the output fields and batch capability, which goes beyond annotations. 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 two short paragraphs: the first defines purpose and output, the second adds usage guidance. Every sentence adds value, front-loaded with the core purpose, and no extraneous content.

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

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

For a list tool without output schema, the description lists key return fields and the prerequisite step (openfinance_list_investments). It omits description of pagination parameters but covers the essential inputs and outputs, making it 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 description coverage, the description compensates by explaining investment_id (required, from openfinance_list_investments) and investment_ids for bulk. It does not explain page and page_size, but those are standard pagination parameters. Overall, adds meaningful semantics 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 it returns movement history for a specific investment position, lists the types of movements (BUY/SELL/TAX/etc.), and details the row fields. It distinguishes itself from sibling tools like openfinance_list_transactions by focusing on investment positions and mentions use after openfinance_list_investments, making the purpose specific and well-defined.

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

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

The description provides clear usage context: 'Use after openfinance_list_investments to get the investment_id.' and mentions bulk support via investment_ids. While it doesn't explicitly state when not to use or list alternatives, the context is sufficient for correct invocation.

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; description adds rate-limit spacing and sequential query behavior. No contradiction, and adds useful 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. Compact yet covers key details.

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

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

Given single optional parameter, no output schema, and strong annotations, the description adequately covers input, behavior, and return structure. Sufficient for agent 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?

With 0% schema description coverage, the description fully compensates by explaining that items are connection selectors (item_id, connector_id, connector_name) and that omitting lists all. Provides essential meaning.

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

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

The description clearly states the tool lists loan contracts per bank connection, mentioning the endpoint. It distinguishes from siblings indirectly by specifying it's for loans, but does not explicitly differentiate.

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

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

Provides clear guidance on how to use the `items` parameter, including omission for all banks, and mentions sequential querying with rate-limit spacing. Does not explicitly state when not 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false confirm safe read operations. Description adds: returns warning/error on upstream errors, aggregates up to 5000 for search, returns truncated flag, bulk support via account_ids. 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?

Well-structured into logical sections (general behavior, credit card specifics, date filters, pagination, search, error handling, health check). Slightly verbose in parts but every sentence adds value. Could trim redundant phrases like 'Same query, different coverage per bank (upstream)'.

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 all user-facing aspects: account types, credit card nuances (PENDING/POSTED, billId), date filters, pagination (max 500), search behavior (aggregation up to 5000), error fallback, health check recommendation. No output schema but behavior is fully specified.

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 description explains all 7 parameters: from/to as ISO YYYY-MM-DD dates, page_size max 500, search_queries case-insensitive substring match with OR semantics, account_id and account_ids for single vs bulk. Fully compensates for missing schema descriptions.

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

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

The description clearly states the tool returns transactions for BANK and CREDIT accounts, distinguishes itemized credit card transactions from bills via openfinance_list_credit_card_bills, and explains the PENDING/POSTED behavior. This separates it from sibling tools like openfinance_list_credit_card_bills and openfinance_get_account_balance.

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

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

Explicitly explains when to use this tool (e.g., for credit card itemized transactions) and when to use alternatives (e.g., openfinance_list_credit_card_bills for total debt). Provides guidance on date filters, pagination, search_queries behavior, and error handling.

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 discloses internal behavior: resolves accounts internally, fans out transactions, caps at 5000/account with truncation flag. Annotations already indicate safe read-only behavior, but description adds concrete detail about operation and output. No contradiction with annotations.

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

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

The description is long but well-structured and front-loaded with core purpose. Every sentence adds value, though it could be slightly more concise (e.g., 'you do NOT need to call...' could be implied). Length is justified by complexity.

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 6 parameters, no output schema, and complex behavior, the description is remarkably complete. It covers all parameters, output format, truncation, filtering, and use cases. Without an output schema, it effectively describes the return structure.

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?

All 6 parameters are described in detail except top_n; the description mentions 'largest N each' but does not explicitly state that top_n controls N. With 0% schema coverage, the description carries full burden and mostly succeeds, with a minor gap for top_n.

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

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

The description clearly states the tool's purpose: consolidated cash-flow analysis for a bank connection in one call. It distinguishes from sibling tools like openfinance_list_accounts and openfinance_list_transactions by explaining that it resolves accounts internally and fans out transactions, eliminating the need for multiple calls.

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?

Explicit guidance on when to use: 'análise anual/mensal', 'fluxo de caixa', etc. It instructs users to pass `item` for one bank or omit for all, specifies ISO date format for from/to, and explains the difference between 'monthly' and 'raw' granularity. It also warns about truncation at 5000/account.

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

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

Description adds behavioral context beyond annotations: mentions return fields (global indicator, degraded components, open incidents, your_banks_affected). Annotations already declare readOnlyHint, idempotentHint, destructiveHint, and description complements them 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?

Description is dense but informative, front-loading purpose and usage. Every sentence adds value. It could be slightly more concise but does not waste words.

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

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

Despite no output schema, the description covers key return attributes (global indicator, degraded components, open incidents, your_banks_affected). It is complete for a zero-parameter tool with clear purpose.

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

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

No parameters defined; schema coverage is 100% with empty object. Description does not need to add parameter info, but maintains clarity by stating it checks status without inputs.

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 'checks' and the resource 'LIVE operational status of the Open Finance provider'. It distinguishes from sibling tool openfinance_get_item_status by specifying that it checks provider health, not 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?

Explicitly describes when to use: when data looks incomplete or stale despite an updated connection. It lists symptoms (accounts/transactions missing, bank not returning everything) and explains what it reveals (upstream outage, known incident). It contrasts with 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 declare readOnlyHint=true and idempotentHint=true. Description adds that the tool returns a connect_url, requires keywords, and respects the user's plan. 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?

Single paragraph with several sentences, each containing useful information. Could be more structured (e.g., bullet points) but no fluff. Front-loaded with main action.

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

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

No output schema exists, but description outlines return fields (connector id, access, audience, connections, accounts, connect_url). Covers key behaviors like missing keywords and plan filtering. 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 coverage is 0%, but description explains that keywords[] is required with example usage, and include_accounts=true retrieves accounts. This adds significant meaning beyond the bare schema.

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

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

The description clearly states it searches bank connectors by name, listing specific return fields (connector id, access, audience, etc.) and a ready connect_url. It distinguishes from siblings like 'connect' by positioning itself as a pre-connection search 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 'Call this BEFORE connecting' and notes that keywords[] is required (returns hint otherwise). It also mentions plan-based filtering. Does not explicitly state alternatives but provides clear when-to-use 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?

Beyond annotations, the description discloses critical side effects: overriding Pluggy's automatic categorization and creating a Category Rule for future similar transactions. It also explains the batch error handling ('per-item errors do not fail the whole batch'), ensuring full behavioral transparency.

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

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

The description is dense and efficient, covering the HTTP method, parameter structure, side effects, return shape, and error handling without redundancy. Every sentence contributes unique value.

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

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

Given the absence of an output schema, the description fully documents the return format: `{ updated, results: [...], errors: [...] }`. Combined with behavioral details, it leaves no significant gaps for an AI agent to invoke the tool correctly.

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

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

With 0% schema description coverage, the description fully compensates by detailing the structure of the `items` parameter: an array of objects with transaction_id and category_id, and specifies where to obtain each ID. 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 clearly states the tool's purpose: 'Corrects the category of one or more transactions (PATCH /transactions/:id).' It is a specific verb-resource combination, and the action is distinct from sibling tools like list 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 guidance on when to use the tool (to fix miscategorized transactions) and explains the data prerequisites (transaction_id from list_transactions, category_id from list_categories). It lacks explicit exclusions or alternatives but offers sufficient context for correct 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?

Annotations provide idempotentHint and destructiveHint, but the description adds no extra behavioral context beyond the core action. It doesn't discuss side effects or outcomes.

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

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

Two efficient sentences, no redundancy. The purpose is stated first, followed by a practical usage tip.

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 report tool, the description covers purpose and key usage hint. Lacks details on return values, but no output schema exists. Could elaborate on other parameters.

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 'conversation' parameter by mentioning it for reproduction, but does not explain 'context' or 'message' beyond their schema types. With 0% schema coverage, partial compensation 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?

Description clearly states the tool reports bugs, missing features, or feedback. It uses a specific verb and resource and distinguishes from sibling tools that focus on Open Finance operations or system info.

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

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

Explicitly advises to include the conversation array for reproduction, providing clear context for use. No direct comparison to alternatives, but siblings are unrelated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds that it returns version details for platform and adapter, providing concrete behavioral insight 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 sentence that is concise and front-loaded with the key action. Every word is necessary; no wasted text.

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

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

Given no parameters and no output schema, the description adequately covers what the tool does. It could optionally specify the output format (e.g., 'returns an object'), but the current description is sufficient for a simple version 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?

There are zero parameters, so the baseline is 4. The description does not need to explain parameters, and the schema already covers all cases. No additional parameter information is required.

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

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

The description clearly states the tool shows 'current MCP platform and adapter versions', using a specific verb and resource. It distinguishes from siblings, which are primarily finance-related or authentication, and no other tool covers version info.

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

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

The description does not provide explicit guidance on when to use or alternatives. However, the tool is simple and standalone; usage is self-evident. A higher score would require stating contexts like 'use to check system compatibility'.

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, destructiveHint=false, and idempotentHint=true. The description adds value by specifying the exact content returned (installed MCPs, connection status, catalog counts), which is beyond the structured 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?

The description is a single sentence that packs all necessary information without any fluff. 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?

Even without an output schema, the description clearly outlines the return value: installed MCPs, connection status, and catalog counts. This is sufficient for the agent to understand what to expect.

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

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

The tool has zero parameters, so a baseline of 4 is appropriate per the guidelines. No parameter documentation is needed because the schema covers an empty object.

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

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

The description clearly states the tool returns the current toolkit state including installed MCPs, their connection status, and catalog tool counts. This specific verb-resource pair distinguishes 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?

No explicit when-to-use or alternatives are provided. However, the context from sibling names suggests it is a diagnostic utility, and the description implies it is for inspecting the system. Lacks guidance on 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.