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, so the description adds value by detailing the exact return fields (authenticated, pending[], connect_url, per-install URLs). 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 two sentences, front-loading the purpose and then providing conditional details. 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?

Given no parameters and no output schema, the description sufficiently explains the returned fields and scenarios. It is complete for a status check tool, though an explicit note about the 'authenticated' field type could be added.

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

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

There are no parameters (0 params, 100% schema coverage). The description does not need to explain parameters. Baseline 4 for zero-parameter tools.

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

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

The description specifies the verb 'Returns' and the resource 'connection status and URLs'. It clearly distinguishes between two states (all providers connected vs missing credentials) and provides specific field names. Given the sibling tools like 'authenticate' and 'openfinance_list_connections', this tool's purpose is unique and 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?

The description implies when to use: to check connection status and obtain URLs. It describes the output for both success and failure scenarios but does not explicitly state when not to use or mention alternatives. However, the context of sibling tools (e.g., 'authenticate' for initiating) provides implicit 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 are minimal (readOnlyHint=false, destructiveHint=false). The description adds value by explaining that writes require owner/admin, and that list_tools+invoke work even without a fresh tools/list. 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 lengthy but efficiently packed with essential information. It front-loads the primary purpose and lists actions compactly. Minor room for improvement in structuring the parameter explanations.

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

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

Given the tool's complexity (13 parameters, multiple actions), the description covers usage context well but lacks parameter-level detail and doesn't describe the output format (no output schema). Adequate but not fully 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 coverage, the description should explain all 13 parameters, but it only implicitly covers action, query, mcp_id, and tool_id. Parameters like limit, arguments, immediate, tier_slug, conversation, etc., are not described. Insufficient for parameter 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 identifies the tool as the official MCP marketplace, listing all supported actions and explicitly stating when to use it first. It differentiates from sibling tools by specifying that search should precede external registries.

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 each action: search first, then describe, install, etc. It details edge cases like flat-mode clients and mentions permission requirements for writes, leaving no ambiguity.

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

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

Annotations provide destructiveHint=true, and the description adds that data will no longer be available and returns an add_connection_url. This goes beyond annotations by explaining consequences and return value. 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, front-loaded with the action, no unnecessary words. Every sentence adds value.

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

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

The tool has one required param and no output schema. Description covers the main action and return value but lacks details about error states (e.g., already disconnected) and parameter semantics. Adequate for a simple tool but missing some 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?

The description mentions 'for a specific bank' but does not explain what the 'item' parameter represents (e.g., bank ID, connection ID). With 0% schema coverage, the description fails to add meaning beyond the schema.

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

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

The description clearly states the verb 'revokes' and the resource 'Open Finance consent for a specific bank and deletes the connection data'. It distinguishes from sibling tools like openfinance_list_connections (listing) and openfinance_force_sync (syncing) by indicating it removes access.

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 context (when you want to disconnect a bank) but does not explicitly state when not to use it or mention alternatives like openfinance_list_connections. It mentions a re-connect URL, which gives some guidance on reconnecting.

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

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

The description fully discloses behavioral traits: it waits up to ~60s, polls, returns specific fields (status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out), and explains no disconnection/reconnection. Annotations are consistent (readOnlyHint=false, destructiveHint=false). No contradiction.

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

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

The description is appropriately sized; every sentence adds value. It is well-structured: action, usage, parameters, return details. No redundant information.

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

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

Given no output schema, the description explains return object structure and fields. It also mentions polling, timeout, and HTTP method (PATCH). It is complete for an AI 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%, but the description adds clear meaning: 'items' is an array of selectors (item_id, connector_id, or connector_name), and omitting it syncs all. 'wait' parameter is explained as fire-and-forget. This fully compensates 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 states explicitly that the tool forces a re-sync and waits for completion, with verb 'Forces', resource 'connections', and behavior 'WAITS for it to finish'. It clearly distinguishes from siblings by explaining additional behavior and referencing openfinance_get_item_status for re-checking.

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 provides explicit usage context: 'Use this when a balance or transaction list looks stale' and explains what it does without disconnecting. It also gives alternatives: setting 'wait: false' for fire-and-forget and re-checking with openfinance_get_item_status when timed_out.

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 beyond annotations by detailing that CREDIT accounts may return BALANCE_FETCH_ERROR as a structured warning instead of throwing, and describes the response shape with errors array. 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: purpose, parameter usage, and response shape. No unnecessary words. Every sentence adds value.

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

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

