Itaú MCP

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

Discloses that calling with no args returns a login link, and with token sets the session. No destructive behavior is indicated, consistent with annotations (destructiveHint: false). However, it does not mention what happens on error (e.g., invalid token) or whether credentials are stored, a minor gap. No annotation contradiction detected.

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 (multiple clauses per sentence). It front-loads the intended audience (MCP.AI for IDE agents) which is good, but could be tightened 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?

For a simple authentication tool with no output schema, the description covers the main use cases. However, it lacks information about return values (e.g., status message after token set) and error handling, which would be helpful 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?

Schema coverage is 0%, but the description explains the single parameter 'token' as an optional JWT for session-only login. It adds context that 'no args' returns a link, clarifying parameter semantics beyond the schema.

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

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

The description clearly states it is for authentication, specifying the action (log in, copy token) and the resource (this server). It distinguishes from sibling tools like 'connect' which likely handles OAuth flows, by focusing on token-based auth and permanent vs session credentials.

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: for session-only vs permanent setup. It explains the alternative of adding token to config for permanent connection, and when to call with or without args. This helps the agent decide which invocation method to use.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read. The description adds value by detailing the two possible return states (authenticated:true with empty pending[] vs connect_url), which is behavioral context 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?

Two short, clear sentences with no wasted words. Front-loaded with the main action 'Returns connection status and URLs'.

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

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

The description covers the main behavior and conditional outputs. It could be more complete by explaining what the connect_url is used for, but for a simple read-only status tool with good annotations, it 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?

With zero parameters, the schema already covers 100% of parameters. The description does not need to add parameter meaning; baseline 4 is appropriate.

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

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

The description clearly states it returns connection status and URLs, with specific verbs 'returns' and resource 'connection status and URLs'. It distinguishes itself from siblings like 'authenticate' and 'marketplace' by focusing on status rather than performing actions.

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 by describing outputs under different conditions (all providers connected vs credentials missing). However, it does not explicitly state when to use this tool versus alternatives like 'authenticate' or 'toolkit_info', nor does it provide when-not-to-use 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?

Discloses that writes (install, uninstall, subscribe, cancel, and the one-off install behind invoke) require workspace owner/admin permissions. Describes invoke behavior (works without installation, can return connect or checkout links). No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

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

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

The description is dense and packs a lot of valuable information, but it is overly long and could benefit from structured lists or bullet points for actions. It earns its length for such a complex tool, but conciseness suffers.

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 13 parameters and many actions, the description covers the high-level flow but lacks per-action parameter guidance. Parameters like 'immediate', 'tier_slug', 'conversation', etc., are not explained. No output schema means return values and error conditions are not described.

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

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

With 0% schema coverage for 13 parameters, the description compensates only partially by explaining the 'action' enum and its implications. Key parameters like 'limit', 'query', 'arguments', 'mcp_id', 'tool_id', etc., lack explicit descriptions of format, constraints, or per-action 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's the official marketplace for MCPs, used for discovering, describing, installing, and invoking tools. It distinguishes from sibling tools like openfinance* by being the primary catalog and execution interface.

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 workflow: use marketplace first for search, then describe for details, then invoke to run. Differentiates when to use invoke vs install (prefer invoke for one-off), mentions auth and payment handling, and lists actions like report_bug and request_mcp with clear purposes.

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 set destructiveHint=true, so the description adds value by explaining the consequences: data deletion and unavailability. It also reveals that the tool returns an 'add_connection_url' for potential reconnection, providing context beyond the annotation alone.

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 short sentences that front-load the core action and then detail the consequence and return value. Every sentence adds value, 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 simple destructive tool with one parameter and no output schema, the description covers the main action, result, and return URL. However, it lacks detail on the 'item' parameter and does not mention prerequisites or error states, leaving some gaps for an agent to infer.

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

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

The input schema has one required 'item' parameter (string) with 0% schema description coverage. The description mentions 'for a specific bank', indicating that 'item' identifies a bank, but it does not specify the format (e.g., UUID, name) or provide examples. This leaves significant 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 the action: revoking Open Finance consent and deleting connection data for a specific bank. It specifies that the bank's data will no longer be available, and mentions a return URL for reconnection. This distinguishes it from sibling tools like 'openfinance_list_connections' or 'connect', which are for listing or adding 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 implicitly indicates when to use this tool (to disconnect a bank), but it does not provide explicit guidance on when not to use it or mention alternatives. With siblings like 'openfinance_list_connections' and 'connect', the description lacks explicit differentiation or usage conditions.

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 that the tool waits up to ~60s, polls until update completes, and returns fields like status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out. No contradiction with annotations; adds context beyond readOnlyHint and 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?

