Méliuz MCP

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

Annotations indicate idempotentHint=true and destructiveHint=false. The description adds context: with no args returns a link, with token sets session. It doesn't disclose response details but does not contradict annotations. Good behavioral context beyond annotations.

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

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

The description is two sentences with front-loaded key info. The second sentence is somewhat lengthy with multiple clauses, but remains clear. Could be slightly more concise without losing meaning.

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, so description must cover outcomes. It explains the two scenarios (with/without token) and what to expect (link or authentication). Lacks explicit response format, but sufficient for a simple authentication tool given the annotations.

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 the single optional parameter 'token' as a JWT to paste for session login, and that omitting it yields a login link. This adds complete meaning to the 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 is for authentication, specifying two methods (config vs session) and the target audience (IDE agents). It distinguishes itself from sibling tools like 'connect' and 'marketplace' which are unrelated.

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: for logging in via browser and copying token. It contrasts the permanent config method with the session-only token paste method, effectively guiding the agent. However, it doesn't explicitly state when not to use (e.g., if already authenticated).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety. Description adds value by detailing conditional output (authenticated:true vs connect_url). No additional behavioral traits disclosed, but annotations suffice.

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

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

Two sentences, no redundancy, front-loaded with purpose. Every sentence contributes meaning without waste.

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

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

For a tool with 0 params, no output schema, and safe annotations, the description covers the main behavior. It lacks details on output format (e.g., structure of pending[] or per-install URLs) but is sufficient for a simple status check.

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; baseline for 0 params is 4. Description adds no parameter info, 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?

Description specifies exact verb 'Returns' and resource 'connection status and URLs'. It distinguishes two distinct states (all connected vs missing credentials) and lists returned fields. This clearly differentiates from sibling tools like authenticate or openfinance 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?

Implied use is to check connection status, but no explicit guidance on when not to use or alternative tools. Given the sibling list, it's reasonable but lacks explicit boundaries.

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 extensively discloses behavioral traits beyond annotations: invoke runs uninstalled MCPs one-off, returns connect/checkout links for auth/payment, install makes permanent, etc. Annotations are readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, and the description aligns without contradiction, adding 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?

The description is long but highly efficient, with every sentence providing essential information. It is structured logically from purpose to flow to specific details, front-loaded with the core purpose, and avoids redundancy. It earns its length with dense, valuable 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?

Given the tool's complexity (13 parameters, 10+ actions, no output schema), the description is remarkably complete. It covers the entire lifecycle, including edge cases (credential/login, payment, installed vs permanent), and mentions workspace vs toolkit distinctions. No gaps are apparent.

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 and 13 parameters, the description does not individually detail each parameter. It explains the action enum and a few others (query, mcp_id, tool_id, arguments) within the flow narrative, but many parameters like limit, message, immediate, etc., are not explained. The description adds some value but insufficiently compensates for the low 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 that the marketplace is the official in-platform catalog for discovering and running MCPs/tools. It differentiates from sibling tools by explicitly saying to use this tool first before any external registry, and outlines the core flow of search, describe, and invoke. The purpose is specific and distinct.

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 comprehensive usage guidelines: when to use (user wants a capability), core flow, preference of invoke over install for one-off use, prerequisites for writes (owner/admin), and handling of credentials and payment. It also advises against using external registries first. All scenarios are covered.

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

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

Annotations indicate destructiveHint=true, and the description adds that data will no longer be available and returns a reconnection URL. This provides useful behavioral context beyond the annotation. 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 three sentences, front-loaded with the main action, and every sentence adds value without redundancy. It is highly efficient.

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

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

The description is incomplete for a destructive action with unknown parameter semantics. It fails to clarify the required 'item' parameter or any prerequisites like authentication. The return of add_connection_url is helpful but insufficient for full 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?

With 0% schema description coverage and only one parameter 'item' (string), the description fails to explain what 'item' represents (e.g., bank identifier). The description adds no meaning beyond the schema, which is insufficient.

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 consent and deletes connection data for a specific bank, with a clear verb-resource pair. It also mentions the return of an add_connection_url, adding specificity. This distinguishes it from sibling tools like openfinance_list_connections.

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

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

