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 discloses that invoke runs MCPs even if not installed, returns connect/checkout links for auth/payment, and that write actions require workspace owner/admin. This adds value beyond the annotations (readOnlyHint=false, destructiveHint=false), but could be more concise.

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 long single paragraph (over 300 words) covering multiple actions and details. While front-loaded with the main purpose, it lacks structure and contains redundant explanations. Could be more concise by separating into sections.

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 15 parameters and no output schema, the description adequately covers the high-level workflow and main action types. However, it omits details on input formats (e.g., 'arguments' as JSON string), response structure, error handling, and pagination for search results. Leaves some gaps for an agent to use the tool fully.

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

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

Schema has 15 parameters with 0% description coverage. The description explains the 'action' parameter's enum values and their purpose (search, describe, install, etc.), and mentions 'mcp_id', 'tool_id', 'arguments' contextually. However, many parameters like 'limit', 'query', 'immediate', 'tier_slug' are not explained, leaving gaps for an agent to correctly invoke the tool.

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

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

The description clearly states the tool as the official marketplace for discovering, describing, and running MCPs. It specifies the core actions (search, describe, invoke) and distinguishes from sibling tools like authenticate or openfinance_* tools. However, the purpose is slightly diluted by excessive detail about workflow.

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

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

Explicitly instructs to use this tool FIRST for finding MCPs before external registries. Differentiates between invoke (one-off) and install (permanent) and references sibling tools like list_tools and install. Provides clear when-to-use and when-not-to-use guidance.

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

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

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?

The description adds substantial behavioral context beyond annotations: it explains that CREDIT accounts may return a warning instead of throwing, and that upstream unavailability leads to degraded results with last-synced balance and a warning. This complements the readOnlyHint annotation.

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

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

The description is a single paragraph of four sentences, front-loading purpose and error details. It is fairly concise but could benefit from bullet-point formatting for 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 one parameter, no output schema, and annotations covering safety, the description covers main behavior, error modes, and response shape. It addresses the complexity of this tool 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?

The only parameter, account_ids, is described as an array with size constraint (1-50), which adds meaning beyond the schema (which only specifies array of strings). This helps the agent understand valid inputs.

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 real-time balance per account ID, specifies the API endpoint, and constrains the input array size to 1-50. This distinguishes it from sibling tools like list_accounts and 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?

While not explicitly stating when to use this tool vs alternatives, the description implies usage for real-time balance queries and details error handling scenarios, providing clear context for its application. No exclusions are mentioned.

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

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

Annotations already indicate readOnly, idempotent, not destructive. The description adds value by explaining the batch return shape and the condition under which a provider_incident block may appear, along with a warning about unreliable data. This goes beyond annotation details.

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 composed of two sentences that efficiently convey purpose, parameter constraints, return shape, and important behavioral caveats. It is front-loaded and avoids extraneous details.

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

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

Given the lack of output schema, the description only partially covers the return format (`{ results, errors }` batch shape) and the potential provider_incident. It does not detail the account object structure beyond mentioning extended creditData. For a 'full account objects' return, more structure detail would improve completeness.

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

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

With 0% schema description coverage, the description compensates by clearly explaining that `account_ids` is an array of 1-50 IDs. It gives the constraints and purpose. Though it could explicitly state the item type (string), the schema already defines that.

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

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