Single paragraph but well-organized with key action first, then usage details, parameter behavior, and return values. Could benefit from bullet points for readability, but covers everything without fluff.

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

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

Given no output schema, the description fully explains return structure ({ results, errors }) and all relevant fields. Covers edge cases (needs_action, timed_out) and provides actionable guidance for each. Complete for a sync tool.

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

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

Despite 0% schema description coverage, the description fully explains both parameters: items (array of selectors, omit to sync all) and wait (boolean for blocking vs fire-and-forget). Provides concrete examples of selectors (item_id, connector_id, connector_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 the tool force syncs bank connections and waits for completion. It specifies the action (force sync), resource (connections), and distinguishes from sibling tools 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 describes when to use (stale balance/transactions), how to use (pass items array or omit for all), and alternatives (openfinance_get_item_status for re-checking). Also explains wait parameter for fire-and-forget.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context about potential warning responses for credit accounts and the response structure, enhancing 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?

Three focused sentences with no redundancy. Each sentence serves a purpose: stating the action, parameter requirements, and behavioral details. Front-loaded with essential information.

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

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

Given no output schema, the description provides the full response shape. It covers parameter limits, error handling, and expected result format, making the tool fully understandable 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?

The schema has no description for the parameter (0% coverage), but the description compensates fully by specifying it must be an array of 1-50 account IDs, adding critical 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 returns real-time balance for given account IDs, specifies the API endpoint, and distinguishes from sibling tools by focusing on balance retrieval.

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 explicitly tells when to use the tool (to get balance per account ID), provides parameter usage details (array of 1-50), and mentions error handling for credit accounts, leaving no ambiguity.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds value by specifying that it returns extended creditData and the response shape `{ results, errors }`, indicating that some IDs may fail. This goes beyond annotations to clarify batch 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?

Description is three concise sentences: first states the purpose, second specifies the parameter usage, third describes the response shape. No wasted words, front-loaded with key information. Efficient for an agent to parse.

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

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

For a simple read endpoint with one parameter and no output schema, the description covers the core aspects: what is returned, parameter constraints, and response structure. It does not detail error handling or extended creditData fields, but it is mostly complete given the tool's 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?

Schema has no description for the single parameter (0% coverage). Description adds that account_ids must be an array of 1-50 items, which provides a constraint not in the schema. However, it does not explain what each account ID represents or any format requirements, so meaning is partially but not fully added.

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 full account objects with extended creditData per id, using the verb 'Returns'. It distinguishes from list tools implicitly by mentioning 'extended creditData' and 'batch shape', but does not explicitly differentiate from sibling tools like openfinance_list_accounts.

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

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

Provides usage guidance on passing account_ids as an array of 1-50 and the batch response shape, implying use when detailed account data is needed. However, it does not explicitly state when not to use or mention alternative tools such as openfinance_list_accounts for summary data.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds vital behavioral context: it discloses that Pluggy does not return a paid/status field, and explains that payments[] typically reflect payment of the previous bill, not necessarily this bill. This prevents misuse and exceeds what annotations convey.

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

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

The description is efficiently structured with a clear main purpose, limitations, usage guidelines, parameter explanation, return shape, and critical caveats. Every sentence provides unique value without redundancy.

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

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

Given the complexity of Open Finance credit card bills, the description is thorough: it covers batch shape, common pitfalls (payments[] semantics), and references sibling tools for related tasks. No output schema exists, but the description sufficiently documents the return fields and 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?

With schema coverage at 0%, the description fully compensates by explaining the single parameter (bill_ids) as an array and instructing to use openfinance_list_credit_card_bills to discover IDs. This adds significant meaning beyond the raw schema.

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

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

The description clearly states the tool returns bill-level detail for credit card bills by ID, specifying exact fields (financeCharges, payments). It explicitly distinguishes from the sibling tool openfinance_list_transactions, which handles itemized transactions. This is a specific verb+resource with clear differentiation.

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

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

The description provides explicit guidance on when to use this tool versus alternatives: it advises using openfinance_list_transactions for itemized transactions and openfinance_list_credit_card_bills to discover bill IDs. It also warns about the semantics of payments[] and recommends checking paid status via the list 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?

The description adds behavioral context beyond annotations: it reveals the two modes, the return format (`{ count, items }` for all), and that it returns status, executionStatus, and connector metadata. Annotations already confirm readOnly and idempotent, so the description enriches without contradicting.

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 redundant information. The first sentence states the core functionality and possible statuses; the second immediately clarifies the dual mode behavior. Every word 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 tool with one optional parameter and no output schema, the description covers the essential facets: purpose, modes, return structure. However, it omits explanation of what 'connector metadata' includes or enumerations for executionStatus, leaving minor 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 input schema has 0% description coverage for the single parameter `item`. The description fully compensates by explaining the semantics of omitting vs. providing `item`, including the different return shapes, which is far more informative than the bare schema.

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

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

The description clearly states the tool returns the current status of a bank connection, listing specific statuses (UPDATED, UPDATING, LOGIN_ERROR, etc.) and distinguishes two distinct modes (all or single), 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 tells when to omit or pass the `item` parameter to get either all banks or a single bank, which provides clear usage context. However, it does not mention when to use this tool over siblings 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 indicate read-only and idempotent behaviors. The description adds critical behavioral details: the connector-dependent meaning of CREDIT balance, aggregation behavior when 'item' is omitted, and the return structure (results array with per-account tags). 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 substantial but efficiently uses every sentence to add value (usage guidance, behavioral nuance, sibling reference). Some redundancy could be trimmed, but overall it is well-structured and front-loaded with the main 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?

Given the tool has 2 unrequired parameters, no output schema, and nuanced credit balance behavior, the description covers most aspects including aggregation, field interpretation, and cross-references to other tools. However, it could explicitly state the filtering effect of the 'type' parameter for 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 description coverage is 0%, so the description must compensate. It explains the 'item' parameter usage well (omit vs. pass). However, the 'type' parameter (enum: BANK, CREDIT) is not explicitly described; the description mentions returning both types but does not clarify that passing 'type' filters results. A clear statement about filtering behavior is 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 it returns accounts for a bank connection, listing specific data fields (balance, number, type, subtype, bankData, creditData, bank, connector_id). It distinguishes from sibling tools like openfinance_list_credit_card_bills by noting that tool provides standardized billing 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?

Provides explicit guidance: omit 'item' to list accounts across all linked banks, pass 'item' to target a single bank. Also warns against misinterpreting CREDIT balance and directs to an alternative tool for accurate billing amounts.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds valuable behavioral details: 'cached for the adapter session' (caching behavior) and 'Single aggregated response — no batch ids' (response structure). This goes beyond annotations.

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

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

Three sentences, front-loaded with the core purpose, followed by field details and a closing note on response format. No redundant information.

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

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

For a list tool with no parameters and no output schema, the description provides essential details: endpoint, caching, field semantics, language options, parent hierarchy, and relationship to update tool. Could mention caching duration or total list scope, but overall complete.

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

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

No parameters, so schema coverage is 100% and baseline is 4 per the rubric. The description does not add parameter info but explains response fields, which is relevant for understanding tool 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 explicitly states it returns Pluggy's transaction category taxonomy, naming the specific endpoint (GET /categories). It clearly identifies the resource and action, and connects to sibling tool openfinance_update_transaction_category by explaining how the id field is used.

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 context (e.g., cached for session, id used by another tool) but does not explicitly state when to call this tool over other list tools or provide 'use this when' 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 provide readOnlyHint, idempotentHint, destructiveHint. The description adds details about returned fields but does not disclose any additional behavioral nuances beyond what annotations convey.

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 conveys the tool's function and key output without extraneous words.

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

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

Given no parameters and existing annotations, the description sufficiently covers the tool's behavior. Despite no output schema, the listed fields provide adequate 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?

No input parameters exist, so schema coverage is 100%. The description adds value by explaining the returned fields, meeting the baseline for zero 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 it returns saved bank connections with specific fields (connector_id, item_id, bank name, add_connection_url), making the purpose explicit and distinct from sibling tools.

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

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

No explicit guidance on when to use this tool versus alternatives like openfinance_list_accounts or other list tools. The context is implied but lacks exclusions or alternative suggestions.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, but the description adds extensive behavioral context: derived payment_status logic with multi-bill matching, connector asymmetry causing open_bill unavailability, and warning on non-failing if product disabled. 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 quite long and dense, with multiple paragraphs covering complex logic. While necessary for a detailed tool, it could be more structured (e.g., bullet points) to improve scannability. It does front-load the core purpose but then dives into detailed edge cases.

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, no output schema, and annotations providing safety hints, the description is remarkably complete. It explains return fields, derived payment status, connector asymmetry, open bill opt-in mechanics, and even provides a legend. No missing elements for agent decision-making.

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

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

Schema coverage is 0%, but the description explains account_id, include_open_bill, and account_ids in detail, including their effects and when to use them. However, page and page_size parameters are not described at all, leaving a gap for pagination behavior.

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 closed credit card bills for a CREDIT-type account, listing specific fields. It distinguishes from siblings like openfinance_get_credit_card_bill and openfinance_list_transactions by explaining the scope (closed bills, not open) and the difference between bill-level summaries and 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?

The description explicitly tells when to use this tool (for closed bills, with opt-in for open bill and total debt) and when not to (for itemized transactions, use openfinance_list_transactions). It warns about not misinterpreting payments[] and provides alternatives for open bill handling and balance interpretation.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral details: it returns a structured error response ({ total:0, results:[], warning }) instead of throwing on 403 or upstream errors, and lists the fields returned (balance, amount, etc.). This is valuable extra 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?

Two sentences with no filler. The first sentence captures the core purpose, the second lists output fields and error handling. 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?

The tool has 4 parameters and no output schema. The description explains output structure (total, results, warning) and example fields but omits parameter documentation and pagination details (page, page_size). For a list tool, pagination is important, so completeness is moderate.

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

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

Schema description coverage is 0%, so the description must compensate for missing parameter details. However, the description does not explain the parameters (item, page, type, page_size) at all. It only describes the output. Therefore, the description adds no semantic value to the input 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 the investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.) and what data each row carries. This distinguishes it from sibling tools like openfinance_list_investment_transactions (transactions) and openfinance_list_accounts (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 specifies the tool is for connections with INVESTMENTS product enabled and explains behavior when it's not (returns empty with warning). It provides clear context but no explicit alternatives or when-not-to-use, though the context is sufficient for an AI agent to infer appropriate usage.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds field-level details (expenses breakdown) and bulk execution behavior, but omits pagination behavior (page, page_size parameters not explained).

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

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

Two sentences, no fluff, front-loaded with purpose and key details. 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?

Covers main parameter (investment_id) and return fields, but misses pagination parameters and does not specify output format (array). With no output schema, more detail on return structure would help 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 description coverage is 0%. Description explains investment_id and investment_ids (bulk), but completely ignores page and page_size parameters. Partial compensation for two out of four 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 it returns 'movement history for a specific investment position' with specific transaction types (BUY, SELL, TAX, etc.). It differentiates from siblings like openfinance_list_investments and openfinance_list_transactions by specifying it's for investment positions only.

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 after openfinance_list_investments to get the investment_id, and mentions bulk support. Does not list when not to use or alternative tools, but context 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 indicate safe read operation; description adds sequential querying with rate-limit spacing and the return format { results, errors } per connection, going beyond annotations.

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

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

Three efficient sentences: purpose, parameter explanation, and omission behavior. No unnecessary words, front-loaded with main action.

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

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

Covers both modes of operation and return format. Lacks details on error scenarios or pagination, but sufficient for a list endpoint with one optional parameter.

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

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

The schema has 0% description coverage; the description fully explains the 'items' parameter as an array of connection selectors (item_id, connector_id, or connector_name), which is critical for correct usage.

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

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

Clearly states 'Lists loan contracts per bank connection' with endpoint. However, does not explicitly distinguish from sibling list tools like openfinance_list_accounts or 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 clear guidance on when to pass 'items' vs omit it, covering both use cases. Does not compare to siblings but the instructions are actionable.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses important behaviors: CREDIT PENDING vs POSTED variability across connectors, aggregation behavior with search_queries, truncation warning, and error response format. 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 comprehensive but slightly verbose. However, it is well-structured: purpose first, then CREDIT specifics, pagination/filters, error handling, and bulk support. Every part adds value, so it earns a high score despite length.

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, multiple edge cases), the description covers all necessary context: parameter usage, behavioral nuances, error handling, and relationships to sibling tools. It is complete and leaves no major 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 compensates fully: explains ISO date format for from/to, pagination max 500, case- and accent-insensitive substring match with OR semantics for search_queries, and bulk support via account_ids. It also adds behavioral nuance like aggregation up to 5000 with search.

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

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

