Atacadão MCP

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

The description discloses that calling with no arguments returns a login link, and calling with token authenticates for the session. It mentions non-expiring vs session behavior. Annotations indicate idempotentHint=true and destructiveHint=false, which are consistent. The description adds value beyond annotations by explaining the two 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 a single, well-structured paragraph of three sentences. It front-loads the purpose and covers both usage modes efficiently without redundant information.

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

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

Given the simple authentication scenario and no output schema, the description provides all necessary information: purpose, two authentication methods, best practice, and how to call the tool. No additional details are 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?

With schema coverage at 0%, the description fully explains the optional 'token' parameter: providing it means the user has pasted a JWT for session login, while omitting it returns the login link. This adds complete meaning beyond the schema's minimal definition.

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

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

The description clearly states the tool's purpose: authentication for IDE agents (Cursor, etc.). It specifies the resource (access token) and actions (log in, copy token, add to config or paste). It distinguishes from siblings by focusing on a specific use case not covered by other 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 provides clear guidance on when to use each option: permanent token via config for persistent connection, or session-only by pasting token. It recommends the config approach as 'best'. However, it does not explicitly state when not to use this tool or compare to alternatives like 'connect'.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds value by detailing the two possible return states (authenticated:true with empty pending[], or connect_url for toolkit and per-install URLs). This goes beyond annotations and provides useful behavioral insight.

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. First sentence states main purpose, second provides specific behavioral details. Front-loaded 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?

For a zero-parameter tool with no output schema, the description explains the two possible return outcomes comprehensively. It covers both success and missing credentials scenarios, making it complete for its simplicity.

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 and schema coverage is 100% (empty schema). The description correctly implies no input is needed. Baseline 4 is appropriate as there is no need for additional param information.

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 connection status and URLs, with specific scenarios for when all providers are connected vs when credentials are missing. This is a specific verb+resource combination that distinguishes it from siblings like 'authenticate' which presumably initiates 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 checking connection status but does not explicitly state when to use vs alternatives. No mention of when not to use or comparisons with siblings like 'authenticate' or 'marketplace'.

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 annotations: writes require workspace owner/admin, invoke works without MCP installed, and returns connect/checkout links for blocked actions. Annotations indicate readOnlyHint=false and destructiveHint=false, which align with the described mutation capabilities. No contradictions.

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

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

The description is well-structured with a clear flow of core actions, followed by special behaviors. It is slightly lengthy but every sentence adds value; no fluff. The front-loading of key purpose ('THE official...') aids 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 13 parameters, no output schema, and 0% schema coverage, the description is remarkably complete. It covers all actions (search, describe, install, uninstall, subscribe, cancel, report_bug, request_mcp, list_tools, invoke), auth/permissions, payment scenarios, and installed vs. one-off behavior. No obvious 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 key parameters: action (with enum meanings), query, mcp_id, tool_id, arguments, immediate, tier_slug, etc. It provides context for how each parameter affects behavior, making the schema usable.

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 identifies the tool as 'THE official mcp.ai marketplace' and details its core flow (search, describe, invoke). It distinguishes itself from external registries and sibling tools by stating 'use THIS tool FIRST'. The action enum covers distinct capabilities, making the purpose specific and 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 explicitly states when to use this tool (first, before external registries) and when not to (prefer external for generic registry). It distinguishes between invoke (one-off) and install (permanent), and provides clear alternatives for common scenarios like credential handling or payment.

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

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

Annotations already declare destructiveHint=true. The description adds detail: revoking consent, deleting data, making data unavailable, and returning a reconnect URL. No contradiction with annotations.

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

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

Three short, front-loaded sentences with no wasted words. Clearly communicates the action, effect, 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?

Covers the primary effect and return value, but lacks details on error conditions, required permissions, or what happens if the connection doesn't exist. No output schema exists to fill 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?

The single parameter 'item' is a string with no description in schema (0% coverage). The description mentions 'for a specific bank' but does not explain what the parameter represents or its format, leaving ambiguity.

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 Open Finance consent, deletes connection data, and returns a reconnection URL. It distinguishes itself from sibling tools like 'connect' and 'openfinance_list_connections' by focusing on disconnection.

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 intent is clear from the name and description, but no explicit guidelines on when to use versus alternatives (e.g., when to disconnect vs. force sync) are provided. It relies on context from sibling 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?

