Stone Pagamentos MCP

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

Discloses behavior beyond annotations: no args returns a link, token arg authenticates, and permanent config alternative. Annotations already indicate idempotent and non-destructive, and description adds valuable 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?

Single dense paragraph effectively conveys all necessary info. Could be slightly more structured, but 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 tool with one optional parameter and no output schema, the description covers all critical aspects: audience, methods, token format, and permanent vs session 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 0% schema coverage, description fully compensates by explaining the 'token' parameter's purpose (JWT for session login) and behavior when omitted (returns link).

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's for authentication, specifying the target audience (IDE agents) and the two login methods (permanent config vs session token). Distinguishes from sibling tools like 'connect' which likely involve external service 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?

Provides clear when-to-use (for login) and explains both permanent and session approaches. Lacks explicit exclusions but gives sufficient context for 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?

The description adds useful behavioral context beyond the annotations, such as the response structure in different states (authenticated and pending when all connected, connect_url when missing credentials). No contradictions with annotations (readOnlyHint, idempotentHint, destructiveHint).

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

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

Two sentences with no wasted words. The main purpose is front-loaded, and the description 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 no output schema and no parameters, the description provides sufficient context about the tool's behavior in two key scenarios. It could potentially cover more edge cases (e.g., partial connections) but is generally complete for a simple status tool.

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

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

With zero parameters, schema coverage is 100%. The baseline is 4 per rules, and the description does not need to add parameter info. It correctly omits 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 connection status and URLs, with specific scenarios for when all providers are connected vs when credentials are missing. However, it does not explicitly distinguish from the sibling 'authenticate' tool, which might also involve connection-related information.

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

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

The description does not provide any guidance on when to use this tool versus alternatives like 'authenticate' or other sibling tools. There is no mention of when not to use it or prerequisites.

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 key behaviors: invoke works without installing, may return connect/checkout links, writes require admin, and search/describe flag installed states. This adds significant value beyond annotations, which only hint at non-read-only nature.

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 dense paragraph, which is verbose for the amount of information. Could be more structured (e.g., bullet points for actions) to improve scanability. Front-loaded purpose is good, but overall 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?

Given no output schema and 13 parameters with 0% schema coverage, the description should provide comprehensive parameter details and return value expectations. It covers the usage flow well but lacks per-parameter specifics and output descriptions, leaving gaps for an agent to 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 coverage, description must explain parameters, but it only broadly describes actions and mentions a few parameters (e.g., query, mcp_id, tool_id). Many parameters (e.g., message, tier_slug, conversation) are left undocumented. Partial compensation.

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

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

The description clearly states the tool is the official marketplace for MCPs and tools, and explains its core actions (search, describe, invoke) and how they relate. It distinguishes from other tools by specifying it should be used first for capability discovery.

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

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

Explicitly instructs to use this tool first before external registries for capability seeking. Contrasts invoke (one-off) vs install (permanent), and notes that write actions require workspace owner/admin. Provides clear when-to-use and 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?

Adds context beyond annotations: mentions revocation of consent, deletion, and reconnection URL. Annotations indicate destructiveHint=true, which matches.

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

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

Three concise sentences, front-loaded with essential information, no wasted text.

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

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

Covers purpose, outcome, and return value; missing parameter clarification slightly reduces 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?

Only parameter 'item' has no schema description (0% coverage), and the tool description does not explain what value to provide; agent must infer.

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 revokes consent, deletes connection data, and makes bank data unavailable, which is specific and distinguishes from siblings.

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

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

Cues usage for disconnecting a bank, but does not explicitly exclude use cases or mention alternatives, though context makes it 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?

With no behavioral hints from annotations (destructiveHint=false, readOnlyHint=false), description fully details synchronous wait up to 60s, polling behavior, possible outcomes (needs_action, timed_out), and return fields. 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?

Description is a single dense paragraph but front-loaded with purpose. Every sentence adds necessary information. Slightly verbose but efficient given complexity. Could be broken into list for clarity, but still well-structured.

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

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

