Sicredi MCP

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

Annotations indicate idempotentHint=true and destructiveHint=false. The description adds behavioral context: the token provides either permanent or session-only access, and the flow to obtain it. No contradiction with annotations.

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

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

The description is a single, well-structured paragraph with all sentences adding value. It front-loads the context and efficiently conveys two authentication methods.

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

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

Given no output schema and the authentication flow, the description covers obtaining token, two usage options, and config setup. It could mention security sensitivity, but overall complete for an authentication tool.

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

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

The single parameter 'token' has no schema description, but the description explains it as a JWT from browser login, optional (calling with no args returns link). This adds crucial meaning beyond the schema.

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

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

The tool name 'authenticate' and description clearly indicate the purpose: logging in, obtaining an access token, and configuring it. It distinguishes from sibling tools like 'connect' or 'report_bug' which serve different functions.

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 two usage modes: permanent setup via config or session-only login by passing token. It does not explicitly state when not to use, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds behavioral context: returns authenticated:true and empty pending[] when all providers connected, and connect_url when credentials missing. This adds value beyond annotations.

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

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

Two sentences, no wasted words. Front-loaded with the main purpose, then explains conditional behavior. Highly concise and 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 no parameters and simple schema, description covers key return fields (authenticated, pending, connect_url). No output schema exists but description sufficiently explains the response shape. Slightly missing explicit non-destructive guarantee, though annotations cover it.

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

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

Input schema has zero parameters, so description cannot add parameter semantics. Baseline for 0 params is 4, and description appropriately focuses on return values.

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 connection status and URLs, distinguishing between all providers connected (authenticated:true, empty pending[]) and missing credentials (returns connect_url). It specifies the resource and outcome, differentiating from sibling tools like authenticate or 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?

Description implies usage for checking connection status but does not explicitly state when to use versus siblings like authenticate or openfinance_provider_status. No exclusions or alternatives 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?

Discloses behavioral traits beyond annotations: explains that invoke works for one-off use even if MCP is not installed, that install makes it permanent, and describes the behavior when credentials are needed (returns connect link) or when wallet is empty (returns checkout link). 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 packed with information but is not overly verbose. It starts with the main purpose, then explains the workflow, and covers various actions and scenarios. A few sentences are complex 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 the tool's complexity (15 parameters, multiple actions, no output schema), the description is remarkably complete. It covers the entire ecosystem, when to use each action, edge cases like credentials and payment, and permission requirements. It compensates well for missing schema descriptions and output schema.

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 main parameters like action, query, mcp_id, tool_id, arguments implicitly through the workflow description, but many parameters (limit, immediate, tier_slug, conversation, cancel_reason, etc.) are not explained individually, leaving gaps.

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

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

The description clearly states it is the official marketplace for MCPs/tools, outlines the core flow (search → describe → invoke), and distinguishes it from external registries. It uses specific verbs like 'search', 'describe', 'invoke', and 'install', and explains the role of each action.

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

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

Provides explicit guidance on when to use this tool first ('use THIS tool FIRST, before any external/generic registry'), explains the flow, when to use invoke vs install, and mentions prerequisites like workspace owner/admin for writes. Also covers edge cases such as missing credentials or empty wallet.

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

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

The description adds value beyond the destructiveHint annotation by detailing that connection data is deleted and becomes unavailable, and that a reconnection URL is returned. It provides useful behavioral context but could mention authorization requirements or side effects.

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

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

The description is three concise sentences, front-loading the core action in the first sentence. Each sentence adds distinct, relevant information (action, consequence, return value) with no extraneous text.

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

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

For a simple one-parameter tool with destructive annotations, the description covers the main action, data impact, and return value. It is missing explicit guidance on the parameter's source (e.g., from list_connections), but overall is sufficiently complete for an agent to use correctly.

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

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

Schema description coverage is 0%, so the description must clarify the parameter. It indicates 'item' identifies a specific bank, but does not specify format or that it should be a connection ID from list_connections. This adds basic meaning but is not comprehensive.

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

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

The description clearly states the action: revoking consent and deleting connection data for a specific bank. It uses strong verbs (revokes, deletes) and explicitly specifies the resource and outcome, distinguishing it from sibling tools like openfinance_list_connections 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?

The description implies usage for disconnecting a bank but does not explicitly state when to use this tool versus alternatives (e.g., listing connections or checking status). No exclusions or alternative tools are mentioned, leaving the agent to infer context.

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

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

