Conta Bemol MCP

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

Discloses behavioral traits beyond annotations: explains that the tool can establish a permanent or session-based connection, and describes the token flow. No contradiction with annotations (idempotentHint=true is consistent with setting a token).

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 redundancy, front-loaded with context, and efficiently conveys all necessary information without excess.

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 authentication tool with good annotations, the description covers purpose, usage modes, parameter semantics, and context completely. No output schema needed; the tool's behavior is fully described.

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?

Though schema coverage is 0%, the description adds meaning to the single optional 'token' parameter by explaining it as a JWT and that omitting it returns a login link. This compensates well, but lacks format details like token structure.

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 via browser login and token. It specifies the context (MCP.AI for IDE agents) and distinguishes itself from sibling tools like connect by focusing on token-based authentication.

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

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

Provides explicit guidance on two methods: adding the token to config for permanent access or pasting it for session-only login. It also explains how to call the tool with or without arguments, giving clear when-to-use instructions.

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 value by detailing behavior in two states (all connected vs missing credentials), including what URLs are returned. This context 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?

Two sentences, front-loaded with action and resource. Every sentence adds information without redundancy. Efficient and clear.

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

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

Covers key behavioral outcomes for different states, which is sufficient for a status-check tool with no parameters and no output schema. Could mention if connect_url is always returned or only when missing credentials, but overall 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 exist, so schema coverage is 100%. Description adds no parameter info, which is acceptable. Baseline for 0-param tools is 4.

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

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

Description clearly states tool returns connection status and URLs, distinguishing between connected and missing credentials states. Verb 'Returns' specifies action, resource is connection status, and it differentiates from sibling tools like 'authenticate'.

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

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

Description implies usage for checking connection status before authentication, but lacks explicit guidance on when to use this tool vs alternatives like 'authenticate' or a more specific status tool. No 'when-not-to-use' or alternative names 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 provide basic hints (readOnlyHint=false, etc.), but the description adds significant detail: invoke works for non-installed MCPs, returns connect/checkout links, explains install vs one-off use, and notes permission requirements. It does not 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?

The description is relatively long but well-structured, front-loaded with the most critical information. Each sentence adds value, though some redundancy exists (e.g., invoke behavior repeated). Could be slightly more concise 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 the tool's complexity (13 parameters, many actions, no output schema), the description covers the overall flow, when to use each action, and key behaviors (invoke links, permissions). It lacks details on lesser-used parameters and return formats, but provides sufficient context for an agent to operate correctly in most scenarios.

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 partially by explaining the purpose of core parameters (action, query, mcp_id, tool_id, arguments) in the flow. However, many parameters (e.g., limit, message, immediate, tier_slug, conversation, request_name, etc.) are not explained, limiting usefulness for complex invocations.

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 marketplace for discovering and running MCPs/tools. It specifies it should be used first when user wants a capability, and outlines the core flow (search, describe, invoke, install), distinguishing 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?

Explicitly states when to use this tool (before external registries) and when to prefer invoke vs install. Also differentiates from list_tools and mentions prerequisites like workspace owner/admin for writes.

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 readOnlyHint=false. The description adds context: consent revocation, data deletion, and return of a reconnect URL. It does not contradict annotations and provides behavioral details beyond them, though it could mention irreversibility or permissions.

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

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

Three concise sentences, each adding value: action, effect, and return value. No unnecessary words, and front-loaded with key information. Efficiently structured for quick comprehension.

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

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

Given the simple tool (1 param, no output schema, annotations present), the description covers the main purpose and return. However, it lacks parameter clarification and error handling context, making it slightly incomplete for an agent to fully understand 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?

The input schema has one required parameter 'item' with type string and no description. The tool description does not clarify what 'item' represents (likely a bank identifier), leaving ambiguity. With 0% schema coverage, the description should compensate but fails to do so.

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

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

The description clearly states the tool revokes consent and deletes connection data for a specific bank, making data unavailable. The verb 'revokes' and 'deletes' precisely describe the action, and the resource 'bank' is specified, distinguishing it from sibling tools like list_connections or get_item_status.

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

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

The description implies usage for disconnecting a bank and mentions a return URL for reconnection, but does not explicitly state when to use versus alternatives or provide exclusion criteria. Lacks guidance on prerequisites or scenarios where this tool should not be used.

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

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

