Bradesco MCP

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

No contradiction with annotations. Annotations indicate idempotentHint=true and destructiveHint=false, which the description supports. It adds behavioral specifics: the permanent method requires config changes, session method via tool call, and the token parameter usage.

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

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

The description is detailed but front-loads key info and is structured into scenarios. Slightly verbose but acceptable for 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 simple input schema (1 optional param, no output schema), the description covers both use cases and return behavior adequately. It could explicitly state the response format but is sufficient.

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

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

Schema coverage is 0% with a single optional token parameter. The description explains its meaning: 'call with { token: "<jwt>" } after the user pastes, or with no args to get the link', which fully clarifies usage.

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

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

The description clearly states the tool's purpose: authenticating users for IDE agents. It specifies verbs like 'log in', 'copy', 'paste', and explains both permanent and session-only methods, distinguishing it from siblings like '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?

Explicitly provides when to use each method: 'Best: add it to this server's config as a header... for a permanent, non-expiring connection' vs 'paste it here for a session-only login'. It also instructs to call with or without token to get a link.

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 discloses that the tool is read-only and idempotent (as per annotations) and adds details about return values based on state (authenticated:true vs 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?

Two sentences, no fluff, front-loaded with main purpose. Every sentence adds necessary information.

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

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

Given no parameters and no output schema, the description fully explains the tool's behavior and return values in different states. Could add more detail on how to use the returned URLs but is sufficient.

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

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

No parameters to describe; schema coverage is 100%. The description adds value by interpreting the output behavior beyond schema.

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

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

Description clearly states the tool returns connection status and URLs, with specific behavior for all connected vs missing credentials. This distinguishes it from sibling tools like 'authenticate' which likely performs 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?

Provides explicit scenarios (all providers connected vs credentials missing) and what to expect in each case. Does not mention when not to use this tool or alternatives, but the context implies it's for checking 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 key behavioral traits beyond annotations: invoke works even when the MCP is not installed (one-off execution without bloat), credential/payment flows are handled via connect/checkout links, and write actions require owner/admin. This adds significant context to the annotations (readOnlyHint=false, openWorldHint=true, etc.) 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 comprehensive but dense, packing a lot of information into a single paragraph. It front-loads the main purpose, but could benefit from a more structured format (e.g., bullet points or sections) to improve readability. Nevertheless, every sentence adds value, and the length is justified by the number of actions.

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

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

Given the tool has 13 parameters and no output schema, the description covers the main actions, flow, and edge cases (connect link, checkout link). However, it lacks explicit details on return values or success/failure indicators, leaving some ambiguity about the exact response format. Still, it is largely complete for an experienced agent.

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

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

The description explains the high-level meaning of many parameters (action, query, mcp_id, tool_id, arguments) through the action flow, but does not detail each parameter's format, constraints, or behavior. With 0% schema coverage, the description partially compensates by contextualizing parameters, but falls short of fully documenting all 13 parameters.

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

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

The description clearly states the tool is the official mcp.ai marketplace for discovering and running MCPs/tools. It distinguishes itself from sibling tools (like authenticate, toolkit_info) by being the central hub for search, describe, invoke, install, and other actions. The description explains the core flow and each action's purpose, making the tool's role 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 when-to-use guidance, instructing to use this tool FIRST before external registries. It outlines the core flow (search → describe → invoke) and distinguishes between one-off use (invoke) and permanent installation (install). It also explains when to use other actions like list_tools, subscribe/cancel, report_bug, and request_mcp, and notes that administrative actions require workspace owner/admin.

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 destructiveHint=true, and the description reinforces this with 'deletes the connection data' and 'data will no longer be available'. It adds extra context by mentioning the return of an add_connection_url for re-connection, which is beyond the annotation scope.

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 efficient sentences that immediately state the core action, followed by consequences and a return value. No redundant information, and the most important details are front-loaded.

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

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

For a simple tool with one parameter and no output schema, the description is nearly complete. It explains the action, effect, and return value. The only gap is the missing documentation for the 'item' parameter, which prevents complete self-containment.

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

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

The input schema has one required parameter 'item' with no description. The description mentions 'for a specific bank' but does not explicitly map this to the parameter, leaving ambiguity about what value to provide. With 0% schema description coverage, the description should have clarified the parameter's 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 action: revoke consent and delete connection data for a specific bank. It distinguishes from sibling tools like openfinance_list_connections by stating the specific verb and resource.

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

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

The description implies usage when revoking consent is needed, but does not explicitly state when to use this tool vs alternatives (e.g., when not to disconnect, prerequisites like having an active connection). No exclusions or alternatives are mentioned.

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 details the PATCH then poll mechanism, waiting up to ~60s, return fields like status, executionStatus, lastUpdatedAt, synced, and potential errors (needs_action, timed_out). Annotations only indicate non-read-only and non-destructive; the description adds rich 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?

The description is dense but well-structured, with the main action first, followed by usage guidance, parameter details, and return value explanation. It could be slightly trimmed but every sentence adds value.

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

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

For a tool with no output schema and moderate complexity (async polling, multiple parameters), the description covers usage, parameter semantics, return structure, error states, and follow-up actions. It is fully adequate for an AI agent to invoke correctly.

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

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

Schema coverage is 0%, but the description fully explains both parameters: 'items' as an array of selectors (item_id, connector_id, or connector_name) with the ability to omit for all banks, and 'wait' boolean for fire-and-forget behavior. This adds complete meaning beyond the bare schema.

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

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

The description clearly states the tool forces re-sync of connections and waits for completion. It specifies the verb (force sync), resource (connections), and distinguishes from siblings by saying 'without disconnecting/reconnecting' and referencing openfinance_get_item_status for checking timed-out syncs.

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 this tool: when a balance or transaction list looks stale. It explains the default waiting behavior and mentions setting wait:false for fire-and-forget. It also tells how to interpret results and what to do on timeout (re-check with openfinance_get_item_status). It does not contrast with all alternatives but provides enough context.

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

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

Annotations already declare readOnly, idempotent, not destructive. The description adds value by disclosing the real-time nature, array constraint, and specific error handling (warning instead of throw for CREDIT accounts). No contradictions.

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

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

Two sentences, each earning its place: first sentence states purpose and endpoint, second gives key usage details and response shape. No unnecessary words.

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

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

Given no output schema, the description explains the response shape. It also covers error cases. For a simple balance fetch tool, this is nearly complete. Could add pagination or rate limits if any.

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 sole parameter `account_ids` is explained with its type (array), size constraint (1-50), and implicit use (pass as array). Schema coverage is 0%, so the description compensates well with this context.

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

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

The description clearly states the verb 'Returns', the resource 'real-time balance payload per account id', and the HTTP endpoint. It distinguishes itself from sibling tools like openfinance_get_accounts_detail by focusing specifically on 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?

The description provides some usage guidance (array of 1-50 account_ids, error handling for CREDIT accounts) but does not explicitly state when to use this tool over alternatives. No exclusions or when-not-to-use are given.

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 behavioral context: returns extended creditData, batch shape with results/errors, no contradictions. It doesn't discuss authentication or rate limits but is sufficient for a simple read operation.

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 states purpose and endpoint, second provides usage and return format. No extraneous text, front-loaded with key information, efficient.

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

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

The tool is simple with one parameter and read-only. No output schema exists, but the description adequately describes the return shape. Given the context, no additional information is needed for correct invocation.

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

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

With 0% schema description coverage, the description compensates by specifying that account_ids must be an array of 1–50 items. It also explains the return shape, adding meaning beyond the bare schema.

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

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

The description clearly states the verb 'Returns', the resource 'full account objects including extended creditData', and distinguishes from sibling tools like openfinance_list_accounts by specifying per-ID detail. The batch nature and endpoint path are also explicit.

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 usage guidance: 'Pass `account_ids` as an array (1–50)' and hints at the batch shape. It lacks explicit when-to-use vs alternatives, but the context of sibling tools and the focus on detail implies it's for specific account detail retrieval rather than listing.

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 description adds critical behavioral context: explains that payments[] reflects payments during THIS bill's billing cycle, typically the previous bill, so cannot assume paid status. Also notes Pluggy does not return paid/status field. No contradiction with annotations.

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

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

Description is lengthy but each sentence adds value. It is well-structured: main purpose first, then exclusions, then usage tips, then output shape, then caveats. Slightly verbose but justified by the amount of necessary detail.

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

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

Tool has one parameter and no output schema, but description compensates fully: specifies output batch shape `{ results, errors }`, details returned fields, explains payments semantics and paid status. No gaps for correct 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?

Only parameter bill_ids is an array. Description explains it should be passed as array and suggests using openfinance_list_credit_card_bills to discover ids. Schema description coverage is 0%, so description compensates well by adding meaning. Could be slightly more explicit about array format, but sufficient.

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 'bill-level detail' for credit card bills by id, listing specific fields (financeCharges, payments with attributes). It distinguishes from listing transactions and other sibling tools. The verb 'Returns' and resource 'credit card bill detail' are precise.

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-level details. Specifies not for individual transactions (recommends openfinance_list_transactions). Provides prerequisite: use openfinance_list_credit_card_bills first to discover ids. Clear when-not and alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds specific status values, executionStatus, and connector metadata, and clarifies response structure. It doesn't contradict annotations.

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

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

Two sentences, first immediately states what it returns, second explains the two usage modes. No redundant information. Front-loaded with most important detail.

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

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

With one optional parameter, strong annotations, and no output schema, the description covers all needed aspects: return values, both usage patterns, and response shapes. 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?

Schema has one string parameter with no description (0% coverage). The description adds critical meaning: omitting returns aggregated result, passing filters to single bank, and specifies response format. Fully compensates for lacking schema description.

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

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

The description uses specific verb 'returns' and resource 'status of a bank connection', lists possible values (UPDATED, UPDATING, LOGIN_ERROR, etc.), and clearly distinguishes between getting status of all banks vs a single bank. This differentiates it from sibling tools like openfinance_list_connections and openfinance_provider_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 states when to omit 'item' (get all) and when to pass it (get single), including the response shape for each case. While it doesn't directly say when not to use, the context is well implied.

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=true, idempotentHint=true, and destructiveHint=false, indicating safe, idempotent read operations. The description adds crucial behavioral context: the meaning of `balance` for CREDIT varies by connector, the `name` field is the legal entity not the brand, and aggregation behavior when omitting `item`. 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 long but packed with necessary context. It is front-loaded with the main purpose and then provides detailed behavioral notes. Every sentence adds value, though some redundancy could be trimmed (e.g., repeating connector-dependent behavior). Still, it remains clear 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 complexity of the tool (two account types, connector-dependent data, aggregation pattern), the description is comprehensive. It explains what each field means, how the `bank` field should be used, the nuances of `balance` for credit cards, and references an alternative tool for standardized data. No output schema is provided, but the description covers return details adequately.

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 two parameters: `item` (string) and `type` (enum). The description provides extensive semantics: for `item`, it explains the difference between omitting it (returns accounts across all connections) and passing it (targets a single bank). For `type`, it clarifies the enum values. Since schema description coverage is 0%, the description fully compensates.

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

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

The description clearly states it returns accounts for bank connections, listing types (BANK/CREDIT), balances, and various fields. It distinguishes itself from sibling tools like openfinance_list_credit_card_bills by specifying what it provides and when to use alternatives.

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: when to omit `item` (to list across all banks) vs pass it (target a single bank), which field to use for user-facing text (`bank`), and warns that `balance` for CREDIT is connector-dependent. It also directs to openfinance_list_credit_card_bills for standardized bill amounts.

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 no destructiveness. The description adds value by confirming the response is cached (single aggregated response, no batch ids) and explaining the structure of each entry (id, description, 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 three sentences, no unnecessary words. The first sentence immediately states the core function, and the rest provide key details about response fields and relationship to another tool.

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

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

For a zero-parameter, simple list tool, the description is complete. It explains the caching behavior, output structure, and how categories connect to the update tool. No output schema is needed given the detailed 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?

There are no parameters, so the baseline is 4. The description does not need to add param info, but it does explain the output fields in detail, which is helpful for understanding how to use the tool.

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

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

The description clearly states it returns Pluggy's transaction category taxonomy, specifies the exact endpoint (GET /categories), and mentions that results are cached for the session. It distinguishes itself from sibling tools like openfinance_list_transactions by focusing on categories.

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

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

The description implicitly indicates when to use it (to retrieve categories for use with openfinance_update_transaction_category) but does not explicitly list alternatives or provide when-not-to-use guidance. The context is clear enough for an agent to decide.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds specific return fields (connector_id, item_id, bank name, add_connection_url) which is valuable 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?

Single sentence that is front-loaded with action ('Returns the saved bank connections') and is concise with no 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?

Given no output schema, the description fully explains what the tool returns. For a parameterless read-only tool, this is 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?

No parameters; schema coverage is 100%. Description adds meaning by specifying the contents of the return value, which is essential since there is no output schema.

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

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

Clearly states it returns saved bank connections with specific fields (connector_id, item_id, bank name, add_connection_url). Distinguishes from siblings like openfinance_list_accounts which list accounts, not connections.

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

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

Implies usage for retrieving stored connections, but does not explicitly provide when-to-use or when-not-to-use guidance versus other tools like connect or openfinance_disconnect_bank.

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) are consistent with the description. The description discloses complex behavioral details: payment mapping semantics, derived payment_status logic, connector asymmetry, that it returns a warning instead of failing if CREDIT_CARDS product is not enabled, and the opt-in nature of include_open_bill. 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 long but packed with necessary information for a complex domain. It uses bold and line breaks for structure. While every sentence seems valuable, some sections could be tightened without losing clarity. Still, it's well-organized overall.

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 (payments, payment_status, open_bill, future_bills, etc.), edge cases (connector asymmetry, banking limitations), and even provides derivation logic for payment_status. It covers all aspects needed for effective use.

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

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

Schema coverage is 0%, so the description carries the full burden. It explains all parameters: account_id, account_ids for batch, page/page_size (implied by bulk support), and include_open_bill with detailed effects (e.g., returns open_bill and total_pending_debt). The description adds 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 explicitly states the tool returns closed credit card bills for a CREDIT-type account, listing specific fields like dueDate, totalAmount, payment_status, etc. It clearly distinguishes from sibling tools like openfinance_list_transactions by noting that this tool provides bill-level summaries, 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?

The description provides extensive guidance on when to use the include_open_bill parameter, how to interpret payment_status, and explicitly states when to use a different tool (e.g., 'To see itemized purchases/charges per bill, use openfinance_list_transactions'). It also warns against assuming a bill is paid based on payments[] alone.

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 details return fields and simplifies error handling by noting it returns a {total:0, results:[], warning} object instead of throwing, consistent with annotations (readOnlyHint, idempotentHint). This adds useful context beyond annotations, though it could mention authentication or rate limits.

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 that front-loads the purpose but includes a long list of return fields and error handling details. While not excessively verbose, it could be more concise by separating general behavior from parameter documentation.

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 and zero parameter coverage in schema, the description should provide parameter guidance but does not. It also omits pagination behavior, default values, and clear use-case examples, leaving significant gaps for agent invocation.

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

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

Schema description coverage is 0%, and the description does not explain any of the four parameters (item, page, type, page_size). Without parameter semantics, an agent cannot reliably construct a valid request.

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 investment portfolio data for a connection, listing specific asset classes (FIIs, stocks, ETFs, fixed income, mutual funds, retirement, COE). It distinguishes itself from sibling tool 'openfinance_list_investment_transactions' by focusing on portfolio 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 does not explicitly state when to use this tool versus alternatives like 'openfinance_list_investment_transactions'. It also does not mention prerequisites (e.g., connection must have INVESTMENTS product enabled) beyond implying error handling when not enabled.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds context about return fields (quantity, value, netAmount, expenses, etc.) and bulk execution, which is beyond 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 only two sentences, front-loaded with purpose and output details. Every sentence adds value: purpose, usage guidance, bulk support. No wasted words.

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

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

Given the tool has 4 parameters, no output schema, and good annotations, the description compensates by detailing return fields and usage context. Missing pagination parameter explanation prevents a higher score.

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

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

Schema description coverage is 0%, so description carries full burden. It explains investment_id (required) and mentions investment_ids for bulk. However, pagination parameters (page, page_size) are not described, leaving them unclear.

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

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

The description clearly states the tool returns movement history for a specific investment position, listing transaction types like BUY/SELL/TAX. It distinguishes from sibling tools like openfinance_list_investments by stating it should be used after that tool to get the 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?

The description gives a clear usage sequence: 'Use after openfinance_list_investments to get the investment_id.' It also mentions bulk support. However, it does not explicitly state when NOT to use this tool versus other transaction tools like openfinance_list_transactions.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by disclosing that multiple connections are queried sequentially with rate-limit spacing and that the return format is `{ results, errors }` per connection. This goes beyond the annotations.

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

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

The description is three well-structured sentences: first states the core purpose, second explains the parameter usage, third covers the omit case. No extraneous information, every sentence earns its place.

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

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

For a read-only list tool with no output schema, the description covers what it does, how to use the only parameter, the return format, and rate-limiting behavior. It is complete given the tool's simplicity and annotation richness.

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 explains the `items` parameter: it specifies that items are connection selectors (item_id uuid, connector_id, or connector_name), that each entry corresponds to one connection, and describes the behavioral effect (sequential querying with rate limiting). 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 it lists loan contracts per bank connection, using the verb 'list' and specifying the resource 'loan contracts' and context 'per bank connection'. It does not explicitly differentiate from sibling tools like openfinance_list_accounts, but the resource name 'loans' is distinct enough.

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: pass `items` for specific connections or omit for all connections. It does not mention alternative tools, but the usage scenarios are well-defined.

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), description adds significant behavioral context: CREDIT PENDING/POSTED varies by connector, aggregation limits for search_queries, error return structure instead of throwing, bulk support via account_ids. No contradictions with annotations.

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

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

