Dock MCP

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

Annotations show idempotentHint=true and destructiveHint=false. Description adds context about permanent vs session behavior, and how to obtain the link when called with no args. No contradiction.

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

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

Two sentences, front-loaded with purpose. Every word adds value. 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?

Completely describes the tool's behavior for both token and no-args calls. No output schema needed; the outcomes are clear.

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 1 optional parameter 'token' with no description. Description fully explains its purpose: paste token for session login, or omit to get link. Compensates for 0% schema 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?

Clearly states the tool is for authentication, with specific actions: log in via browser or provide token. Distinguishes from sibling tools like connect and marketplace.

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 instructions for two usage scenarios (permanent config vs session-only token), and implies when to use each. No explicit alternatives needed since siblings are unrelated.

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. Description adds behavioral context about specific return values (authenticated field, pending array, connect URLs) that go beyond annotation hints.

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

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

Two sentences, front-loaded with main purpose, no wasted words.

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

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

For a zero-parameter status check tool, the description fully explains the two main states and return values. No output schema is needed given the simple nature.

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

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

No parameters exist, schema coverage is 100%. Description does not need to add parameter info; baseline 4 is appropriate.

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

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

Description clearly states it returns connection status and URLs with specific cases for different states. It distinguishes from siblings implicitly by focusing on status, but does not explicitly differentiate.

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 it versus siblings like 'authenticate' or 'list_connections'.

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

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses key behaviors: invoke works without installation, returns connect/checkout links when needed, and one-off invoke doesn't bloat the toolkit. No contradiction with annotations exists.

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 logically structured, covering core flow, each action, and edge cases. It is front-loaded with the tool's role and sequential flow. Could be slightly more concise, but the detail is warranted given 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?

For a tool with 13 parameters, no output schema, and multiple actions, the description provides a thorough contextual overview including usage patterns and auth/payment handling. Missing explicit return format examples for search/describe, but overall sufficient for 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 0% schema description coverage, the description adds only implicit meaning for parameters through narrative (e.g., action enum values explained contextually). However, it does not explicitly document individual parameter semantics like 'immediate', 'arguments', or 'tier_slug', leaving gaps for the agent.

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

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

The description clearly states the tool's purpose as the official mcp.ai marketplace for discovering and running MCPs/tools. It distinguishes itself from sibling tools by positioning itself as the primary entry point for capability search, and contrasts with specific tools like openfinance* and report_bug.

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

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

Explicitly instructs to use this tool FIRST for any capability request, before external registries. Provides detailed guidance on when to use invoke vs install, explains auth/payment fallback flows, and states that write operations require workspace owner/admin.

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 aligns with the destructiveHint=true annotation and adds value by specifying that data 'will no longer be available' and that a reconnection URL is returned. This goes beyond the annotation details.

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

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

The description is three concise sentences, each adding necessary information without redundancy. It is front-loaded with the main action and efficiently covers the key points.

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 low complexity and existing annotations, the description covers the tool's effect and return value. However, the lack of parameter documentation (item) leaves a gap in completeness for an agent to correctly invoke the 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 required 'item' parameter is not described in the schema or description, leaving its meaning unclear. With 0% schema description coverage, the description should compensate but does not.

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

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

The description clearly states the action ('revokes consent', 'deletes connection data') and the resource ('specific bank'). It also distinguishes itself from sibling tools like 'openfinance_list_connections' by specifying that it removes data and provides a reconnection 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 implies use when disconnecting a bank but does not provide explicit when-to-use, when-not-to-use, or alternative tools. The context is clear but lacks comparative 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?

Describes behavior beyond annotations, including waiting up to 60s, polling mechanism, return fields (status, executionStatus, lastUpdatedAt, synced), and edge cases like needs_action or timed_out. Annotations already have readOnlyHint=false, but description adds valuable context.

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

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

The description is detailed but concise for the complexity; each sentence is informative and front-loaded. Could be slightly shorter but still very 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 complexity (sync with waiting, polling, error states) and no output schema, the description covers return structure, statuses, and error conditions comprehensively, making it complete for agent use.

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

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