The description clearly states the verb 'Returns' and the resource 'transactions' for bank accounts, specifying both BANK and CREDIT types. It distinguishes itself by noting that for CREDIT accounts it is the only way to get itemized transactions, differentiating it from sibling tools like openfinance_list_credit_card_bills.

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

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

The description provides explicit when-to-use guidance: for CREDIT accounts, it's the only way for itemized transactions, while for standardized bill totals, use openfinance_list_credit_card_bills. It also covers date filters, pagination, search, error handling, and troubleshooting steps, leaving no ambiguity about context and alternatives.

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

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

Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds behavioral details beyond annotations: it caps scanning at 5000 transactions per account with a truncated flag, and explains the two granularity modes (monthly vs. raw) and their output structures. 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 well-structured, front-loaded with the core purpose and key differentiator (single call, no prior account listing). Each sentence adds value, but the description is relatively long. It could be slightly more concise without losing essential 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 tool's complexity (6 parameters, no output schema), the description compensates adequately by explaining the output structure (compact summary vs raw rows, per-account breakdown, top expenses/revenues, truncation flag). Missing explicit mention of how top_n controls the number of top items and lack of error handling info, but overall sufficient 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?

Despite 0% schema description coverage, the description explains most parameters well: item (supports multiple identifiers), from/to (ISO dates), granularity (monthly/raw with defaults and output implications), and type (BANK/CREDIT). The top_n parameter is only implicitly mentioned ('largest N each') but not explicitly linked, which is a minor 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 does consolidated cash-flow analysis for bank connections in one call, resolving accounts internally and freeing the user from calling openfinance_list_accounts first. It distinguishes itself from sibling tools like openfinance_list_transactions by providing a higher-level aggregate view.

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 context on when to use this tool (for annual/monthly analysis, cash flow, income/expenses) and when not to need other tools (no need to call openfinance_list_accounts). It also explains how to target specific banks or all connections. However, it lacks an explicit comparison to the closely related sibling openfinance_list_transactions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying it checks a public status page, returns a global indicator (none/minor/major/critical), degraded components, open incidents, and flags affected banks. This aligns with annotations and provides richer behavioral context.

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

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

