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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds scenario details about return values (authenticated vs connect_url) but does not disclose additional behaviors like rate limits or authentication requirements beyond what annotations provide.

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

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

The description consists of two sentences, efficiently front-loading the main purpose and key conditional details. No extraneous words or fluff.

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

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

The description covers the primary states (connected and missing credentials) for the return values. However, it does not mention error scenarios or other potential states (e.g., partial connectivity). Given zero parameters and good annotations, it is mostly complete.

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

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

The input schema has zero parameters, and schema description coverage is 100%. With no parameters, the description does not need to add parameter semantics; a baseline of 4 is appropriate.

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

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

The description clearly states the tool returns connection status and URLs, with specific conditions for connected vs missing credentials. However, it does not explicitly distinguish from sibling tools like 'authenticate' or 'marketplace', which may have overlapping purpose for connection-related operations.

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

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

The description implies the tool is for checking connection status but does not provide explicit guidance on when to use it versus alternatives, such as 'authenticate' for initiating connections. No exclusions or when-not-to-use are mentioned.

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

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

The description goes well beyond the annotations (which provide only openWorldHint, readOnlyHint, etc.) by detailing key behaviors: invoke works even when the MCP is not installed, invoke returns connect/checkout links as needed, install makes MCP permanent, and writes require workspace owner/admin. 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 long but efficient, packing in essential information without fluff. It front-loads the core purpose and flow, then adds details. Every sentence serves a purpose, though it could be slightly more structured (e.g., bullet points for actions).

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

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

Given the tool's complexity (13 parameters, 10 actions) and no output schema, the description covers the overall flow, when to use each action, fallback behaviors, and permissions. It does not detail every parameter or return format, but the core use cases are well-covered.

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 explains the purpose of several parameters (action, query, mcp_id, tool_id, arguments) contextually, but does not detail all 13 parameters (e.g., tier_slug, conversation, request_name, etc.) or their expected formats. This leaves some ambiguity for an 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 identifies the tool as 'THE official mcp.ai marketplace' and specifies its role: discovering and running MCPs/tools. It distinguishes itself from sibling tools (like authenticate or connect) by positioning itself as the primary tool for capability discovery before external registries.

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: 'use THIS tool FIRST, before any external/generic registry.' It outlines the core flow (search → describe → invoke) and contrasts invoke vs install for temporary vs permanent use. It also notes permission requirements for write actions.

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 aligns with annotations (destructiveHint=true) and adds context: 'The bank's data will no longer be available' and 'Returns an add_connection_url to re-connect if needed.' This provides clarity beyond the annotations.

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

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

The description is two sentences, no wasted words, and front-loaded with the primary action. It is efficient and directly conveys the tool's purpose and key effect.

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 low complexity (one required param, no output schema). The description covers the effect and a return value, but missing parameter documentation reduces completeness. It is adequate but not comprehensive.

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

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

