XP MCP

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

The description adds context beyond annotations: it explains the two calling modes and the option to configure a permanent token. Annotations already indicate idempotent and non-destructive behavior. The description could be more explicit about return values, but overall it's strong.

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

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

The description is concise and well-structured, with each sentence providing distinct information: target audience, process, best practice, and usage modes. 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 simple authentication tool with one optional parameter, the description covers the main usage patterns. It could be improved by mentioning the expected return value or error handling, but it's sufficient for agent 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 schema has a single parameter 'token' with no description. The description explains that it is a JWT access token, adding critical semantic meaning. With 0% schema coverage, this fully compensates.

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

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

The description clearly states the tool is for authentication, specifying how it works for IDE agents. It distinguishes from siblings like 'connect' by focusing on token-based login and session management.

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 usage scenarios: call with token for session login or without args to get a login link. It also suggests a best practice for permanent connections. However, it does not explicitly exclude alternatives or compare to sibling tools.

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

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

Annotations already declare the tool as read-only and idempotent. The description adds value by explaining the conditional return values (authenticated vs connect_url), which is useful context beyond what annotations provide. However, it does not disclose any additional behavioral traits.

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 extremely concise with two sentences, no wasted words, and the main purpose is front-loaded. It effectively communicates the tool's 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?

Given the tool has no parameters and no output schema, the description adequately explains the two possible response states. It provides enough context for an agent to understand what the tool returns without needing additional documentation.

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 no parameters, so the schema coverage is 100%. Per the rubric, 0 parameters earns a baseline score of 4. The description does not need to add parameter information.

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 connection status and URLs, with specific behavior for different states (authenticated vs missing credentials). It distinguishes itself from siblings like 'authenticate' and 'marketplace' by focusing on status inspection.

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 the tool is used to check connection status but does not explicitly state when to use it over alternatives like 'authenticate' or when not to use it. More explicit guidance would improve clarity.

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 key behavioral traits beyond annotations: invoke runs one-off without installing, install makes permanent, work requires owner/admin for writes, and how invoke handles missing credentials or insufficient wallet. No contradiction with annotations (readOnlyHint=false, 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?

The description is dense and informative but lacks brevity and structure. It front-loads key concepts but then includes many details in a single paragraph, making it harder to parse quickly. Could benefit from bullet points or clearer separation of actions.

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, no output schema, many sibling tools), the description is highly complete. It covers all actions, their use cases, return behaviors (connect/checkout links), and limitations, leaving little ambiguity for an AI 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?

With 0% schema description coverage, the description compensates by explaining the main parameters (action, query, mcp_id, tool_id, arguments) through workflow context. However, it does not individually describe less central parameters like limit, immediate, tier_slug, or conversation, leaving some gaps despite overall good 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 is the official mcp.ai marketplace catalog and runtime, distinguishing itself as the primary tool for discovering and running MCPs. It specifies the core flow (search, describe, invoke) and explicitly advises using this tool first before external registries, differentiating it from sibling tools.

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

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

Provides extensive guidance on when to use invoke vs install, how to handle credentials and payment, and alternatives like request_mcp when nothing fits. It also explains list_tools for current callables and subscribe/cancel for billing, offering a complete decision framework.

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 destructiveHint=true, so the description's statement about data deletion aligns but adds context about returning an add_connection_url for reconnection. This extra behavioral detail about the response is valuable beyond the structured annotation.

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

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

Three short sentences, no redundancy, and each sentence adds essential information: what the tool does, the consequence, and what is returned. 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 simple one-parameter destructive tool with clear annotations, the description covers the core action and outcome. However, the parameter 'item' is underspecified, and no output schema exists to compensate. The tool's role is adequately complete but leaves a gap in parameter 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?

The input schema has one required string 'item' with 0% description coverage. The description only implicitly refers to 'a specific bank' but never explicitly states that 'item' is the bank identifier or provides any format/validation details. The agent is left to infer the parameter's 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 uses a specific verb ('revokes' and 'deletes') and clearly identifies the resource ('Open Finance consent for a specific bank'). It distinguishes from sibling tools by focusing exclusively on disconnection, while other tools handle listing, syncing, or account details.

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 the tool is used to disconnect a bank, but it does not explicitly state when to use it versus alternatives like openfinance_list_connections or any prerequisites. No guidance on when not to use is 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?

