Mercado Pago MCP

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

Discloses key behaviors: ability to set permanent or session-only token, how token is provided, and that calling with no args returns a link. Adds context beyond annotations (idempotentHint, non-destructive) that already indicate safe, repeatable behavior.

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

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

Description is slightly verbose but well-structured: starts with purpose, then two usage options. Each sentence adds value. Could be more concise but remains 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 tool's simplicity (1 optional param, no output schema), the description covers all necessary context: how to authenticate, two methods, and how to invoke the tool. No gaps.

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

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

Schema only defines 'token' as string with no description. The description explains its meaning (JWT token from browser), how to use it (paste after user gets it), and the effect of omitting it (returns link). Fully compensates for 0% schema description coverage.

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

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

The description clearly states the purpose: authentication by logging in and obtaining an access token. It specifies two methods (permanent config vs session-only) and distinguishes itself from sibling tools, none of which are authentication-focused.

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 provides when to use each calling pattern: with no args to get a link, with token to set session, and recommends a permanent config approach. Guides agent on user interaction and best practices.

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. The description adds specific return fields (authenticated, pending, connect_url) and explains the two relevant states, providing useful behavioral context beyond the annotations.

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

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

Two concise sentences with no filler. The most important information (returns status and URLs) is first, followed by clarifying examples.

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 parameterless tool, the description adequately covers the two main states. It could mention if the tool itself requires prior authentication, but that is reasonable inferred.

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

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

There are zero parameters, so the description carries full burden. It explains the tool's behavior without needing parameter info, justifying a baseline of 4.

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

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

The description clearly states 'Returns connection status and URLs', with concrete examples of two states. This distinguishes it from sibling tools like authenticate and openfinance_list_connections, which have different purposes.

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

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

The description implies when to use: to check connection status and get missing credential URLs. While it doesn't explicitly exclude alternatives, the context signals and sibling list show no direct overlap, making usage clear.

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

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

The description adds substantial behavioral context beyond annotations: it explains that invoke works even when the MCP is not installed, returns connect/checkout links for blocked scenarios, and that writes require workspace owner/admin. Annotations only indicate readOnlyHint=false and openWorldHint=true, so the description enriches the agent's understanding of side effects and prerequisites.

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 spanning multiple sentences and details. While it front-loads the core purpose, it becomes verbose with edge cases and secondary actions. It could be restructured (e.g., bullet points for actions) to improve readability without losing information.

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

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