The description provides extensive behavioral details beyond annotations: waiting up to 60s, polling mechanism, return values including error states like needs_action and timed_out. No contradiction with annotations.

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

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

Front-loaded with action and key behavior, then structured details. Every sentence adds value without redundancy.

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

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

Given no output schema, the description thoroughly covers return structure and possible states. No gaps for a 2-parameter tool.

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

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

Despite 0% schema description coverage, the description fully explains both parameters: 'wait' for fire-and-forget vs waiting, and 'items' as array of selectors or omitted for all connections.

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

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

The description clearly states it forces a re-sync and waits for completion. It distinguishes from sibling tools like openfinance_get_item_status by describing a different behavior.

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 (stale balance/transactions), what it avoids (no disconnect/reconnect), and mentions alternative (openfinance_get_item_status for timed_out).

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 value beyond annotations by detailing the real-time nature, the specific error handling for credit accounts (structured warnings instead of throwing), and the response shape (`{ results: [...], errors: [...] }`). No contradictions with annotations.

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

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

Three sentences that are front-loaded with the purpose, followed by parameter guidance and edge-case handling. Every sentence adds essential information without redundancy.

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

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

The description covers the tool's input, behavior, and output shape adequately given the simple parameter set and absence of output schema. It does not mention prerequisites like authentication, but that may be implied by the broader context (sibling tools include authenticate).

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 the parameter name (`account_ids`), type (array), and size constraints (1–50). It could provide more context about the format of the account IDs, but the given info is sufficient for correct 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 verb ('returns'), resource ('real-time balance payload per account id'), and even the endpoint ('GET /accounts/:id/balance'). It distinguishes from sibling tools like openfinance_list_accounts, which likely lists accounts rather than fetching their 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 gives explicit parameter instructions ('Pass `account_ids` as an array (1–50)') and explains behavior for credit accounts (BALANCE_FETCH_ERROR with warnings). However, it does not explicitly state when to use this tool versus alternatives like openfinance_list_accounts, though the context strongly implies 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds batch output shape and error handling ({ results, errors }), providing full transparency beyond annotations.

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

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

Three sentences covering purpose, parameter usage, and output shape. No redundant information, highly efficient.

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

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

Given low complexity, comprehensive annotations, and clear descriptions of input/output, the description is complete for an agent to use the tool correctly without additional 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?

Despite 0% schema coverage, the description clarifies the parameter 'account_ids' must be an array of strings (account IDs) and constrains size to 1–50, fully compensating for missing 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?

Clearly states it returns full account objects with extended creditData per account ID, distinguishing from listing tools like openfinance_list_accounts. Specifies the endpoint and batch behavior.

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 implied usage context: use this for detailed account info by ID, as opposed to listing. Mentions batch size limit (1–50) and output shape, helping agent decide when to use. Lacks explicit alternative comparisons.

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

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

The description goes beyond annotations by explaining the semantics of payments[] (not a paid status), that Pluggy does not return paid status, and the batch response shape. Annotations provide safety profile but this description adds crucial interpretive context. 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 front-loads the purpose and immediate behavior, then provides usage guidelines and caveats. It is not overly verbose given the complexity, but could be slightly trimmed. Overall, well-structured.

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

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

Without an output schema, the description provides a list of fields for payments[] and mentions financeCharges. It covers the batch shape, error handling, and the critical behavioral nuance about payment timing. The only gap is a more explicit description of financeCharges fields, but overall it is sufficiently complete for an agent to 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?

The input schema has only one parameter with no description. The description adds essential context: how to obtain valid bill_ids (via sibling tool), and that they correspond to the :id path parameter. It also notes the batch shape. This significantly supplements 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 starts with 'Returns bill-level detail for one or more credit card bills by id' and immediately lists the fields. It contrasts with sibling tools by noting what is not included (individual transactions) and directs to openfinance_list_transactions. This provides precise purpose and differentiation.

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

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

The description gives explicit guidance: use openfinance_list_credit_card_bills first to discover bill_ids, use openfinance_list_transactions for itemized transactions, and prefer the sibling tool for payment status. It also warns about misinterpreting payments[]. This fully addresses when to use this tool and when not to.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description need not repeat that. It adds behavioral context about the return structure (returns `{ count, items }` when omitting `item`) and the status field. This is sufficient for a read-only tool with simple 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?