The schema coverage is 0%, and the description does not explain the 'item' parameter. The agent cannot determine what value to provide, even though the tool name suggests it's a bank identifier. The description should document this parameter.

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 (revokes consent, deletes data) and the resource (a specific bank's connection). It distinguishes from siblings like openfinance_list_connections or openfinance_force_sync by focusing on disconnection and deletion.

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 usage: when a bank connection needs to be revoked. It mentions returning a reconnection URL, hinting at post-use behavior. However, it lacks explicit when-not-to-use or direct 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?

Description adds context beyond annotations: waits up to ~60s, polls until done, returns fields like status, executionStatus, lastUpdatedAt, synced, and error conditions (needs_action, timed_out). No contradiction with annotations.

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

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

The description is somewhat verbose but every sentence adds value and key information is front-loaded. A bit long but efficient given the complexity.

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

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

Complete for a complex sync tool: covers input, output format, error states, and alternative usage (fire-and-forget). No output schema, but description adequately covers 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?

Despite 0% schema coverage, the description fully explains parameters: items as array of selectors (item_id, connector_id, connector_name) and the wait boolean, including the special case of omitting items to sync all.

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 forcing a bank to re-sync connections and waits for completion. It distinguishes from siblings like openfinance_get_item_status by specifying when to use this tool vs checking 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?

Explicit when-to-use (stale balance/transactions) and when-not (no disconnect/reconnect). Provides alternatives like openfinance_get_item_status for timed_out cases and mentions fire-and-forget option with wait:false.

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 explaining real-time behavior, potential warning for CREDIT accounts, and the response structure including an errors array. 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 concise with three sentences, each adding essential information: purpose with API endpoint, input format with limit, special case handling, and response shape. No redundant words, front-loaded with the core action.

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

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

Given the simple single-parameter tool and no output schema, the description fully covers input requirements, behavioral nuances, and output structure. The tool's role among siblings is clear, and annotations provide safety profile. Complete for an agent to use correctly.

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

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

Schema description coverage is 0%, so the description compensates by explaining the parameter 'account_ids' as an array with a size constraint (1–50). However, it does not clarify what each string represents (account IDs), although this is inferable from the tool 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?

The description clearly states the verb 'Returns real-time balance payload' and resource 'per account id', specifying the API endpoint. It effectively distinguishes from sibling tools like openfinance_list_accounts or openfinance_get_accounts_detail by focusing solely 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?

The description provides clear input guidelines ('Pass account_ids as an array (1–50)') and explains error handling for credit accounts with structured warnings. It does not explicitly state when to avoid or use alternatives, but the context is sufficiently clear for an agent to determine 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 the tool is read-only and idempotent. The description adds valuable context: extended creditData, batch output format, and array size limits, without contradicting 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 short and front-loaded with purpose, followed by usage details. Could be slightly more structured (e.g., a bullet for output shape), but is efficient and clear.

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

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

Given the low complexity, good annotations, and absence of output schema, the description covers the main aspects: input constraints, batch output, and data content. Missing details like error handling or response structure, but 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?

The schema has no parameter descriptions (0% coverage). The description clarifies that account_ids is an array of 1-50 string IDs, but does not specify ID format or provide examples. Adequate but not exceptional.

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

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

The description clearly states the tool returns full account objects with extended creditData, specifies the HTTP endpoint, and mentions the batch shape. It distinguishes from sibling tools that likely return summaries.

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

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

The description explains how to use the tool (pass account_ids array of 1-50) and the batch output shape, but does not explicitly state when to use it versus alternatives like openfinance_list_accounts.

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

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

Annotations already declare readOnlyHint, etc. Description adds critical behavioral context: does NOT return individual transactions, batch shape, Pluggy limitation (no paid/status field), payments[] interpretation. 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 dense but efficient, covering purpose, return shape, exclusions, usage path, and critical caveats. Every sentence adds value; could be slightly tighter but structure is logical.

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 explains return shape (financeCharges, payments with fields), batch format, and key behavioral nuance (payments[] meaning). References sibling tools and provides complete guidance for correct 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?

Single parameter 'bill_ids' has 0% schema description coverage. Description explains it must be an array of string IDs, provides usage direction (discover ids via list tool), and implies the value source. Compensates well for schema 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?

Description clearly states it returns bill-level detail for credit card bills by id, listing specific fields (financeCharges, payments) and explicitly distinguishes from sibling tool for transactions. Verb+resource is specific and accurate.

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

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

Explicitly advises to first use openfinance_list_credit_card_bills to discover ids, and directs to openfinance_list_transactions for itemized transactions. Also warns about payments[] interpretation and references alternative tool for paid 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 readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by specifying the returned data (status, executionStatus, metadata) and the dual response shapes. 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?

Two sentences that are front-loaded with purpose and usage. Every word earns its place; no redundancy or fluff.

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

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

For a simple tool with one optional parameter and no output schema, the description covers both usage modes and the output structure. It does not mention error cases or potential null status, but completeness is 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?

Schema coverage is 0%, so the description must compensate. It explains that omitting 'item' returns all banks and passing it returns a single bank. It could specify the type or format of 'item' more precisely, but the name and context are sufficient.

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

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

The description clearly states it returns the current status of a bank connection, listing possible status values and mentioning executionStatus and connector metadata. It distinguishes between querying all linked banks versus a single bank via the optional 'item' parameter, which sets it apart 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?

It explicitly explains when to omit or pass the 'item' parameter, and describes the return shapes for each case. It does not explicitly mention when not to use this tool or alternatives, but the context is clear enough for an agent to decide.

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

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

Discloses that `name` is the legal entity not the brand, `balance` for CREDIT is connector-dependent, and billing cycle info is in creditData. Annotations already indicate safe read operation, so description adds valuable 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?

The description is detailed and front-loaded, but somewhat lengthy. Every sentence adds value, though minor consolidation could improve conciseness. Well-structured with clear paragraphs.

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

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

With no output schema, the description fully documents return values and their meanings, including caveats and usage scenarios for both parameter modes. No missing critical information.

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

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

While schema coverage is 0%, the description explains the `item` parameter's usage well (omitting for all banks, passing for single). However, it doesn't explicitly explain that the `type` parameter filters results; it only mentions account types in the response. Slightly incomplete for type parameter.

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

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

The description clearly states the tool returns accounts for a bank connection, distinguishing between BANK and CREDIT types and listing returned fields. It also differentiates itself 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?

Provides explicit guidance on when to omit or use the `item` parameter (list all vs. single bank), and warns about connector-dependent CREDIT balance, directing 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?

The description adds significant behavioral context beyond annotations: it explains caching, the response structure (id, description, descriptionTranslated, parentId, parentDescription), and that it's a single aggregated response. Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint, all consistent.

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?

Four sentences, no wasted words. The main purpose is front-loaded, and each sentence adds value: caching, output fields, and relationship to another tool.

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

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

Given no parameters, rich annotations, and no output schema, the description is complete. It explains the output structure, caching behavior, and how it connects to the update tool. No gaps identified.

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 the baseline is 4. The description does not need to add parameter info but describes the output fields in detail, which indirectly helps the agent understand what the tool returns.

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 transaction category taxonomy from Pluggy, specifying the action (returns), resource (category taxonomy), and caching. It distinguishes itself from sibling tools like openfinance_update_transaction_category by noting that the category ids are used by that tool.

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: to retrieve categories for use with update_transaction_category. It mentions caching and that it's a single aggregated response, but does not explicitly state when not to use it or provide alternatives. Given the clear context, it's mostly 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds value by specifying the exact returned fields and noting an add_connection_url for linking additional banks, providing behavioral context beyond annotations.

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

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

The description is a single sentence that covers the tool's purpose, output, and key elements. It is front-loaded with the core function and contains no superfluous information.

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

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

Given no parameters and no output schema, the description provides sufficient context about the return value (fields and add_connection_url). It could mention the purpose of listing connections (e.g., to manage bank links), but it is largely complete for a simple 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?

There are zero parameters, and schema description coverage is 100% (implicitly complete). With no parameters, the baseline is 4, and the description adds no parameter info, which is adequate since none exist.

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

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

The description clearly states the tool returns saved bank connections for the install, listing specific fields (connector_id, item_id, bank name, add_connection_url). It uses a specific verb 'Returns' and resource 'saved bank connections', which distinguishes it from sibling list tools that return other entities (e.g., accounts, transactions).

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when-not-to-use, or name sibling tools that might be more appropriate for specific scenarios. Agents have no basis to choose this tool over others like openfinance_list_accounts.

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

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

Discloses complex behavioral traits beyond annotations: payment cycle semantics, derived payment_status logic, connector asymmetry for open bill unavailability, and that results are bill-level summaries not transactions. Annotations only indicate readOnly/idempotent.

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

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

Description is lengthy but well-structured with sections (IMPORTANT, CONNECTOR ASYMMETRY). Every sentence adds value, but could be slightly more concise. Front-loads main purpose then details.

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

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

Highly complete given complexity: covers return fields, payment logic, connector asymmetry, bulk support, opt-in behavior, error warning, and cross-reference to other tools. No output schema but description compensates fully.

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?

Explains account_id (required), account_ids (bulk), include_open_bill (opt-in, default false). But does not describe page and page_size parameters at all, despite 0% schema coverage. Partial compensation leaves a gap for two common 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 CLOSED credit card bills for a CREDIT-type account, listing specific fields. It distinguishes from sibling tools like openfinance_get_credit_card_bill and openfinance_list_transactions, ensuring no confusion.

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 this tool vs alternatives: for itemized transactions, use openfinance_list_transactions; to get open bill, use include_open_bill opt-in; explains when to use derived fields instead of balance. Also warns about connector asymmetry.

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 valuable behavioral context, such as returning a structured error object (total, results, warning) instead of throwing exceptions when INVESTMENTS is not enabled. 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 a single paragraph that is front-loaded with the main purpose. While it packs a lot of detail, it could be more structured (e.g., separating output details from error handling). Still, every sentence serves a purpose without unnecessary verbosity.

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?

There is no output schema, so the description compensates by explaining the return structure (total, results, warning) and listing fields like balance, amount, etc. It also addresses error cases. However, it lacks documentation on pagination parameters (page, page_size) and the meaning of 'item' and 'type', leaving gaps for the agent.

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

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

The input schema has 4 parameters (item, page, type, page_size) with 0% description coverage. The tool description does not explain the purpose or allowed values for any parameter (e.g., what 'item' refers to, how pagination works). With low schema coverage, the description should compensate but fails to do so.

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

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

The description clearly states it returns investment portfolio data for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.) and fields. This distinguishes it from siblings like openfinance_list_investment_transactions, which deal with transactions rather than portfolio overview.

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

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