The description clearly states the tool returns full account objects with extended creditData per ID via GET /accounts/:id. It specifies the batch shape and the account_ids parameter. However, it could more explicitly differentiate from sibling tools like openfinance_list_accounts or openfinance_get_account_balance.

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 the parameter constraint (array of 1-50 ids) and a warning about provider incidents, but it does not guide when to use this tool versus alternatives such as openfinance_list_accounts or openfinance_get_account_balance. No when-not-to-use or trade-offs are mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: batch shape { results, errors }, Pluggy's missing paid/status field, payments[] semantics (typically payment of previous bill), and inconsistent billId hint. 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 long (multiple paragraphs) but well-structured and front-loaded with the core purpose. It efficiently conveys purpose, exclusions, usage alternatives, and behavioral caveats. However, it could be slightly more concise by eliminating redundant mentions of payments[] semantics.

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 input schema (1 parameter) and lack of output schema, the description covers parameter sourcing, return shape, and critical behavioral nuances (connector-specific inconsistencies, payment interpretation). It does not fully enumerate all fields in the bill object (e.g., dueDate, totalAmount are referenced but not listed as fields). Overall, it provides deep context but omits some return structure details.

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% (no description for bill_ids parameter). The description instructs to pass bill_ids as an array and to use openfinance_list_credit_card_bills first to discover IDs. This adds usage context but could be more precise about ID format or source. Score 3, adequately compensating for lack of 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 explicitly states it returns bill-level detail by ID, lists key fields (financeCharges, payments[] with subfields), and clearly distinguishes from sibling tools by stating it does NOT return individual transactions, pointing to openfinance_list_transactions. This gives a specific verb-resource pair and differentiates from alternatives.

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 this for bill-level detail, use openfinance_list_transactions for itemized transactions, use openfinance_list_credit_card_bills first to discover bill IDs, and prefer the list endpoint for paid status. It also explains the meaning of payments[] and warns against reconstructing totals, covering 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 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is safe. Description adds operational details: batch shape '{ results, errors }' and array limit (1-50). 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?

Description is packed with information but not overly verbose. It front-loads the main purpose and return fields, then gives usage guidance. A bit long but each 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 the tool has only one parameter, no output schema, and the description covers return fields, batch behavior, usage context, and limits, it is fully complete for an agent to invoke correctly.

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

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

Schema coverage is 0%, but description compensates by explaining that loan_ids is an array of strings, max 50 items, and that output returns a batch shape with results and errors. This adds meaning beyond the bare schema.

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

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

The description clearly states the verb 'Returns' and the resource 'full loan contract detail by id', and lists specific fields. It also distinguishes from sibling tool 'openfinance_list_loans' by saying 'Use after openfinance_list_loans to deep-dive on a specific contract.'

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: after listing loans to get full detail. It does not mention when not to use or alternatives, but the context is clear enough for an AI agent.

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

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

Adds significant context beyond annotations: explains that `name` is legal entity not brand, advises using `bank` for user-facing text, warns that CREDIT balance is connector-dependent, and describes the `provider_incident` block. No contradiction with annotations.

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

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

Description is fairly long but every sentence provides useful information. Starts with a clear purpose sentence, then flows through usage, field explanations, and caveats. Slightly verbose but well-structured.

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

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

Given the tool has 2 optional parameters and no output schema, the description covers return structure, field semantics, edge cases (provider incidents), and usage scenarios. References sibling tool for bills, making it practically 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 description coverage is 0%, so description must compensate. It explains the effect of omitting vs including `item` and the meaning of `type` enum. Could be more explicit about parameter names, but adds substantial 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?

Clearly states it returns accounts for a bank connection with specific types and fields. Distinguishes between listing across all banks vs a single bank, differentiating from siblings like openfinance_get_account_balance and 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?

Explicitly says when to omit or pass the `item` parameter, and gives a concrete user-facing use case ('my accounts/cards'). Also points to sibling tool for credit card bills, providing clear 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?

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?

The description reveals detailed behavioral traits beyond annotations, such as the payment logic with Brazilian Open Finance semantics, derivation of payment_status, open_bill derivation, connector asymmetry, and warnings about bill grouping reliability. Annotations already indicate read-only and idempotent, and the description adds significant context without contradiction.

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

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

The description is long and dense, covering many details. While it is well-structured with separate sections, it could be more concise. The front-loading with the core function is good, but the length reduces 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?

Given the complexity of the domain and no output schema, the description is very complete. It explains the return structure, derived fields, edge cases (connector asymmetry, payment_status logic), warnings, and the account echo block. It also tells what not to do, making it comprehensive.

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

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

