Banco do Brasil MCP

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

Beyond annotations (idempotent, non-destructive), the description discloses two behavioral modes: returning a link when no args, and logging in with a token. It explains the permanent vs session distinction, 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 informative but slightly verbose. It is front-loaded with key info and every sentence adds value. Could be tightened slightly, but overall well-structured.

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

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

Given the simple tool (1 optional param, no output schema), the description covers the main behaviors and use cases. It lacks explicit error handling or response details, but is adequate for an agent.

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

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

The single optional parameter 'token' is explained in context: if provided, it is used for session login; if omitted, the tool returns a link. This adds meaning beyond the schema, even though schema coverage is 0%.

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

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

The description clearly states this tool is for authentication, specifically for IDE agents. It specifies the action (log in, copy token) and resource (MCP.AI server). No sibling tool handles authentication, so it is well-distinguished.

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

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

The description provides clear usage guidance: two methods (permanent config or session login) and how to invoke with or without the token parameter. It implicitly tells when to use each method, though it does not explicitly list when not to use the tool.

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

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

Beyond annotations (readOnlyHint, destructiveHint, idempotentHint), the description adds specific behavioral details: returns authenticated:true with empty pending[] when all providers connected, or connect_urls when credentials missing. This provides clear expected outcomes.

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

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

Two sentences, no wasted words. Front-loaded with key information ('Returns connection status and URLs'), then elaborates with conditional details.

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

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

Despite no output schema, the description fully covers the two possible response scenarios. For a parameterless tool, this is complete and sufficient for an agent to understand what to expect.

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

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