Given the complexity of 13 optional parameters and no output schema, the description covers the essential workflow, actions, and edge cases (not installed, paid, credentials, admin requirements). However, it lacks parameter-level documentation for many fields, which would be necessary for complete understanding. Overall, it is fairly comprehensive but not fully exhaustive.

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 'action' enum and relates 'mcp_id', 'tool_id', and 'arguments' to the flow, but many parameters (e.g., 'limit', 'query', 'message', 'conversation', 'report_context') remain unexplained. The description provides partial parameter context but not systematic coverage for all 13 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 defines the marketplace tool as the primary catalog for MCPs and tools, with a specific verb (search, describe, install, etc.) and resource (MCP marketplace). It distinguishes itself from sibling tools by explicitly stating 'use THIS tool FIRST' and outlining the core flow, making its purpose unmistakable.

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 each action (e.g., 'Core flow: action=search discovers MCPs... describe returns one MCP's full profile... invoke RUNS that tool') and when not to use alternatives ('prefer invoke for a single/occasional use', 'use install only to make an MCP PERMANENT'). It also covers credential and payment scenarios, leaving no ambiguity.

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

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

Annotations already indicate destructive behavior (destructiveHint=true). The description adds that bank data will no longer be available and provides a re-connection URL, offering 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?

Two sentences efficiently convey the tool's action and effect without extraneous 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 is adequate for a simple tool with one parameter and no output schema, but the missing parameter definition leaves a gap that could confuse agents.

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

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

The single required parameter 'item' is not explained in the description or schema (0% schema description coverage). The description should clarify what 'item' represents (e.g., bank identifier) but does not.

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

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

The description clearly states the tool revokes Open Finance consent and deletes connection data for a specific bank, distinguishing it from sibling tools like 'connect' or 'openfinance_force_sync'.

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 conveys when to use it (to revoke consent and delete data) and mentions it returns a re-connection URL, but does not explicitly state when not to use it or provide 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?

The description fully discloses behavior: synchronous polling with ~60s timeout, fire-and-forget option, return fields including status flags and error conditions. Annotations (readOnlyHint=false, destructiveHint=false) are consistent; the description adds 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 dense but every sentence adds value. It front-loads the core action, then covers usage, parameters, return values, and edge cases in a logical order with no waste.

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

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

Given the tool's complexity, no output schema, and zero parameter descriptions in schema, the description provides complete information: when to use, parameters, return format, error states, and next steps for timed-out or needs_action scenarios.

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?

Although schema description coverage is 0%, the description thoroughly explains both parameters: 'items' (array of selectors or omit for all) and 'wait' (boolean for synchronous vs fire-and-forget). This compensates fully for the missing schema descriptions.

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

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

The description clearly states the tool's purpose: forces a bank to re-sync connections and waits for completion. It distinguishes itself from sibling tools like openfinance_get_item_status by describing the sync-and-wait mechanism and the scenarios when it should be used.

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

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

The description explicitly states when to use (stale balance/transaction list) and when not to (without disconnecting), provides an alternative (fire-and-forget with wait:false), and directs the user to openfinance_get_item_status for timeout cases.

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 and idempotent. Description adds value by explaining real-time nature, response shape with results and errors, and specific error handling for CREDIT accounts (warning instead of throwing). No contradiction with annotations.

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

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

Three concise sentences front-loaded with purpose, then constraints, edge case, and response shape. No fluff, every sentence adds value.

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

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

Given no output schema, the description adequately covers response shape, error cases, and input constraints. It mentions the endpoint for context. Could mention authentication or prerequisites but overall complete for agent 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?

Schema coverage is 0%, but the description adds critical semantics: `account_ids` as an array of size 1-50. This goes beyond the schema which only defines type and no constraints.

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 returns real-time balance payload per account id, including the endpoint. It specifies the input array constraints but does not explicitly differentiate from sibling tools like openfinance_list_accounts or openfinance_get_accounts_detail.

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

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

No explicit guidance on when to use this tool vs alternatives. It does not mention prerequisites or when not to use it. The description focuses on behavior but lacks usage context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds value by specifying batch size limit, return shape ({results, errors}), and inclusion of extended creditData.

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 the purpose, includes all essential information without redundancy.

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

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

For a simple batch GET tool with one parameter and no output schema, it covers input constraints, return shape, and data content. Could mention response fields or error handling, but is fairly complete.

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

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

Schema provides no description (0% coverage). Description adds critical constraint: array size 1-50 and explains that IDs correspond to accounts. No format details, but compensates well for the 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 full account objects with extended creditData per ID, distinguishing it from sibling list tools like openfinance_list_accounts which 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?

Explicitly states input format (array of 1-50 IDs) and batch return shape. Implies use when extended creditData is needed, but does not explicitly exclude 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?

Discloses behavioral traits beyond annotations: batch shape {results, errors}, absence of paid/status field in Pluggy, and the nuanced interpretation of payments[] indicating previous bill payment, not current bill status.

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 relatively long but front-loaded with core purpose. Every sentence adds value, though some details (e.g., subfield list) could be integrated into a more concise structure.

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 lists returned fields and batch shape. Provides cross-reference to sibling tools and explains nuanced behavior relevant to domain. Complete for a read-only detail endpoint.

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

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

The single parameter bill_ids is explained: pass as an array, discover ids via sibling tool. Schema coverage is 0%, so description compensates well, though it could add example values or format hints.

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

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

The description clearly states it returns bill-level detail for credit card bills by id, specifies included fields (financeCharges, payments[]), and explicitly excludes individual transactions, distinguishing it from openfinance_list_transactions.

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

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

Provides explicit guidance: use openfinance_list_transactions for itemized transactions, use openfinance_list_credit_card_bills first to discover bill_ids, and includes a NOTE warning about the meaning of payments[] in Brazilian Open Finance.

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 read-only and idempotent; description adds response format details (single vs. list) and the concept of execution status, enhancing transparency beyond structured fields. No contradictions.

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

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

Two concise sentences, front-loaded with what the tool returns and key behavior, with no wasted words.

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

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

Adequately covers the tool's behavior and response formats given its simplicity; could specify the exact return object for a single bank (e.g., status, executionStatus), but current explanation is sufficient for selection and invocation.

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

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

Despite 0% schema description coverage, the description fully compensates by explaining the effect of omitting (returns count and items for all banks) vs. providing (returns single bank status) the 'item' 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 the current status of a bank connection with specific statuses listed (UPDATED, UPDATING, LOGIN_ERROR, etc.), distinguishing it from sibling tools that handle authentication, sync, or account details.

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

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

Explicitly explains when to omit vs. include the 'item' parameter for all banks vs. single bank. Could add more about when not to use (e.g., for initial connection), but current guidance is clear and actionable.

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

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

Annotations declare readOnlyHint, idempotentHint, and non-destructive. The description adds critical context: the connector-dependent meaning of `balance` for credit cards, the distinction between `name` (legal entity) and `bank` (brand), and the structural difference when omitting `item` (aggregated results with per-account metadata). 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 relatively long but every sentence adds value. It front-loads the primary function, then covers parameter usage, field disambiguation, and a critical warning. It is well-structured with clear sections and no redundant information. The length is justified by the complexity of the 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 the tool has 2 optional parameters, no output schema, and a rich return structure, the description is remarkably complete. It explains the return fields (`bank`, `connector_id`, `item_id`), the difference between `name` and `bank`, the special handling of CREDIT balances, and references the sibling tool for standardized billing. Minor details like exact field names in bankData/creditData are noted as returned, which suffices.

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 bears full responsibility. It thoroughly explains both parameters: `item` (optional, when passed targets a single bank, when omitted lists all) and `type` (implied filter by the note that accounts are of type BANK or CREDIT). The description adds meaning beyond the schema by explaining the effect of omitting `item` and the tag attached to each account.

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

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

The description clearly states the tool lists accounts for a bank connection, specifying account types (BANK/CREDIT) and returned fields (balance, number, type, etc.). It distinguishes from sibling tools like openfinance_list_credit_card_bills by directing users there for standardized billing data. The verb 'list' and resource 'accounts' are specific and unambiguous.

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

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

The description provides explicit guidance: when to omit `item` (list across all banks, use for 'my accounts/cards' without naming a bank) and when to pass `item` (target a single bank). It also warns against misinterpreting `balance` for credit cards and directs to openfinance_list_credit_card_bills for standardized amounts. This covers when to use and when not to use.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds valuable behavioral context: caching for the session, single aggregated response with no batch ids, and field-level details. This goes beyond annotations and helps the agent understand performance and usage patterns.

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 (three sentences), front-loaded with the core purpose, and efficiently details each return field. Every sentence adds value without redundancy or waste.

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

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

Despite no output schema, the description fully explains return structure (id, description, descriptionTranslated, parentId, parentDescription) and behavioral traits (cached, aggregated). Annotations cover safety. The tool is simple (no params), and the description leaves no significant gaps.

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

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

The tool has zero parameters, and schema coverage is 100% (vacuous). Per guidelines, baseline is 4. The description adds no parameter details because none exist, which is appropriate.

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

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

The description clearly states the tool returns Pluggy's transaction category taxonomy (GET /categories). It specifies the resource (categories) and the verb (returns/list). It also distinguishes from sibling tools by noting that the 'id' field is used by openfinance_update_transaction_category, providing a clear relationship.

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 before updating a category by highlighting the 'id' field's role in openfinance_update_transaction_category. It mentions caching and aggregated response, but does not explicitly state when to use it vs alternatives. However, no direct alternatives exist among siblings for listing categories, so the guidance is adequate but not explicit.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds context about returned fields and an add_connection_url, which is useful beyond 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?

The description is a single, efficient sentence that front-loads the purpose and key outputs. Every word adds value.

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

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

Given no parameters, an output schema, and existing annotations, the description fully explains what the tool does and returns. It is complete 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?

There are no parameters (schema coverage 100% for empty properties). According to rules, baseline is 4 for zero params. The description provides no parameter info, but none 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 the tool returns saved bank connections and lists specific fields (connector_id, item_id, bank name, add_connection_url). This distinguishes it from sibling list tools like openfinance_list_accounts.

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

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

The description implies the tool is for listing connections but does not explicitly state when to use it vs alternatives (e.g., other list tools). No when-not-to-use or alternative guidance is provided.

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

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

Description adds significant behavioral info beyond annotations (readOnlyHint, idempotentHint, destructiveHint). Explains payment cycle logic, derived payment_status, open_bill opt-in behavior, connector asymmetry, and caution about billing status. 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?

Long and verbose, but well-structured with sections (IMPORTANT, OPEN BILL, CONNECTOR ASYMMETRY). Could be more concise without losing critical 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?

Comprehensively explains return fields (payments[], payment_status, open_bill, total_pending_debt, etc.) given no output schema. Covers edge cases (connector asymmetry, warning behavior) and provides complete context for a complex tool.

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

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

Schema coverage is 0%, so description must compensate. It explains include_open_bill in detail and mentions account_id/account_ids context, but does not describe page, page_size, or account_id syntax. Adds meaningful value for key parameters but not fully comprehensive.

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 the tool 'Returns CLOSED credit card bills for a CREDIT-type account' and lists specific fields. Distinguishes from sibling tools like openfinance_get_credit_card_bill and openfinance_list_transactions.

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

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

Provides clear context on when to use (closed bills) and mentions alternatives for itemized purchases. Does not explicitly state when not to use, but gives enough guidance through semantics and interactions.

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 detailing the fallback response on errors (returns { total:0, results:[], warning }) and listing specific fields returned (balance, amount, rate, dueDate, etc.). 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 a single dense paragraph, but it efficiently packs a lot of information (asset types, fields, error handling). Could benefit from slight structuring (e.g., bullet points for fields), but not overly verbose.

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

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

Given the complexity (multiple investment types, many fields, 4 parameters, no output schema), the description is incomplete. It lists return fields but fails to explain parameter usage, pagination, or how the different asset types map to the type parameter. The error handling detail is helpful but not sufficient.

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

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

Schema description coverage is 0%. The description does not explain any of the 4 parameters (item, page, type, page_size), leaving the agent without guidance on how to use them. The type parameter's enum values are not even mentioned.

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, fixed income, mutual funds, retirement, COE). This verb+resource combination distinguishes it 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 implies usage for retrieving investment data but lacks explicit guidance on when to use this tool vs alternatives (e.g., openfinance_list_investment_transactions). It does mention error handling behavior, but no when-not-to-use 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?

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds detailed field information (quantity, value, amounts, expenses) and bulk execution capability, providing significant 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?

