Player's Bank MCP

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

Annotations indicate idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds context beyond annotations by explaining token usage, session vs permanent modes, and browser login flow. It 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?

The description is a single paragraph but efficiently front-loaded with audience and purpose, then presents best practice and alternative usage. Every sentence adds value with no redundancy.

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

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

For a simple authentication tool with no output schema, the description covers input options and usage scenarios well. It lacks explicit info about return values (e.g., success message or token confirmed), but given the tool's straightforward nature, it is mostly 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 single parameter 'token' has 0% schema description coverage. The description fully explains its meaning: it's the JWT access token from browser login, optional, and can be omitted to get a login link. This adds necessary semantic meaning.

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

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

The description clearly states the tool's purpose: to authenticate for MCP.AI IDE agents. It uses specific verb 'log in' and 'authenticate' and distinguishes from sibling tools like 'connect' and 'marketplace', which are not 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?

The description provides explicit guidance on when and how to use the tool: best practice to add token to config for permanent connection, or paste token for session-only login. It also explains how to call with or without the token parameter, and gives 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, destructiveHint. Description adds meaningful behavioral context: details response fields (authenticated, pending, connect_url) and explains the two distinct states. This provides value beyond annotations.

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

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

Two sentences, no wasted words. The first sentence states the main purpose, and the second explains the two response cases. Perfectly front-loaded and efficient.

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

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

The description explains response content for the two main states, but does not cover partial connections or error scenarios. Given the tool's simplicity and lack of output schema, the description is fairly complete but could be slightly more 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?

No parameters exist, so baseline is 4. There is no need for additional parameter information, and the description does not need to compensate for missing schema details.

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

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

Description clearly states the tool returns connection status and URLs, with specific cases for all connected vs missing credentials. Verb 'returns' and resource 'connection status' are precise, and the binary case explanation distinguishes it from authentication or listing 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?

Usage is implied as a health-check or status tool, but there is no explicit guidance on when to use versus alternatives like 'authenticate' or 'openfinance_list_connections'. No exclusion criteria or when-not-to-use instructions 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?

The description discloses key behaviors beyond annotations: that invoke can run tools without installing, that write operations require owner/admin, and that credential/payment issues return connect/checkout links. These add significant context not captured in 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 lengthy but well-organized, front-loading the core flow and key distinctions. Each sentence adds value, though some details (e.g., reporting bugs) could be condensed. Overall, it is appropriately sized for the tool's complexity.

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

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

Given the tool's complexity (13 parameters, multiple actions, no output schema), the description covers high-level flow and behavioral notes but lacks detailed parameter documentation. It provides enough context for basic usage, but the agent would need additional information to correctly invoke all actions with proper parameter values.

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 burden on the description is high. However, the description only explains a few parameters (action, query, mcp_id, tool_id, arguments) implicitly through the core flow. Parameters like limit, immediate, tier_slug, conversation, request_name, etc., are not given any semantic meaning, leaving the agent to guess their purpose.

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

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

The description clearly identifies the tool as the official marketplace for discovering and running MCPs/tools. It specifies the verb-resource relationship and distinguishes it from sibling tools by outlining the core flow (search, describe, invoke) and when to use each action.

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

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

The description explicitly states to use this tool FIRST for capability discovery, and contrasts it with alternatives like report_bug and request_mcp. It provides clear guidance on when to use invoke vs install, and mentions prerequisite conditions (owner/admin for writes).

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

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

Annotations already set destructiveHint=true, and the description adds context about data deletion and return of an add_connection_url, providing useful behavioral insight 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 concise sentences front-load the action and outcome, with no extraneous 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 tool with one parameter and destructiveHint annotation, the description is largely complete, but could specify the parameter format and any side effects beyond data deletion.

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 fails to explain what the 'item' parameter represents (likely a bank identifier), leaving a significant gap for agent 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 revokes consent and deletes connection data for a specific bank, distinguishing it from sibling tools like openfinance_list_connections which are read-only.

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

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