Tool has 0 parameters with 100% schema coverage (empty properties). Baseline 4 applies as description needs no additional parameter info. Description does not repeat schema content.

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 uses specific verb 'returns' and clearly states the resource (connection status and URLs). It distinguishes two states (all providers connected vs. missing credentials) and implicitly differentiates from siblings like 'authenticate' (which performs authentication) and 'openfinance_list_connections' (which lists 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?

Description implies usage for checking connection status but does not explicitly state when to use this tool versus alternatives like 'authenticate' or other connection-related tools. No when-not or alternative guidance is provided.

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

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

Beyond annotations (readOnlyHint=false, openWorldHint=true), the description adds critical behavioral details: invoke works without installing, returns connection/auth links if needed, and install/uninstall/subscribe/cancel require owner/admin. No contradiction with annotations.

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

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

The description is dense but well-structured, starting with the tool's importance, then core flow, then key nuances. Every sentence adds value, though it could be slightly more compact with bullets. Still efficient for the 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 and 13 parameters, the description provides a solid overview of the tool's capabilities and usage patterns. It misses details on parameter combinations and output formats, but covers the main workflows sufficiently for an agent.

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

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

With 0% schema description coverage, the description compensates by explaining the core flow (search, describe, invoke) and key parameters like action, mcp_id, tool_id. However, not all 13 parameters are explicitly described (e.g., limit, immediate, arguments format). Still adds significant meaning beyond the empty 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 is 'THE official mcp.ai marketplace' for discovering and running MCPs/tools. It distinguishes from sibling tools (mostly openfinance_* and authentication tools) by being the primary catalog and execution interface for MCPs.

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 to use this tool FIRST before external registries. Provides clear guidance on when to use search, describe, invoke vs install, and notes that install requires workspace owner/admin. Gives specific conditions for invoke returning connect or checkout links.

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 mark destructiveHint=true, and the description adds context: data will no longer be available and a reconnection URL is returned. This explains the destructive nature beyond the annotation.

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

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

Three sentences with no wasted words. The main action and key consequences are front-loaded, achieving conciseness without sacrificing clarity.

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

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

Given no output schema and minimal annotations, the description covers the primary effect and return value. However, it omits the parameter meaning and any prerequisites, making it only minimally complete for a 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?

Schema coverage is 0% with one 'item' parameter of type string. The description says 'specific bank' but does not clarify what the parameter represents (e.g., bank ID or name), leaving ambiguity for the agent.

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

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

The description clearly states that the tool revokes Open Finance consent and deletes connection data for a specific bank. It distinguishes from siblings like openfinance_list_connections by specifying deletion, and mentions returning a reconnection 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?

The description implies when to use (to disconnect a bank), but provides no explicit guidance on when not to use or alternatives among the many sibling tools. Adequate but lacks comparative 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 don't fully describe behavior (no readOnly/ destructive hints). Description adds: sync without disconnecting, waits up to 60s, returns results with status fields, and explains edge cases like needs_action and timed_out.

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 key action and purpose. Somewhat long but each sentence adds value. Minor redundancy could be trimmed.

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

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

Given no output schema, description fully covers return format, error states, and polling behavior. Provides complete context for a complex tool.

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

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

Schema has 0% coverage, but description fully explains both parameters: items array can take item_id, connector_id, or connector_name; omit to sync all. Wait parameter: false for fire-and-forget.

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

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

The description clearly states the tool forces a bank to re-sync connections and waits for completion. It specifies the verb 'forces sync' and resource 'bank connections', distinguishing it from siblings like openfinance_get_item_status.

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

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

Explicitly tells when to use this tool: when balance or transaction list looks stale. Provides alternatives: fire-and-forget with wait:false, and re-check with openfinance_get_item_status on timeout.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so no destructive behavior. Description adds valuable context: it warns about CREDIT accounts returning BALANCE_FETCH_ERROR as a warning instead of throwing, and specifies the response shape with results/errors. This goes beyond annotations by explaining error handling and output format.

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 with no fluff. First sentence states purpose and resource, second adds parameter guidance, third provides response shape. Front-loads the key action returns real-time balance. 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 simple one-parameter tool with no output schema, the description is complete. It covers the return format (results/errors), special behavior for credit accounts, and parameter constraints. Given the tool's low complexity, no additional detail 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?

Schema coverage is 0%, but description adds essential meaning: 'Pass `account_ids` as an array (1–50)' clarifies the format and size constraint (1 to 50 items), which the schema lacks (no min/max). This compensates for the lack of schema description, though it doesn't explain what the strings represent (account IDs), which is deducible from the name.

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

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

Description clearly states it 'Returns real-time balance payload per account id' with specific HTTP verb and resource (GET /accounts/:id/balance). The phrase 'per account id' differentiates it from sibling tools like openfinance_list_accounts, which list accounts, or openfinance_get_accounts_detail, which likely returns more detailed 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?

Description implies usage for fetching real-time balances by account ID but does not explicitly state when to use vs alternatives. It mentions handling CREDIT accounts with a structured warning, which is a usage nuance, but lacks explicit when-not-to-use or alternative tool names.

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

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

Annotations already declare readOnlyHint true, idempotentHint true, destructiveHint false. The description adds value by describing batch shape `{ results, errors }` and the array parameter constraint, which are beyond 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?

Two sentences with no redundant information. The first sentence covers the core purpose and endpoint; the second covers input and output shape. Minimal and 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 one parameter and no output schema, the description covers the essential details: input format, constraints, and response shape. It lacks some nuance about error handling or specific fields but is mostly complete.

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

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

Schema has 0% description coverage, but the description explains the parameter: an array of account IDs (1–50) and the response shape. This effectively compensates for the missing schema descriptions.

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

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

The description clearly states the tool returns full account objects including extended creditData per ID, and specifies the HTTP verb and endpoint (GET /accounts/:id). It distinguishes from sibling tools like openfinance_list_accounts by emphasizing detailed data.

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

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

The description provides context for when to use the tool (when needing full account objects by IDs) and specifies batch size limits (1–50). However, it does not explicitly state when not to use it or name alternatives like openfinance_list_accounts.

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

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

Beyond annotations (readOnlyHint=true), the description adds critical behavioral context: does NOT return individual transactions, explains payments[] caveat (previous bill), and notes that Pluggy lacks a paid/status field. This prevents misinterpretation.

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, front-loading the core purpose, then caveats and usage details. It is slightly long but every sentence adds value; could be slightly more concise without loss.

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

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

Given no output schema, the description covers the return shape (`{ results, errors }` batch) and key output fields. It also warns about payment timing and recommends an alternative for paid status. 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?

With 0% schema coverage, the description fully explains the bill_ids parameter: it's an array of bill IDs to query, and how to obtain them via openfinance_list_credit_card_bills. This adds all necessary 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 it returns bill-level detail for credit card bills by id, listing specific fields like financeCharges and payments. It distinguishes from the sibling tool openfinance_list_transactions, which get itemized transactions.

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

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

Explicitly says to use openfinance_list_credit_card_bills first to discover ids and use openfinance_list_transactions for itemized transactions. Also explains the batch shape and the limitation about payments reflecting previous bills.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context by explaining the two response formats (single bank vs. list with count and items) and the types of data returned (status, executionStatus, connector metadata). 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 consists of two sentences, both front-loaded with the core purpose and immediately followed by usage variations. Every sentence adds value with no redundancy or 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 the tool has one optional parameter, no output schema, and rich annotations, the description is largely complete. It covers the return data types and two distinct response patterns. It could optionally mention that the status values are strings (implied by listing them), but the information provided is sufficient 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 only one optional parameter 'item' and 0% schema description coverage, the description compensates well by explaining the effect of omitting vs. passing it, and the resulting response structures. It does not specify the expected format of 'item' (e.g., ID string), but the usage implications are clear.

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 status of a bank connection, listing specific status values (UPDATED, UPDATING, LOGIN_ERROR, etc.), along with executionStatus and connector metadata. It distinguishes between two modes: omitting 'item' for all linked banks and passing 'item' for a single bank, making the purpose highly specific and distinguishable from siblings.

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

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

The description explicitly explains when to omit 'item' (for an overview of all banks) and when to pass 'item' (for a specific bank). However, it does not provide guidance on when not to use this tool or direct comparisons to sibling tools like openfinance_list_connections or openfinance_provider_status.

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

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

Annotations already declare readOnlyHint and destructiveHint, making the safety profile clear. The description adds important behavioral context: credit card balance meaning is connector-dependent, 'name' is the legal entity not the brand, aggregation behavior when omitting 'item', and the correct use of 'bank' field for user-facing text. No contradictions with annotations.

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

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

The description is lengthy but well-structured, with clear sections for output fields, usage instructions, warnings, and cross-references. Every sentence adds value, though it could be slightly more concise without losing 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?

Given no output schema, the description lists key fields (balance, number, type, bank, connector_id, etc.) and explains aggregation behavior. It covers the warning about credit balance and cross-references alternative tool. However, it does not mention pagination, limits, or error scenarios, which would enhance completeness.

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

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

Given 0% schema description coverage, the description must explain parameters. It thoroughly explains the 'item' parameter (omit for all, pass for single bank). However, the 'type' parameter (enum BANK/CREDIT) is not directly explained in terms of filtering; the description implies both types are returned, leaving ambiguity whether 'type' filters results. This is a gap.

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

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

The description clearly states the tool returns accounts for bank connections with specific fields (balance, number, type, etc.) and distinguishes between BANK and CREDIT types. It also differentiates from sibling tool openfinance_list_credit_card_bills by advising to use that tool for standardized bill amounts.

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

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

The description provides explicit guidance on when to use this tool vs the alternative for credit card bills. It explains using 'item' parameter to target a single bank vs omitting it to list all accounts. However, it does not explicitly contrast with other sibling tools like get_account_balance.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description reveals caching duration (adapter session) and the aggregated nature of the response. This adds useful behavioral context.

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

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

Three sentences efficiently convey purpose, return structure, and usage context without redundant information. Front-loaded with the core 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?

Despite lacking an output schema, the description fully explains all relevant fields (id, description, descriptionTranslated, parentId, parentDescription) and their role in category updates. No gaps for a no-parameter tool.

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

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

No parameters exist in the input schema, so the description does not need to add parameter semantics. It appropriately focuses on the return value and 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 it returns the transaction category taxonomy, specifying the endpoint (GET /categories), caching behavior, and relationship to sibling tool openfinance_update_transaction_category.

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

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

It provides guidance on when to use the tool (e.g., before updating categories) and language preference (descriptionTranslated for pt-BR users). However, no explicit exclusions or alternative tools 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, providing safety profile. The description adds value by detailing return fields, but does not disclose additional behavioral traits beyond what annotations cover.

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 with no fluff, directly states purpose and key return fields. Efficient and well-structured.

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

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

Given zero parameters, clear annotations, and no output schema, the description fully covers the tool's behavior. It tells the agent exactly what to expect.

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

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

The tool has no parameters, so schema coverage is 100%. The description does not need to add parameter info. Baseline 4 is appropriate as there is nothing missing.

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

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

The description clearly states the tool returns saved bank connections and lists specific fields (connector_id, item_id, bank name, add_connection_url). It distinguishes itself from sibling tools like openfinance_list_accounts which list accounts within connections.

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

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

The description implies usage for retrieving existing connections and getting a URL to add new ones, but does not explicitly state when to use versus alternatives like connect or marketplace. Guidance 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?

The description discloses critical behavioral traits beyond the annotations: the payment cycle logic, derivation of payment_status, open bill derivation from pending transactions, connector asymmetry, and the fact that the tool does not return a paid/status field natively. All disclosure aligns with annotations (readOnlyHint, idempotentHint, destructiveHint false) and adds valuable context for correct invocation.

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

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

The description is very long and detailed, covering payment logic, open bill semantics, and connector asymmetry. While well-structured with paragraphs and bold emphasis, its length reduces conciseness. Every sentence adds value, but the description could be shortened without losing essential guidance.

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 (0% schema coverage, no output schema, many sibling tools), the description is exceptionally complete. It explains the output structure, derived fields, payment statuses, open bill logic, connector asymmetry, and cross-references to other tools. It leaves no critical gaps 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?

The input schema has 0% description coverage, so the description must compensate. It explicitly explains include_open_bill (opt-in for open bill/total debt) and mentions account_ids for bulk support. However, page, page_size, and account_id are not described in detail, though their purpose can be inferred. The description partially compensates but is not exhaustive for all 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 that the tool returns CLOSED credit card bills for CREDIT-type accounts, listing specific fields like dueDate, totalAmount, payments[], etc. It distinguishes itself from siblings by explicitly noting that results are bill-level summaries, not individual transactions, and directs users to openfinance_list_transactions for itemized purchases per 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?

The description provides extensive usage guidelines: it explains the Brazilian Open Finance semantics, when to use include_open_bill, the payment cycle logic, connector asymmetry, and alternatives to avoid misuse (e.g., not assuming a bill is paid from payments[]). It also warns about the 'PAST_DUE_UNCONFIRMED' status and advises against categorically flagging a bill as 'vencida'.

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) already indicate a safe, read-only operation. The description adds useful behavioral details: it returns a fallback object {total:0, results:[], warning} instead of throwing errors on 403 or other upstream issues. This goes beyond what annotations provide. 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 efficiently lists return types and fields. It is front-loaded with the main purpose. However, it includes a dense enumeration that could be more structured for readability.

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

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