No output schema, but description fully documents return object (results, errors, status fields, synced, etc.). Covers all aspects: purpose, when to use, parameters, behavior, output, and follow-up actions. Complete for a non-trivial tool.

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

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

Schema coverage is 0%, but description explains 'items' as array of selectors (item_id, connector_id, or connector_name) and optional to sync all. 'wait' explained as boolean for fire-and-forget. Adds meaning beyond basic 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 it forces re-sync of bank connections and waits for completion. It distinguishes from sibling tools by explaining it pulls fresh data without disconnecting, addressing stale balance/transaction lists. The verb 'forces re-sync' and resource 'bank connections' 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 says 'Use this when a balance or transaction list looks stale'. Provides guidance on items parameter (omit for all banks) and wait parameter (false for fire-and-forget). Also advises to check with openfinance_get_item_status on timeout. Complete usage instructions.

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

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

Adds context beyond annotations: real-time nature, error handling for credit accounts, and response shape. Annotations already indicate read-only and 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?

Three concise sentences with key information front-loaded. No redundant text.

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 response shape and error handling without an output schema. Missing details on authentication or prerequisites, but those are common across sibling tools.

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 lacks descriptions (0% coverage). The description adds meaning by specifying the array constraint (1-50 items) and that values are account IDs, but does not elaborate on string format.

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 an account ID and specifies the endpoint. It distinguishes from siblings 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 specifies when to use (get balance) and includes constraints (array of 1-50 account IDs). Does not explicitly exclude alternatives, but no sibling tool serves the same purpose.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: the batch endpoint returns { results, errors } and requires 1-50 account IDs. 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?

Two sentences, front-loaded with purpose, then constraints and return shape. No fluff or redundant information. Efficiently communicates key points.

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 mentions the return shape ({ results, errors }) and the array length limit. However, it does not describe the structure of result objects or error details. Given the complexity of account objects with extended creditData, more detail would be beneficial.

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% for the only parameter (account_ids). The description adds that it is an array of IDs with a size limit (1-50). This is helpful but does not specify what the IDs represent (presumably account IDs) or expected format. More detail would improve 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 it returns full account objects including extended creditData per account ID. It mentions batch shape and the parameter. However, it does not explicitly distinguish itself from the sibling tool openfinance_list_accounts, which might return summary data, so it's not perfectly clear when to use which.

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

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

The description implies usage when you need full details for specific account IDs by requiring account_ids as an array. It gives a length constraint (1-50) but no guidance on when not to use it or alternatives. Sibling tools exist (e.g., openfinance_list_accounts) but no comparison is made.

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 idempotentHint=true. The description adds behavioral details beyond annotations: notes Pluggy does not return a paid/status field, explains the batch shape { results, errors }, and warns about payments[] being from the previous bill's cycle.

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 thorough and front-loaded with the main purpose. Every sentence adds value, but it is somewhat long. Could be slightly more concise without losing clarity.

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

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

Given no output schema, the description fully explains the return shape (fields, batch shape) and provides critical context about payments and paid status. It covers potential pitfalls and directs to complementary tools, making it complete 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?

Schema description coverage is 0%, but the description adds meaning by stating 'Pass `bill_ids` as an array' and advising to use openfinance_list_credit_card_bills to discover ids. This provides context beyond the bare schema, though it could explicitly confirm the format.

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 bill-level detail for one or more credit card bills by id, listing specific fields (financeCharges, payments[] with id, paymentDate, amount, valueType, paymentMode). It distinguishes itself from sibling tools like openfinance_list_transactions by clarifying it does not return individual 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 clear guidance on when to use this tool versus alternatives: it directs users to openfinance_list_transactions for itemized transactions and to openfinance_list_credit_card_bills for discovering bill IDs and checking payment status. It also explains the caveat about payments[] reflecting the previous bill's payment.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating safe read operations. The description adds value by explaining that it returns status, executionStatus, and connector metadata, and describes the structure for all-banks mode (`{ count, items }`). 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 consists of two efficient sentences. Every part adds value: the first sentence defines the return fields, the second explains the two invocation modes. Zero wasted words, well structured for quick comprehension.

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

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