The description discloses behavioral traits beyond annotations, such as polling up to ~60s, returning specific fields like needs_action and timed_out, and the effect of wait: false. This adds significant context to the minimal annotation set.

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

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

The description is moderately long but well-structured, starting with the main action and then detailing parameters, return values, and special cases. Every sentence adds value, though slightly verbose.

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

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

Given no output schema, the description fully explains the return format and error states, covering main use cases and edge cases. The tool's complexity is well addressed.

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 both parameters: items as an array of selectors (item_id, connector_id, connector_name) or omit to sync all, and wait as boolean for fire-and-forget. This adds all needed meaning.

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

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

The description clearly states the tool forces a bank to re-sync connections and waits for completion. It distinguishes from sibling read tools like openfinance_list_transactions by explicitly targeting stale data scenarios.

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 tells when to use it (stale balances/transactions) and provides alternatives like openfinance_get_item_status for timeout cases. It also mentions fire-and-forget mode via wait: false, though it does not explicitly list 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?

Adds significant behavioral context beyond annotations: real-time nature, special handling for CREDIT accounts (returns warning instead of throwing), and response shape with errors array. Annotations already declare readOnlyHint but description enriches with error handling details.

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. Front-loads purpose, then constraints, then error behavior, then response shape. 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?

Covers all key aspects: purpose, parameter constraint, error scenario, response structure. No output schema exists, but description fully compensates. Given tool simplicity, it is fully sufficient for agent understanding.

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 array size constraint (1–50) and referencing account IDs. It adds meaning beyond the raw schema, though it could clarify that each string is a unique account identifier.

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

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

Description clearly states 'Returns real-time balance payload per account id' with specific verb and resource. The mention of the REST endpoint adds further precision. It distinguishes from sibling balance-related tools by focusing on the balance endpoint.

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

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

Provides usage guidance on passing account_ids as an array of 1-50 items, but does not explicitly state when to use this tool versus alternatives like openfinance_get_accounts_detail or openfinance_list_accounts. No when-not or alternative tool mentions.

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 batch response format {results, errors} and array size limit, building on annotations that mark it read-only, idempotent, and non-destructive.

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

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

Two concise sentences: first states purpose, second provides usage details. 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?

Covers purpose, parameter, batch shape; no output schema needed. Could mention error handling but omission is acceptable given simplicity.

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?

Compensates for 0% schema coverage by explaining account_ids is an array of IDs with 1–50 constraint and expected shape, providing essential context.

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

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

Clearly states it returns full account objects with extended creditData per ID, and distinguishes from listing tools like openfinance_list_accounts by specifying per-ID retrieval with batch shape.

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?

Indicates array of account_ids (1–50) but lacks explicit when-to-use vs siblings; however, context from sibling tools makes intended usage inferable.

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

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

Adds context beyond readOnlyHint=true: does not return individual transactions, batch shape { results, errors }, limitation that Pluggy lacks paid/status field, and important caveat about Brazilian Open Finance payments[] reflecting previous bill payments. No contradiction with annotations.

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

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

Description is detailed but well-structured, front-loading main purpose and then providing necessary context. Every sentence adds value; could be slightly more concise but remains clear and organized.

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

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

Given no output schema, description fully explains return structure (financeCharges, payments[]), what is excluded, how to get transactions, prerequisite steps, and critical business logic about payments and paid status. Complete for this 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% description coverage, but description fully explains bill_ids parameter: it's an array, should be obtained via openfinance_list_credit_card_bills, and example usage is implied. This compensates well for lacking 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 bill-level detail for credit card bills by ID, lists the specific fields (financeCharges, payments[] with subfields), and explicitly distinguishes from itemized transactions which are handled by sibling tool 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?

Provides explicit guidance: use openfinance_list_credit_card_bills first to discover bill_ids; for itemized transactions use openfinance_list_transactions with date range; explains how to interpret payments[] and directs to openfinance_list_credit_card_bills for paid status. Also describes batch return shape.

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, idempotentHint, and destructiveHint as false, so the description's behavioral disclosure is supplementary. It adds useful context about the output contents (status, executionStatus, connector metadata) and the dual-mode behavior, which goes beyond annotations.

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

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