With minimal annotations (no readOnly, idempotent, or destructive hints), the description fully discloses blocking behavior (polls up to 60s), return fields including status, executionStatus, lastUpdatedAt, synced, needs_action, and timed_out, and the immediate-return option with wait:false.

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: main action first, then usage, parameters, return format, and edge cases. While dense with information, it could be slightly trimmed without losing clarity.

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

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

Given the complexity (polling, multiple outcomes), no output schema, and sparse annotations, the description covers purpose, usage, parameters, return structure, error conditions (needs_action, timed_out), and references a sibling tool for follow-up. It is fully 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?

Input schema has 0% description coverage for its two parameters. The description compensates completely: explains items accepts selectors (item_id, connector_id, or connector_name) and omitting syncs all, and clarifies wait:false for fire-and-forget.

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

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

The description clearly states it forces a bank re-sync and waits for completion. It specifies the HTTP method and polling behavior, distinguishes from siblings like openfinance_get_item_status, and explains the all-banks option when items are omitted.

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 when-to-use guidance: 'Use this when a balance or transaction list looks stale'. It contrasts with disconnect/reconnect approach, offers fire-and-forget via wait:false, and directs users to re-check with openfinance_get_item_status on 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?

Adds detailed behavioral context beyond annotations: includes degradation to last-synced balance with realtime:false, structured warnings for credit accounts, and the exact response shape. Annotations already indicate read-only and idempotent, which the description supports.

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

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

Description is informative but slightly verbose; however, it is well-structured with clear sections for constraints, error handling, and response shape.

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 response shape, error modes, and degradation conditions, making it self-contained for correct tool invocation.

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

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

Schema has 0% description coverage; the description compensates by stating the array constraint (1-50). Provides necessary context for the single parameter beyond its type.

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 real-time balance per account ID, specifying the endpoint and the key parameter. Distinguishes from sibling tools focused on other account details or transactions.

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

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

Explicitly notes the account_ids array constraint (1-50) and describes error behaviors, though does not provide explicit when-to-use or when-not-to-use guidance beyond the function.

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 behavioral context beyond annotations: explains the { results, errors } batch shape, the provider_incident block, and its implications on data reliability. Annotations already indicate read-only, idempotent, non-destructive; description enhances with real-world edge cases.

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

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

Three concise, front-loaded sentences: main purpose, parameter constraint, and critical behavioral warning. No extraneous text; every sentence earns its place.

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

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

Despite no output schema, the description covers return value structure (batch shape, provider_incident) and usage constraints. It addresses the agent's key concerns: what it returns, how to call it, and when to distrust results.

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 fully compensates by explaining that account_ids is an array of strings (1-50) and that the tool fetches per ID. The batch shape and incident warning further clarify expected behavior.

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

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

The description clearly states it returns full account objects with extended creditData per ID, specifying the batch shape and potential provider_incident block. It distinguishes from sibling tools like openfinance_list_accounts by focusing on detailed per-ID retrieval.

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

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

Provides explicit guidance on account_ids array size (1-50), batch shape, and a critical warning about not presenting unreliable values during provider incidents. However, it does not directly compare to alternative tools like openfinance_list_accounts for simpler listing needs.

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 mark the tool as readOnly, idempotent, and non-destructive. The description goes further by detailing that Pluggy does not return a paid/status field, and explains that the payments array typically corresponds to the previous bill's payment, clarifying that a non-empty payments array does not imply this bill was paid. 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 detailed and front-loaded with the core purpose. While every sentence adds value, the length is slightly higher than minimal due to extensive caveats and behavioral notes. However, the information density justifies the length, so it remains concise relative to the tool's complexity.

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

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

Given no output schema, the description explains the return shape ({ results, errors } batch shape) and fields in payments. It also notes the sparse/inconsistent billId hint. This provides a complete picture for the agent to correctly invoke the tool and interpret results without ambiguity.

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 a single required parameter (bill_ids array) with 0% description coverage. The description fully compensates by explaining that bill_ids should be passed as an array and that users should discover IDs using openfinance_list_credit_card_bills. This adds necessary semantic context for proper 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 explicitly states the tool returns bill-level detail for credit card bills by ID, including financeCharges and payments. It clearly distinguishes from itemized transaction retrieval by stating what is NOT returned and naming the alternative tool (openfinance_list_transactions). This satisfies a specific verb+resource+scope and differentiates from siblings.

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

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