Discloses behavior beyond annotations: blocking wait up to ~60s, polling mechanism, return fields (status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out), and error states like LOGIN_ERROR. 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?

Well-structured and front-loaded with core action, but a single long paragraph; could be slightly more concise with bullet points, but 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 and moderate complexity, description covers purpose, usage, parameters, return values, timeouts, and error handling. Provides all necessary context for agent to invoke 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?

With 0% schema coverage, description fully compensates: explains `items` as array of selectors and that omitting syncs all, and `wait: false` for fire-and-forget. Adds meaning beyond 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?

Description clearly states the tool forces a bank re-sync and waits, distinguishing it from siblings like openfinance_get_item_status by explicitly mentioning the alternative. Uses specific verb 'force sync' and resource '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 explicit when-to-use ('when a balance or transaction list looks stale'), what it does not do ('WITHOUT disconnecting/reconnecting'), and how to handle outcomes (re-check with openfinance_get_item_status on timeout, fire-and-forget with wait: false).

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 and idempotentHint, so safety profile is clear. The description adds valuable behavioral context: credit accounts may return BALANCE_FETCH_ERROR as structured warnings, and the response shape includes results and errors arrays. This helps the agent understand non-standard error handling.

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

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

The description is three sentences, each adding unique value. It front-loads the core action (returns balance) and uses minimal words. No redundancy or filler.

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 provides the response shape and error structure. For a simple balance lookup tool with one parameter, this is fully sufficient for correct invocation. All relevant behavioral aspects are covered.

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 by specifying that account_ids must be an array of 1-50 strings. It also explains that credit accounts may trigger specific errors. This adds critical constraints not present in the schema's JSON 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 the tool returns a real-time balance payload per account id, specifies the HTTP method and endpoint, and defines the input parameter. It distinguishes from sibling tools like openfinance_list_accounts by focusing on balance retrieval.

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

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

The description specifies that account_ids must be an array of 1-50 elements and mentions that credit accounts may return a warning instead of an error. However, it does not explicitly advise when to use this tool versus alternatives like openfinance_get_accounts_detail.

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

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

Annotations already declare readOnlyHint and idempotentHint, so description adds little beyond the extended creditData mention and batch shape. It does not discuss rate limits, error handling, or any side effects beyond what annotations imply.

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 main functionality, then parameter details, then return shape. 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?

Despite no output schema, description gives return shape ({ results, errors }) and mentions extended creditData. For a read-only tool with good annotations, it is sufficiently complete, though more detail on account fields could help.

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

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

With 0% schema coverage, description compensates by specifying array size (1–50), endpoint structure (GET /accounts/:id), and that account_ids is required. This adds meaningful context beyond the raw schema.

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

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

Description clearly states verb 'Returns' and resource 'full account objects', specifies it includes extended creditData, and differentiates from list tools by requiring specific IDs. The batch shape and parameter details add 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?

Implies usage when needing detailed account data by ID, but does not explicitly compare with sibling tools like openfinance_list_accounts or other get endpoints. No when-not-to-use or alternative recommendations.

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

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

Discloses behavioral traits beyond annotations: batch shape {results, errors}, no paid/status field from Pluggy, nuance about payments array belonging to previous bill. Does not contradict 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?

Packed with useful information, front-loaded with main purpose and key distinctions. Slightly verbose but every sentence adds value. Could be tightened slightly, but still 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?

No output schema, but description explains return shape, fields, and critical behavioral notes. Covers all needed context for an agent to use the tool correctly.

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

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

Schema coverage is 0% so description carries full burden. Explains the single required parameter 'bill_ids' as an array and how to obtain them via list tool, adding value beyond schema types.

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

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

Clearly states it returns bill-level detail for credit card bills by id, listing specific fields (financeCharges, payments). Distinguishes from sibling openfinance_list_transactions which returns 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?

Explicitly instructs to use openfinance_list_credit_card_bills first to discover ids, and when to use openfinance_list_transactions for itemized transactions. Provides important nuance about payments interpretation.

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

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