Two concise paragraphs: the first lists output fields, the second gives usage guidance (preceding step and bulk support). No redundant information.

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

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

No output schema, but the description enumerates many return fields. It also notes dependency on openfinance_list_investments. Lacks explanation of pagination behavior or default page_size.

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 must explain parameters. It explains investment_id and investment_ids (bulk), but page and page_size are missing. This partial coverage merits a score of 3.

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

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

The description clearly states it returns movement history for a specific investment position, listing transaction types (BUY/SELL/TAX etc.). It distinguishes from siblings like openfinance_list_investments by specifying that it provides transaction-level detail.

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

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

Explicitly advises to use after openfinance_list_investments to get the investment_id, and mentions bulk support. However, it does not provide exclusions or 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 read-only, idempotent, non-destructive. Description adds that multiple connections are queried sequentially with rate-limit spacing and returns per-connection results/errors. Provides 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?

Two sentences, front-loaded with main purpose. No wasted words. Clear and efficient.

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

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

Covers two usage modes and return format. Could detail result/error structure more, but given no output schema, it provides enough context 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 has 0% description coverage; description fully explains `items` as an array of connection selectors (item_id, connector_id, connector_name) and behavior when omitted. Adds substantial meaning beyond 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?

Clearly states it lists loan contracts per bank connection, a specific resource. Distinguishes between listing for specific connections (via `items`) or all banks. Differentiates from sibling list tools like list_accounts, list_transactions.

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

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