Description is lengthy but front-loaded with main purpose. Each sentence adds value. Could be more structured (e.g., bullet points), but current prose is clear and efficient. Slightly verbose but 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 7 parameters, no output schema, and multiple siblings, description is very complete. Covers error handling, edge cases (truncated, credit card sync failure), and cross-references other tools. No output schema, but success return is implicitly understood; still, a minor gap.

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

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

Schema description coverage is 0%, but description compensates well: explains from/to as ISO YYYY-MM-DD, page_size max 500, search_queries behavior (case-insensitive substring, OR semantics), and account_ids for batch. Almost fully covers all parameters with meaningful detail.

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 'Returns transactions for a bank account (BANK or CREDIT type)', specifies the resource and action. It distinguishes from sibling openfinance_list_credit_card_bills by noting that for CREDIT accounts, this is the only way to get itemized transactions, and each transaction links to a bill.

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: for CREDIT accounts, this is the only way; for open-bill total, use sibling tool. Explains behavior differences per bank and advises narrowing date range if truncated. Mentions checking connection health when total is 0. Lacks explicit when-not-to-use, but still highly informative.

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=true, idempotentHint=true, and destructiveHint=false, already indicating a safe read. The description adds valuable behavioral details: it resolves accounts internally, caps scans at 5000/account with a truncation flag, and explains the difference between monthly (compact summary) and raw (all rows) granularity.

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, starting with core purpose, then internal resolution, parameter details, use cases, and granularity trade-offs. It is informative without being overly verbose, though slightly long.

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 optional params, no output schema), the description explains the return structure for both granularities (entradas, saídas, por_mes, top_despesas, etc.) and the truncation flag. It lacks exact JSON details but provides sufficient context for an agent to understand output. Sibling comparisons are implicit but present.

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

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