The description is one sentence that efficiently conveys the purpose, output, and two usage modes. Every word is necessary and well-structured, with no redundancy.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is fully complete. It covers what the tool returns, the two modes, and the effect of the parameter, leaving no gaps for an AI 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?

Despite 0% schema description coverage, the description fully explains the single parameter 'item' and its role: passing it returns a single bank's status, omitting it returns all banks' statuses. This is a perfect compensation for the lack of schema descriptions.

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

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

The description clearly states the tool returns the current status of a bank connection with specific statuses like UPDATED, UPDATING, LOGIN_ERROR, plus executionStatus and connector metadata. It distinguishes between two use cases: getting all banks' statuses or a single bank's status, which differentiates it from sibling tools like openfinance_list_connections.

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

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

The description explicitly provides usage guidelines: omitting the item parameter gets all banks' statuses, while passing item gets a single bank's status. This is clear and context-aware, though it does not explicitly mention when not to use the tool or alternatives, which would warrant a 5.

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 read-only, idempotent, non-destructive. Description adds behavioral context: 'balance' is connector-dependent, 'name' vs 'bank' distinction, and aggregation behavior. 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 somewhat long but well-structured with logical sections. Front-loaded with main purpose. Every sentence adds value, though could be slightly more compressed.

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

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

No output schema, yet description details return fields and their meanings, including critical caveats about 'balance'. Directs to complementary 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?

Schema has 0% description coverage. Description explains 'item' (optional, targets single bank) and 'type' (enum BANK/CREDIT) adequately. Lacks format specifics (e.g., string length) but sufficient for 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?

Description clearly states it returns accounts for bank connections, specifying types (BANK and CREDIT) and fields returned. It distinguishes itself from siblings like openfinance_list_credit_card_bills by noting that tool is 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?

Explicitly explains when to omit or pass 'item' and when to use 'type'. Provides clear usage guidance, including how to handle 'balance' values and directs to an alternative tool for standardized amounts.

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

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

Adds meaningful behavioral context beyond annotations: cached per session, describes output fields (id, description, etc.), and notes the relationship to update tool. No contradictions with readOnlyHint, idempotentHint, destructiveHint.

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 redundant information. First sentence states purpose, second lists output fields, third clarifies batch behavior. Efficient and front-loaded.

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

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

Covers all essential aspects: caching, output structure, and relation to other tools. Even without output schema, the description sufficiently documents the return type, making it complete for a zero-parameter read-only 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 in schema, so description cannot add parameter info. However, it provides valuable semantic details about the returned fields (including translation) and the cache behavior, which compensates for the lack of output schema.

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

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

States clearly that it returns the cached transaction category taxonomy from Pluggy. Distinguishes from sibling tools like openfinance_list_transactions by specifying the focus on categories. Includes cross-reference to 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?

Indicates it is cached and gives a single aggregated response, implying it is suitable for reading categories without real-time needs. No explicit when-not-to-use or alternatives, but the context is clear enough with annotations.

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, idempotentHint true, and destructiveHint false. The description adds value by revealing that it returns an add_connection_url for linking additional banks, providing context beyond annotations.

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

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

Single sentence that front-loads the purpose and includes key details with no wasted words.

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

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

For a tool with no parameters and no output schema, the description provides sufficient detail about what is returned, making it complete for its simplicity.

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

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

With no parameters, the schema coverage is 100%. The description adds meaning by listing the returned fields, which compensates for the lack of an output schema.

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

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

The description clearly states it returns saved bank connections with specific fields (connector_id, item_id, bank name, add_connection_url), distinguishing it from sibling tools like openfinance_list_accounts or connect.

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

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

The description implies use when you need to retrieve existing connections. It does not explicitly mention when not to use, but the context is clear given no parameters and the simple listing purpose.

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 far beyond the annotations by explaining the complex payment logic, connector asymmetry, the derived payment_status calculation, and the opt-in nature of the open_bill projection. It also notes that the tool may scan extra data when include_open_bill is true, and that it returns warnings rather than errors for missing product enablement. 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 very long and provides comprehensive information, but it is structured as a single block of text. The key purpose is front-loaded, and every sentence contributes necessary detail for understanding the complex behavior. However, better structuring (e.g., bullet points) could improve readability without losing information.

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

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