The description is two sentences with maximum efficiency. The first sentence defines the purpose and resource; the second provides usage context, expected outcomes, and return structure. Every word earns its place with no fluff.

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

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

Given zero parameters, no output schema, and good annotations, the description fully covers the tool's purpose, usage scenarios, and return value. It explains when to use, what to expect, and how it differs from related tools, making it complete for effective use.

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

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

There are no parameters (schema coverage 100% with 0 params). The description doesn't need to add parameter semantics, but it explains the output structure, which is meaningful given no output schema. Baseline 4 is appropriate as no param info is required.

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

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

The description clearly states the tool checks the LIVE operational status of the Open Finance provider (its public status page). It explicitly distinguishes itself from the sibling tool `openfinance_get_item_status` by noting the provider's health is separate from the user's connection. The verb 'checks' with specific resource 'provider status' makes the purpose unambiguous.

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

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

The description provides explicit guidance on when to use the tool: 'Use it whenever data looks incomplete or stale even though a connection shows UPDATED...'. It explains what the tool reveals (upstream outage, known incident) and the goal (distinguish provider-side problem from connection issue). It also references an alternative (`openfinance_get_item_status`) for own connection 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=true, idempotentHint=true, and destructiveHint=false, ensuring safety. The description adds behavioral details: it honors the user's plan (PF hides PJ banks), never dumps the catalog, and returns a hint if keywords are omitted.

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

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