Despite listing return fields and types, the description fails to explain parameter semantics (pagination, filtering) and does not mention output structure details beyond the fallback. Given the absence of an output schema, the description should provide more context on 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?

Schema description coverage is 0% with no parameter descriptions in the schema. The tool description does not mention any of the four parameters (item, page, type, page_size) or their meaning. Since it doesn't compensate for the low coverage, the score is minimal.

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 portfolios for a connection, listing specific types (FIIs, stocks, ETFs, etc.) and fields. This distinguishes it from sibling tools that deal with accounts, transactions, or 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?

The description specifies the tool is for connections with INVESTMENTS product enabled, and explains behavior when the product isn't enabled (returns a fallback object). However, it does not explicitly state when not to use this tool or compare it to similar siblings like openfinance_list_investment_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 and idempotentHint=true, so description adds value by detailing the types of transactions returned and the fields included. It does not cover pagination behavior, but the core safety traits are well documented.

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 clear paragraphs with front-loaded purpose and structured details. Every sentence adds information, and the bulk support note is separate. 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?

Without output schema and with schema lacking parameter descriptions, the description explains the return content well but omits pagination details. Moderate completeness for a list tool.

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

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

Schema has 0% description coverage, so description must explain parameters. It mentions investment_id and investment_ids but does not describe page or page_size, leaving their purpose 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 uses specific verbs and resources ('Returns the movement history for a specific investment position') and lists transaction types (BUY/SELL/TAX etc.), clearly distinguishing from sibling tools like openfinance_list_investments.

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

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