The description implies usage for disconnecting a bank, but does not explicitly state when to use versus not use it, nor mention prerequisites. However, context is clear given the unique action.

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 beyond annotations by explaining the polling mechanism, timeout (~60s), return fields (status, executionStatus, lastUpdatedAt, etc.), error conditions, and implications of needs_action and timed_out.

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 with all info, well-organized and front-loaded. Each sentence adds value, but slightly lengthy; still appropriate for the detail.

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?

Comprehensive coverage: explains return structure, error handling, and usage scenarios. No output schema, but description fully explains what the tool returns and what to expect.

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

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

Adds significant meaning beyond schema: items accepts selectors (item_id, connector_id, or connector_name) and can be omitted for all banks; wait controls fire-and-forget behavior. Schema coverage 0%, description 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?

Clearly states it forces a bank re-sync and waits for completion. Distinguishes from siblings by specifying it pulls fresh data without disconnecting, and contrasts with openfinance_get_item_status for re-checking.

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

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

Explicit when-to-use: 'when a balance or transaction list looks stale'. Provides guidance on omitting items for full sync, setting wait=false for fire-and-forget, and alternative tool for re-check.

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

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

Beyond annotations (readOnlyHint, destructiveHint), it discloses real-time behavior, potential BALANCE_FETCH_ERROR for certain accounts, structured warnings instead of exceptions, and the response shape with results and errors.

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 cover purpose, usage, and special cases. No redundant words, all essential information 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?

Despite missing output schema, the description fully specifies the response shape and handles the main edge case (CREDIT account errors). It provides sufficient context for a balance retrieval 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?

With 0% schema description coverage, the description adds value by clarifying that account_ids is an array and limiting it to 1-50 items. It also states the return format, which is absent from 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 a real-time balance payload per account id, referencing the specific HTTP endpoint. It distinguishes from sibling tools like openfinance_list_accounts (which returns account details) 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?

It specifies the required parameter account_ids as an array of 1-50 and describes the error handling for CREDIT accounts. However, it does not explicitly state when not to use this tool compared 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not repeat that. It adds value by disclosing the batch response shape ({ results, errors }), indicating partial success handling. 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 sentences, front-loaded with the core purpose and ending with parameter details and output shape. Every sentence is essential; 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 one parameter and no output schema, the description covers the tool's purpose, parameter constraints, and output shape. It is sufficient for an agent to invoke correctly, though it could mention that this is specifically for multiple accounts (batch).

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 the burden. It explains that account_ids is an array of strings with size constraint 1-50, and that it's used for batch retrieval. This adds essential meaning beyond the schema's type definition.

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

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

The description clearly states the tool returns full account objects with extended creditData, specifying the HTTP endpoint (GET /accounts/:id) and batch shape. It distinguishes from sibling list_accounts (which likely returns summaries) and get_account_balance (returns only balance).

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

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

The description implies usage for batch retrieval of full account details by ID array (1-50), but does not explicitly state when to use this tool over alternatives like list_accounts or get_account_balance. Usage context is implied but lacks explicit 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, idempotentHint=true, and destructiveHint=false. The description adds critical behavioral context: batch result shape, the absence of a paid/status field, and the nuanced meaning of payments[] (refers to previous bill). This goes beyond annotations and prevents misinterpretation.

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 comprehensive but somewhat lengthy. It is well-structured with front-loaded purpose, usage guidance, and caveats. Every sentence is valuable, but trimming redundant phrasing could improve conciseness without losing information.

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

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

Given the complexity (batch shape, payment nuance, reliance on sibling tools) and no output schema, the description covers all needed context. It explains return fields, references to discover IDs, and critical interpretation warnings, making it fully complete 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 one parameter (bill_ids) with 0% description coverage. The description explains it should be an array and that IDs come from list_credit_card_bills, adding meaning beyond schema. A higher score would require more detail on array format or constraints, but the explanation is adequate.

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

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

The description explicitly states the tool returns bill-level details for credit card bills by ID, listing specific fields. It distinguishes from sibling tools like openfinance_list_transactions and openfinance_list_credit_card_bills, making the purpose clear 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?

The description provides explicit guidance: use openfinance_list_credit_card_bills first to discover IDs, and openfinance_list_transactions for itemized transactions. It also warns about the interpretation of payments[] and directs to check paid status via another tool, offering clear when-to-use and when-not-to-use advice.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds detail that the tool returns executionStatus and connector metadata, and discloses the different return structures for all vs. single banks. This provides good behavioral context beyond annotations.

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

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