The description implies usage for retrieving portfolio data and mentions error handling (returns a warning structure instead of throwing). However, it does not explicitly state when to use this tool versus alternatives like openfinance_list_investment_transactions or other listing tools. No when-not or exclusion criteria are provided.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by detailing the return data (movement types, fields like netAmount, expenses), but does not disclose additional behavioral traits (e.g., authentication, rate limits). Given annotation coverage, a score of 3 is appropriate.

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

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

The description is concise (two short paragraphs) and front-loaded with the core purpose. It uses bullet-style listing for movement types. Slightly more structure could improve readability, but no unnecessary content exists.

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

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

Given 4 parameters and no output schema, the description covers the main purpose and usage sequence but omits details on pagination (page, page_size), meaning of parameters, and explicit output structure. It does list key fields, but more detail would enhance completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that investment_id is required and investment_ids enables bulk, but does not describe page or page_size. No format or constraints are provided for any parameter. This leaves significant gaps for an agent to use the tool correctly.

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, lists movement types (BUY/SELL/TAX/INTEREST/AMORTIZATION/TRANSFER), and names key fields. It distinguishes itself from sibling tools like openfinance_list_investments by stating it should be used after that tool to get the investment_id, and inherently differs from openfinance_list_transactions by being per-investment.

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

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