Explicitly advises to use after openfinance_list_investments to get investment_id, and mentions bulk support. However, it does not specify when not to use this tool or list alternative tools for other scenarios.

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

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

Beyond annotations (readOnly, idempotent), the description reveals sequential querying with rate-limit spacing and the return structure { results, errors } per connection, adding valuable behavioral context.

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

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

Three well-structured sentences front-load the purpose, then detail parameter usage and behavior, with no wasted words.

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

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

Despite lacking output schema, the description covers purpose, parameter semantics, behavioral details, and return structure, making it complete for a simple list tool.

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

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

The description explains that items are connection selectors (item_id, connector_id, or connector_name) and that omitting them lists all loans. This adds crucial meaning beyond the schema's bare type array of strings.

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

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

The description clearly states the tool lists loan contracts per bank connection, specifying the HTTP method (GET /loans). It distinguishes from sibling list tools by focusing on loans and explaining the items parameter usage.

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

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

The description provides explicit guidance on when to pass items (for specific connections) and when to omit it (for all linked banks), but does not explicitly compare to 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 already indicate read-only and idempotent, but the description adds crucial behavioral details: the variance in PENDING/POSTED by connector, error handling (returns warning/error instead of throwing), aggregation behavior of search_queries, and token implications of rich/raw modes.

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 verbose but well-structured, starting with the core purpose and then detailing special cases, parameters, and error handling. Some sentences could be trimmed without losing meaning, but the organization is logical and front-loaded.

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

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