Given no output schema, the description adequately covers what is returned (status, executionStatus, connector metadata; and for all-banks: `{ count, items }`). The parameter explanation is complete. No missing aspects for correct invocation and understanding.

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

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

The input schema has one optional `item` parameter with no description, and schema description coverage is 0%. The description compensates fully by explaining that omitting `item` returns all banks and passing `item` returns a single bank, adding critical 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 tool returns the current status of a bank connection and lists the specific fields. It distinguishes between getting status for all linked banks (by omitting `item`) and for a single bank (by passing `item`), which is a specific verb+resource scope.

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

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

The description explicitly explains two usage modes: omit `item` for all banks, pass `item` for a single bank. It provides clear context on how to invoke each mode, though it does not explicitly contrast with sibling tools or state when not to use this tool. The sibling list is large, but the description 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?

Beyond annotations (readOnlyHint, idempotentHint), description reveals critical behavioral nuances: credit card balance meaning is connector-dependent, account name vs. bank brand distinction, and the inclusion of item_id in results. 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?

Description is lengthy but each sentence adds value. Front-loaded with core purpose, then adds details and warnings. Slightly verbose, but well-structured with logical flow.

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?

Completely covers all aspects: return fields, parameter behavior, cross-connector differences, and relationship to sibling tools. No gaps given the tool's complexity and available structured data.

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

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

Schema description coverage is 0%, so description compensates fully. Explains item parameter semantics clearly (omit for all, pass for single) and mentions type enum implicitly through return types. Could explicitly state that type filters results, but overall adds substantial 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?

Description clearly states the verb ('Returns accounts') and resource ('for a bank connection'), specifies account types (BANK and CREDIT) and included fields. It differentiates 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?

Explicitly instructs when to omit item parameter for listing across all banks vs. pass item for a single bank. Warns against misinterpreting credit card balance as monthly bill and directs to alternative tool for standardized amounts. Provides clear use-case guidance.

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

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

Annotations already indicate safe, idempotent read. Description adds caching behavior and clarifies single aggregated response, providing additional 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?

Three sentences, each providing essential information without redundancy. Perfectly concise.

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

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

Completely explains the structure of each entry in the response, including fields and language preferences. No output schema exists, so description must cover it, and it does.

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, baseline 4. Description does not need to add param info since there are none.

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

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

Clearly states it returns Pluggy's transaction category taxonomy, and the description distinguishes it from siblings by noting it is cached and a single aggregated response.

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?

Explains how to use the categoryId in another tool (openfinance_update_transaction_category) and mentions language preferences for pt-BR users, but does not explicitly state when to use vs 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 provide readOnlyHint, idempotentHint, destructiveHint. Description adds the returned fields and the add_connection_url, which is helpful but doesn't disclose additional behavioral traits beyond annotations.

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

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

Single sentence with all essential information, front-loaded with verb 'Returns'. 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?

Given no output schema, description explains return fields. Annotations cover safety. No missing info for a simple list tool.

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

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

No parameters; baseline 4 applies. Description adds meaning about return fields but does not need to document 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?

Description clearly states it returns saved bank connections with specific fields (connector_id, item_id, bank name, add_connection_url). Distinguishes from siblings which focus on accounts, transactions, etc.

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?

Implied usage: first step to list existing connections before using other tools. No explicit when-not or alternatives, but context makes it clear.

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

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

The description details complex behaviors: payment logic across bills, derived payment_status rules, connector asymmetry for open bills, and the fact that it returns a warning if the product is not enabled. Annotations already declare readOnlyHint and idempotentHint, and the description adds extensive context beyond those.

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-organized, starting with the core purpose, then important semantics, then details. Each sentence adds necessary information for the complex domain. It could be slightly more concise, but the structure is logical and front-loaded.

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

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