Explicitly advises to use after openfinance_list_investments to obtain the investment_id. Mentions bulk support with investment_ids. No explicit when-not-to-use or alternatives, but the context is clear for its intended use case.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe read behavior. The description adds behavioral details like sequential querying with rate-limit spacing and the return format per connection, which are beyond what annotations provide.

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

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

The description is two sentences: the first states purpose and method, the second covers parameter usage and response format. It is front-loaded and contains no superfluous information.

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

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

The description mentions the return format ({ results, errors }) and sequential behavior. However, without an output schema, it could elaborate on the structure of 'results', but the core information is sufficient for a listing tool.

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

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

The schema has 0% description coverage for the 'items' parameter. The description compensates fully by explaining that the array contains connection selectors (item_id, connector_id, or connector_name) and the effect of providing or omitting it.

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

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

The description clearly states the action ('Lists loan contracts') and the resource ('per bank connection'), and specifies the HTTP method. This differentiates it from sibling tools like list_accounts or list_transactions.

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

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

The description provides explicit guidance on using the 'items' parameter to fetch loans for specific connections, and omitting it to get all. It also mentions rate-limit spacing for multiple connections. However, it does not explicitly state when not to use this tool or suggest 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?

Despite annotations already indicating read-only and idempotent, the description adds critical behavioral details: error handling (returns warning object), pagination limits, search aggregation up to 5000, detail level trade-offs, and credit card pending/posted variations. 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?