Given no output schema, the description provides a complete return structure (results and errors) and handles the error case. The tool is simple and the description is fully adequate.

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 explains the only parameter: account_ids as an array, size 1–50. It also connects parameter to the per-account 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?

Description clearly states it returns real-time balance per account ID with the HTTP endpoint. It distinguishes from siblings like openfinance_list_accounts that list accounts without balances.

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

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

Provides explicit constraints on account_ids array (1–50) and mentions special behavior for CREDIT accounts. No explicit when-not-to-use, but the context is clear given the tool's narrow scope.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the output includes extended creditData and is batched as { results, errors }. This adds behavioral context (e.g., batch error handling) beyond annotations, 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 two sentences, concise and front-loaded. It includes the endpoint, what data is returned, parameter usage, and output shape. Every sentence earns its place with zero 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?

No output schema exists, but the description mentions the batch shape { results, errors }, informing the agent of the return structure. It covers the key aspects: what it does, how to call it, and what to expect. Minor missing details like error handling for invalid IDs are implied by the batch errors structure.

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 0% description coverage on parameters. The description compensates by stating 'Pass `account_ids` as an array (1–50)', providing type, constraint (array of strings, 1-50 items), and purpose. This adds meaningful guidance beyond the schema's bare type definition.

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 for given IDs, and references the endpoint GET /accounts/:id. This distinguishes it from sibling tools like openfinance_list_accounts (which likely returns summaries) and openfinance_get_account_balance (which returns only balance). The verb 'Returns' and resource 'full account objects' are specific.

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

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

The description instructs to pass account_ids as an array (1-50), implying usage when full details for specific IDs are needed. It does not explicitly state alternatives or when not to use, but the sibling context provides differentiation. A slight gap without 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 already set readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable context beyond annotations: notes that Pluggy does not return a paid/status field, explains payment cycle nuance, and mentions batch shape. No contradiction.

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

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

The description is a single paragraph that front-loads the main purpose. It is comprehensive but somewhat dense; every sentence adds value, but breaking into sections could improve readability. No wasted words.

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

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

Given there is no output schema and the tool involves batch results and payment cycle nuance, the description is thorough. It explains the shape of results, limitations (no paid/status field), and cross-bill relationships, making it sufficient for an AI 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?

The only parameter 'bill_ids' has 0% schema description coverage. The description clarifies it should be an array and recommends using openfinance_list_credit_card_bills first to discover ids. This adds meaning but lacks examples or constraints on the array format or id structure.

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

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

The description clearly states it returns bill-level detail for credit card bills by id, specifies returned fields (financeCharges, payments), and explicitly says what it does NOT return (individual transactions). It distinguishes from sibling tool openfinance_list_transactions by noting that tool is for itemized 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?

It provides explicit when-to-use guidance: use openfinance_list_credit_card_bills first to discover ids, and use openfinance_list_transactions for itemized transactions. It also warns about payment cycle interpretation, giving 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. Description adds behavioral details: return format for list mode (`{ count, items }`) and the specific data fields (status, executionStatus, connector metadata), which go beyond annotations. 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 efficient sentences with no redundant information. First sentence defines the core purpose, second explains parameter usage. Front-loaded and compact.

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 the response format for both single and list modes. However, it does not cover potential error responses or edge cases, which might be needed for a full understanding.

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

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

Schema has 0% coverage for the `item` parameter, so description carries the full burden. It explains that omitting `item` returns all banks and passing it returns a single bank, adding meaning beyond the schema. Could be improved with example values or allowed statuses.

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 bank connection status with specific statuses (UPDATED, UPDATING, LOGIN_ERROR), executionStatus, and connector metadata. It distinguishes two modes (single vs. all) with explicit parameter usage, differentiating 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?

Provides clear guidance on when to omit or pass the `item` parameter for different use cases. However, it does not explicitly compare to sibling tools or state when not to use this tool, though the context is implied.

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, and idempotentHint=true. The description adds significant behavioral context, such as the connector-dependent meaning of credit card balance and the structural differences in response when item is omitted vs present, which goes 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 long but every sentence provides necessary detail. It is well-structured, starting with the return data, then usage modes, then caveats, and finally cross-referencing an alternative tool. It could be slightly more concise, but the length is justified given the 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 the tool's complexity (two optional parameters, cross-bank aggregation, nuanced credit balance), the description is remarkably complete. It explains the data structure, usage pitfalls, and links to alternative tools. Without an output schema, it effectively describes the return fields, making the agent well-informed.

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

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