The description provides comprehensive usage guidance: directs users to first use openfinance_list_credit_card_bills to discover bill_ids, warns against reconstructing totals from transactions, explains limitations of the billId hint, and advises on checking payment status via the bills list tool. It explicitly states when-not-to-use and provides alternatives, exceeding typical guidelines.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral detail: it returns status, executionStatus, connector metadata, and the shape of the response when omitting `item` (`{ count, items }`). This goes beyond annotations without contradicting them.

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

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

The description is two sentences, both concise and informative. No unnecessary words, and all content 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?

Despite no output schema, the description covers the return format for both use cases. For a simple status tool, this is complete and sufficient for an agent to understand what to expect.

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

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

The input schema has one parameter `item` with no description (0% schema description coverage). The description fully compensates by explaining the parameter's role: pass `item` for a single bank, omit for all banks. This adds essential meaning.

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

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

The description clearly states the tool returns the current status of a bank connection with specific examples (UPDATED, UPDATING, LOGIN_ERROR). It distinguishes between two use cases: omitting `item` for all banks or passing `item` for a single bank. This clearly differentiates 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 explicitly explains when to omit or pass the `item` parameter, providing clear usage context. It does not explicitly mention when not to use this tool or alternatives, but the context is sufficient for an agent to decide.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds transparency about the batch response shape '{ results, errors }' and the array size limit (1-50), which are behavioral traits beyond what annotations provide.

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

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

The description is fairly long but well-structured: it starts with the HTTP endpoint and main purpose, lists key fields, gives usage sequencing, then parameter and output details. It is front-loaded and avoids redundancy, though some field enumeration could be trimmed.

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 and no output schema, the description covers the main use case, expected input constraints, and output shape. It does not explain error details or edge cases, but it is sufficient for an agent to use it correctly in most 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?

The input schema has no description for loan_ids (0% coverage). The description adds meaning by specifying it should be an array of 1-50 IDs, which is a constraint not in the schema. It also hints at the output shape related to the parameter (batch processing).

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 loan contract details by ID, listing specific fields like interestRates, amortizationScheduled, etc. It explicitly distinguishes from the sibling tool openfinance_list_loans by saying 'Use after openfinance_list_loans to deep-dive on a specific contract.' This provides a specific verb and resource.

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

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

The description gives explicit usage guidance: 'Use after openfinance_list_loans to deep-dive on a specific contract' and specifies that loan_ids should be an array of 1-50 items. While it doesn't list exclusions or alternatives beyond the sibling, the context is clear enough.

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 include readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds critical context: the meaning of name vs. bank, the balance caveat, and the provider_incident block indicating potentially unreliable values. 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 lengthy but efficiently structured: front-loaded with primary result, followed by details on each field, then caveats and alternatives. Every sentence adds value, though a minor reduction in verbosity could improve conciseness without losing clarity.

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

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

Despite having no output schema and only 2 parameters (0 required), the description provides a comprehensive picture: account types, fields, special meanings (name vs bank), balance interpretation nuances, provider incident handling, and references to sibling tools for complementary functionality. Covers edge cases thoroughly.

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%, requiring the description to explain parameters fully. It explains that omitting item aggregates all connections (each row tagged with bank/connector_id/item_id) and passing item targets a single bank (response carries those fields at root). Type parameter is explained as BANK/CREDIT filter. Adds significant meaning beyond the schema.

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

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

The description clearly specifies that the tool returns BANK and CREDIT accounts with detailed fields (balance, number, type, subtype, bankData, creditData). It distinguishes itself from sibling tools like openfinance_list_credit_card_bills, showing specific verb+resource and scope.

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

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

Explicitly states when to omit item (list all banks) vs. pass item (single bank). Provides caveats about balance interpretation (connector-dependent) and directs to openfinance_list_credit_card_bills for standardized billing amounts. Warns about provider_incident affecting data reliability.

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, idempotent, and non-destructive. Description adds caching behavior and explains response structure, which goes beyond annotations.

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

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

Three sentences, front-loaded with purpose, then details on output. Every sentence is informative 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 zero parameters, rich annotations, and complete output description, no gaps remain. User knows exactly what to expect.

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 to describe; baseline score applies. Description adds no param info but none is needed.

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

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

Description clearly states the tool returns Pluggy's transaction category taxonomy, mentions the endpoint, and explains the structure. It is distinct from sibling list tools by focusing on categories.

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 guidance on using the categoryId with another tool and notes language preference. Lacks explicit when-not advice but context is sufficient.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the description adds minor context by mentioning the add_connection_url. It does not add significant behavioral details 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?

Single sentence, front-loaded with the purpose, no redundant information. Every word adds value.

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

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