The description adds behavioral context beyond annotations: it specifies that omitting `item` returns `{ count, items }` and passing it returns a single item. It also enumerates possible statuses. The annotations already indicate read-only and idempotent, so the description complements them well.

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

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

Two sentences, front-loaded with the tool's purpose, followed by precise usage instructions. No redundant 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?

Though there is no output schema, the description covers the return format for both usage scenarios, lists possible status values, and mentions additional fields (executionStatus, connector metadata). This is complete for the tool's scope.

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

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

The input schema has no description for the `item` parameter (0% coverage). The description fully compensates by explaining both omission and use cases, making the parameter's purpose and behavior crystal clear.

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

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

The description clearly states the tool returns the current status of a bank connection, listing possible status values and metadata. It distinguishes itself from siblings by specifying the unique behavior of returning either all connections or a single one based on the parameter.

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 get all linked banks) and when to pass it (for a single bank). This provides clear usage context, though it does not explicitly mention when not to use this tool versus alternatives like list_connections or accounts.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds critical behavioral context: the `balance` for CREDIT accounts is connector-dependent and should not be treated as 'this month's bill', and the `name` field is the legal entity, not the brand. This goes beyond what annotations offer.

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 well-structured, with each sentence adding value. It could be slightly more concise, but it avoids redundancy and front-loads key information. Still, it earns a high score for efficiency relative to content density.

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 an output schema and the tool's complexity (two parameter modes, nuanced field semantics), the description is comprehensive. It explains return fields, the distinction between `name` and `bank`, and the connector-dependent behavior of CREDIT balance. It also points to a sibling tool for further detail, covering all essential contextual needs.

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 carries full burden. It thoroughly explains both parameters: `item` (optional, to filter by specific connection) and `type` (enum to filter by account type). It also clarifies the effect of omitting `item`.

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 accounts for bank connections (BANK and CREDIT) with specific fields like balance, number, type, subtype, bankData, and creditData. It also distinguishes between listing all accounts (without `item`) and targeting a single bank (with `item`), making the purpose very specific and unambiguous.

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

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

Explicitly states when to use `item` (to target a single bank) and when to omit it (to list across all banks). It also recommends the sibling tool `openfinance_list_credit_card_bills` for standardized credit bill 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 declare readOnlyHint, idempotentHint, and destructiveHint as false, so the description's additional mention of caching behavior is a valuable supplement that ensures the agent knows data may not be real-time.

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

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

Three sentences, front-loaded with the core action, and each sentence provides essential 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?

Despite no output schema, the description fully explains the return structure, including field meanings and how they relate to other tools, making the tool's behavior completely understandable.

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, and the description adds significant value by detailing the output fields (id, description, descriptionTranslated, parentId, parentDescription) and their usage, especially linking categoryId to the update_transaction_category tool.

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

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

The description clearly states the tool returns Pluggy's transaction category taxonomy, cached for the session. It specifies the verb (returns) and resource (categories), and differentiates it from sibling tools that deal with transactions, accounts, etc.

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 that the output provides category IDs, descriptions, and parent relationships, and notes the function is cached. While it doesn't explicitly state when not to use it, the purpose is clear and alternatives are implicitly obvious given the sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds specific return fields (connector_id, item_id, bank name, add_connection_url) and explains purpose. 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 sentence that efficiently conveys the tool's purpose and output. 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?

For a simple listing tool with no parameters and no output schema, the description covers the key returned fields and purpose. Could mention if results are limited or paginated, but likely not critical.

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

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

No parameters; schema coverage is 100%. Description provides context on what the tool returns, which is sufficient given no inputs.

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

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

Description clearly states it returns saved bank connections with specific fields (connector_id, etc.) and an add_connection_url. Distinguishes from sibling tools by focusing on listing vs. connecting, authenticating, or other 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?

No explicit when-to-use or when-not-to-use guidance. Context from sibling names implies this is for viewing existing connections, not creating new ones. Could benefit from mentioning alternatives like authenticate or connect.

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, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: it explains that no paid/status field exists natively, how payments are assigned across bills, the derived payment_status logic, connector asymmetry (open bill may be unavailable), the default false for include_open_bill, and that a warning is returned if CREDIT_CARDS is not enabled. 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 very long and dense with extensive details (e.g., field lists, payment_status legend, connector asymmetry). While well-structured with sections, it could be more concise by summarizing some technical details or moving them to a reference section. The verbosity slightly reduces clarity for quick scanning.

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

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