Two sentences with no wasted words. The first sentence states the core purpose and outputs. The second sentence explains the key usage distinction. Highly efficient.

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

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

Given the tool has one optional parameter, no required fields, no output schema, and no nested objects, the description covers all necessary context: what the tool returns, how to use `item`, and the response shape for the no-`item` case. It is complete for an agent to select and 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?

The schema has one optional parameter `item` with no description (0% coverage). The description fully explains its purpose: omit for all banks, pass for a single bank. This adds critical meaning that the schema lacks, enabling correct invocation.

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 specific status values (UPDATED, UPDATING, LOGIN_ERROR) and additional fields (executionStatus, connector metadata). It also distinguishes between the two modes of operation (all banks vs. single bank), which differentiates it from siblings like openfinance_list_connections that might return a list without detailed status.

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

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

The description provides explicit guidance: omit `item` to get status of all linked banks, pass `item` for a single bank. It does not explicitly mention when not to use this tool or compare to alternatives like openfinance_list_connections, but the usage is clear from the 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?

Goes beyond annotations by detailing critical behavioral nuances: credit card 'balance' is connector-dependent and should not be treated as 'this month's bill', and explains 'creditData' fields like 'balanceCloseDate' and 'balanceDueDate'. This adds significant 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 lengthy but well-organized, front-loading the main purpose and then adding important caveats. Every sentence adds value, though some could be tightened for brevity.

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 comprehensively explains return fields (balance, number, type, subtype, bankData, creditData), plus contextual fields like 'bank' and 'connector_id'. It also covers edge cases and cross-references sibling tools, making it complete for the tool's complexity.

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

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

Despite 0% schema description coverage, the description thoroughly explains both parameters: 'item' (optional, for single bank vs. all) and 'type' (enum for BANK/CREDIT). This fully compensates for the schema's lack of parameter 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?

Description clearly states it returns accounts for bank connections, listing specific types (BANK, CREDIT) and the data fields included. It also distinguishes between listing all accounts vs. a single bank, making the purpose highly 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?

Explicitly explains when to omit vs. pass the 'item' parameter, and provides direct guidance on using the sibling tool 'openfinance_list_credit_card_bills' for standardized billing data, effectively guiding 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 indicate safety (readOnlyHint, idempotentHint). Description adds caching behavior and explains output fields, which is useful context beyond annotations.

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

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

Two efficient sentences that front-load the purpose and provide necessary detail. 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?

The description fully explains the return value, caching, and field semantics. With no output schema, this is complete for a zero-parameter tool.

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

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

No parameters exist, so schema coverage is 100%. The description adds value by detailing the output structure, which is necessary since no output schema is provided. Baseline 4 is appropriate.

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

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

The description clearly states the tool returns 'Pluggy's transaction category taxonomy' and specifies the GET endpoint. It distinguishes from sibling tools by focusing on categories and noting the cache and field details.

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 retrieving category IDs to use with openfinance_update_transaction_category. It could be more explicit about when to call (e.g., once per session) but is generally clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds context about the return value (connection details and add_connection_url) but no further behavioral traits (e.g., latency, rate limits, error conditions). With annotations covering safety, a 3 is appropriate.

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

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

Single sentence, no fluff. All words add value, clearly stating the tool's output.

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 no parameters and no output schema, the description adequately describes what is returned. Could mention if list can be empty or if pagination applies, but given the tool's simplicity, it is mostly complete.

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

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

Input schema has no parameters, baseline is 4 per rules (0 params = baseline 4). Schema description coverage is 100%, so description doesn't need to add parameter info.

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

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

The description clearly states that the tool returns saved bank connections, listing specific fields (connector_id, item_id, bank name, add_connection_url). This distinguishes it from sibling list tools like list_accounts or list_transactions.

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

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

No guidance on when to use or not use this tool versus alternatives. No mention of prerequisites (e.g., needing authentication first) or scenarios where this is the correct choice among many similar list 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 (readOnlyHint, idempotentHint, destructiveHint) are consistent. The description adds significant behavioral context: billing cycle payment assignment rules, derived payment_status algorithm, connector asymmetry for open bills, and the fact that include_open_bill triggers an extra scan. 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 well-structured with clear sections and front-loaded main purpose. Every sentence adds value, though some parts (e.g., detailed payment logic) could be more concise. The 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 no output schema, 5 parameters, and zero schema descriptions, the description covers return fields, derived data, edge cases, cross-referencing to other endpoints, and warnings. It is comprehensive enough for an AI agent to use correctly.

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

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