The description is complete for a simple list tool with no parameters and no output schema. It explains what is returned, though it could mention that it returns all connections for the install.

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

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

With zero parameters and 100% schema coverage, the description does not need to add parameter info. Per evaluation rules, baseline is 4.

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

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

The description clearly states the tool returns saved bank connections and lists the specific fields (connector_id, item_id, bank name, add_connection_url). It uses the verb 'Returns' and distinguishes from sibling tools like connect and disconnect.

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 this tool is for retrieving existing connections, but it does not explicitly state when to use it versus alternatives like connect or disconnect, nor does it mention when not to use it.

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 rich behavioral details beyond annotations, such as payment cycle semantics, derived payment_status logic, open bill availability conditions, and bill grouping reliability warnings. 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 excessively long, spanning several paragraphs with detailed explanations that could be condensed. Important information is front-loaded but overall wordiness reduces readability.

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

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

Given the complexity of Open Finance semantics and no output schema, the description covers return fields, derived statuses, open bill intricacies, and warnings. It is nearly complete, though a full field structure for each bill object is not explicitly enumerated.

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 account_id, account_ids (bulk support), and include_open_bill in detail. Page and page_size are not explicitly described, but their purpose can be inferred. The description adds significant meaning beyond the bare schema.

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

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

The description clearly states it returns CLOSED credit card bills for CREDIT-type accounts, listing specific fields. It distinguishes from siblings by mentioning that for itemized transactions, use openfinance_list_transactions, and that this tool provides bill-level 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?

Extensive guidance is provided, including when to use include_open_bill, connector asymmetry, warnings about cross-bank attribution, and not reconstructing totals. However, it lacks explicit comparison with sibling openfinance_get_credit_card_bill for retrieving a specific bill.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds value by disclosing that it returns a non-throwing fallback on errors (403 or upstream), and lists key fields like balance, rates, and ISIN. 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 a single paragraph that packs significant detail, but it lacks structure (e.g., separating purpose, parameters, returns). It is not extremely verbose, but could be organized better for quick scanning.

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

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

The description covers the return structure (fields like balance, rates, ISIN) and error handling, but misses pagination details (page and page_size behavior) and whether item is required. Given 4 parameters and no output schema, more completeness would help.

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%, meaning the schema provides no explanations. The description does not explain individual parameters (item, page, type, page_size) beyond the enum for type. Users must guess their meanings, especially for requiredness and defaults.

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

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

The description clearly states it returns investment portfolios, listing specific asset types (FIIs, stocks, ETFs, etc.). It distinguishes from sibling tools like openfinance_list_accounts and openfinance_list_transactions by focusing on investments.

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

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

The description explains when to use it (for investment portfolios) and mentions graceful fallback when INVESTMENTS isn't enabled. However, it does not explicitly state when to avoid this tool or compare to alternatives, though the context from sibling names helps.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds value by detailing the specific fields returned (quantity, value, expenses breakdown), which is beyond annotations. No contradictions or missing 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 concise, with two short paragraphs: one explaining functionality and return fields, another for usage order and bulk support. No unnecessary sentences, though the information could be slightly more structured (e.g., missing pagination mention).

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 (4 params, no output schema), the description covers the main purpose, required fields, and return structure well. However, it omits pagination behavior (page, page_size) and does not mention that the tool is read-only (though annotations cover that). This gap reduces completeness.

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

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

With 0% schema description coverage, the description must compensate. It explains investment_id and investment_ids (for bulk) but completely ignores page and page_size parameters, leaving their purpose and format undocumented. Only partial parameter guidance is provided.

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

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

The description clearly states it returns the movement history for a specific investment position, listing transaction types (BUY, SELL, etc.). It is specific about the resource and action, but does not explicitly differentiate from sibling tools like openfinance_list_transactions, which may cover other account types. However, the context of 'investment' and reference to openfinance_list_investments provides implicit differentiation.

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

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

The description explicitly advises to use this tool after openfinance_list_investments to obtain investment_id. It also mentions bulk support via investment_ids, giving clear context on when to use it. No explicit when-not-to-use or alternatives are stated, but the sequential guidance is sufficient.

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

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

Beyond annotations indicating read-only and idempotent behavior, the description reveals sequential querying, rate-limit spacing, and the response format { results, errors } per connection. No contradiction with annotations.

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

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

Three sentences front-load purpose, then detail parameter usage and behavior. Every sentence adds value with no redundancy or fluff.

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

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

Given the single parameter and no output schema, the description covers input semantics, runtime behavior (sequential, rate-limited), and output format. No gaps are apparent for a loan-listing tool.

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

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