Schema description coverage is 0%, requiring the description to explain parameters. It covers to/from as ISO dates, item as connector_id/connector_name/item_id, type as BANK/CREDIT filter, granularity with default 'monthly' and effects. However, top_n is only implied by 'largest N each' and not explicitly described.

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 provides consolidated cash-flow analysis for a whole bank connection in one call, distinguishing it from sibling tools like openfinance_list_transactions that likely list individual transactions without aggregation.

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 lists use cases (e.g., 'análise anual/mensal', 'fluxo de caixa') and states when to use raw granularity. It also clarifies that calling openfinance_list_accounts first is unnecessary, but does not explicitly mention alternatives like openfinance_list_transactions for raw transaction lists.

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 readOnlyHint/idempotentHint by describing return values (global indicator, degraded components, incidents) and behavior (flags affecting your banks), fully transparent.

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?

Concise, front-loaded, uses clear sentences with no redundancy; every sentence adds value.

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

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

Despite no output schema, describes all return elements (indicator, components, incidents, affected banks), fully meeting completeness for its simple input.

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

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

No parameters; schema coverage 100% so description cannot add param info, baseline 4 applies.

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

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

Clearly states it checks the LIVE operational status of the Open Finance provider, distinguishes from sibling tool openfinance_get_item_status by specifying it's provider health vs connection health.

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

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