Given the absence of an output schema, the description thoroughly explains return values (payments, payment_status, open_bill, future_bills). It covers edge cases, connector asymmetry, and provides cross-references. The complexity of the tool demands such completeness, and it delivers.

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

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

With 0% schema description coverage, the description compensates by explaining important parameters: include_open_bill (opt-in, what it returns), account_ids (bulk support), and the common use of page/page_size. It adds meaning beyond the bare schema, though page/page_size are not elaborated.

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 CREDIT-type accounts, listing key fields and providing a derived payment_status. It distinguishes itself from sibling tools like openfinance_get_credit_card_bill (singular) and openfinance_list_transactions (itemized).

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 guidance is given: when to use (closed bills, not open), when to opt-in for open bill (include_open_bill), and when to use alternative tools (e.g., openfinance_list_transactions for itemized purchases). It also warns against misinterpreting payments due to Open Finance semantics.

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

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

Annotations already indicate readOnly=true and idempotent=true. The description adds context about the return shape (total, results, warning) and error case behavior, which goes beyond annotations.

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

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

The description is a single dense paragraph but effectively front-loads the purpose and lists key details. It could be slightly better structured but remains concise without unnecessary content.

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 endpoint with no output schema, the description covers the return format and error handling well. Missing parameter descriptions are the main gap, but overall it provides sufficient context.

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%, and the description does not explain any of the four parameters (item, page, type, page_size). The return value description doesn't compensate for missing parameter semantics.

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

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

The description clearly states the tool returns investment portfolios for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.). It distinguishes from sibling tools like openfinance_list_accounts or openfinance_list_transactions by focusing on INVESTMENTS product.

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 that it's for connections with INVESTMENTS product enabled, and mentions error handling (returns warning instead of throwing). However, it does not explicitly state when to use versus alternatives or provide exclusion criteria.

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

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

Annotations already mark as readOnly, idempotent, non-destructive. Description adds value by enumerating transaction types and return fields (quantity, value, expenses breakdown). Does not contradict annotations; adds behavioral detail beyond what is in structured fields.

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 paragraphs: first lists output details, second provides usage context and bulk support. No redundant information. Efficient and well-structured.

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

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

Provides enough detail for use: operation type, required param, bulk capability. Lacks explanation of pagination (page, page_size) and their defaults. Given no output schema, description adequately summarizes return fields but omits page-related 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?

Schema description coverage is 0%. Description explains investment_id (needed from list_investments) and investment_ids (bulk), but does not cover page or page_size parameters. Partially compensates for missing schema descriptions but leaves pagination undocumented.

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

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

Clearly states it returns movement history for a specific investment position, listing transaction types (BUY/SELL/TAX/etc.). Differentiates from sibling tools like openfinance_list_investments (which provides investment IDs) and openfinance_list_transactions (general transactions).

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

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

Explicitly says to use after openfinance_list_investments to get investment_id, providing a clear dependency. Mentions bulk support via investment_ids. Does not specify exclusions or when not to use, but gives sufficient context for selection.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, indicating a safe, read-only operation. The description adds valuable behavioral context: sequential queries with rate-limit spacing, and the return format `{ results, errors }` per connection. This goes 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, compact paragraph with precise language. Every sentence adds value: purpose, parameter usage, alternative mode, and behavior. No wasted words, and the key information is front-loaded.

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

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

Given the tool's simplicity (1 parameter, no output schema, rich annotations), the description is complete. It covers purpose, parameter semantics, behavior (rate-limit spacing, sequential queries), and return format (`{ results, errors }`). No gaps remain for an agent to invoke the tool correctly.

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

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

The input schema has one parameter `items` with 0% coverage, but the description fully explains its semantics: an array of connection selectors (item_id uuid, connector_id, or connector_name), and the behavior when omitted. This adds essential 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 it lists loan contracts per bank connection, specifies the HTTP method (GET /loans), and distinguishes between providing specific connections via `items` or listing all linked banks. This is a specific verb+resource definition that sets it apart from sibling 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?