While lengthy, the description is well-structured: starts with core function, then credit card specifics, filtering/pagination, error handling, detail levels, cross-tool references, and bulk support. Every sentence adds value, but could be slightly more front-loaded for quick scanning.

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 complex tool with 8 parameters and no output schema, the description covers all necessary context: output structure, credit card edge cases, performance implications, and relationships to sibling tools. No gaps remain.

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 compensates fully: explains date format ISO YYYY-MM-DD, page_size max 500, search_queries case-insensitive OR semantics, detail enum with specific field additions (merchantInfo, creditCardMetadata), and bulk account_ids support. Each parameter is thoroughly documented.

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

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

Description clearly states 'Returns transactions for a bank account (BANK or CREDIT type)' and specifically notes it's the only way to get itemized transactions for CREDIT accounts, distinguishing 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?

Provides explicit guidance on when to use this tool vs alternatives (e.g., for credit card bills use openfinance_list_credit_card_bills), and includes context on narrowing date ranges when truncated, and checking connection health via openfinance_get_item_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, idempotentHint, destructiveHint. Description adds that the scan caps at 5000/account and flags truncated:true. It also explains output structure (compact summary vs raw rows with enrichment). No contradictions.

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

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

The description is long but well-structured, front-loading the core idea and then detailing parameters. Every sentence adds value, though it could be slightly more concise. Still, it is appropriate for the tool's complexity.

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

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

Given no output schema and 7 params with 3 enums, the description covers purpose, parameter semantics, default behavior, output structure summary, truncation limit, and usage patterns. It is complete for an agent to select and invoke correctly.

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

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

With 0% schema description coverage, the description fully explains all 7 parameters: item (connector_id/name/item_id or omit for all), from/to (ISO dates), type (BANK/CREDIT), top_n (implied in top expenses), detail (compact/rich/raw), granularity (monthly/raw). It also explains defaults and effects.

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 consolidated cash-flow analysis over a period in one call, differentiating from needing to call openfinance_list_accounts first. It includes specific use cases like 'análise anual/mensal', 'fluxo de caixa', and 'maiores gastos/recebimentos', making 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?

Explicitly explains when to use: for analyzing cash flows, fluxo de caixa, etc. It says you do NOT need to call list_accounts first, and that omitting item analyzes all linked banks. It also details parameter options like granularity and detail for different needs, providing clear 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 declare readOnlyHint=true and idempotentHint=true. Description adds context: it checks a public status page (non-destructive, external call), returns specific fields (global indicator, degraded components, incidents, affected banks), and explains how it helps diagnose outages. 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 well-structured and front-loaded with the core purpose. Each sentence adds value: purpose, usage guidance, and output details. No unnecessary words 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?

With no parameters and no output schema, the description fully explains the tool's purpose, behavior, return fields, and use case. Complete information for an agent to select and invoke correctly.

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

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

No parameters exist; schema coverage is 100% (empty). Description does not need to add parameter info. 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?