Explicitly tells when to use (data incomplete/stale despite updated connection) and what it helps diagnose (upstream outage vs connection issue), guiding correct tool selection.

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, indicating safe operation. The description adds valuable behavior: returns connector id, access type, audience, linked connections/accounts, and connect_url; honors user's plan (PF vs PJ); and returns a hint if keywords are missing. No contradictions.

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

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

The description is a single dense paragraph that efficiently conveys purpose, usage, behavior, and parameters. It could be slightly more structured (e.g., bullet points) but contains no unnecessary words.

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

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

Given no output schema, the description thoroughly explains what is returned (connector id, access, audience, accounts, connect_url) and covers edge cases (plan filtering, missing keywords). It is self-contained and adequate for agent invocation.

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

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

With 0% schema coverage, the description fully explains both parameters: keywords is an array of strings (with examples) and is required; include_accounts is boolean and affects account inclusion in results. This adds essential meaning beyond the schema.

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

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

The description clearly states it searches bank connectors by name and returns connector details including a connect URL. It distinguishes from sibling tools like 'connect' by specifying this is for the pre-connection search step.

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 'Call this BEFORE connecting' and indicates that keywords[] is required, with a hint returned if omitted. It provides clear when-to-use guidance but does not mention when not to use or specific alternatives among the many sibling tools.

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

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