Given the complexity of Brazilian Open Finance credit card bills, the description thoroughly covers all necessary context: how payments land, derived fields, open bill opt-in, connector asymmetry, and alternative tools for transactions. It also mentions error handling. The description is complete enough for an AI agent to correctly select and 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?

While the description explains the include_open_bill parameter in detail and mentions account_ids for batch support, it does not describe the page and page_size parameters. With 0% schema description coverage, the description should compensate for all parameters. The lack of explanation for pagination parameters partially undermines compensation, resulting in a score of 3.

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 with derived fields and optional open bill data. It distinguishes itself from related tools like openfinance_list_transactions and openfinance_get_credit_card_bill by specifying that it returns bill-level summaries, not individual transactions, and that it lists multiple 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?

The description provides explicit guidance on when to use this tool, including important semantics about payment landing, the derived payment_status, and advice on using open_bill instead of account balance. It also advises against using this tool for individual transactions and directs to openfinance_list_transactions for that purpose, and notes that the tool returns warnings instead of failing when the product is not enabled.

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

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

Annotations indicate readOnlyHint=true, destroyingHint=false. Description adds useful behavioral detail: it returns a specific structure ({total, results, warning}) instead of throwing exceptions on 403 or upstream errors, which is critical for agent understanding.

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 single paragraph, front-loaded with key purpose and asset types. It lists fields concisely. Could be slightly more structured (e.g., mention parameters), but no wasted sentences.

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 complexity (multiple asset types, fields, error cases) and no output schema, description covers main returns but lacks detail on pagination, parameter usage, and full return structure. Adequate but leaves gaps.

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

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

Schema has 4 parameters with 0% description coverage. Description fails to explain any parameter (item, page, type, page_size) or their syntax/usage. Since schema coverage is very low, description should compensate but does not, leaving agents guessing.

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 verb 'Returns' and specific resource 'investment portfolio for a connection', listing concrete asset types (FIIs, stocks, ETFs, etc.) and fields returned. This distinguishes it from siblings like 'openfinance_list_investment_transactions' and '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?

Description implies usage for fetching overall portfolio but does not explicitly state when to prefer this over similar tools (e.g., 'openfinance_list_investment_transactions' for transactions). It mentions error handling but lacks guidance on prerequisites or when not to use.

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

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

Annotations already confirm read-only, idempotent, non-destructive behavior. The description adds valuable detail on the returned fields (e.g., expenses breakdown, agreedRate) and bulk support, surpassing annotation context without contradiction.

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

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

Two concise sentences with immediate purpose statement, plus a clear bulk support note. 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 moderate complexity and no output schema, the description provides a thorough list of returned fields and usage context. However, it lacks details on pagination behavior and error scenarios, which would improve completeness.

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

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

Schema coverage is 0%, so the description must compensate. It explains the main parameter investment_id and introduces investment_ids for bulk usage, but does not describe page or page_size, missing a chance to clarify pagination 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 returns movement history for a specific investment position, enumerating transaction types (BUY, SELL, TAX, etc.) and distinguishing it from sibling tools like openfinance_list_investments and 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 recommends using after openfinance_list_investments to obtain the investment_id, providing a clear usage sequence. Though it does not explicitly state when not to use it, the context effectively guides the agent.

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

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

Adds behavioral context beyond annotations: indicates sequential querying with rate-limit spacing for multiple connections, and returns { results, errors } per connection. No contradiction with annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false). Could be improved with more details on rate limits or response structure, but sufficient.

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

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

Three sentences, each serving a purpose: purpose, parameter usage, and return structure. Front-loaded with main action. 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?

Provides enough context for a list operation: explains parameter behavior, sequential querying, and return format. Lacks details on pagination, ordering, or specific rate limits, but is adequate given the tool's simplicity and the presence of annotations indicating read-only behavior.

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 parameter items is explained in detail: it accepts an array of connection selectors (item_id uuid, connector_id, or connector_name), and omitting it queries all connections. This fully compensates for the 0% schema description coverage.

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

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

Clearly states it lists loan contracts per bank connection via GET /loans. Distinguishes between fetching for specific connections (using items) versus all connections. Differentiates from sibling tools like openfinance_list_accounts, which list accounts instead.

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?