With 0% schema coverage, the description fully explains both parameters: 'items' as array of selectors (item_id, connector_id, connector_name) and option to omit for all, and 'wait' boolean for synchronous vs fire-and-forget. Adds meaning beyond raw schema.

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

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

The description clearly states the tool forces a sync and waits for completion, using specific verbs like 'forces' and 're-sync', and distinguishes itself from sibling tools like openfinance_get_item_status by explaining when to use which.

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 (stale balance/transactions), what it achieves (pulls fresh data without disconnecting), and how to use it (omit items for all banks, set wait: false for fire-and-forget). No exclusions needed.

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 (readOnly, idempotent, non-destructive), the description adds critical behavior: response shape with results/errors, and that CREDIT accounts may return a warning instead of throwing. No contradiction with annotations.

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

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

Four sentences, front-loaded with the core purpose and endpoint. Each sentence adds essential information (input, error handling, response shape). No waste.

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

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

For a simple tool with one parameter, the description covers endpoint, input format, error behavior, and response shape. Missing details on balance format (currency/decimal) but sufficient for correct 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?

The single parameter account_ids is described as an array of account IDs with size limit 1-50. Schema provides type and required, but description adds semantic meaning and constraint, which is valuable given 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 it returns a real-time balance payload per account ID, including the specific API endpoint. This distinguishes it from related tools like openfinance_list_accounts that only 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?

Usage is implied: pass account_ids array (1-50). Notes CREDIT accounts may return a warning. No explicit when/why vs alternatives, but the purpose is clear enough for an agent to infer appropriate use.

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

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

Annotations already confirm read-only, idempotent, non-destructive behavior. The description adds useful context: endpoint pattern, batch result shape `{results, errors}`, array size limit, and mention of extended creditData.

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

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

Two concise sentences cover purpose, endpoint, parameter usage, and return format with no redundancy or unnecessary 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?

For a single-parameter read tool with annotations, the description covers endpoint, parameter constraints, and return shape adequately. No output schema exists, but description gives sufficient detail.

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

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

The schema has 0% description coverage for account_ids, but the description specifies the array format and a size constraint (1-50), adding critical usage detail beyond the schema.

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

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

The description clearly states it returns full account objects with extended creditData per ID, distinguishing it from the sibling list tool openfinance_list_accounts which likely returns a summary.

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 use when full details are needed by specifying the batch array (1-50) and return shape, but it does not explicitly contrast with list_accounts or provide when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, so safety is clear. Description goes beyond by detailing return shape (financeCharges, payments with fields), batch response format {results, errors}, and the important behavioral note that Pluggy does not return a paid/status field. It also explains the tricky payment semantics (payments reflect previous bill's payment), preventing misuse.

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 compact yet comprehensive, with every sentence adding value. It is front-loaded with the core function, then provides usage guidance, behavioral notes, and parameter semantics. The structure is logical and easy to parse, with no wasted words.

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

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

Given the complexity of credit card bill data and the absence of an output schema, the description is remarkably complete. It explains the return fields, batch shape, limitations (no paid status), and provides cross-references to related tools. The agent can use this tool correctly based solely on the description.

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. It explains that `bill_ids` is an array of strings, how to pass it, and how to discover valid ids using `openfinance_list_credit_card_bills`. Adds significant meaning beyond the bare schema 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?

Clearly states verb 'Returns' and resource 'bill-level detail for credit card bills by id'. Distinguishes from sibling tools by explicitly stating what it does NOT do (individual transactions) and names the alternative tool. The description is specific and leaves no ambiguity about the tool's function.

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 you have bill ids) and when-not-to-use (for itemized transactions). Directs to sibling tool `openfinance_list_credit_card_bills` for id discovery and `openfinance_list_transactions` for transactions. Also includes a crucial caveat about payments and paid status, guiding agent away from incorrect assumptions.

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

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

Annotations indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds behavioral context by specifying return structure (`{ count, items }` for all, single object for one) and the inclusion of executionStatus and connector metadata. It does not contradict annotations and provides useful details beyond what annotations convey.

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 that are front-loaded with the core purpose, then immediately explain the two usage modes. No redundant information or vague phrasing. Each 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?