Annotations indicate a write operation (readOnlyHint=false). The description goes beyond annotations by explaining the side effect of teaching Pluggy (creating a Category Rule) and detailing batch behavior (return shape with per-item errors). No contradiction with annotations is present.

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 relatively long but every sentence serves a purpose. It front-loads the primary action, then explains parameters, side effects, and return shape. While efficient, it could be slightly more concise, but 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 the tool's complexity (batch update with side effects), the description covers all essential aspects: purpose, parameter details, side effect (category rule creation), return shape with error handling, and prerequisites. No output schema exists, but the return shape is described. No gaps are evident.

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

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

Schema description coverage is 0%, but the description fully explains the 'items' parameter as an array of objects with transaction_id and category_id, and specifies where each ID comes from. This compensates completely for the lack of schema description.

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 'corrects' and the resource 'category of one or more transactions'. It distinguishes from sibling tools by specifying how to obtain transaction_id and category_id from openfinance_list_transactions and openfinance_list_categories, and contrasts with automatic categorization.

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 to fix miscategorized transactions and improve categorization accuracy going forward'. It also provides prerequisites (transaction_id from list_transactions, category_id from list_categories) and explains side effects (creates a Category Rule). This gives clear guidance on when and how 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 idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description does not add behavioral context beyond stating the purpose. With annotations covering key traits, this is adequate but lacks extra detail like side effects or response behavior.

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

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