Describes exactly when to use: to retrieve loan contracts. Explains how to use the items parameter (array of selectors) and the effect of omitting it (lists across all linked banks). Mentions sequential querying with rate-limit spacing. Does not explicitly exclude alternatives, but the purpose 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?

The description adds substantial behavioral context beyond annotations: varying credit card transaction availability by connector, aggregation limits with search_queries, error handling (returns warning/error instead of throwing), token costs for detail levels, and connection health checks. 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 verbose and could benefit from structuring (e.g., bullet points or sections). It packs a lot of information but as a single dense paragraph, it reduces scanability. For a tool with many parameters and behavioral nuances, conciseness is sacrificed for completeness. Still, it is informative and front-loaded with core 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?

The description covers all essential aspects: what the tool returns (total, results, warning, error), how to interpret results (truncated flag), what each detail level provides, and cross-references to other tools for complementary data (bills, account info, connection health). Without an output schema, this description provides necessary 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?

With 0% schema coverage, the description fully compensates by explaining each parameter: from/to as ISO date filters, page/page_size for pagination (max 500), detail enum with usage guidance, account_id/account_ids for single or bulk, search_queries for case-insensitive substring matching with OR semantics. Additionally explains aggregation behavior with search_queries.

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: returning transactions for bank accounts. It distinguishes between BANK and CREDIT accounts, notes that for CREDIT accounts it's the only way to get itemized transactions, and contrasts with other tools like openfinance_list_credit_card_bills. The verb 'returns' and resource 'transactions' are explicit.

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

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

The description explicitly states when to use this tool vs alternatives (e.g., for itemized credit card transactions vs. bill totals via openfinance_list_credit_card_bills, and for closing/due dates via openfinance_list_accounts). It also provides conditional guidance for error handling and data completeness.

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 disclosing the 5000-transaction cap per account with a truncated flag, and details on default behavior and output formats.

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 front-loaded with the main purpose. It mixes parameter explanations with use cases, which slightly reduces clarity, but every sentence adds value. Could be more structured but is 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?

Despite no output schema, the description thoroughly explains the return structure: compact summary with totals, monthly evolution, top expenses/receipts, per-account breakdown, and raw transaction rows with optional enrichment. Includes truncation flag.

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 7 parameters: item (target or omit), from/to (ISO dates), granularity (monthly vs raw), detail (compact/rich/raw), type (BANK/CREDIT), and top_n (implied as 'largest N'). Defaults and effects are covered.

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

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

The description clearly states the tool's purpose: 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call.' It distinguishes from sibling tools by explaining it resolves accounts internally, eliminating the need for separate calls to 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?

The description provides explicit usage scenarios like 'análise anual/mensal', 'fluxo de caixa', and granularity/detail options. It offers clear context but does not explicitly mention alternatives like openfinance_list_transactions, which could be a sibling for per-account queries.

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, but the description adds richer behavioral context: it returns global indicator, degraded components, open incidents, and flags incidents affecting connected banks. 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 four sentences, each serving a purpose: stating the action, explaining when to use, detailing return info, and specifying output fields. It is informative but could be slightly more concise without losing clarity.

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

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

Given no output schema, the description comprehensively covers return values (global indicator, degraded components, open incidents, your_banks_affected) and provides complete context for when to use the tool. 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?

There are zero parameters, so the description need not add parameter information. The baseline for no parameters is 4; the description appropriately does not mention 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 explicitly states it checks the LIVE operational status of the Open Finance provider, distinguishing it from the connection-level tool openfinance_get_item_status. The verb 'checks' and specific resource 'provider status' make the purpose clear, and it differentiates well 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 provides explicit guidance on when to use this tool: 'whenever data looks incomplete or stale even though a connection shows UPDATED'. It also clarifies that it reveals upstream outages versus connection issues, helping the agent decide between this and other 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 provide readOnlyHint, idempotentHint, and destructiveHint. Description adds significant detail: it honors user's plan (PF hides PJ), returns specific fields, and explains behavior when keywords are missing (returns a hint). This adds value beyond annotations without contradiction.

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

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