For a simple read-only tool with one parameter and no output schema, the description covers the main behavior, return structure for both modes, and example statuses. It could mention what connector metadata includes, but the information provided is sufficient for an agent to invoke the tool correctly.

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

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

The single parameter `item` has 0% schema description coverage, so the description must compensate. It explains that omitting `item` returns status for all linked banks, while passing it gets a single bank's status. This adds meaningful semantic information, though it does not specify format or constraints for the `item` value.

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

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

The description clearly states the tool returns the current status of a bank connection, lists example statuses (UPDATED, UPDATING, LOGIN_ERROR, etc.), and mentions additional fields (executionStatus, connector metadata). It also distinguishes between two usage modes: omitting `item` for all connections and passing `item` for a single bank. This makes the purpose specific and distinct from sibling tools like openfinance_list_connections.

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

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

The description provides clear guidance on when to omit vs. pass the `item` parameter, but does not explicitly compare to sibling tools or state when not to use this tool. It implies usage context through the two modes, but lacks explicit exclusions or alternatives.

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

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

Beyond annotations (readOnlyHint=true, idempotentHint=true), the description adds that each account's `name` is the legal entity not the brand, advises using `bank` for user-facing text, and explains the connector-dependent nature of CREDIT balance. 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 detailed and well-structured, starting with an overview and progressing into usage, caveats, and cross-references. While it's longer than minimal, every sentence adds necessary context, so it earns a high score but loses a point for slight verbosity.

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

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

Given the lack of output schema, the description thoroughly lists returned fields and their meaning. It covers special cases (CREDIT balance ambiguity) and provides cross-references to other tools for completeness. The agent has enough information to correctly invoke and interpret 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 description coverage, the description fully compensates. It explains the `item` parameter's behavior (omit vs. pass) and the `type` enum values (BANK = checking/savings, CREDIT = credit card). It also mentions added fields returned (bank, connector_id, item_id), enriching understanding 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 that the tool returns accounts (BANK and CREDIT) with specific fields like balance, number, type, subtype, bankData, and creditData. It distinguishes between two account types and provides context about the returned data, 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 explicitly explains when to omit the `item` parameter (to list accounts across all linked banks) vs. pass it (to target a single bank). It also warns against treating CREDIT balance as this month's bill and directs to `openfinance_list_credit_card_bills` for standardized amounts, providing clear guidance on 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 mark readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the result is cached per session and is a single aggregated response, providing beyond-annotation 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 front-loaded with the main verb and noun, and every sentence adds meaningful detail. It is concise with 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 fully explains the response structure and links to a sibling tool. For a zero-parameter, read-only tool, 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?

There are no parameters (schema coverage 100%), so a baseline of 4 applies. The description adds value by explaining the response fields (id, description, etc.) and their usage.

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

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

The description clearly states it returns Pluggy's transaction category taxonomy, names the endpoint, and lists the fields. It distinguishes from sibling tools like list_transactions by focusing on categories, and mentions the specific use case with updating 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?

The description implies usage before calling openfinance_update_transaction_category, and notes that descriptionTranslated is preferred for pt-BR users. However, it lacks explicit when-not-to-use or alternative tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying returned fields and the add_connection_url for linking additional banks. 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, well-structured sentence that conveys all necessary information without redundancy.

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

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

For a simple, read-only list tool with no parameters and no output schema, the description adequately specifies the return content. It could mention potential limitations (e.g., no pagination details) but is sufficient for basic use.

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

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

No parameters exist (schema description coverage 100%), so the description does not need to explain parameters. The baseline score of 4 applies as the tool is parameterless.

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 with specific fields (connector_id, item_id, bank name, add_connection_url). It distinguishes from sibling list tools (e.g., list_accounts, list_transactions) by focusing on 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 implies usage to view bank connections but provides no explicit guidance on when to use this tool versus siblings like openfinance_list_accounts or openfinance_get_item_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?

Goes well beyond annotations: explains that Pluggy does not return a paid/status field, derives payment_status, explains payment cycle logic, connector asymmetry for open bills, and the meaning of derived fields. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint 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 very long and dense. While well-structured with paragraphs and bolding, it is not concise. It could be more front-loaded and trimmed without losing essential information.

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

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