Explicitly explains when to pass `items` and when to omit. Notes sequential querying with rate-limit spacing. Lacks explicit comparison to alternatives, but context with siblings 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?

Discloses error handling (returns structured error instead of throwing), explains PENDING vs POSTED behavior by connector, and details search aggregation limits 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?

While detailed and well-structured, the description is lengthy; each sentence adds value, but slight tightening could improve conciseness.

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 aspects: core functionality, credit card specifics, search behavior, error handling, troubleshooting, and bulk support, leaving no gaps for this complex tool.

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

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

With 0% schema description coverage, the description fully explains all parameters including date format (ISO YYYY-MM-DD), pagination limits (max 500/page), and search behavior (OR semantics, case-insensitive).

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 transactions for bank accounts (BANK or CREDIT type) and distinguishes it as the only way to get itemized credit card transactions, referencing sibling tools for 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?

Explicitly advises when to use alternative tools (e.g., openfinance_list_credit_card_bills for open bill totals) and provides troubleshooting guidance for zero results.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds significant behavioral details: internal fan-out across accounts, scan cap at 5000 per account with a 'truncated:true' flag, and the difference between compact monthly summary and raw row output. No contradictions.

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

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

The description is well-structured, starting with the core purpose and then detailing parameters and behavior. It is slightly verbose but every sentence provides value. The use of bullet-style enumeration in plain text is effective. 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 the tool's complexity (consolidates multiple accounts, offers two granularities, returns nested structures) and the absence of an output schema, the description is remarkably complete. It explains the compact summary fields (entradas, saídas, saldo_liquido, por_mes, top_despesas/recebimentos, by_account), the raw mode, the scan cap, and the truncation flag. No obvious gaps.

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

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