The description is two sentences, front-loads the core purpose and key details, and contains no unnecessary words. Every part earns its place.

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

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

For a simple status tool with annotations, the description covers the main behaviors and return structures. However, it does not detail the fields in the single bank response (e.g., exactly what connector metadata contains) and lacks an output schema, leaving minor 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?

The input schema has a single optional parameter `item` with no description (0% coverage). The description fully compensates by explaining its semantics: omit for all banks, pass for a single bank.

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 example status values like UPDATED and LOGIN_ERROR. It distinguishes between two modes (all banks vs. single bank), which sets it apart from sibling tools like openfinance_list_connections.

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

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

The description explicitly explains when to omit the `item` parameter (for all banks) and when to pass it (for a single bank). While it provides clear usage context, it does not explicitly compare to alternatives or mention when not to use this tool.

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

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

Description aligns with annotations (readOnly, non-destructive, idempotent) and adds critical context about CREDIT balance being connector-dependent, the meaning of `creditData` fields, and naming conventions. No contradictions.

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

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

The description is lengthy but well-structured, starting with the core function and then adding usage notes. Every sentence adds value, though some repetition could be trimmed slightly.

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 lists returned fields and explains key nuances (e.g., `name` vs `bank`, CREDIT balance limitations). It lacks a full nested structure specification but is sufficient for effective 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?

Although schema description coverage is 0%, the description fully explains both parameters: `item` (omit vs pass behavior) and `type` (BANK/CREDIT). This compensates entirely for the lack of schema descriptions.

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

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

The description clearly states it returns accounts for bank connections, differentiating between BANK and CREDIT types, and lists specific data fields (balance, number, type, subtype, bankData, creditData). It also explains the distinction between `name` and `bank`, making the tool's purpose precise and distinct from sibling tools like `openfinance_get_accounts_detail`.

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

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

Explicitly provides when to omit `item` (to list all linked banks) and when to pass `item` (target single bank). It also warns against treating CREDIT `balance` as the current bill and directs users to `openfinance_list_credit_card_bills` for standardized amounts, offering clear alternatives.

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

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

Discloses caching behavior and singles-response nature beyond annotations (readOnlyHint, idempotentHint, destructiveHint). No contradictions. Provides clear 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?

Efficiently structured with purpose first, then field details. Slightly verbose but every sentence adds value. Could be slightly more concise, but overall good.

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?

Fully explains return structure (fields, usage, language variants) and caching. No output schema, so description compensates well. Complete for a zero-parameter, read-only tool.

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

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

No parameters, so baseline of 4 applies. Description does not need to explain parameters, and it adds value by describing output fields.

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 'Pluggy's transaction category taxonomy' and specifies it's cached. Distinguishes from sibling list tools by focusing on category taxonomy, not transactions or accounts.

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

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

Mentions caching and that it's a single aggregated response, but does not explicitly state when to use this tool over alternatives. However, it implies its use for obtaining category IDs for updating transactions via openfinance_update_transaction_category.

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 the agent knows it is safe. The description adds value by disclosing the return structure (fields included) and the install-scoped nature, but does not cover potential edge cases like empty results or rate limits.

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

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

The description is a single, well-structured sentence that efficiently conveys the core purpose and output. 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 tool has no output schema, the description adequately describes the return fields (connector_id, item_id, bank name, add_connection_url). It does not mention error scenarios or edge cases, but for a simple list operation, it is sufficiently 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 zero parameters, so the baseline is 4. The description does not need to elaborate on parameters; it correctly focuses on the output.

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 for the current install, listing specific fields (connector_id, item_id, bank name, add_connection_url). It distinguishes itself from siblings like connect and openfinance_disconnect_bank by focusing on listing existing 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 the tool is for listing connections and mentions the add_connection_url for linking additional banks, but does not explicitly state when to use it versus alternatives or when not to use it. Still, the context from sibling tool names makes the usage 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds extensive behavioral context: it explains that results are bill-level summaries (not transactions), connector asymmetry, payment_status derivation, warning behavior, and the meaning of derived fields. 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 verbose but every sentence adds value. It front-loads the main purpose but embeds many explanatory details in the middle. While not overly concise, the density of information is justified by the tool's complexity. A slightly more structured format 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?