The schema only defines items as an array of strings. The description adds critical meaning: items are connection selectors (item_id uuid, connector_id, or connector_name) and omission lists all banks. This compensates for 0% schema description coverage.

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

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

The description clearly states the tool lists loan contracts per bank connection via a GET /loans endpoint. It is distinct from sibling tools like openfinance_list_accounts by focusing on loans and specifying the per-connection scope.

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

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

The description explains when to pass items (for specific connections) and when to omit it (for all connections). It mentions sequential querying with rate-limit spacing, but does not explicitly address when to use alternatives, though the context is clear.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. Description adds critical behavioral details: auto-pagination with 5000 ceiling, truncated flag, error structure on upstream failures, per-connector nuances for credit pending/posted, and provider incidents. 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 but front-loaded with key purpose and usage. Each sentence adds value, covering many edge cases. Some redundancy exists (e.g., billId warning repeated), but overall efficiently packed. Slight room for more structured formatting, but content is appropriate for complexity.

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

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

Given 0% schema coverage and no output schema, the description is exceptionally complete. It explains response structure (account echo, provider_incident), pagination mechanics, search behavior, detail levels, error handling, and connector-specific behaviors. Covers all scenarios an agent might encounter.

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 fully compensates. All 8 parameters are explained with context: from/to as ISO YYYY-MM-DD, page semantics (omit for auto-pagination), page_size max 500, detail enum with examples, account_id and account_ids for bulk, search_queries with case/accent-insensitive OR semantics. Adds value beyond 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 transactions for bank accounts (BANK or CREDIT type). For CREDIT accounts, it specifies this is the ONLY way to get itemized transactions, distinguishing it from sibling tools like openfinance_list_credit_card_bills. The verb 'list transactions' is specific and the resource is well-defined.

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 extensive guidance: when to use (CREDIT itemized), when not to use (do not sum by billId), and explicit alternatives (use openfinance_list_credit_card_bills for bill totals). Also covers pagination strategies, search usage, detail levels, and cross-checking account echo. No ambiguity.

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

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

Annotations already declare readOnlyHint and idempotentHint, indicating a safe read operation. The description adds significant behavioral context: the scan caps at 5000 transactions per account with a truncated flag, possible provider_incident block, and details on granularity and detail options. No contradictions with annotations.

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

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

The description is long but each sentence adds value. It is well-structured: starts with the core benefit, then explains parameters, then provides behavioral notes. It uses backticks for parameter names and clear formatting. No redundancy or fluff.

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

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

Given no output schema, the description thoroughly explains what the tool returns: a compact summary with totals, monthly evolution, top expenses/receipts, per-account breakdown, and optionally raw transactions with enrichment. It also covers truncation and provider incidents. The description is complete for correct tool usage.

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

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

Schema description coverage is 0%, but the description fully explains all 7 parameters: item (allows targeting one bank or all), from/to (ISO dates), granularity (monthly vs raw), detail (compact/rich/raw), type (BANK/CREDIT), and top_n (implied by top lists). It also explains defaults and combinations, compensating fully for the 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 clearly states that the tool provides consolidated cash-flow analysis for a whole bank connection in one call, avoiding the need for separate account listing calls. It distinguishes itself from siblings by noting it resolves accounts internally and allows analyzing all linked banks. Specific use cases are listed.

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

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

The description explicitly tells when to use this tool (for cash-flow analysis, annual/monthly analysis, top expenses/receipts) and when not (e.g., using default granularity when itemized rows are not needed). It also explains alternatives like omitting item to analyze all banks, and warns about truncation and provider incidents.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds context: checks a public status page, returns global indicator, degraded components, open incidents, and flags affected banks. 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?

Single paragraph, front-loaded with purpose, then usage context, then return fields. Every sentence adds value with 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?

Despite no output schema, description details return fields. For a parameterless tool, this is fully complete. It sets clear expectations for the agent.

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

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

No parameters, schema coverage 100%. Description does not need to add parameter info. It clearly explains the tool's input (none) and output, making it complete.

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 checks the provider's live operational status, distinct from connection status. It uses specific verb 'checks' and resource 'LIVE operational status of the Open Finance provider', and explicitly distinguishes from sibling tool 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?

Provides explicit when to use: when data looks incomplete/stale despite connection showing UPDATED. Also explains benefits: reveals upstream outage or known incident, helps differentiate provider-side from connection issues.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds value by detailing the caveat for non-Open-Finance connectors, the keyword requirement, and the plan-based filtering. This goes beyond annotations without contradicting them.

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

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