The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no caveats (e.g., whether disconnecting mid-sync is safe). The context is implied 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?

Describes behavioral traits: waits up to ~60s, can time out, returns specific status fields (needs_action, timed_out), and indicates side effects (pulling fresh data without disconnect). Annotations are minimal, so description compensates fully.

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

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

Description is dense but well-structured with clear sections; while slightly long, every sentence adds value. Could be tightened slightly but not wasteful.

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 parameters and no output schema, the description covers usage, parameter details, return fields (results, errors, status, etc.), timeout handling, and error conditions. Complete and self-contained.

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 provides all parameter semantics: explains that 'items' can be selectors (item_id, connector_id, connector_name) and omitting it syncs all banks. Describes 'wait' as fire-and-forget vs. blocking.

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

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

The description clearly states the tool forces re-sync of bank connections and waits for completion. It distinguishes from alternatives like disconnecting/reconnecting and provides specific use case ('balance or transaction list looks stale').

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 when to use ('stale data'), how to use with optional wait parameter, and mentions alternative tool (openfinance_get_item_status) for checking status after timeout.

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 readOnly and idempotent. The description adds important behavioral details: CREDIT accounts may return a structured warning instead of throwing, and the response shape includes errors array. This goes beyond annotations.

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

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

The description is three sentences long, front-loaded with the main purpose. Every sentence adds value without redundancy. Highly 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?

For a single-parameter tool with no output schema, the description provides endpoint, input format, error handling details, and response shape. It covers all necessary context for an agent to use 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 schema has 0% description coverage, but the description compensates by explaining the parameter's purpose and constraints (array of strings, 1-50). It clarifies that account_ids is used to fetch balances per 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 returns a 'real-time balance payload per account id' with the endpoint and input parameter. It distinguishes from siblings like openfinance_list_accounts which lists accounts rather than fetching balances.

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 the input format (array of 1-50 account_ids) and error behavior for CREDIT accounts. However, it does not explicitly compare with alternative tools for retrieving account data, leaving some ambiguity about when to use this vs. openfinance_get_accounts_detail.

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 true. The description adds value by detailing the return shape ({ results, errors }) and that it includes extended creditData. 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?

Two sentences, front-loaded with the core purpose, and no extraneous information. Every word contributes.

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

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

Given the simple parameter set and annotations, the description is mostly complete. It could mention partial failure handling (e.g., if some IDs are invalid) but is adequate for common 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?

With 0% schema coverage, the description compensates by specifying the parameter type (array of strings), the array size constraint (1–50), and the per-ID behavior. 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 returns full account objects with extended creditData per ID, and specifies the batch nature with array input. This distinguishes it from siblings like openfinance_list_accounts, which likely returns summaries.

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

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

The description implies usage for fetching detailed account data by IDs, but does not explicitly contrast with siblings like list_accounts or other detail endpoints. It provides batch constraints (1-50) but no when-not-to-use advice.

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 annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses the batch shape { results, errors }, notes that Pluggy does not return a paid/status field, and explains the nuance that payments[] may reflect previous bill's payment. This adds critical behavioral context not captured by annotations.

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

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

The description is well-structured: starts with the core purpose, then clarifies what it does not do, provides usage steps, and ends with important warnings about payment status interpretation. Every sentence adds value, and the information is front-loaded for quick understanding.

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, the description adequately explains the return shape (financeCharges, payments[] with fields) and the batch format. It addresses edge cases like payment status misinterpretation and provides complete context for an AI 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 only one parameter (bill_ids) with no description. The description compensates by explaining that bill_ids should be passed as an array, and advises using openfinance_list_credit_card_bills to discover IDs. This adds essential guidance for correct parameter usage.

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

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

The description clearly states the tool returns bill-level detail for credit card bills by ID, explicitly lists returned fields (financeCharges, payments[]), and distinguishes itself from sibling tools by stating it does not return individual transactions. It accurately contrasts with openfinance_list_transactions and openfinance_list_credit_card_bills.

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

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

The description provides explicit guidance: use openfinance_list_credit_card_bills first to discover IDs, and use openfinance_list_transactions for itemized transactions with date range. It also warns about interpreting payments[] correctly, advising to check payment_status via cross-bill match. This covers when and when not to use the tool.

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

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