Given no output schema and 0% schema coverage, the description is comprehensive. It covers return fields, derived fields, parameter behavior, edge cases (payment allocation, connector asymmetry, non-enabled product), and directs users to related tools. All necessary context for correct usage is provided.

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 the description must compensate. It explains account_id (required), account_ids for bulk, and include_open_bill with its semantics. However, it does not describe page and page_size parameters. While the main parameters are covered, the missing pagination description is a gap given the high burden from zero 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?

The description explicitly states that the tool returns closed credit card bills for a CREDIT-type account, listing key fields. It differentiates from siblings like openfinance_list_transactions by noting this tool returns bill-level summaries, not individual transactions, and from openfinance_get_credit_card_bill by offering batched execution and additional derived 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?

The description provides detailed guidance on when to use this tool, including explaining Brazilian Open Finance semantics for payment allocation, the optional include_open_bill parameter for open bill and total debt, connector asymmetry, and advising to use openfinance_list_transactions for itemized transactions. It gives explicit when-to-use and when-not-to-use information.

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

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

The description adds significant behavioral context beyond the annotations (readOnlyHint, idempotentHint, destructiveHint). It explains that the tool returns a safe response (total, results, warning) on errors like INVESTMENTS not being enabled, which is not covered by annotations. 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 a single, dense paragraph that front-loads the main purpose and lists key details (types, fields) without extraneous information. Every sentence adds value, making it concise and well-structured.

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

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

While the return structure is well-described and annotations cover safety, the lack of parameter documentation (pagination, filtering) leaves a gap in completeness. The tool is fairly simple, but the missing parameter semantics reduce overall context for an AI 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 input schema has 4 parameters with 0% description coverage. The description does not explain any parameter (item, page, type, page_size), leaving the agent to infer their meanings from names only. For a tool expecting connection identification and pagination/filtering, this is a significant 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 the tool returns investment portfolio for a connection, listing specific investment types (FIIs, stocks, ETFs, etc.) and the data fields included. It distinguishes from sibling tools like openfinance_list_investment_transactions by focusing on portfolio data rather than transactions.

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

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

The description implies usage for retrieving investment portfolios but does not explicitly state when to avoid this tool or mention alternatives. It does note that errors are handled gracefully, providing a hint for error handling, but lacks direct comparison with siblings.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description's additional detail on return fields (quantity, value, expenses breakdown) adds context without contradiction. No new behavioral traits beyond annotations, but the field list is helpful.

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 focused sentences: first describes purpose and output, second gives usage flow and bulk feature. No extraneous words; efficient and well-structured.

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

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

No output schema, so description compensates by listing return fields. With annotations covering safety, the description is mostly complete. Missing details on pagination parameters (page, page_size) but overall 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?

Schema coverage is 0%, but description only explains investment_id and investment_ids. Parameters page and page_size are not described, leaving a gap for the agent. The description partially compensates but not 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?

The description clearly states the tool returns movement history for an investment position, listing specific transaction types (BUY, SELL, TAX, etc.) and distinguishing from siblings like openfinance_list_investments and openfinance_list_transactions.

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

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

Explicitly says to use after openfinance_list_investments to get investment_id, and mentions bulk support via investment_ids. Provides clear when-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 indicate readOnlyHint=true and idempotentHint=true. The description adds behavioral details beyond annotations: sequential queries with rate-limit spacing and return structure '{ results, errors }' per connection. 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 no wasted words. First sentence states purpose, second explains parameter semantics and behavior. Well-structured and front-loaded.

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

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

Given the tool has 1 optional parameter, no output schema, and good annotations, the description covers all necessary aspects: parameter usage options, rate-limit spacing, and return structure per connection. It is complete for selecting and invoking correctly.

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

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

Schema coverage is 0%, so the description must compensate. It explains that `items` is an array of connection selectors (item_id uuid, connector_id, or connector_name) and how multiple connections are processed. This adds significant meaning beyond the schema type 'array of strings'.

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 'Lists loan contracts per bank connection (GET /loans)', specifying the resource ('loan contracts') and the action ('lists'). It distinguishes from sibling tools like openfinance_list_accounts by focusing on loans and the 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?