The description is two sentences long, front-loaded with the main purpose, and each sentence adds essential information without waste.

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

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

Given the tool's complexity (search with filtering, plan-aware behavior, and specific output fields), the description covers all aspects: input, output, behavioral nuances, and usage context. No output schema exists, so the description appropriately explains return values.

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 description coverage at 0%, the description fully compensates by explaining keywords as a required array of bank name strings (with examples) and including include_accounts as a flag to also return accounts. This adds meaning beyond the raw schema types.

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

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

The description clearly states the verb (searches) and resource (bank connectors), with specific details on input (keywords) and output (connector id, access, audience, linked connections, connect_url). It distinguishes itself from siblings by its search-by-name functionality.

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

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

The description explicitly says 'Call this BEFORE connecting to hand the user a one-click link,' providing clear when-to-use guidance. It also notes that keywords[] is required and that without it the tool returns a hint. No explicit alternatives are mentioned, but the context is sufficient.

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

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

The description discloses important behavioral traits: it overrides automatic categorization and creates a Category Rule affecting future transactions. It also describes the batch error handling. Annotations are sparse but not contradicted.

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

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

The description is a single paragraph that front-loads the core purpose and progressively adds detail. It is slightly long but every sentence adds value; could be more terse but still effective.

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

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

Despite no output schema, the description explains the full batch response shape and error handling. It covers input derivation, side effects, and usage context, making it complete for this 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 description coverage, the description fully compensates by explaining the input format (array of objects with transaction_id and category_id) and where to obtain IDs from sibling tools. However, it lacks explicit detail on the category_id format (though implied from sibling tool).

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

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