Annotations already indicate read-only, idempotent, and non-destructive hints. The description adds valuable behavioral details: what data is returned (status, executionStatus, connector metadata) and the two response formats. No contradictions. It does not mention rate limits or additional constraints, but given the simple nature, the description is sufficient.

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

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

The description is two sentences long, each serving a distinct purpose: first sentence describes the return value, second sentence explains the two usage modes. No unnecessary words. Front-loaded with the core action.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is complete. It explains both invocation modes and their return structures. The sibling tools include other get/list operations, but the description sufficiently distinguishes this one.

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

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

The schema has a single optional parameter 'item' with no description. The description fully compensates by explaining that passing 'item' returns status for a single bank, while omitting it returns status for all linked banks (with a structure of count and items). This is exactly what the parameter semantics need.

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

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

The description clearly states the tool returns the current status of a bank connection, listing specific statuses (UPDATED, UPDATING, LOGIN_ERROR) and includes executionStatus and connector metadata. It also distinguishes between two modes: with item (single bank) and without (all banks). This is specific and differentiates from sibling tools like openfinance_list_connections which likely list connections without status 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?

The description provides explicit guidance on when to use the tool with or without the item parameter. It clearly explains that omitting item returns all linked banks with count and items, while passing item returns a single bank. However, it could further clarify when to use this tool over related siblings like openfinance_list_connections.

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 readOnlyHint=true. The description adds crucial behavioral details: the aggregation when 'item' is omitted, the connector-dependent nature of credit card balance, and the meaning of 'creditData' fields. 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 comprehensive but verbose, with multiple paragraphs. It is well-structured with front-loaded purpose, but could be more concise for a simple list tool. The length is justified by the nuanced credit card balance explanation.

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 return fields (balance, type, bank, connector_id, etc.) and key behavioral details. It references a sibling tool for further billing clarity. No major gaps are evident.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'item' thoroughly (omit for all, pass for single bank) and clarifies the returned types (BANK, CREDIT). However, it does not explicitly state that the 'type' parameter can filter results, which is inferred from the schema. Still adds significant value.

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

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

The description clearly states it returns accounts for bank connections, distinguishing between BANK and CREDIT types with specific data fields, and explains how omitting 'item' aggregates across all linked banks. This differentiates it from sibling tools like openfinance_list_connections 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?

The description provides explicit guidance: when to omit 'item' for all accounts, when to pass 'item' for a single bank, and warns against misinterpreting credit card 'balance', directing users to openfinance_list_credit_card_bills for standardized amounts. It also clarifies the 'bank' vs 'name' fields for user-facing text.

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, destructiveHint), the description adds that the response is cached for the adapter session and is a single aggregated response with no batch ids. This provides useful behavioral context not captured in annotations.

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

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

The description is concise, covering the purpose, caching behavior, output structure, and a usage hint in three sentences. It is front-loaded and avoids unnecessary verbiage.

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 explains the return structure and caching. With no output schema provided, the description fills the gap. It is complete enough for the agent to understand the tool's purpose and output.

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?

Since there are zero parameters, the description adds value by detailing the output fields (id, description, descriptionTranslated, parentId, parentDescription) and their practical usage. This compensates for the lack of an output schema.

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

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

The description clearly states the tool returns Pluggy's transaction category taxonomy, cached for the session. It specifies the source (GET /categories) and the key fields, distinguishing it from other list tools that return transactions or 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 mentions that the category `id` is used by `openfinance_update_transaction_category` and gives a language preference hint, but does not provide explicit guidance on when to use this tool vs. alternatives like `openfinance_list_transactions`. Usage context is implied but not fully specified.

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, and non-destructive behavior. The description adds value by detailing returned fields and the presence of an add_connection_url, but does not disclose potential behaviors like pagination or error handling.

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 of 24 words that front-loads the purpose and includes key details without extraneous 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?

No output schema exists, but the description covers the return fields. It could mention that the response is a list or clarify the format of add_connection_url, but overall is adequate for a simple listing tool.

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

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