Single paragraph, dense but not verbose. Every sentence adds unique value. Front-loaded with purpose. Uses examples and parenthetical lists for efficient information delivery.

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 lists all returned fields and covers edge cases (missing keywords). For a search tool with 2 parameters, this is fully complete. Includes enough context 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?

Despite 0% schema description coverage, the description fully explains both parameters: keywords with example usage and requirement condition, include_accounts with its effect on return data. This compensates completely 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 states it searches bank connectors by name and what it returns (connector id, access type, audience, linked connections, accounts, connect_url). Differentiates from siblings by specifying it should be called BEFORE connecting, and mentions that without keywords it returns a hint, not the whole catalog.

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.' Provides clear context for use, but does not explicitly exclude alternative tools or name siblings to use instead. Keywords being required is emphasized.

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 minimal annotations (readOnlyHint false, destructiveHint false), the description discloses key behaviors: it overrides automatic categorization, teaches Pluggy by creating a category rule, and explains batch error handling. This is rich, actionable 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 concise and well-structured: starts with the main action, then parameter format, then side effects, then return shape. 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?

Despite no output schema, the description includes the return shape (`{ updated, results, errors }`) and covers input, behavior, side effects, and error handling, making it fully 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?

Schema description coverage is 0%, but the description fully compensates by detailing the 'items' array structure, field sources (transaction_id from openfinance_list_transactions, category_id from openfinance_list_categories), and the effect of each parameter, providing complete semantic meaning.

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

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

The description clearly states the tool corrects transaction categories (verb+resource) and distinguishes from siblings by referencing where to obtain required IDs (openfinance_list_transactions, openfinance_list_categories).

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

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

Explicitly states the purpose ('fix miscategorized transactions') and explains the side effect of creating a category rule, guiding the agent on when to use. Lacks explicit when-not-to-use but provides strong contextual 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 declare idempotentHint=true and destructiveHint=false. The description adds that the tool reports bugs but does not clarify the idempotency behavior or what happens after submission. It does not contradict annotations, but also does not significantly enhance behavioral understanding beyond them.

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

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

The description is a single concise sentence that front-loads the purpose. No wasted words, and every part is necessary.

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 incomplete parameter descriptions, the description provides the core idea but leaves out details on how to effectively use all parameters. It is minimally complete for a straightforward feedback 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?

With 0% schema description coverage, the description must compensate. It hints that the 'conversation' parameter should contain recent messages, but does not explain 'message' or 'context' parameters. This provides only partial guidance for the 3 parameters.

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

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

The description clearly states the tool is for reporting bugs, missing features, or sending feedback. The verb 'report' and resource 'bug/feedback' are specific, and the tool is clearly distinct from sibling tools that focus on financial operations.

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

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

The description provides clear context: include the conversation array with recent messages for reproduction. However, it does not explicitly state when not to use the tool or mention alternatives, but the usage is self-explanatory for a feedback tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it outputs platform and adapter versions, which goes beyond the annotations by specifying the content.

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 with no wasted words. It is perfectly concise and front-loaded.

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

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

Given the tool has zero parameters and no output schema, the description provides sufficient context. It could optionally detail the output structure, but the current description is adequate for a simple version query.

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 100%), so there is nothing to explain. The description correctly omits parameter details, and the baseline for 0 params 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?

The description clearly states the tool shows current MCP platform and adapter versions, which is a specific verb-resource pair. It distinguishes itself from sibling tools that perform operations on financial data 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 usage is self-evident: call when version info is needed. No explicit when-not or alternatives are given, but the simplicity and lack of parameters make such guidance unnecessary.

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, destructiveHint=false, idempotentHint=true. Description adds specifics about what data is returned (installed MCPs, connection status, tool counts), providing 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?

Single sentence, no fluff. Clearly communicates the output value. 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 zero parameters and low complexity, the description fully explains the tool's return value. No output schema needed as description is sufficient.

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

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

No parameters exist, so parameter semantics are fully covered by the schema (100% coverage). Baseline 4 for 0 parameters 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?

Description specifically states 'returns the current toolkit state: installed MCPs, their connection status, and how many catalog tools each exposes.' This clearly distinguishes it from sibling tools which are mostly about 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?

No explicit when-to-use or when-not-to-use guidance is provided. The purpose implies usage for inspecting toolkit state, but lacks alternatives or exclusions.

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