The description provides explicit guidance: pass `items` to fetch per connection or omit to list across all banks. It mentions sequential querying with rate-limit spacing, giving context for use. However, it does not explicitly state when not to use this tool or compare to 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?

Discloses upstream-dependent behavior (pending vs posted varies), error handling (returns warning instead of throwing), token cost differences across detail levels, and search truncation. Annotations already indicate readOnly/idempotent, so description adds significant context without contradiction.

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

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

Long but dense with information. Front-loaded with main purpose and account type distinction. Could be broken into sections for readability, but every sentence 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?

No output schema, but description covers return structure (transaction fields, warnings, truncated flag). Also covers error states, bulk support, and links to related tools for statement dates and connection health. Complete 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 has 0% description coverage, but description thoroughly explains all 8 parameters: detail enum with examples, search_queries semantics and truncation, from/to format, pagination limits, and bulk account_ids. Fully compensates for missing schema descriptions.

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

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

Clearly states it returns transactions for bank/credit accounts. Distinguishes credit card itemized transactions as the only source, differentiating from sibling tools like openfinance_list_credit_card_bills. Verb+resource is 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?

Explicitly tells when to use each detail level, when to use alternative tools (bills, accounts for closing dates), and how to handle zero results or truncation. Provides clear context for when not to use (e.g., for total debt use bills).

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 critical behavioral details: internal fan-out of transactions, default compact summary, per-account scanning cap of 5000 with truncated flag, and parameter options that affect behavior. 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 dense but well-organized, starting with core purpose and then detailing parameters and options. Every sentence contributes value, though a brief listing structure could improve readability.

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

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

For a tool with 7 parameters, no output schema, and no nested objects, the description covers all critical aspects: functionality, parameter usage, behavioral limits, and use cases. It includes return format highlights (compact summary fields) and truncation behavior, making it self-contained.

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

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

Schema coverage is 0%, so description must compensate. It explains 'item' accepts connector_id/name/item_id, 'from'/'to' are ISO dates, granularity options, detail options, and type filter. However, 'top_n' is only implied as 'largest N' and not explicitly linked to the parameter, slightly reducing clarity.

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

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

The description specifies a consolidated cash-flow analysis for a bank connection, resolving accounts internally and fanning out transactions. It distinguishes itself from sibling tools like openfinance_list_transactions by obviating the need to list accounts first.

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

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

Explicitly states when to use (e.g., 'análise anual/mensal', 'fluxo de caixa') and when to use alternatives like granularity:'raw' for detailed rows. Also explains that omitting 'item' analyzes all linked banks, providing clear context for selection.

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 readOnlyHint and idempotentHint. Description adds substantial behavioral context: it returns global indicator, degraded components, open incidents, and flags affected banks. This tells the agent exactly what to expect and how to interpret results.

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

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

Single paragraph, front-loaded with the core action. Each sentence adds value, though the description is relatively long. Could be slightly more concise, but overall clear and structured.

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

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

Given no output schema, the description explains the return fields (global indicator, degraded components, incidents, affected banks). This is sufficient for an agent to decide when to use and interpret results. Minor gap: exact structure of incidents not detailed, but adequate for the tool's purpose.

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, baseline 4. The description adds no parameter-level detail as none exist, but it provides context on what the tool does without parameters, which is sufficient for an agent.

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

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

The description clearly states it checks the LIVE operational status of the provider. It distinguishes from openfinance_get_item_status by specifying this is provider health, not connection health. The verb 'checks' and resource 'provider status' are specific and unambiguous.

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

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

Explicitly says when to use: when data is incomplete/stale despite connection showing UPDATED. Provides clear context for troubleshooting upstream outages. Also differentiates from the sibling tool for connection status, giving 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 read-only, idempotent, non-destructive behavior. The description adds specific behavioral details: it honors the user's plan (hides PJ for PF), requires keywords, and never dumps the full catalog. These supplement the 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 concise (4-5 sentences) and well-structured: purpose first, then output fields, plan filtering, usage advice, and a note on required input. Every sentence adds value with no redundancy or fluff.

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

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