There are no parameters; schema coverage is 100%. Per guidelines, baseline is 4. No additional parameter information is needed, and the description does not contradict 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 returns saved bank connections for the current install and lists specific fields (connector_id, item_id, bank name, add_connection_url). This distinguishes it from sibling tools like openfinance_list_accounts or openfinance_get_item_status.

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

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

No guidance on when to use this tool versus alternatives. There is no mention of when not to use it or which sibling tools might be more appropriate for related tasks.

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, so the safety profile is clear. The description adds significant behavioral context: explains the payment_status derivation logic, cross-bill payment matching, connector asymmetry, warning on product not enabled, and that open_bill requires an extra scan. No contradiction with annotations.

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

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

The description is quite long and contains many details. While comprehensive, it could be more structured or concise. It front-loads the main purpose but then includes many caveats and explanations that could be organized better. Some redundancy in explaining payment_status derivation.

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 (Brazilian Open Finance semantics, derived payment_status, connector asymmetry, optional open_bill), the description is very complete. It explains return fields, derivation algorithms, and caveats. Without an output schema, the description fully covers what the tool returns. It also addresses edge cases and alternative 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?

Schema description coverage is 0%, so the description must explain parameters. It thoroughly explains include_open_bill (opt-in, what it returns, connector asymmetry) and account_ids (bulk support). account_id is implied as required. page and page_size are not explicitly described but are standard pagination parameters. Overall, adds good meaning for key parameters.

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

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

The description clearly states it returns closed credit card bills for a CREDIT-type account, listing specific fields and derived payment_status. It distinguishes from sibling tools like openfinance_list_transactions (for itemized purchases) and openfinance_get_credit_card_bill (presumably for a single bill). The purpose is specific and unambiguous.

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

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

The description explicitly provides when to use this tool vs alternatives: 'To see itemized purchases/charges per bill, use openfinance_list_transactions'. It also includes important usage guidance such as the payment_status derivation, connector asymmetry, and the opt-in open_bill parameter. It warns about not assuming payment status from payments[] alone.

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: describes error handling (returns {total, results, warning} instead of throwing on 403 or upstream errors). Annotations already cover readOnly and idempotent; description adds behavioral detail.

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, front-loaded with purpose, enumerates types and fields efficiently. Could be slightly restructured 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?

Provides good overview of return fields and error behavior, but lacks parameter usage details and pagination guidance. With no output schema, description partially compensates but leaves gaps.

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

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

Schema description coverage is 0%, but description does not explain any of the 4 parameters (item, page, type, page_size). Does not clarify mapping between description's listed types and the type enum, nor pagination or item 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?

Clearly states the tool returns investment portfolio for a connection, enumerates specific types (FIIs, stocks, ETFs, fixed income, mutual funds, retirement, COE), and lists returned fields. Distinct from sibling tools like openfinance_list_accounts.

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

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

Implied usage for connections with INVESTMENTS product enabled, but no explicit guidance on when to use versus alternatives like openfinance_list_accounts or openfinance_list_transactions. Lacks exclusions or alternative tool names.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description adds value by detailing return fields and transaction types. It also notes bulk execution capability. 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 short paragraphs, front-loaded with purpose. Every sentence adds meaningful 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?

Given 4 parameters, no output schema, and existing annotations, the description covers return fields, transaction types, usage order, and bulk support. Missing pagination details but otherwise 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?

Schema coverage is 0%, so description must compensate. It explains investment_id and investment_ids, but does not describe page or page_size parameters. This leaves some ambiguity for pagination.

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/etc.) and specific fields. This distinguishes it from sibling tools like openfinance_list_investments which lists positions themselves.

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 after openfinance_list_investments to get the investment_id. Mentions bulk support with investment_ids. Does not list when not to use, but provides clear context for correct usage.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds sequential per-connection querying with rate-limit spacing and per-connection result/error structure, going beyond annotations.

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

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

Four sentences, each serving a purpose: main action, parameter usage, omission behavior, return structure. No redundancy.

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

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