Schema coverage is 0%, so the description carries the full burden. It explains 5 of 6 parameters: 'item' (accepts connector_id, connector_name, or item_id), 'from'/'to' (ISO dates), 'granularity' (monthly vs raw), and 'type' (BANK or CREDIT). The 'top_n' parameter is missing from the description, though its effect is implied in 'top_despesas/top_recebimentos (largest N each)'. Overall, adds substantial 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 it provides 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period' and distinguishes from sibling tools by noting it resolves accounts internally, eliminating the need for separate calls. Specific use cases like 'fluxo de caixa' and 'maiores gastos/recebimentos' are provided.

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 (e.g., for annual/monthly analysis, cash flow) and when not to use it (e.g., no need to call openfinance_list_accounts first). It also explains when to choose granularity 'raw' vs 'monthly'. However, it does not directly compare to openfinance_list_transactions, though the name and behavior imply differentiation.

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

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

Annotations already declare readOnlyHint and idempotentHint, so no safety surprise. Description adds value by detailing return fields (global indicator, degraded components, incidents) and the `your_banks_affected` flag, providing operational 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?

Description is front-loaded with purpose, followed by usage guidance and return value details. Every sentence adds value, though slightly verbose. Efficient overall.

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

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

Despite no output schema, the description fully explains what the tool returns: global indicator, degraded components, open incidents, and affected banks. For a status check tool with no parameters, this is complete and actionable.

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

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

No parameters exist, and schema coverage is 100%. Description adds no param-specific info, but per guidelines, with 0 parameters baseline is 4. No need for further elaboration.

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, distinguishing from the connection-specific `openfinance_get_item_status`. The verb 'checks' and resource 'provider status' are specific and unambiguous.

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

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

Explicitly indicates when to use: when data looks incomplete or stale despite updated connection status. Provides concrete scenarios (accounts missing, bank not returning data) and explains the diagnostic value (upstream outage vs connection issue).

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds valuable behavioral traits: it honors the user's plan (PF hides PJ banks), returns a ready connect_url, and never dumps the full catalog without keywords. This is transparent and useful.

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 carrying essential information. The description is front-loaded with the primary function and immediately followed by return details and usage advice. 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, the description explains the full return per match (connector id, access, audience, linked connections, accounts, connect_url). It also covers plan-based filtering. For a search tool with two parameters, this is complete and sufficient.

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

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

With 0% schema description coverage, the description compensates well by explaining keywords (array of strings, required, example) and include_accounts (boolean, enables account return). It adds meaning beyond the bare schema, though it could be more precise about the exact format of include_accounts behavior.

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

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