Covers all necessary aspects: core functionality, parameter details, edge cases (truncated, total=0), references to complementary tools, and error handling. For a tool with 8 parameters and no output schema, the description is comprehensive.

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

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

With 0% schema description coverage, the description fully compensates by explaining each parameter: date format, detail enum meanings, search_queries substring matching with OR semantics and aggregation, pagination limits, and bulk support via account_ids.

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 accounts of type BANK or CREDIT, and distinguishes itself from siblings like openfinance_list_credit_card_bills and openfinance_list_accounts by specifying its unique role for credit transactions.

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

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

Provides explicit guidance on when to use different detail levels, when to use alternative tools for credit card bills or account details, and how to handle pagination and search queries. Also advises on checking connection health if total is zero.

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

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

Annotations indicate readOnly and idempotent; the description adds critical behavioral details: the 5000-transaction cap per account with truncation flag, and the performance trade-off of granularity:'raw'. This goes well 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?

The description is dense but efficient, front-loading the main purpose. Each sentence adds value. It could be slightly better structured with explicit parameter sections, but given the complexity, it remains concise.

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

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

Given the tool's complexity (7 parameters, no output schema, 0% schema coverage), the description is comprehensive. It covers parameter usage, defaults, output structure ('compact' vs 'raw'), limitations (truncation), and use-case examples. No significant 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 description coverage, the description fully compensates by explaining all parameters: item (connector_id/connector_name/item_id), from/to (ISO dates), granularity (monthly/raw with default), detail (compact/rich/raw), type (BANK/CREDIT), and top_n (implied). It also clarifies defaults and the meaning of each detail level.

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 over a period, resolving accounts internally. It distinguishes from siblings like openfinance_list_transactions by emphasizing one-call consolidation and specific use cases like 'fluxo de caixa' and 'maiores gastos/recebimentos'.

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

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

The description explains when to use this tool (e.g., for cash-flow analysis) and when to omit the item parameter to analyze all banks. It notes that calling openfinance_list_accounts first is unnecessary. However, it does not explicitly name alternative sibling tools for cases like raw transaction 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 already declare readOnlyHint, idempotentHint, destructiveHint. Description adds behavioral context: returns global indicator, degraded components, open incidents, and flags incidents affecting connected banks. 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?

Three well-structured sentences front-loaded with key purpose and usage. Could be slightly more concise but 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?

With zero parameters and no output schema, the description fully covers behavior, return values, and use cases. Annotations provide safety profile. No gaps.

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

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

No parameters exist; schema coverage is 100%. Description doesn't need to add parameter info. Baseline of 4 is appropriate.

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

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

The description clearly states the tool checks the LIVE operational status of the Open Finance provider's public status page, distinguishing it from the sibling tool openfinance_get_item_status which checks connection 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 tells when to use: when data is incomplete/stale despite connection showing UPDATED, and distinguishes from openfinance_get_item_status, providing clear alternative guidance.

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

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety. Description adds useful behavioral context: returns hint if keywords missing, honors user plan, and describes output fields. No contradictions.

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

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

Description is concise, front-loaded with main action, and each sentence adds value. Slightly dense but no unnecessary filler. Could be slightly more structured, but effective.

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

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