With 0% schema description coverage, the description compensates by explaining the key parameters like account_id, include_open_bill (with detailed semantics), account_ids for bulk support, and the role of page/page_size (though page and page_size are not explicitly described). The inclusion of open_bill logic adds significant value, but the lack of explicit page/page_size documentation is a minor gap.

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

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

The description clearly states that the tool returns closed credit card bills for CREDIT-type accounts, specifying the fields and distinguishing it from sibling tools like openfinance_list_transactions. It explicitly lists the returned fields and notes that this tool provides bill-level summaries, not individual transactions.

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

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

The description provides extensive guidelines on when to use this tool (e.g., for closed bills, using the open_bill opt-in) and alternatives (e.g., use openfinance_list_transactions for itemized purchases). It also warns against misusing the payments array and cross-checking the account echo, offering 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?

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?

The description adds extensive behavioral context beyond the annotations (readOnlyHint, idempotentHint, destructiveHint). It discloses that responses may be truncated, that credit card data can be sparse/inconsistent, that error returns come as objects rather than exceptions, and that provider incidents may affect results. 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 very thorough but somewhat verbose, covering many edge cases and caveats. It is well-structured with logical sections and front-loads the main purpose, but could be more concise without losing essential information.

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

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

Given the tool's complexity (8 parameters, varied behaviors by account type and connector, pagination, error handling, provider incidents, bulk support) and lack of output schema, the description is extremely complete. It explains the response structure, error handling, and how to handle edge cases like zero results or provider incidents.

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 8 parameters: to/from (ISO YYYY-MM-DD), page (omit for auto-pagination), page_size, detail (compact/rich/raw with coverage notes), account_id (required), account_ids (bulk), and search_queries (case-insensitive substring match, OR semantics). It also explains the effect of each detail mode.

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 or CREDIT accounts, distinguishes it from sibling tools like openfinance_list_credit_card_bills, and specifies that for CREDIT accounts it is the only way to get itemized transactions. It also mentions the tool is for a specific account and supports bulk with account_ids.

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

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

The description provides explicit guidance on when to use this tool versus alternatives (e.g., for bill totals, use openfinance_list_credit_card_bills), how to handle pagination (omit page for auto-pagination, use explicit page for manual), how to interpret results (truncated, zero results, provider incidents), and advises checking account identity when multiple banks are connected. It also covers filtering with from/to and search_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?

Annotations indicate readOnlyHint and idempotentHint true, and destructiveHint false. The description adds significant behavioral insight: consolidation logic, truncation at 5000/account with a flag, provider_incident block, enrichment behavior, and default granularity details. 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 verbose but well-structured, starting with the core purpose, then explaining parameters, defaults, and caveats. Every sentence adds value, though it could be slightly more concise by grouping related details.

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

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

Given the tool's complexity (7 parameters, no output schema, multiple edge cases), the description is comprehensive. It covers return structures (compact summary vs raw rows), default behaviors, truncation, provider incidents, and enrichment options. Without an output schema, it provides sufficient detail for an agent to understand the response.

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

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

With 0% schema description coverage, the description fully explains all 7 parameters: item (with alternative inputs), from/to (ISO date format), granularity (monthly vs raw, with effects), detail (compact/rich/raw, with enrichment details), type (BANK/CREDIT), top_n (implied). The description adds meaning beyond the schema enums and examples.

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

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

The description explicitly states the tool provides 'consolidated cash-flow analysis for a whole bank connection over a period, in one call,' resolving accounts internally, which clearly distinguishes it from sibling tools like openfinance_list_transactions that likely return raw transactions without aggregation.

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

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

The description provides clear context for when to use the tool (e.g., 'análise anual/mensal', 'fluxo de caixa') and when alternatives like setting granularity to raw are needed. It advises on per-account caps and provider incidents. However, it does not explicitly name sibling tools as alternatives, though the context implies them.

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.