Simple tool with one parameter and no output schema is fully covered: input semantics, behavioral details, and output structure are all described adequately.

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% coverage, but the description fully defines `items` as an array of connection selectors (item_id uuid, connector_id, or connector_name) and explains behavior when omitted. Completely compensates.

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, referencing the GET /loans endpoint. Distinguishes from siblings like list_accounts or list_transactions by specifying loan contracts.

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 when to pass `items` (specific connections) and when to omit (all banks). Mentions sequential querying with rate-limit spacing, but does not explicitly state when to use 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?

Descriptions discloses auto-pagination, 5000 ceiling, truncation warning, error handling (returns error in response), and variation in credit card pending/posted status. These go beyond the annotations (readOnlyHint, idempotentHint, destructiveHint) and add significant behavioral context.

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

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

The description is long but every sentence provides value. It is front-loaded with core purpose and organized into sections. However, it could be more concisely structured with bullet points or shorter paragraphs to reduce verbosity.

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

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

The description covers use cases, parameter details, error handling, and relationships with sibling tools. Although there is no output schema, the description hints at return structure (e.g., detail levels). It is nearly complete for a complex tool with multiple optional parameters.

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

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

Despite 0% schema description coverage, the description explains all 8 parameters in detail: from/to format, pagination behavior with page/page_size, detail enum with rich/raw descriptions, search_queries with OR semantics, and bulk account_ids. This fully compensates for missing schema descriptions.

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

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

The description clearly states it returns transactions for bank accounts (BANK or CREDIT type), and distinguishes between credit card and bank account use cases. It also mentions sibling tools like openfinance_list_credit_card_bills for 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?

Provides explicit guidance: for credit cards it's the only way to get itemized transactions, for bill totals use openfinance_list_credit_card_bills, and if zero results check connection health via openfinance_get_item_status. Also explains when to narrow date range if truncated, and pagination behavior.

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 show readOnlyHint=true and idempotentHint=true. Description adds meaningful context beyond that: internal account resolution, transaction fan-out, scan limit of 5000/account with truncated flag, and per-account breakdown. 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 long but well-structured: purpose first, then options, then examples of use cases. Every sentence adds valuable information, though some repetition could be trimmed (e.g., mentioning 'compact summary' twice).

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

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

Despite no output schema, the description thoroughly explains return values: compact summary includes total entradas/saidas, saldo_liquido, monthly evolution, top expenses/revenues, per-account breakdown. Raw mode returns consolidated transactions with optional enrichment. Also covers truncation flag.

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

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

Schema coverage is 0%, but the description fully explains all 7 parameters: item, from, to, granularity, detail, type, top_n. It describes defaults (e.g., granularity:'monthly'), allowed values, and their effects. No parameter left unexplained.

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 tool as 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call', distinguishing it from sibling tools like openfinance_list_accounts and openfinance_list_transactions by stating it resolves accounts internally.

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 tells when to use this tool (e.g., for 'analise anual/mensal', 'fluxo de caixa'), and when to use granularity 'raw' or detail 'rich'/'raw'. Also clarifies when NOT to call openfinance_list_accounts first.

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, indicating safe, idempotent read. Description adds context about output structure (global indicator, degraded components, incidents, your_banks_affected), which is valuable 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 a single paragraph front-loaded with purpose, but remains clear and all sentences add value. Slightly wordy but not excessive.

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

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

For a zero-parameter tool with no output schema, the description fully explains what it returns (global indicator, degraded components, incidents, your_banks_affected) and in what scenarios to use it. Complete enough for the 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?

Input schema has zero parameters, so baseline is 4. Description correctly adds no parameter info as 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?

Description clearly states the tool checks the LIVE operational status of the Open Finance provider, distinguishing it from the connection-level 'openfinance_get_item_status' sibling. Uses specific verb 'checks' and resource 'operational status'.

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

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

Explicitly specifies when to use: when data looks incomplete/stale despite an updated connection, with concrete examples (missing accounts, transactions, balances). Also explains what it reveals (upstream outage, known incident) and how it differentiates provider vs connection issues.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds many behavioral traits: honors user's plan to filter banks, returns a hint if keywords omitted, provides ready connect_url, and surfaces caveat warnings for credential connectors.

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 that conveys all essential information without wasted words. It could be improved by breaking into bullet lists for readability, but it remains concise and front-loaded.

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

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