Schema description coverage is 0%, so the description must compensate. It thoroughly explains the item parameter, including its effect on the response structure. However, the type parameter (enum) is mentioned only implicitly in the return description; it could be more explicit about filtering behavior. Overall, it adds substantial value but has 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 it returns accounts for a bank connection, listing specific types (BANK and CREDIT) and the data fields included. It distinguishes between usage modes (with and without item parameter) and clarifies the meaning of name versus bank, effectively differentiating from sibling tools like 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 explicit guidance on when to omit item (for all accounts across banks) and when to pass it (for a single bank). It also warns about the credit balance caveat and directs to openfinance_list_credit_card_bills for standardized billing information, offering 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?

Annotations already provide readOnlyHint, destructiveHint, idempotentHint. The description adds key behavioral details: caching, single aggregated response, and field meanings (e.g., parentId, descriptionTranslated). 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 highly concise yet comprehensive—covers purpose, caching, field details, and usage hints in two sentences. Every phrase adds value 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?

With no output schema, the description fully explains the return structure (fields: id, description, descriptionTranslated, parentId, parentDescription) and their practical use. The tool's simplicity and annotations ensure 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?

No parameters exist (schema coverage 100%). The description adds meaning by explaining the return fields and their specific roles, like 'id' being the categoryId for updates and 'descriptionTranslated' for Portuguese users.

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 per session. It specifies the HTTP method (GET /categories) and distinguishes it by noting the categoryId is used by openfinance_update_transaction_category, making its purpose and relation to siblings explicit.

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 guides usage by linking to the update category tool and explaining field usage (e.g., descriptionTranslated for pt-BR users). While it doesn't explicitly state when not to use, the sibling list contains no other category tool, so 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying the returned fields and the fact that add_connection_url links to the Open Finance widget, providing 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?

A single, well-structured sentence that efficiently communicates the tool's purpose and output. No unnecessary words, and the key information is front-loaded.

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

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

Given no parameters and no output schema, the description fully covers the tool's behavior and return values. It explains exactly what is returned, making it complete for AI agent understanding.

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

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

With zero parameters, schema coverage is effectively 100%. The description adds no parameter detail but none is needed. Baseline for 0 params is 4, and the description is appropriate.

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

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

The description clearly states it returns saved bank connections with a specific verb 'Returns' and lists the exact fields returned (connector_id, item_id, bank name, add_connection_url). It distinguishes from sibling tools like openfinance_disconnect_bank or openfinance_force_sync which perform different actions.

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 listing saved connections but does not explicitly state when to use this tool versus alternatives like authenticate or connect. No when-not guidance is provided, leaving some ambiguity 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?

Discloses detailed payment status derivation logic, including the cross-bill matching algorithm and the PAST_DUE_UNCONFIRMED state. Explains connector asymmetry for open bill availability. Annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent and the description adds rich behavioral context beyond 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 very long (over 300 words) and contains some redundancy (payment_status explained twice). While structured with paragraphs and bold terms, it could be more concise without losing critical information.

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

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

Given the complexity (finance semantics, connector asymmetry, derived fields, no output schema), the description is thorough. It covers return structure, payment status, open bill derivation, connector limitations, and related tool instructions. No gaps apparent.

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

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

Schema has 5 parameters with 0% description coverage. The tool description explains include_open_bill in depth and implies account_id/account_ids usage, but does not explicitly describe page and page_size. The extra detail on include_open_bill compensates, but not all parameters are fully documented.

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 with specific fields (dueDate, totalAmount, etc.) and distinguishes from sibling tools like openfinance_get_credit_card_bill and openfinance_list_transactions. It explicitly says this tool's results are 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?

Extensive when-to-use and when-not-to-use guidance: explains that include_open_bill is opt-in for open bill and total pending debt, warns about connector asymmetry where open_bill may be unavailable, and directs to openfinance_list_transactions for itemized purchases. Provides explicit alternatives.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by specifying that the tool returns a structured error object instead of throwing on 403 or upstream errors, and lists fields like balance, amount, rates, etc. However, it does not mention pagination behavior or rate limits.

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 front-loads essential information (asset types, return structure). Every sentence adds value, though it could be slightly more structured. No unnecessary words.

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

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

Given 4 parameters (all optional), no output schema, and many sibling tools, the description partially compensates by listing return fields and error handling. However, it lacks parameter explanations and does not fully clarify when to use this tool over siblings like openfinance_list_investment_transactions.

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

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