With 0% schema description coverage, the description compensates well by explaining each parameter's purpose and defaults for include_open_bill and account_ids (bulk). Page and page_size are implied but not explicitly described as optional; slight gap prevents a 5.

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

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

The description starts with a clear verb ('Returns') specifying the resource ('CLOSED credit card bills for a CREDIT-type account') and lists key fields. It distinguishes from sibling tools like openfinance_get_credit_card_bill and openfinance_list_transactions by detailing the derived payment_status and cross-referencing.

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 and when-not-to-use guidance, including the logic behind payment_status vs raw payments, the opt-in nature of include_open_bill, and warnings about connector asymmetry. It explicitly instructs never to mark a bill as 'vencida' categorically and explains fallback behavior.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable transparency by detailing the error-handling behavior (returns { total, results, warning } instead of throwing) and listing specific return fields, going beyond the annotations.

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

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

The description is a single paragraph that efficiently conveys the tool's purpose and return structure. While it could be more structured (e.g., bullet points for fields), it is concise and 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 the lack of output schema and high parameter count (4), the description should document parameters and fully cover return fields. It partially covers returns but omits parameter details, making it incomplete for agents to correctly invoke the tool.

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

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

The input schema has 4 parameters with 0% description coverage, and the description provides no information about the parameters (item, page, type, page_size). It fails to add any meaning beyond the schema, leaving agents without guidance on parameter 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 returns investment portfolio data for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.) and fields (balance, amount, rates, etc.). It distinguishes from sibling tools like openfinance_list_investment_transactions and openfinance_list_accounts by focusing on the portfolio overview.

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 retrieving investment portfolios but does not explicitly state when to use this tool versus siblings like openfinance_list_investment_transactions. It lacks guidance 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description need not repeat safety. It adds value by enumerating returned fields (e.g., quantity, value, expenses) and transaction types. Does not address pagination behavior despite page/page_size parameters, but overall good disclosure beyond annotations.

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

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

Two concise paragraphs: first covers purpose, transaction types, and fields; second provides usage guidance and bulk support. Every sentence earns its place with no redundancy or fluff. Front-loaded with the essential 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?

Given 4 parameters (1 required), no output schema, and annotations present, the description covers purpose, usage, main parameters, and return fields. It lacks mention of pagination behavior or error handling, but for a read-only list tool, it is largely complete and meets agent needs.

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

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

Schema description coverage is 0%, so description must compensate. It explains investment_id (required) and investment_ids (bulk) clearly, but omits any description of page and page_size parameters. This partial coverage lifts it above a 2 but insufficient for a higher score since half the parameters remain unexplained.

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, listing transaction types (BUY, SELL, TAX, etc.) and fields. It distinguishes itself from siblings like openfinance_list_investments by indicating sequential usage ('Use after...') and from general transaction tools by focusing on investment-specific data.

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

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

Explicitly advises to use after openfinance_list_investments to get the investment_id, providing clear context. Mentions bulk support with investment_ids. While it doesn't explicitly state when not to use, the context from siblings and the specific focus on investment transactions implies appropriate usage. Lacks explicit exclusions but is otherwise helpful.

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

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

Discloses GET method, sequential per-connection querying, rate-limit spacing, and return format (results/errors). Adds value beyond annotations (readOnlyHint, idempotentHint, destructiveHint). 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, front-loaded with purpose, then parameter details. No redundant phrases. 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?

Complete for a simple read-only tool with one optional parameter and no output schema. Covers purpose, parameter usage, rate-limit behavior, and 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?

With 0% schema description coverage, the description fully explains the 'items' parameter: connection selectors (item_id uuid, connector_id, connector_name), how omitting it works, and behavior for multiple connections.

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 lists loan contracts per bank connection (GET /loans). Specifies resource and grouping, distinguishing from sibling list tools for other financial data.

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

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

Explicitly instructs when to pass 'items' (connection selectors) and when to omit (list all). Mentions sequential querying with rate-limit spacing. Lacks explicit alternatives but sufficient for the tool's function.

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?