Description clearly states the tool checks the LIVE operational status of the Open Finance provider, distinguishing it from the user's own connection status via explicit mention of sibling tool 'openfinance_get_item_status'. The verb 'checks' and resource 'provider status' are specific.

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

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

Explicitly describes when to use: when data looks incomplete or stale despite an updated connection. Contrasts with connection-level status, guiding the agent to differentiate provider-side problems from connection issues.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, confirming a safe read operation. The description adds valuable behavioral context: it returns a hint when keywords are empty (never dumps catalog), honors user plans, and includes details like connect_url. This enriches the agent's understanding 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 well-structured and front-loaded, starting with the tool's purpose. While it is somewhat lengthy, each sentence adds value (e.g., plan filtering, behavior without keywords). Minor redundancy could be trimmed, but overall it is efficient.

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

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

Despite lacking an output schema, the description thoroughly explains what the tool returns (connector id, access, audience, linked connections, accounts, connect_url). It also covers edge cases (empty keywords) and plan filtering. Given the complexity and sibling tools, this description is complete enough for correct usage.

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

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

The schema has 0% description coverage, so the description must compensate. It does so by providing concrete examples for keywords (e.g., ['nubank','btg']) and explaining the effect of include_accounts=true. This adds significant meaning beyond the bare schema definition, making parameter usage clear.

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

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

The description clearly states the tool 'Searches the available bank connectors by name', providing a specific verb (searches) and resource (bank connectors). It distinguishes itself from siblings like openfinance_list_connections by focusing on keyword search and returning connector details including a pre-built connect_url.

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

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

The description explicitly says 'Call this BEFORE connecting to hand the user a one-click link to the right bank,' giving clear when-to-use context. It also mentions that keywords[] is REQUIRED and that the tool honors the user's plan. However, it does not explicitly name alternatives or state when not to use it, which would be ideal.

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 are minimal (no readOnly, destructive hints). The description goes beyond them by revealing that recategorizing creates a Category Rule, affecting future categorization, and describing batch error handling. This provides essential 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 front-loaded with the core action and progressively details side effects, input sources, and output format. Every sentence adds value, and the information is well-organized for quick comprehension.

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

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

Given no output schema, the description fully specifies the return shape (`updated`, `results`, `errors`). It also covers error handling (per-item errors don't fail batch) and side effects (rule creation). This makes the tool's behavior complete and predictable.

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 bears the full load. It explains the `items` array structure, required fields (`transaction_id`, `category_id`), and the source of each ID from sibling tools. This adds significant meaning beyond the schema.

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

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

The description clearly states the verb 'corrects' and the resource 'category of transactions', and includes the HTTP method PATCH. It distinguishes from sibling tools like listing or syncing by focusing on category correction and future learning.

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

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

The description explains when to use the tool ('to fix miscategorized transactions') and where to obtain required IDs from related tools. It does not explicitly state when not to use it or provide alternatives, but the context is sufficient for appropriate selection.

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

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

Annotations 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, idempotentHint=true, destructiveHint=false. The description adds valuable context about what the returned state contains (installed MCPs, connection status, catalog count), which goes beyond the annotations without contradicting 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?

Single sentence that fronts the purpose ('Returns the current toolkit state:') followed by concise enumeration of returned data. No wasted words, easy 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?

Given zero parameters, no output schema, and simple nature of the tool (state introspection), the description covers all essential information: what the tool does and what it returns. No gaps for an agent to make errors.

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

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

Tool has zero parameters, so baseline is 4. Description does not need to add parameter meaning. It correctly omits any parameter details since none exist.

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 'toolkit state' and lists three specific pieces: installed MCPs, connection status, and catalog tool count. This verb+resource+scope distinguishes it from siblings that perform actions on finance 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 description implies usage for checking toolkit state, but provides no explicit when/when-not guidance or alternatives. No exclusions mentioned. Context makes it clear this is for introspection, but lacks explicit guidance.

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