Schema description coverage is 0%, so the description must compensate. It fails to explain any of the 4 parameters (item, page, type, page_size) beyond the enum values visible in the schema. The description focuses on return fields instead, leaving parameter meaning unclear.

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 investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.) and distinguishes itself from siblings like openfinance_list_investment_transactions. The verb 'returns' and the resource scope are precise.

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 by listing asset types and mentioning error handling for disabled INVESTMENTS, but does not explicitly state when to use this tool versus alternatives like openfinance_list_transactions or openfinance_get_accounts_detail. No exclusions or prerequisites are given.

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 read-only and idempotent. Description adds detail on returned data (fields like agreedRate, expenses) and bulk support. 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 sentences with high information density. Front-loaded purpose and key details. No 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?

Covers main use case, connects to related tool, and lists return fields. Lacks output schema but is sufficient for a read-only list tool. Could mention error handling or limits.

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%. Description clarifies the key parameter `investment_id` and introduces `investment_ids` for bulk, but omits explanation for `page` and `page_size`. Partial compensation.

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

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

The description clearly states it returns movement history for an investment position, listing transaction types and key fields. It explicitly distinguishes from siblings by advising to use after `openfinance_list_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?

Provides clear guidance on when to use (after getting investment_id) and mentions bulk support. Does not explicitly state exclusions or alternatives, 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 indicate read-only and non-destructive. Description adds sequential querying with rate-limit spacing and per-connection return format, providing 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?

Three sentences, no redundancy. Front-loaded with purpose, followed by parameter details and return shape. Efficient and clear.

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

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

Covers parameter usage, optionality, behavior (sequential with rate limit), and return shape. Lacks details on error handling or response structure beyond per-connection, but sufficient for simple read 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 has zero coverage (0%), but description explains that 'items' are connection selectors (item_id, connector_id, or connector_name) and that omitting them fetches all. Compensates fully.

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?

Clear verb+resource: 'Lists loan contracts per bank connection (GET /loans)'. Distinguishes from sibling list tools by specifying loan contracts and per-connection 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?

Explicit use cases: pass 'items' for specific connections, omit for all. Mentions rate-limit spacing for multiple connections. Does not explicitly exclude alternatives, but context suffices.

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?

Exceeds annotations by detailing upstream error behavior (returns warning/error instead of throwing), credit card specificity (PENDING vs POSTED variation by connector), search aggregation limits (5000), and need for potential force sync. No contradiction with readOnlyHint, idempotentHint, etc.

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 long but each sentence adds value. Structured logically: purpose, credit-specific behavior, filtering parameters, error handling, zero-total advice, bulk support. Slightly verbose in some parts but overall effective.

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

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

Covers purpose, account types, differentiation, connectors variation, error behavior, search limits, health check guidance, and bulk. Lacks explicit description of transaction response fields (though error response structure is hinted), but given the complexity and no output schema, it is quite 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?

Despite 0% schema description coverage, the description fully explains all 7 parameters: from/to as ISO date filters, page/page_size for pagination (max 500), account_id/account_ids for bulk, search_queries as case-insensitive substring match with OR semantics and aggregation limit. Compensates completely.

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 verb (returns), resource (transactions), and scope (for BANK or CREDIT accounts). It distinguishes from sibling tool `openfinance_list_credit_card_bills` by specifying that for CREDIT accounts, this is the only way to get itemized transactions, and directs to the sibling for bill totals.

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: when to use (for itemized transactions, especially for CREDIT), when to use alternative (`openfinance_list_credit_card_bills` for bill totals), behavior on empty results (check connection health), and how to handle search_queries (narrow date range if truncated). Also notes bulk support.

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, idempotent, non-destructive. The description adds behavioral details: internal account resolution, transaction fan-out, default monthly summary with compact format, per-account breakdown, and truncation at 5000 per account with a flag. This goes beyond annotations.

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

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

The description is relatively long but front-loaded with purpose. Every sentence provides useful information, though it could be slightly more concise. It structures content logically: purpose, how to use, parameter details, return format, and caveats.

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 6 parameters, no output schema, and complex behavior (fan-out, aggregation, truncation), the description is comprehensive. It explains return values (monthly evolution, top expenses, per-account breakdown) and highlights truncation, leaving no major 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?

Despite 0% schema description coverage, the description explains all 6 parameters: item (connector_id/name or item_id, optional for all), from/to (ISO dates), granularity (monthly vs raw with details), type (BANK/CREDIT), top_n (implied). It adds value by describing defaults and 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 provides consolidated cash-flow analysis for a bank connection, resolving accounts internally. It distinguishes itself from siblings like openfinance_list_accounts and openfinance_list_transactions by explaining it fans out transactions across accounts in one call.

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

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

The description specifies when to use: for annual/monthly analysis, cash flow, top expenses/revenues. It explains how to target a bank or all banks, and when to use raw granularity for itemized rows. However, it does not explicitly mention when not to use or direct to alternatives like openfinance_list_transactions for per-account 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 already indicate readOnlyHint, idempotentHint, and not destructive. The description adds rich behavioral context: it's a live check of a public status page, returns global indicator, degraded components, incidents, and flags affected banks. No contradiction.

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

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

Two sentences, the first stating the core function, the second detailing usage and return values. Every word adds value, no 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?

Despite no output schema, the description comprehensively lists return elements (global indicator, components, incidents, your_banks_affected). For a health-check tool with connected banks context, this is 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?

The tool has zero parameters and 100% schema coverage, so the description naturally adds no parameter info. Baseline for 0 params is 4, which is appropriate.

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

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

The description clearly states the tool checks the LIVE operational status of the Open Finance provider, using a public status page. It explicitly distinguishes from the sibling `openfinance_get_item_status` by specifying this is provider health, not connection health.

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: when data seems incomplete or stale despite an updated connection. It explains that it reveals upstream outages or incidents, helping differentiate provider-side problems from connection issues. While it doesn't list when not to use, the guidance is strong.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value beyond annotations by revealing that the tool honors the user's plan (PF hides PJ), returns a pre-connected URL, and does not dump the catalog without keywords. These details inform the agent about side effects and constraints without contradicting 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 paragraph of about six sentences. It is detailed but not verbose; every sentence contributes to understanding. It could be slightly more concise, but it efficiently front-loads the main purpose and key behaviors.

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 (search with filtering, user plan, linking), the description covers what it does, what it returns, when to use, parameter details, and behavior when keywords are omitted. There is no output schema, but the description enumerates return fields. It could mention rate limits or maximum matches, but for a search tool this is sufficient.

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

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

The input schema has 0% description coverage, so the description fully compensates. It explains the keywords parameter with an example and states it is required, clarifying that omitting it yields a hint. It also explains include_accounts by noting it controls whether accounts are returned. Both parameters are described in a way that agents can use correctly.

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

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

The description clearly states the tool searches bank connectors by name, lists the returned fields (connector id, access type, audience, linked connections/accounts, connect URL), and distinguishes it from sibling tools by specifying it should be called before connecting to provide a one-click link. The verb 'searches' and resource 'bank connectors' are specific, and the behavioral detail about honoring the user's plan adds further clarity.

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 usage guidance: 'Call this BEFORE connecting to hand the user a one-click link to the right bank.' It also states that keywords are required and that omitting them returns a hint rather than dumping the catalog, which prevents misuse. While it doesn't enumerate alternatives, the sibling context and the 'before connecting' direction suffice.

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=false), the description discloses significant side effects: it overrides automatic categorization, creates a Category Rule that affects future transactions, and explains per-item error handling with batch response shape. This fully informs the agent of behavioral consequences.

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

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

The description is relatively long but front-loaded with the main action ('Corrects the category...'). Every sentence adds value (side effects, response shape, parameter sources). Minor redundancy in repeating 'category' could be trimmed, 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 and a complex batch operation with side effects, the description covers purpose, parameters, behavioral impact, response structure, and error handling. It adequately equips an agent to use the tool correctly without additional context.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining the 'items' array structure, specifying that 'transaction_id' comes from a sibling tool and 'category_id' from another. It also details the response format, adding 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 tool 'corrects the category of one or more transactions' and specifies the HTTP method and endpoint. It distinguishes from sibling tools by referencing the source tools for transaction_id and category_id, making the purpose unambiguous.

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

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

The description explains when to use the tool (to fix miscategorized transactions and improve future categorization) and how it teaches Pluggy via category rules. It implicitly contrasts with listing tools but lacks explicit when-not-to-use or alternative sibling comparisons. The context is clear but could be more directive.

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. Description adds concrete details about the returned data structure, which 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?

Single sentence, front-loaded with primary action, no unnecessary words. Every phrase 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?

Despite no output schema, description sufficiently explains return structure (installed MCPs, status, catalog counts). Complete for a simple info 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; description correctly omits parameter details. Baseline 4 for zero-parameter 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?

Description uses specific verb 'Returns' and resource 'current toolkit state' with explicit details (installed MCPs, connection status, catalog tool counts). Clearly distinguishes from sibling tools which focus on 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?

Clearly states what the tool returns, implying it's for getting an overview of the toolkit state. No explicit when-not or alternative guidance, but sibling tool names provide context that this is unique.

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