Disclosed nuances beyond annotations: PENDING vs POSTED variance by connector, error handling returns warning/error, bulk support, search_queries aggregation limit and truncation. Annotations already indicate read-only and idempotent; description adds significant behavioral context.

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

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

Dense but well-structured. Starts with core purpose, then credit specifics, then parameters, then error/truncation notes. Slightly verbose but each sentence adds necessary information. Could be more concise by grouping credit details, but 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?

Completeness is high given complexity: covers both account types, differentiates from siblings, explains all parameters, error handling, and bulk support. Even without output schema, the description provides sufficient context for correct usage.

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

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

With 0% schema coverage, the description fully compensates by detailing all 7 parameters: account_id (required), from/to (ISO date), page/page_size (max 500), search_queries (case-insensitive OR substring), and account_ids (bulk). No parameter is left unexplained.

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

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

The description clearly states it returns transactions for BANK or CREDIT accounts, with specific credit card behavior. It distinguishes itself from sibling tools by explaining when to use this vs. list_credit_card_bills.

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

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

Provides explicit guidance: for credit accounts, this is the only way to get itemized transactions; for standardized totals use list_credit_card_bills. Also advises to check connection health if total is 0 and to narrow from/to if truncated.

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 important behavior beyond annotations: scan caps at 5000/account with truncation flag, and granularity:'monthly' returns compact summary. Annotations (readOnlyHint, idempotentHint, destructiveHint=false) are consistent, 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 verbose; however, all sentences add value. It is well-structured with main purpose first, then parameter details, usage examples, and behavior notes. Minor room for trimming.

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 complexity, the description is remarkably complete. It explains return format for monthly granularity (entradas, saídas, saldo_liquido, por_mes, top_despesas/recebimentos, by_account) and mentions the truncation flag. 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?

With 0% schema coverage, the description fully explains all six parameters: item (accepts connector_id/name/item_id, omit for all), from/to (ISO dates), granularity (monthly vs raw), type (BANK/CREDIT), and top_n (implied by top_despesas/recebimentos). Adds meaning beyond schema enums and types.

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

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

The description clearly states the tool provides consolidated cash-flow analysis for a bank connection in one call. It distinguishes from siblings by explaining it internally resolves accounts and fans out transactions, eliminating the need for prior calls like openfinance_list_accounts.

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

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

Explicitly tells when to use (e.g., 'análise anual/mensal', 'fluxo de caixa') and when not to (e.g., raw itemized rows require granularity:'raw'). It advises against calling openfinance_list_accounts first and explains omitting item analyzes all linked banks.

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

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

The description adds significant behavioral context beyond the annotations (readOnlyHint, idempotentHint, destructiveHint false). It explains that the tool returns a global indicator, degraded components, open incidents, and 'your_banks_affected' which flags incidents affecting the user's connected banks. This fully discloses the tool's behavior and outputs.

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 is front-loaded with the primary purpose. While it is relatively long, every sentence adds value, covering usage, return fields, and differentiation from siblings. Minor redundancy exists (e.g., mentioning 'upstream outage' and 'provider-side problem' similarly), but overall it is well-structured and informative.

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

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

Given the tool has 0 parameters and no output schema, the description completely covers its functionality. It explains the input (none), the output structure (global indicator, degraded components, open incidents, your_banks_affected), and when to use it. There are no gaps; the agent has all necessary context 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?

The tool has 0 parameters, so the input schema provides no information. The description compensates by explaining what the tool checks and returns in detail. According to the guidelines, 0 parameters gives a baseline of 4, and the description adds value by clarifying the tool's function and output, making it easy for the agent to understand when to invoke it.

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

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

The description clearly states the tool checks the LIVE operational status of the Open Finance provider's public status page. It explicitly distinguishes this from the sibling tool openfinance_get_item_status which checks the user's own connection. The verb 'checks' and specific resource 'provider health' make the purpose unambiguous.

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

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

The description provides explicit when-to-use guidance: use when data looks incomplete or stale even though a connection shows UPDATED. It tells the agent to differentiate provider-side problems from connection problems. It also contrasts with the sibling tool openfinance_get_item_status, offering clear context for 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 indicate readOnly and idempotent. Description adds that it honors user's plan (PF hides PJ) and provides a hint when keywords are empty, adding value beyond annotations.

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

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