The description clearly states the tool corrects the category of one or more transactions, specifying the HTTP method and endpoint. It explicitly references sibling tools for input IDs, distinguishing its purpose from listing and other 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 tells when to use ('fix miscategorized transactions and improve categorization accuracy') and explains the learning side effect, but does not explicitly state when not to use it or mention 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?

Annotations indicate idempotentHint true and destructiveHint false, so the description adds value by specifying the need for recent messages for reproduction. However, it does not disclose privacy implications or whether the report is stored.

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

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

The description is two sentences, front-loading the purpose and providing a key instruction. Every word earns its place.

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

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

The description covers the basic use case but omits expected outcomes (e.g., confirmation) and detailed parameter semantics. Given the tool's simplicity, it is minimally adequate.

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 should explain each parameter. It only mentions the conversation array and lacks guidance on the required 'message' and optional 'context' 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, which distinguishes it from sibling tools focused on financial operations. However, it does not specify what happens after submission (e.g., ticket generation).

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

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

The description advises including the conversation array for reproduction, which provides clear context for when to use the tool. No exclusions or alternative tools are mentioned, but the sibling list shows no overlap.

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 no behavioral context beyond what annotations provide, such as output format or side effects.

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 zero wasted words. It is exactly as concise as needed for this trivial tool.

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

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

For a zero-parameter, no-output-schema tool, the description is complete enough. It covers the fundamental purpose, though it could hint at return format for full clarity.

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

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

There are no parameters and schema coverage is 100%, so the description does not need to add parameter details. Baseline score of 3 is appropriate as it adds no extra semantic 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 shows MCP platform and adapter versions, using a specific verb and resource. Even though there is a sibling 'toolkit_info', the scope is distinct and immediately understood.

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

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

No explicit when-to-use or alternatives are provided, but the tool is self-evident as a version checker. The absence of guidance is acceptable given its simplicity, but it does not differentiate from similar information 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 declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, destructiveHint=false. The description adds value by specifying the output includes installed MCPs and their connection status, which is beyond what annotations provide.

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

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

Single sentence that is front-loaded and contains no redundant information. Every word 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 zero-parameter info tool, the description adequately conveys what the output contains. No output schema exists, but the description covers the essential aspects.

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 object). According to guidelines, 0 parameters baseline 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 returns the current toolkit state including installed MCPs, connection status, and number of catalog tools each exposes. It distinguishes itself from sibling tools which are action-oriented (authenticate, connect, openfinance_*).

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 it's for getting state, but does not provide explicit guidance on when to use this tool versus alternatives like openfinance_get_item_status for specific connection details.

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