The description gives explicit guidance: pass `items` as an array of connection selectors to fetch specific connections (with rate-limit spacing), or omit `items` to list across all linked banks. This clearly tells when and how to use each mode, though it does not explicitly mention when not to use the tool or alternative 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?

Description adds context beyond annotations: details about CREDIT pending/posted behavior, bulk support, error handling (returns error object), pagination limits, and aggregation with search_queries. 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?

Well-structured with clear sections, but somewhat lengthy. However, every sentence adds value, and the structure aids readability.

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

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

Covers all parameters, error handling, use cases, and troubleshooting. Lacks explicit output schema, but describes error response and implies success response structure. Adequate for a list tool.

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

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

Schema description coverage is 0%, but description fully explains all parameters: from/to (ISO YYYY-MM-DD), page, page_size (max 500), search_queries (case-insensitive substring match, OR semantics), and account_ids for bulk.

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).' It specifies the resource (transactions) and action (list). It distinguishes from siblings by noting this is the only way to get itemized credit card transactions and contrasts with 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: for CREDIT accounts, this is the ONLY way to get itemized transactions; use openfinance_list_credit_card_bills for standardized totals; advises narrowing date range if truncated:true; and suggests checking connection health if total is 0.

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

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

Adds significant context beyond annotations: default granularity returns compact summary fields, raw returns all rows, scan caps at 5000/account with truncation flag, and filtering by type. 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 front-loaded with core purpose and packed with necessary details. While slightly lengthy, every sentence adds value and avoids redundancy.

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

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

Given the lack of output schema and 6 parameters, the description covers key outputs (por_mes, top_despesas, etc.), behavior (truncation, default granularity), and edge cases (omit item). Minor gap: raw granularity output format not fully detailed.

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 by explaining item, from/to, granularity, and type. However, the top_n parameter is not explicitly mentioned, though the concept of 'largest N' is implied in top_despesas/recebimentos.

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 specifies a concrete verb ('Consolidated cash-flow analysis') and resource ('whole bank CONNECTION'), and distinguishes from sibling tools like openfinance_list_accounts by noting it resolves accounts internally, eliminating the need for prior calls.

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

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

Explicitly states when to use (e.g., 'análise anual/mensal', 'fluxo de caixa') and covers both default and raw granularity use cases. It explains omitting item to analyze all banks, but does not explicitly contrast with alternative tools like 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, idempotentHint, destructiveHint, and openWorldHint. The description adds behavioral context by specifying that it checks a public status page and returns a global indicator, degraded components, open incidents, and flags affecting the user's banks. This goes beyond the annotations, but the annotations already cover the safety profile adequately.

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 three sentences that efficiently cover purpose, usage context, and return value. No redundancy; every sentence earns its place.

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

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

Given zero parameters and no output schema, the description fully explains what the tool does, when to use it, and what it returns. It is complete for a status-checking tool.

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

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

There are no parameters (0 params), so baseline 4 is appropriate. The schema coverage is 100%, so no additional parameter information is needed.

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 checks the LIVE operational status of the Open Finance provider's public status page, distinguishing it from the sibling tool openfinance_get_item_status which checks the user's own connection. The verb 'checks' and specific resource 'provider status' are 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 use this tool: 'whenever data looks incomplete or stale even though a connection shows UPDATED'. It explains what the tool reveals (upstream outage or known incident) and how it helps differentiate provider-side issues from connection problems, thus providing clear usage guidance.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds behavioral traits: honors user's plan (PF vs PJ), returns hint if no keywords, and provides connect_url. 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 informative but slightly lengthy; however, every sentence adds value. Front-loaded with main action and key details. Could be more concise 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 exists, so description explains return fields (connector id, access, audience, etc.) sufficiently. With annotations covering safety profile and context signals (2 params, no required params in schema but description clarifies), it is complete for agent 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?