With no output schema, the description fully describes the return structure: closed bill fields, payments array, payment_status, and the optional open_bill structure. It also covers edge cases like connector asymmetry and warning behavior. No gaps remain for an agent to understand the tool's output.

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

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

Schema description coverage is 0%, so the description must explain parameters. It explains account_id (required), account_ids (bulk support), and include_open_bill (with detailed opt-in rationale). However, page and page_size are not described, though they are common pagination parameters. This gap prevents a score of 5.

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

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

The description clearly states it returns CLOSED credit card bills for a CREDIT-type account, listing specific fields. It distinguishes from siblings like openfinance_get_credit_card_bill and openfinance_list_transactions, making the tool's 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 when-to-use guidance, including Brazilian Open Finance semantics for payment_status, when to use include_open_bill, and when the open bill is unavailable. It also advises using openfinance_list_transactions for itemized purchases and warns against misinterpreting payments. Alternatives are clearly identified.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds useful behavioral context by detailing the fallback response on errors and listing the fields returned. No annotation contradiction.

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

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

The description is a single paragraph that packs many details but lacks structure. It is not overly long, but could benefit from clearer separation of parameter guidance, output description, and usage notes.

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 4 parameters and no output schema, the description provides a good overview of returned data and error handling, but omits parameter explanations and precise return structure, making it incomplete for accurate invocation.

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

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

Schema description coverage is 0%, yet the description does not explain any parameters (item, page, type, page_size). It mentions 'connection' but does not clarify which parameter corresponds. The list of fields in results is about output, not 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?

The description clearly states the tool returns the investment portfolio for a connection, listing specific asset types and attributes. It distinguishes from siblings like openfinance_list_investment_transactions by focusing on portfolio positions 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 indicates when to use the tool: for connections with INVESTMENTS product enabled. It implicitly guides against alternatives by listing what it returns, but does not explicitly state when not to use it 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 confirm read-only, idempotent, non-destructive. Description adds specific fields returned (quantity, value, expenses breakdown) and transaction types. No contradiction, and adds value beyond annotations, though could mention pagination behavior or limits.

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

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

Two concise sentences with front-loaded key information: purpose, output details, usage hint, and bulk support. 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?

With 4 parameters, no output schema, and moderate complexity, the description covers output fields well but misses pagination parameters and error handling. Adequate but has 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 has 4 parameters with 0% description coverage. Description only mentions investment_id and investment_ids, omitting page and page_size. Does not fully compensate 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?

Description clearly states the tool returns movement history for a specific investment position, listing transaction types and fields. It also explicitly distinguishes from sibling openfinance_list_investments by advising to use after that tool to obtain investment_id.

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

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

Provides clear usage context: use after openfinance_list_investments to get investment_id, and mentions bulk support with investment_ids. However, does not explicitly state when not to use or provide alternatives beyond the implicit sequence.

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 the annotations (readOnlyHint, idempotentHint), the description adds that connections are queried sequentially with rate-limit spacing and the return format (`{ results, errors }` per connection). No contradictions with annotations.

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

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

The description is two sentences, front-loaded with purpose, and every part adds value. 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?

Despite no output schema, the description mentions the return structure per connection. It covers the optional parameter and rate-limiting behavior, making it complete for an agent to 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 description coverage, the description fully compensates by explaining the `items` parameter format (array of connection selectors: item_id, connector_id, or connector_name) and the effect of omitting it.

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 lists loan contracts per bank connection (GET /loans). It distinguishes itself from sibling list tools by specifying the resource (loans) and the behavior with the `items` 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 provides explicit guidance on when to use the `items` parameter (for specific connections) and when to omit it (list across all banks). While it doesn't directly contrast with sibling tools, the purpose is specific enough to avoid confusion.

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 extensive behavioral context beyond annotations: PENDING vs POSTED variation per connector, search_queries aggregation up to 5000 with truncation warning, error handling returning structured response instead of throwing, and bulk support. 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 with clear sections, but slightly verbose. Front-loaded with core purpose, and every sentence adds value. Could be tightened, 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?