Highly complete given the tool's complexity. Covers return structure (payment_status, open_bill object), connector asymmetry, relationship to other tools, and derived fields. No output schema, but description effectively describes the output. All relevant edge cases are addressed.

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

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

With 0% schema description coverage, the description compensates by explaining the key parameters: account_id, account_ids, include_open_bill. It does not explicitly describe page and page_size, but these are common pagination parameters. Overall 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 states the tool returns CLOSED credit card bills for a CREDIT-type account, with specific fields listed. It distinguishes itself from siblings like openfinance_list_transactions (for individual transactions) and openfinance_get_credit_card_bill (single bill).

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 (for closed bills) and when not to (for individual transactions, use openfinance_list_transactions). Also explains when to use include_open_bill and advises against using the account's balance directly. Includes connector asymmetry warnings.

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

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context: on errors (403 or upstream) it returns { total:0, results:[], warning } instead of throwing, and lists specific fields like balance, amount, rates, dueDate, etc. 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 a single dense paragraph that packs purpose, types, fields, and error handling. It front-loads the purpose but lacks structural breaks. It is somewhat lengthy but not excessively so, though it could be more scannable.

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 covers return fields and error handling, but misses parameter explanations and pagination details. The tool has 4 optional params with no guidance, leaving some gaps for an 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?

Schema description coverage is 0%, so the description must explain the parameters. It does not elaborate on 'item', 'page', 'type', or 'page_size' beyond what the schema provides. The agent gets no additional meaning, e.g., that 'item' refers to a connection ID or that 'type' filters asset categories.

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

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

The description clearly states the tool returns investment portfolio data for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.) and fields. This distinguishes it from siblings like openfinance_list_accounts or openfinance_list_loans.

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

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

The description implicitly indicates usage for retrieving investment data, but does not explicitly state when or when not to use it, nor does it mention alternatives among siblings. However, it covers error handling (returns structured response on 403), which provides some 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 already indicate readOnly, idempotent, non-destructive. The description adds significant behavioral details: transaction types, fields returned, and bulk execution capability. 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?

Two succinct sentences cover purpose, return fields, and usage hint. No wasted words, front-loaded with key 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?

Describes return fields adequately given no output schema, but lacks pagination details (page/page_size) and precise bulk usage rules. Adequate but with clear gaps.

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

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

Schema coverage is 0%, so description must compensate. It explains investment_id (required) and mentions investment_ids for bulk, but does not clarify the relationship between them (e.g., can investment_ids replace investment_id?) and omits page/page_size entirely. Incomplete parameter guidance.

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 movement history for a specific investment position, listing transaction types like BUY/SELL/TAX. It distinguishes from sibling tools by specifying it works on a single investment (from openfinance_list_investments) and details the returned fields.

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

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

Explicitly instructs to use after openfinance_list_investments to obtain investment_id, and mentions bulk support via investment_ids. However, no explicit when-not-to-use or alternatives are provided.

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

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

Adds context beyond annotations: sequential queries with rate-limit spacing and return format { results, errors } per connection. Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, and description does not contradict.

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 succinct sentences with no wasted words. Front-loaded with main action, then details on parameter usage and behavior.

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, behavior (sequential/rate-limited), and return shape. Lacks details on what fields loan contracts contain and error handling beyond 'errors' key, but sufficient for a list tool with good annotations.

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

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

Schema has no description for `items` (0% coverage); description compensates fully by explaining that items are connection selectors (item_id uuid, connector_id, or connector_name) and that omitting fetches all connections.

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 'Lists loan contracts per bank connection (GET /loans)' with specific verb and resource. It distinguishes from sibling tools like openfinance_list_accounts by mentioning the items parameter for per-connection listing vs. omitting for all banks.

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 describes when to pass `items` (for specific connections) and when to omit (for all linked banks), with guidance on sequential rate-limited execution. Does not mention alternative tools but given the context, it 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?