The description clearly states it searches bank connectors by name keywords and lists what is returned (connector id, access type, audience, etc.). It uses a specific verb 'searches' and resource 'bank connectors', and distinguishes itself from sibling tools like list_connections or openfinance_list_connections by focusing on search and providing a ready 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?

Explicitly states 'Call this BEFORE connecting to hand the user a one-click link', giving clear when-to-use advice. It also mentions that keywords[] is REQUIRED and the fallback behavior (returns a hint). It does not explicitly mention when not to use or alternatives, but the guidance is strong.

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

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

Beyond the minimal annotations (readOnlyHint=false, destructiveHint=false), the description fully discloses behavioral traits: overriding automatic categorization, teaching Pluggy by creating Category Rules, and the batch partial-failure handling. 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 focused paragraph that front-loads the core purpose, then efficiently covers input structure, behavioral side effects, and return format. Every sentence adds value, with no filler or redundancy.

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

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

Given the complexity of a batch update tool with side effects and no output schema, the description is remarkably complete. It explains input construction, behavioral consequences, error handling, and ties to sibling tools, leaving no essential gaps.

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

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

With 0% schema coverage, the description provides full meaning for the single parameter items: it explains the array structure, required fields (transaction_id, category_id), and sources for these IDs from sibling tools, plus the return shape. This compensates entirely for the missing schema descriptions.

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

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

The description clearly states the tool corrects the category of one or more transactions, specifying the HTTP method and endpoint. It distinguishes itself from sibling tools by explaining where to get input IDs from other tools.

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

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

The description explicitly tells when to use the tool (to fix miscategorized transactions) and provides step-by-step guidance on constructing the input by referencing sibling tools for IDs. It also explains the side effect of creating a Category Rule for future accuracy.

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 non-destructive, so the description does not need to repeat that. However, it does not disclose what happens upon reporting (e.g., ticket creation, notification to developers) or any authentication requirements. The description adds minimal behavioral context beyond the annotations.

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

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

A single, well-structured sentence that is front-loaded and concise. Every word serves a purpose, and there is no extraneous information.

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

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

Given the tool's simplicity, the description adequately covers its use case. It tells the agent to include conversation for reproduction. However, it does not explain the outcome (e.g., success message) or how the report is handled, which would be helpful for an agent to confirm action completion.

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 must compensate but only partially does so. It mentions the 'conversation' parameter and its purpose, but the required 'message' parameter and optional 'context' are left unexplained. The agent would not know what to put in 'message' or 'context' from the description alone.

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 is for reporting bugs, missing features, or sending feedback. It uses specific verbs and resource types, and distinctly differentiates from sibling tools which are focused on authentication, openfinance operations, or version info.

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

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

The description advises to include the conversation array for reproduction, providing clear context for when to use the tool. However, it does not explicitly mention when not to use or provide alternatives, but given the clear purpose and sibling set, the guidance 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?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds the specific output (platform and adapter versions), which is sufficient given the low-risk 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?

A single, concise sentence that is front-loaded and contains no unnecessary words.

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

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

For a simple version check tool with no output schema, the description is complete and informative enough 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?

No parameters exist, so baseline 4 applies. The description correctly omits any 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 uses a specific verb 'Show' and clearly identifies the resource ('current MCP platform and adapter versions'), which distinguishes it from sibling tools like authenticate or finance 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 implies usage for checking versions, but lacks explicit guidance on when to use this tool versus alternatives or any exclusions.

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 value beyond annotations by specifying the exact return content. Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, making behavior clear.

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 is concise, front-loaded with the verb 'Returns', and conveys all necessary information efficiently.

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 informational nature, the description fully explains what the tool returns. No additional details are needed.

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

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

There are no parameters, so schema coverage is effectively 100%. The description does not need to add parameter info; baseline of 4 is appropriate.

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

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

The description clearly states the tool returns toolkit state, listing installed MCPs, connection status, and catalog tools count. It is specific and distinguishes from sibling tools which focus on authentication, finance, 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?

The description implies usage for retrieving state information, and there are no alternative tools for this purpose. However, it does not explicitly state when to use it or contrast with siblings.

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