Covers all edge cases: credit card metadata linking to bills, search truncation, error handling, bulk support, and cross-tool guidance. No output schema but describes return structure (total, results, warning, error, truncated). 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?

Despite 0% schema coverage, the description thoroughly explains all parameters: from/to as ISO dates, pagination limits, search_queries semantics (case-insensitive substring, OR, truncation), and account_ids for bulk. Adds meaning absent from 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?

Clearly states it returns transactions for BANK or CREDIT accounts. For CREDIT accounts, explicitly notes it's the only way to get itemized transactions, distinguishing it from sibling tools like openfinance_list_credit_card_bills and openfinance_get_item_status.

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

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

Provides explicit when-to-use: for itemized credit card transactions; when-not: for open-bill total use openfinance_list_credit_card_bills; and troubleshooting: check connection health if total is 0, and force sync if 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, ensuring the agent knows it's safe. The description adds valuable behavioral details: internal account resolution, fan-out of transactions, default compact summary behavior, and a cap of 5000 transactions per account with a truncated flag.

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 but well-organized, front-loading the main purpose and then detailing parameters and options. It is concise given the amount of information, though it could benefit from slight structural improvements (e.g., bullet 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?

No output schema exists, but the description thoroughly explains the return format: total entradas/saídas/saldo_liquido, monthly evolution (por_mes), top despesas/recebimentos, per-account breakdown (by_account), and truncation flag. This is sufficient for an agent to decide when to use 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?

Schema coverage is 0%, so the description fully compensates by explaining all 6 parameters: item (connector_id, connector_name, or item_id; omissible for all linked banks), from/to (ISO dates), granularity (monthly vs raw with output differences), type (BANK or CREDIT), and top_n (implied in top_despesas/top_recebimentos).

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 performs consolidated cash-flow analysis for a bank connection over a period in one call. It uses specific verbs and resources and distinguishes from siblings by noting that it resolves accounts internally, so calling openfinance_list_accounts first is unnecessary.

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

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

The description provides explicit guidance on when to use the tool (for annual/monthly analysis, cash flow, top expenses/receipts) and when to use the 'raw' granularity (only when itemized rows are needed). It does not explicitly state when not to use, but the context is clear enough.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), description discloses that the tool returns global indicator, degraded components, open incidents, and affected banks. No contradictions with annotations; adds valuable 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?

Description is a single paragraph with 5 sentences, front-loaded with main purpose. Every sentence adds value, but could be slightly more concise without losing clarity.

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

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

For a parameterless tool with no output schema, description fully explains return values and usage context. Complete for the tool's simplicity.

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 (0 parameters, 100% schema coverage). Baseline for 0 parameters is 4. Description does not need to add parameter info, so score 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 checks the live operational status of the Open Finance provider's public status page, distinguishing it from openfinance_get_item_status which checks connection status. The verb 'checks' and specific resource 'provider status' make 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?

Explicitly advises use when data looks incomplete or stale despite an updated connection, to identify upstream outages. Directly contrasts with openfinance_get_item_status, providing clear when-to-use and when-not-to-use guidance.

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

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

The description adds several behavioral details beyond the readOnlyHint and idempotentHint annotations: it honors the user's plan (PF/PJ), returns a connect_url, and mentions the behavior when keywords are missing (returns a hint). 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 compact, front-loading the core action and returns. Each sentence adds value: what it does, what it returns, plan filtering, usage instruction, and keyword requirement. No wasteful phrases.

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 two-parameter schema without output schema, the description covers purpose, usage, parameter semantics, return value structure, and plan filtering. It addresses the 'before connecting' context and the behavior when keywords are omitted, making it fully helpful 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?

Schema coverage is 0%, but the description explains both parameters: keywords (array of strings, required in practice, with examples) and include_accounts (boolean). It adds the important context that keywords is effectively required and that include_accounts enables account details. While it doesn't provide exhaustive documentation, it compensates well for the lack of schema descriptions.

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

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

The description clearly states it searches bank connectors by name, returns connector details, and explicitly says 'Call this BEFORE connecting'. The verb 'searches' and resource 'bank connectors' are specific, and the scope (by name, with plan filtering) distinguishes it from sibling tools that list connections or accounts.

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

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