Beyond annotations (readOnly, idempotent), the description discloses varying CREDIT PENDING/POSTED per connector, auto-pagination up to 5000 with truncation, error handling returning structured error objects, and detail level costs. 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 well-organized, front-loaded with core purpose, and logically flows through use cases. Every sentence adds value, though slight verbosity prevents a perfect 5.

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 output fields (creditCardMetadata.billId, merchantInfo, etc.) and error responses. It covers edge cases, references sibling tools, and provides complete guidance for a complex tool.

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

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

Schema coverage is 0%, but the description compensates fully, explaining each parameter (from/to as ISO dates, search_queries for substring match, page and page_size for pagination, detail enum values with effects). It adds behavior context like aggregation before filtering.

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), uses the verb 'Returns', and distinguishes from siblings like openfinance_list_credit_card_bills and openfinance_list_transactions_by_item by specifying when to use each.

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: for credit card transactions this is the only way to get itemized ones, contrasts with openfinance_list_credit_card_bills for total debt, explains pagination strategies (auto vs manual), and advises on checking connection health if total is 0.

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

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

The description discloses key behavioral traits: internal account resolution, fan-out of transactions, default summary output with metrics, truncation at 5000/account with `truncated:true` flag. Annotations already confirm read-only and idempotent behavior, so the description adds value beyond them. No contradiction with annotations.

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

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

The description is quite long but well-structured: it front-loads the purpose, then explains parameters in order. Some redundancy (e.g., 'compact, rich, raw' repetition) could be trimmed, but it remains clear and organized.

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 (7 parameters, no output schema), the description covers the tool's output comprehensively: monthly evolution, top expenses/revenues, per-account breakdown, and truncated flag. It explains the distinction between monthly and raw granularity. The only missing detail is the exact structure of `by_account` or `top_despesas`, but it suffices for an 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?

The description explains most parameters: `item`, `from`/`to`, `granularity`, `detail`, `type`, and implicitly `top_n` via 'largest N each'. However, defaults for `detail` and `top_n` are not explicit, and `top_n` is not directly named as a parameter. Schema coverage is 0%, so the description bears the full burden but has minor 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 the tool's purpose: 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call.' It specifies the verb (analyse), resource (connection transactions), and scope (consolidated, no need for separate accounts). It differentiates from siblings like openfinance_list_transactions by emphasizing aggregation and simplification.

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: 'you do NOT need to call openfinance_list_accounts first' and explains when to omit the `item` parameter. It also clarifies when to use `granularity:'raw'` and the `detail` options. However, it does not explicitly contrast with sibling tools like openfinance_list_transactions or state when this tool is inappropriate.

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 annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds valuable behavioral context: it returns a global indicator, degraded components, open incidents, and flags incidents affecting connected banks. This goes beyond what annotations provide, though the annotations already cover the most critical behavioral aspects.

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 moderately concise with three sentences, each adding value: first states purpose and differentiation, second provides use cases and reasoning, third lists output. It is front-loaded with the core purpose. While it could be slightly trimmed, every sentence earns its place and there is 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?

Given the tool has no parameters and no output schema, the description fully covers what the tool does and what it returns. It explains the use case, distinguishes from siblings, and details the output format (global indicator, degraded components, incidents, affected banks). This is complete for a status check 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 tool has zero parameters and schema coverage is 100%, so no parameter documentation is needed. The description uses its space to explain the tool's purpose and output instead of repeating missing parameter details. Baseline for 0 parameters is 4, and the description does not add any parameter info, which is appropriate.

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

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

The description clearly states the tool 'Checks the LIVE operational status of the Open Finance provider (its public status page)'. It uses a specific verb (checks) and resource (provider operational status), and immediately distinguishes itself from the sibling tool 'openfinance_get_item_status' by specifying it checks the provider's health, not the user's connection.

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

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

The description provides explicit guidance: 'Use it whenever data looks incomplete or stale even though a connection shows UPDATED...'. It explains the context (missing accounts/transactions, bank not returning everything) and how it helps differentiate provider-side problems from connection issues. It also names the alternative tool to use for connection status.

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 (readOnlyHint=true, destructiveHint=false) are complemented by description: it won't dump full catalog, honors user plan, and includes caveat warnings for non-Open-Finance connectors. 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?

Single dense paragraph, but effectively front-loaded with core purpose. Could be slightly more structured (e.g., bullet points) but not overly verbose.

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

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