Given the tool's simplicity (2 parameters, no output schema), the description is complete: it covers input semantics, output fields, behavioral notes (plan filtering, required keywords, hint behavior), and usage context. No additional information is needed 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?

With 0% schema description coverage, the description fully compensates by explaining both parameters. It describes keywords as required array of strings with examples, and include_accounts as optional boolean that triggers including accounts. All parameter semantics are clearly conveyed 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 searches bank connectors by name, lists returned fields (connector id, access type, audience, linked connections, connect_url), and distinguishes itself from sibling tools by emphasizing it should be called before connecting. The verb 'searches' and resource 'bank connectors' are specific, making 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 provides explicit guidance: 'Call this BEFORE connecting to hand the user a one-click link to the right bank.' It also notes that keywords are required and that without them a hint is returned, implying when to use. However, it does not explicitly mention when not to use or alternative tools for listing all connectors, but the required nature of keywords implies that.

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 (non-readOnly, non-idempotent). The description goes far beyond by disclosing that it creates a Category Rule, teaches Pluggy for future matches, and details batch error handling.

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

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

Every sentence adds value. It is front-loaded with the core action and expands on side effects and batch shape. Slightly long but appropriately detailed.

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 provides return shape and error handling. Covers prerequisites, side effects, and batch behavior. Complete for a mutation tool in a complex domain.

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 coverage, the description adds rich meaning: items array structure, how to obtain transaction_id and category_id from other tools. It compensates well for the schema's lack of descriptions.

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

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

The description clearly states the tool corrects transaction categories via PATCH /transactions/:id, mentioning source IDs from sibling tools. It distinguishes from list tools and other updates.

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

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

The description explicitly states when to use: to fix miscategorized transactions and teach the system. It describes batch behavior and side effects, though no explicit when-not-to use.

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

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

Annotations declare idempotentHint=true and destructiveHint=false; the description adds the requirement to include conversation data. It does not disclose any other behavioral traits like effects after reporting, but complements annotations adequately 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 a single concise sentence that covers the main purpose and a key instruction. It is efficient but lacks additional structured detail, earning a high score for its brevity.

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 feedback tool, the description should specify the outcome (e.g., ticket creation) and any prerequisites. It fails to provide this, leaving the tool's full behavior unclear.

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

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

Schema description coverage is 0%, so the description must explain parameters. It only mentions the 'conversation' parameter, omitting explanations for the required 'message' and optional 'context', leaving key parameters underdefined.

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 reports bugs, missing features, or feedback. It specifies a unique action distinct from sibling finance and authentication tools, making its 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 advises including the conversation array for reproduction, offering contextual guidance. It implies use for reporting issues but does not explicitly state when not to use or list alternatives, though the context of siblings makes it 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. The description adds specificity that the tool shows both platform and adapter versions, which is valuable beyond the 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?

Single sentence, front-loaded, no wasted words. Every word is necessary.

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 is very simple with no parameters and no output schema. The description adequately covers what the tool does. Given the low complexity and robust annotations, it 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?

No parameters. Schema coverage is 100% (empty schema). Baseline for zero parameters is 4, and description does not need to add anything about parameters.

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

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

Description clearly states the verb 'Show' and the specific resource 'current MCP platform and adapter versions'. It is distinct from all sibling tools, which focus on authentication, finance operations, etc.

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 guidance on when to use this tool versus alternatives. However, given its simple nature and zero parameters, the usage context is implied. A higher score would require stating that it's for checking version info without side effects.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds specific output details (MCPs, connection status, catalog counts) without contradicting annotations, providing useful behavioral context.

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

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

The description is a single sentence that efficiently conveys the tool's purpose and output 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?

Despite lacking an output schema, the description sufficiently explains what the tool returns. Given the tool's simplicity, 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 the schema has 100% coverage. Per guidelines, baseline is 4, and no additional parameter semantics are needed.

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

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

The description clearly states the tool returns toolkit state including installed MCPs, connection status, and catalog tool counts. It is specific and distinct from sibling tools that focus on openfinance 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?

While the description implies use for checking toolkit status, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria. However, as a simple status tool, it is reasonably clear.

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