The description provides clear guidance: 'Call this BEFORE connecting'. It also specifies that keywords are required and without it a hint is returned. However, it does not explicitly mention alternatives for listing all connectors or other scenarios, which would strengthen the 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?

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description reveals key behaviors: overriding automatic categorization, teaching Pluggy via Category Rule creation, and batch error handling. This fully informs the agent about side effects and partial failure behavior.

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

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

The description is a single dense paragraph that conveys all necessary information without redundancy. While efficient, it could be slightly restructured for readability, but no information is wasted.

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 explicitly details the return shape (updated, results, errors) and error handling behavior (per-item errors don't fail the batch). This fully covers the agent's need to interpret the response.

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

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

Despite 0% schema description coverage, the description explains both parameters: transaction_id from openfinance_list_transactions and category_id from openfinance_list_categories. This adds essential context beyond the schema's type-only definitions.

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

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

The description clearly states the tool corrects the category of transactions, specifying the HTTP method and endpoint. It distinguishes itself from siblings by explicitly referencing openfinance_list_transactions and openfinance_list_categories as sources for IDs, making its role unique among update 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?

The description explains when to use the tool (to fix miscategorized transactions) and describes its side effect (creating a Category Rule). It does not explicitly state when not to use it, but the context and sibling names imply its specific purpose.

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 this is not read-only (readOnlyHint=false) and is idempotent (idempotentHint=true). The description adds that the conversation array should be included for reproduction, which is a usage detail rather than behavioral disclosure. It does not describe any side effects or required permissions beyond what annotations provide.

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

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

The description is two sentences long, with no wasted words. The first sentence states the purpose, the second provides a crucial usage hint. It is appropriately sized 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 3 parameters, no output schema, and annotations present, the description is somewhat minimal. It explains the purpose and gives one usage hint, but does not cover return values, error cases, or what happens after reporting. It is adequate but could be more comprehensive.

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

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

The schema has 3 parameters with 0% documentation coverage. The description adds meaning for the 'conversation' parameter by specifying its purpose (include recent messages for reproduction). However, it does not clarify 'context' or 'message' beyond their schema definitions.

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: reporting bugs, missing features, or feedback. It uses specific verbs ('Report') and identifies the resource (bug/feature/feedback). Among the sibling tools, this is the only feedback tool, so it distinguishes itself well.

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 use this tool: to report bugs, missing features, or send feedback. It also gives a usage hint to include the conversation array. However, it does not explicitly state when not to use it or mention any 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 indicate read-only, idempotent, non-destructive. Description adds that it reveals platform and adapter versions, which is useful context beyond annotations.

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

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

Single concise sentence, 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 zero-parameter, simple read tool, description fully covers behavior and output (version info). No output schema required.

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 adds no parameter-specific info, but none is needed.

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

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

Description clearly states it shows current MCP platform and adapter versions. Distinguishes well from siblings which are mostly 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?

No explicit when-to-use or alternatives, but for a simple version info tool the purpose is self-explanatory. Could be improved by noting it's useful for debugging or verifying setup.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's job is to add context. It does so by specifying what the returned state includes (installed MCPs, connection status, catalog tool counts), which is beyond the annotations. No contradiction 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 a single succinct sentence (13 words) that front-loads the key action and output. Every word is necessary; there is no wasted content.

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

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

Although there is no output schema, the description adequately specifies the return content (installed MCPs, connection status, catalog tool counts). Given the tool's low complexity and the rich annotations, the description is sufficient for an agent to understand what to expect.

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

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

The tool has zero parameters and schema description coverage is 100%, so the description need not add parameter information. Baseline 4 is appropriate because the description is not required to elaborate on nonexistent 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?

The description uses a specific verb 'Returns' and identifies the resource as 'the current toolkit state' with concrete details (installed MCPs, connection status, catalog tool counts). This clearly distinguishes it from sibling tools like 'show_version' or 'connect', which focus on different aspects.

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 a general status-checking purpose but does not explicitly state when to use this tool versus alternatives like 'show_version' or 'authenticate'. No exclusions or context are provided, leaving the agent to infer usage from the tool's purpose alone.

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