The description is a single paragraph that packs substantial information but is somewhat dense. It front-loads the main action and consequences (returns per match, caveat, plan handling). Could benefit from breaking into sentences or bullet points for easier parsing.

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

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

Given no output schema, the description adequately explains return values (connector id, access, audience, connect_url, caveat) and edge cases (no keywords returns a hint, never dumps catalog). However, it doesn't cover potential errors or rate limits, and the keyword requirement mismatch with schema slightly undermines 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 explaining keywords as an array of strings (with examples) and include_accounts as a boolean to include accounts. However, it contradicts the schema by stating keywords is required when the schema lists no required parameters, slightly reducing clarity.

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 searches bank connectors by name, listing specific return fields (connector id, access, audience, etc.). It distinguishes itself from sibling tools like 'connect' and 'openfinance_list_connections' by focusing on initial search and providing a pre-selected connect_url.

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

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

The description instructs to call this BEFORE connecting and explains that it honors the user's plan (PF vs PJ). It also states that keywords[] is required, though it doesn't explicitly mention when not to use it or provide alternatives. The context is clear but could include exclusions.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false. Description adds critical behavioral details: overrides automatic categorization, creates a Category Rule for future similar transactions, and batch error handling (per-item errors do not fail the whole batch). No contradictions.

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

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

Description is slightly lengthy but every sentence adds value. Well-structured: purpose, parameter mapping, side effect, response shape. Could be slightly more concise 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?

No output schema provided, but description includes the batch response shape. Explains side effect (rule creation). All aspect of the tool are covered given its complexity.

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 for parameter descriptions. Description compensates fully: explains items array structure, source of transaction_id and category_id from other tools, and meaning of each field.

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 'Corrects the category of one or more transactions' with specific verb and resource. Distinguishes from sibling tools like openfinance_list_transactions and openfinance_list_categories by explaining they are sources for 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?

Explicitly tells when to use (fix miscategorized transactions and improve future categorization). Explains how to obtain required IDs from other tools. No explicit 'when not to use' but context is clear given no alternative update tool exists.

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, which describe safety. The description adds instruction to include conversation array for reproduction, but does not elaborate on side effects or ticket creation. 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 concise sentences: first sentence states purpose, second sentence provides a key usage instruction. 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?

No output schema, but the tool is simple. The description covers the purpose and one critical input detail (conversation). However, it omits explanation of the context parameter and any response expectations. Adequate for a basic feedback tool but not 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 has 0% description coverage, so the description must compensate. It only mentions the conversation parameter ('include the conversation array') but does not explain context or message beyond requiring it. The conversation param is noted as a string with default '[]', but no format guidance is given.

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

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

The description clearly states the tool's purpose: report a bug, missing feature, or feedback. It distinguishes itself from the sibling tools, which are mostly Open Finance operations or authentication.

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

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

The description implies usage for reporting issues or feedback but does not explicitly state when not to use it or mention alternatives. The context of sibling tools suggests no other feedback channel exists, but guidance is implicit.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds marginal value by specifying that it shows platform and adapter versions, but does not disclose any additional behavioral traits beyond what annotations cover.

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

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

The description is a single sentence with no wasted words. It is front-loaded and efficient.

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

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

Given the tool's extreme simplicity (no parameters, no output schema, rich annotations), the description completely covers what the tool does. No additional context 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?

The tool has zero parameters, so the description does not need to add parameter meaning. Baseline score of 4 applies as schema coverage is irrelevant.

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 using specific verb 'Show' and identifies resources 'MCP platform and adapter versions'. It is unambiguous and distinguishes itself from siblings as the only version reporting tool.

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

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

No explicit when-to-use or alternatives are given, but the tool's purpose is self-explanatory (show version). The lack of guidelines is acceptable due to triviality, but a minor improvement would note that it is safe to call at any time.

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 it as read-only and idempotent. The description adds context on the returned data (installed MCPs, connection status, tool counts), which 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?

One sentence, zero waste, front-loaded with purpose.

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

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

Given zero parameters and no output schema, the description fully covers the tool's behavior for an informational tool.

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

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

No parameters exist, so baseline 4. Description does not need to add parameter info.

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

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

The description clearly states the tool returns toolkit state including installed MCPs, connection status, and catalog tool counts. It is specific and distinguishes from all siblings.

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

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

No explicit when or when-not guidance, but as a status tool, usage is implied. No alternatives mentioned.

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