The description is packed with information but could be better organized into bullet points. Still, it is relatively concise and avoids 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 no output schema, the description enumerates return fields (id, access, audience, connections, accounts, connect_url) and plan behavior, making the tool's output fully understandable.

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 adds meanings: keywords[] with examples and include_accounts effect. Both parameters are explained sufficiently.

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 it searches bank connectors by name, returns specific fields, and distinguishes from siblings like 'connect' and 'marketplace' by providing a connect_url.

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?

Clear guidance: 'Call this BEFORE connecting' and explains behavior when keywords are omitted (returns a hint, never dumps catalog). Explicit when-not-to-use scenario is covered.

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

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

The description fully discloses the side effect of creating a Category Rule that affects future transactions, and explains the batch error handling. Annotations only provide readOnlyHint=false, so the description adds substantial behavioral context.

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

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

The description is efficiently structured: it starts with the primary purpose, then provides usage guidance, behavioral impact, and response format. Every sentence adds value without redundancy.

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

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

Given the lack of output schema, the description adequately covers return values and error handling. It mentions prerequisites (IDs from other tools) but does not discuss authentication or rate limits. Still, it is largely complete for practical use.

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

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

Schema coverage is 0%, but the description adds meaning by explaining the structure of the items array, the source of IDs, and the batch response shape. It could be improved by specifying ID formats, but the explanation is still valuable.

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 corrects transaction categories with a specific HTTP method (PATCH). It distinguishes itself from sibling tools like list_transactions and list_categories, which are read-only, by focusing on the update action.

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

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

The description provides clear guidance on when to use the tool ('fix miscategorized transactions') and how to obtain the required IDs from sibling tools. It lacks explicit when-not-to-use or alternative tools, but the context is sufficient for an agent to understand 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 indicate the tool is idempotent and non-destructive, but the description adds no behavioral details beyond the action. It does not disclose what happens after reporting (e.g., ticket creation or limitations).

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

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

The description is very short (two sentences) and gets to the point. It could be slightly more structured but is not verbose.

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

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

Given no output schema and minimal annotations, the description lacks completeness. It does not specify return values, required permissions, or how the feedback is processed, leaving the agent uncertain.

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 the 'conversation' parameter is hinted at in the description, while 'message' (required) and 'context' are not explained. Schema descriptions are absent (0% coverage), so the description should compensate but largely does not.

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

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

The description clearly states the tool's purpose: reporting bugs, missing features, or sending feedback. This is specific and distinguishes it from sibling tools which are primarily OpenFinance or system 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 advises to include the conversation array for reproduction, providing some usage context. However, it does not explicitly state when to use this tool versus alternatives or any exclusions.

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, so the safety profile is covered. The description adds the specific information returned (platform and adapter versions) but does not disclose any additional behavioral traits beyond what annotations provide.

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

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

Single sentence, no unnecessary words, perfectly front-loaded with the function. Every word earns its place.

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

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

Given the tool is simple with no parameters and no output schema, the description combined with annotations fully covers what the tool does and its safety profile. No additional information is needed.

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 schema coverage is 100%. The description does not need to add parameter information because none exist. Baseline score of 4 is appropriate as the schema handles all param semantics.

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

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

The description clearly states the tool shows current MCP platform and adapter versions. The verb 'show' combined with specific resource 'platform and adapter versions' makes the purpose unmistakable, and no sibling tool duplicates this function.

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 version information is needed, and given the absence of similar tools among siblings, no explicit when-not-to-use guidance is necessary. The context is clear enough 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 already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's burden is lower. The description adds value by detailing the return content (installed MCPs, status, catalog counts), which is not covered by 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 a single sentence that is concise and front-loaded, containing no unnecessary words. It efficiently communicates the tool's purpose and return 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 tool has no parameters and no output schema, the description provides sufficient detail about what the tool returns. It tells the agent exactly what to expect (installed MCPs, connection status, catalog tool counts), making it complete for this simple 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 no parameters (0), so baseline is 4 per calibration. The description does not need to add parameter information as the schema is already complete.

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

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

The description clearly states the tool returns the current toolkit state, including installed MCPs, connection status, and catalog tool counts. It uses a specific verb ('returns') and resource ('toolkit state'), and distinguishes itself from sibling tools which handle financial operations or authentication.

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

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

The description implies usage for inspecting toolkit state, and among siblings, no similar tool exists, so no exclusion is needed. However, it does not explicitly state when to use or not use this tool, which would improve guidance.

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