The description is a single sentence that front-loads the purpose. It is concise, but could benefit from a clearer separation of purpose and usage instructions. Nonetheless, it is efficient.

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

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

Given the simple nature of the tool (feedback) and the presence of annotations, the description is minimally complete. However, it lacks parameter details and does not explain what happens after submission, which could confuse an agent.

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

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

Schema description coverage is 0%, and the description only mentions 'conversation array' without explaining the purpose of the 'message' (required) or 'context' parameters. This is insufficient for correct invocation, as the agent must guess the role of each field.

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

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

The description clearly states the tool is for reporting bugs, missing features, or sending feedback. It specifies to include the conversation array. This distinguishes it from all sibling tools, which are primarily for authentication, finance, 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?

The description gives a specific usage instruction ('Include the conversation array with recent messages for reproduction'), but does not provide when-to-use or when-not-to-use context, nor does it mention alternative tools. The usage is implied but not explicit.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, meaning the description only needs to add specific context. It adds what versions are shown but nothing beyond that. For a simple readonly tool, this is sufficient but not exceptional.

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?

A single, complete sentence with no filler. Every word is necessary and the information is front-loaded.

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

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

Given zero parameters, simple annotations, and no output schema, the description is entirely sufficient. It fully covers what the tool does without needing additional return value explanation.

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 with 100% schema coverage, so baseline is 4. The description adds no parameter details, but none are needed. This score reflects the appropriate baseline.

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 specifies the tool's action ('Show') and the exact resources ('current MCP platform and adapter versions'). It is a specific verb+resource that distinguishes it from all listed 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 implicitly communicates the usage context: call this when you need to know current platform and adapter versions. No explicit when-not-to-use or alternatives, but given the tool's simplicity and uniqueness among siblings, it's 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by specifying the exact information returned (installed MCPs, connection status, catalog tools), going beyond the safety profile. No contradictions.

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

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

The description is a single sentence of about 20 words, front-loaded with the core purpose, and contains no filler words or redundant information.

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

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

For a tool with no parameters and no output schema, the description sufficiently explains what it returns—installed MCPs, connection status, and catalog tool counts—covering all necessary context.

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

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

There are no parameters (schema coverage 100%), so description's job is minimal; baseline for 0 params is 4. Description adds no parameter info, which is appropriate.

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

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

The description uses a specific verb ('Returns') and resource ('current toolkit state'), listing exact details (installed MCPs, connection status, catalog tools count), which clearly distinguishes it from sibling tools like authenticate or finance operations.

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

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

The description implies usage for checking toolkit state but provides no explicit guidance on when to use it versus alternatives, nor does it mention any preconditions or exclusions.

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