Given no output schema, the description thoroughly explains the return content (id, access, audience, linked connections, connect_url, caveat) and also covers plan restrictions and fallback behavior when keywords is missing. This is sufficient 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?

Schema coverage is 0%, but the description provides examples for keywords (['nubank','btg']) and explains include_accounts adds accounts. However, there is a slight contradiction: description calls keywords required while schema does not mark it required, which may confuse agents.

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 available bank connectors by name, lists specific return fields (id, access, audience, linked connections, connect_url, caveat), and distinguishes itself from siblings like openfinance_list_connections by emphasizing it is called BEFORE connecting to provide a one-click link.

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

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

The description explicitly says 'Call this BEFORE connecting' and warns about caveats for non-Open-Finance connectors. It also states that keywords[] is required and never dumps the whole catalog, but does not explicitly compare to all sibling 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 discloses critical side effects: overrides automatic categorization, creates a Category Rule for future similar transactions (case-insensitive exact match), and details batch error handling (per-item errors do not fail whole batch). Annotations are all false, so description bears full burden and excels.

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 paragraph but every sentence adds value. Could be slightly more structured with separate sections for response shape, but overall efficient.

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

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

Given no output schema, description covers response shape, error handling, side effects, and parameter sourcing comprehensively. All necessary context for correct invocation is present.

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 the items array structure, required fields (transaction_id, category_id), and how to obtain each from other tools. This adds significant value 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?

Description clearly states the tool corrects categories via PATCH /transactions/:id, with specific resource and action. It distinguishes from sibling tools like openfinance_list_transactions by focusing on update behavior.

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

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

Description explicitly tells when to use (to fix miscategorized transactions) and where to get required IDs (from openfinance_list_transactions and openfinance_list_categories). However, no explicit when-not-to-use or alternative tools 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 indicate idempotentHint=true and destructiveHint=false, so the description adds value by specifying the reproduction requirement. No contradictions, and the description is consistent with the safe read-like behavior implied by annotations.

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

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

The description is two sentences with no wasted words: the first states purpose, the second gives usage instructions. This is highly efficient and front-loaded.

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

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

For a simple feedback tool with no output schema, the description covers purpose and a key parameter, but omits details on the 'context' parameter and return behavior, making it adequate but not thorough.

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 only partially explains the conversation parameter but fails to detail the required 'message' or optional 'context', leaving significant ambiguity for an agent.

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

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

The description clearly states the tool is for reporting bugs, missing features, or feedback, which is specific and distinct from sibling tools that focus on financial operations.

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

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

It explicitly says to include the conversation array for reproduction, which provides actionable guidance. It does not exclude other scenarios, but no alternatives are needed as this is a unique feedback tool.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds specific context about what versions are shown (platform and adapter), enhancing transparency beyond the annotations.

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

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

The description is a single sentence of 9 words, perfectly concise for a simple info tool with no parameters. Every word is necessary and 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?

The tool has no parameters, no output schema, and no nested objects. The description fully covers what the tool does. No additional information is 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 (0), so the description does not need to explain parameters. Baseline score of 4 applies as per guidelines.

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.' It distinguishes itself from all sibling tools, none of which relate to version 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 implicitly indicates when to use this tool (to check versions) but does not explicitly state when not to use it or list alternatives. However, given the context, it is obviously the correct tool for version queries.

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

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

Description adds context beyond annotations: specifies return details (installed MCPs, status, tool counts). Annotations already signal read-only and idempotent, so description complements well.

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

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

Single sentence that is front-loaded with purpose and details. No wasted words; every part 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?

For a simple read-only tool with no output schema, the description fully explains the return value. Annotations cover safety, making this complete.

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

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

No parameters exist; schema coverage is 100%. Description explains what the output contains, adding value for an agent.

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

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

Description clearly states the tool returns current toolkit state, specifying the exact content (installed MCPs, connection status, catalog tool counts). This distinguishes it from all sibling tools like authenticate or connect.

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

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

While no explicit when-to-use or alternatives are given, the simple read-only nature makes usage obvious. The description implies it's for checking state, and no sibling provides same function, so guidance is clear.

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