No output schema, but description details returned fields (id, access, audience, connections, accounts, connect_url) and error behavior (hint without keywords). Covers edge cases and plan filtering.

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 descriptions missing (0% coverage), but description explains both parameters: keywords is required despite schema, with example format, and include_accounts triggers return of linked connections/accounts. Adds critical 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?

Clearly states the tool searches bank connectors by name (keywords array), returning connector id, access type, audience, linked connections/accounts, and connect_url. Distinguishes from siblings like 'authenticate' and 'connect' by specifying it is a pre-connection search 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?

Explicitly states to call BEFORE connecting and that keywords[] is REQUIRED (returns hint otherwise). Provides context on when to surface caveats and that plan filtering applies, giving clear guidance on when and how to use.

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

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

The description goes beyond minimal annotations by disclosing that recategorizing creates a Category Rule, affecting future transactions. It also explains batch behavior with per-item errors not failing the whole batch, providing full transparency.

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 efficiently packs essential information without excessive verbosity. It could benefit from clearer structuring (e.g., bullet points) but remains concise and informative.

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 absence of an output schema, the description thoroughly explains the return value and side effects. It covers the batch update process, error handling, and the automatic rule creation, making the tool's behavior complete clearly.

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

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

With 0% schema coverage, the description compensates by explaining that items is an array of { transaction_id, category_id }, and specifies where to obtain each ID. It also describes the return shape, adding 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 tool corrects transaction categories via a PATCH endpoint. It distinguishes from sibling tools by explaining that transaction_id comes from openfinance_list_transactions and category_id from openfinance_list_categories, linking to relevant 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 explains the tool is for fixing miscategorized transactions and improving future categorization. It implicitly provides guidance by referencing source IDs, but does not explicitly state when not to use it or alternatives.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds that conversation is needed for reproduction, but otherwise does not disclose side effects or behavior 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 with no redundancy: first states purpose, second provides usage guidance. Every word 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?

No output schema exists, and parameter descriptions are minimal. The tool is simple (feedback reporting), but missing details on expected response or handling of submissions. Adequate but not thorough.

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

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

Schema coverage is 0%, so description must compensate. It only explains the 'conversation' parameter partially ('include the conversation array with recent messages'), but offers no detail on 'context' or 'message' fields, leaving three parameters under-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 the verb and resource: 'Report a bug, missing feature, or send feedback.' It distinguishes from sibling tools, which are all finance or authentication related.

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 guidance to include the conversation array for reproduction, but does not specify when not to use the tool or mention 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, idempotentHint, and destructiveHint. The description adds no extra behavioral context (e.g., no mention of output format or side effects). It neither contradicts nor significantly enhances 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, concise sentence that efficiently conveys the tool's purpose without unnecessary words.

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

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

For a simple, zero-parameter version tool with no output schema, the description adequately conveys 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?

There are zero parameters, and the schema has 100% coverage (empty). The description need not add parameter details. Baseline for no params 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 action ('Show') and the resource ('current MCP platform and adapter versions'). It is specific and differentiates from sibling tools, which are primarily focused on financial operations.

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

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

The description does not explicitly state when to use this tool versus alternatives. However, its purpose is self-evident as a version query tool, making explicit guidelines less critical.

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 context that the tool returns state about MCPs, which is 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?

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose with no wasted words.

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

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

Given zero parameters and no output schema, the description adequately covers what the tool does. It could optionally mention that it is a read-only status check, but the annotations already indicate that. Slightly lacking in output format details, but sufficient for correct 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?

No parameters exist in the input schema, so baseline is 4. The description adds value by explaining the output content (installed MCPs, connection status, catalog tool counts), which compensates for no output schema.

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

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

The description clearly states the tool returns toolkit state, specifying 'installed MCPs, their connection status, and how many catalog tools each exposes.' This uses a specific verb and resource, and the content distinguishes it from sibling tools that perform actions or retrieve financial data.

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

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

The description implies usage for checking state, but does not explicitly state when to use this tool versus alternatives or when not to use it. Given no sibling tool provides identical functionality, the lack of explicit guidance is acceptable but not exceptional.

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