Schema coverage is 0%, so description carries full burden. It explains both parameters: 'keywords' array of strings (required) and 'include_accounts' boolean. Adds meaning beyond schema such as requirement and behavior when missing.

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

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

The description clearly states the tool searches bank connectors by name, listing specific return fields (connector id, access, audience, linked connections, accounts, connect_url). It distinguishes from siblings as no other search tool is present.

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 'Call this BEFORE connecting' and notes that keywords are required (without it returns a hint). Provides context about plan filtering and pre-selected connect_url. Does not explicitly exclude alternatives 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?

The description goes beyond the annotations (which only indicate non-destructive and non-idempotent) by revealing a key side effect: recategorizing automatically creates a Category Rule that influences future transactions. This is critical behavioral context for an AI agent.

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

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

The description is moderately concise, front-loading the primary action and then layering in important details about batch behavior and side effects. It could be slightly more concise, but every sentence serves a 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?

Despite no output schema, the description explicitly details the return shape ({ updated, results, errors }) and batch error handling. This provides complete contextual information for the agent to understand the tool's behavior and response.

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

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

With 0% schema description coverage, the description fully explains the 'items' parameter: it requires an array of objects with transaction_id and category_id, and specifies that the IDs come from sibling tools. This adds significant meaning beyond 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 'Corrects the category of one or more transactions' with a specific HTTP method and endpoint, and distinguishes itself from sibling tools like openfinance_list_transactions by focusing on mutation rather than listing.

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 improve future categorization. It also tells where to source transaction_id and category_id from other tools. However, it does not explicitly state when not to use it or mention 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 idempotentHint=true and destructiveHint=false, so the description's mention of reporting is consistent. No additional behavioral traits are disclosed, such as whether the request is sent immediately or requires confirmation.

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

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

The description is a single sentence with no redundant information. It is concise and front-loaded with the purpose.

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

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

For a simple feedback tool with 3 parameters and no output schema, the description covers the main purpose but lacks sufficient detail on parameter usage and the expected behavior after submission.

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

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

With 0% schema description coverage, the description adds minimal value. It mentions the conversation array but does not clarify the format or expected structure. The required 'message' parameter and optional 'context' are not explained.

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 is a specific verb-resource combination. It is distinct from all sibling tools, which are focused on financial operations.

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

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

The description explicitly advises to include the conversation array with recent messages for reproduction, providing clear guidance on how to use the tool. However, it does not specify when not to use it or mention any 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond the purpose, such as authentication requirements, rate limits, or output format. Thus, description provides minimal added transparency.

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

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

The description is a single, concise sentence with no unnecessary words. It is front-loaded with the action and resource, making it 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 the tool's simplicity (no input parameters, no output schema, a single clear purpose), the description is fully complete. It covers all needed information for an AI agent to understand when and how to invoke it.

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 no parameters, so schema description coverage is 100%. The description correctly implies there are no parameters; baseline for zero parameters is 4. No additional parameter information is necessary or provided.

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 'Show the current MCP platform and adapter versions' clearly specifies the action (show) and the resource (MCP platform and adapter versions). It is distinct from sibling tools, which focus on authentication, banking operations, or other functionalities.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives. Since it is a simple informational tool, usage context is implied, but no exclusions or prerequisites are mentioned.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe read operation. The description adds value by specifying the exact information returned (installed MCPs, connection status, catalog tools), which is beyond the annotations. No contradiction.

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

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

A single sentence that is clear and concise with no filler. It front-loads the core purpose and 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?

Given no output schema, the description adequately explains what the tool returns. It is complete for a simple introspection tool with annotations providing safety assurances.

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

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

The tool has zero parameters and schema coverage is 100%. Baseline for no parameters is 4. The description does not need to add parameter details.

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 with specific elements: installed MCPs, connection status, and catalog tool count. It is a specific verb+resource that distinguishes from all 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?

The description provides clear context for usage (current toolkit state), but does not explicitly mention when not to use it or compare to alternatives. However, no sibling tool performs a similar function, so the lack of exclusions is acceptable.

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