Given no output schema, description fully explains return values (connector id, access, audience, linked connections, accounts, connect_url). Also covers behavior without keywords and plan filtering. All necessary context for agent use is 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?

With 0% schema description coverage, description fully explains both parameters: keywords (required, example usage '["nubank","btg"]') and include_accounts (when true includes accounts). This compensates entirely for missing schema descriptions.

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

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

Description clearly defines the tool as searching bank connectors by name, returning specific fields like connector id, access type, audience, linked connections, and connect_url. It distinguishes from dumping the whole catalog and uses specific verb 'searches' with resource 'bank connectors'.

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 'Call this BEFORE connecting to hand the user a one-click link to the right bank', providing clear usage timing. Does not explicitly state when not to use or list alternatives, but context is sufficiently 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?

Discloses side effect of creating a Category Rule (case-insensitive exact match), overrides automatic categorization, and explains per-item error tolerance. Annotations only cover readOnly/hints; description adds critical 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?

Description is dense but efficient, with clear front-loading (verb+method+input). Each sentence adds unique value (side effects, return shape, error handling). 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 simple input schema and no output schema, the description fully documents input semantics, side effects, and return shape. Sufficient for an agent to correctly invoke and interpret results.

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

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

Despite 0% schema description coverage, the description thoroughly explains the items array structure, required fields (transaction_id, category_id), and sources for these IDs from sibling tools, adding full 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?

Clearly states it corrects transaction categories via PATCH, specifying input format and referencing sibling tools for ID sources. Definitively distinguishes from other tools like openfinance_list_transactions.

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

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

Explicitly describes when to use (to fix miscategorized transactions), how it teaches Pluggy for future categorization, and batch error handling. Provides clear context for selecting this tool over 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 indicate idempotent hint and non-destructive nature; description adds context about including conversation for reproduction but lacks details on side effects, authentication needs, 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?

Single sentence is concise and front-loaded with purpose, but lacks structure like bullet points or sections for parameters.

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 three parameters and no output schema, the description omits response behavior, error cases, and prerequisites, making it incomplete for a mutation-like 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?

Description mentions the conversation parameter for reproduction, giving some meaning beyond the schema, but does not explain 'context' or 'message' parameters. With 0% schema coverage, partial value.

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 reports bugs, missing features, or sends feedback, distinguishing it from sibling tools which are all finance-related 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?

It provides guidance to include the conversation array for reproduction, but does not explicitly state when to use this tool over alternatives or when not to use it.

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

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

The description adds valuable context beyond the annotations (readOnlyHint, idempotentHint, destructiveHint) by specifying exactly what versions are shown (MCP platform and adapter). This fully covers the tool's behavior without contradicting 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, front-loaded sentence with no wasted words. Every part contributes to understanding the tool's purpose.

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

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

For a zero-parameter, read-only tool with strong annotations, the description is complete. It clearly states what version information is returned, requiring no further elaboration.

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 and 100% schema description coverage. The description naturally does not need to add parameter semantics, and the baseline for zero parameters is 4, 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 the specific verb 'show' and clearly identifies the resource as 'current MCP platform and adapter versions'. It uniquely distinguishes this tool from all siblings, none of which deal with version information.

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

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

The description does not provide explicit when-to-use or when-not-to-use guidance. However, given the tool's simplicity (no parameters, read-only), its purpose self-explains usage context. A score of 3 acknowledges the lack of direct guidelines but recognizes that implied usage is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's safe and idempotent. The description adds valuable context on what specific data is returned (installed MCPs, connection status, catalog tool counts), which goes beyond the annotations.

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

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

Single sentence, concise, and front-loaded with the verb 'Returns'. Every word provides 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?

The description explains what the tool returns (installed MCPs, connection status, catalog tools count) without an output schema. This is sufficient for a simple informational tool with no parameters.

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

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

No parameters, so baseline is 4 per guidelines. The description does not need to add parameter info since there are none.

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 clearly states the resource: 'current toolkit state: installed MCPs, their connection status, and how many catalog tools each exposes.' This distinguishes it from sibling tools which are action-oriented (e.g., authenticate, connect).

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

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

No explicit guidance on when to use this tool versus alternatives, but the purpose is self-evident as a read-only state inspection tool. The sibling tools are all actions (connect, authenticate, etc.), so context implies this is for informational queries only.

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