Rico MCP

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

Discloses that calling with no args returns a link, and passing token authenticates for session. Annotations already indicate idempotency; description adds flow details 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?

Three sentences cover all necessary info. Good front-loading. Could be slightly more structured (e.g., bullet points for methods), but still 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?

Covers main uses and two authentication paths. Lacks output format details (e.g., success/error message when token is passed), but adequate for a simple auth tool.

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

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

Schema coverage is 0%, but description fully explains the token parameter: its purpose (JWT for session login), that it's optional, and what happens when omitted (get link).

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 authenticates an MCP.AI IDE agent, specifying two methods (permanent config token or session token). It distinguishes from sibling tools by focusing solely on 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?

Provides clear context on when to use (for logging in) and how to use (with or without token, config vs session). Does not explicitly exclude alternatives, but siblings are unrelated.

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

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

Annotations already indicate readOnlyHint and idempotentHint true. The description adds behavioral details: when all providers are connected, returns authenticated:true and empty pending; otherwise returns connect URLs. 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, no wasted words. Front-loaded with action and resource, then details scenarios. Highly concise.

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

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

Given zero parameters, rich annotations, and no output schema, the description fully covers return values and main scenarios. No 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?

No parameters exist, so description doesn't need to add param info. Schema coverage is 100% (trivially). Baseline for 0 params is 4.

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

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

The description clearly states the tool returns connection status and URLs, with specific behavior based on provider connection state. It distinguishes from siblings like 'authenticate' and 'openfinance_list_connections' by specifying what it returns.

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

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

The description implies usage for checking connection status, especially when credentials are missing. It does not explicitly state when not to use or name alternatives, but context from siblings provides enough contrast.

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 discloses key behaviors beyond annotations: invoke works even if MCP not installed, returns connect/checkout links, requires owner/admin for writes, and explains install vs invoke. 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?

Description is long but well-structured with front-loaded purpose and a clear flow. Some redundancy could be trimmed, but overall efficient for the complexity.

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

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

Given 13 parameters, multiple actions, and no output schema, the description provides thorough guidance on usage, auth, payments, and permissions, making it complete 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 description explains main parameters (action, mcp_id, tool_id, arguments) in context of the flow. However, many parameters (limit, query, message, etc.) are not explicitly described, so partial compensation.

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

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

The description clearly states the tool is the official MCP marketplace, with verbs like search, describe, invoke, install, etc., and distinguishes it from sibling tools by emphasizing it's the primary entry point for discovering and running MCPs.

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 this tool FIRST before any external registry, and outlines the core flow (search → describe → invoke) with clear distinctions between invoke (one-off) and install (permanent), and when to use each.

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

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

Annotations already mark destructiveHint=true. The description adds that deletion makes data unavailable and returns an add_connection_url for reconnection, providing useful behavioral context beyond the 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?

The description is two sentences long with no unnecessary words. It front-loads the primary action and outcome, then adds the return value. Every sentence serves a purpose.

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

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

The description explains the action and return value, which is adequate for a simple destructive tool with one parameter. However, the lack of parameter documentation and no explanation of response format or error states leaves minor gaps, especially given no output schema.

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

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

The single required parameter 'item' has no description in the schema (0% coverage) and the tool description does not clarify what 'item' represents (e.g., connection ID, bank identifier). The description mentions 'specific bank' but fails to map it to the parameter, leaving the agent with no guidance.

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

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

The description clearly states it revokes consent and deletes connection data for a specific bank, making data unavailable. It distinguishes from sibling tools like openfinance_list_connections (listing) and openfinance_force_sync (syncing) by specifying the destructive action and return of a re-connection URL.

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

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

The description does not explicitly state when to use this tool vs alternatives, such as openfinance_list_connections or openfinance_force_sync. There is no guidance on prerequisites (e.g., having an active connection) or caveats about irreversibility beyond the destructiveHint annotation.

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 consistent (no destructive hint, not read-only). Description adds key behavioral details: waits up to 60s, polls until done, returns final status and synced flag, and explains error conditions. No contradiction.

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

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

Description is relatively long but efficient, front-loading the core purpose. Every sentence adds value, though minor redundancy could be trimmed. Still, structure is clear and well-organized.

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

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

Despite no output schema, description provides complete return format (results, errors, status fields) and handling instructions. Covers error states, timeouts, and next steps. Fully adequate for tool usage.

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

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

Schema coverage is 0%, so description carries full burden. It thoroughly explains both parameters: 'wait' as boolean for blocking vs fire-and-forget, and 'items' as array of selectors with allowed formats (item_id, connector_id, connector_name) and behavior when omitted.

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

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

The description clearly states the verb 'force sync' and the resource 'bank connections', specifying that it re-syncs and waits for completion. It distinguishes from siblings by focusing on forced synchronization with waiting and returning results.

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 (stale balance/transactions), provides alternative without disconnecting, explains parameter usage (items array, wait=false for fire-and-forget), and gives guidance on handling results (needs_action, timed_out).

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds value by detailing the response shape, error handling (structured warning instead of throwing), and real-time nature, which goes 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 three sentences with no wasted words. It front-loads the purpose and endpoint, then covers usage, error behavior, and response shape concisely.

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

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

For a single-parameter tool with no output schema, the description is complete. It covers input constraints, error handling, response structure, and a specific edge case (CREDIT accounts). No gaps are apparent.

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

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

With 0% schema description coverage, the description compensates well by explaining that account_ids is an array of strings, limited to 1-50 items. This adds critical constraints and meaning beyond the schema.

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

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

The description clearly states the tool returns real-time balance per account id via a specific endpoint (GET /accounts/:id/balance). It distinguishes from siblings like openfinance_get_accounts_detail and openfinance_list_accounts by focusing solely 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 the input format (array of account_ids, 1-50) and notes that CREDIT accounts may return a BALANCE_FETCH_ERROR with a warning. It does not explicitly say when to use this tool versus alternatives, but the purpose is clear enough that no confusion arises.

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 safety profile is clear. The description adds the batch shape and array limit but doesn't disclose additional behaviors like error handling or authentication. For a tool with strong annotations, this is adequate but not exceptional.

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 plus a short note on batch shape. Every word is functional; no fluff. It is front-loaded with the key action and resource.

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 one parameter and no output schema, the description covers the purpose, parameter constraints, and return shape ('{ results, errors }' batch). It is complete given the low complexity.

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

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

With 0% schema description coverage, the description compensates by explaining that `account_ids` must be an array of 1–50 items. It doesn't elaborate on what each string represents (account IDs), but the purpose makes it obvious. This adds value 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?

The description clearly states the tool returns full account objects with extended creditData per ID, and distinguishes itself from list-level siblings by specifying a batch detail operation. It includes the endpoint and confirms the batch shape.

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 to pass `account_ids` as an array of 1–50, which suggests when to use this tool for specific accounts. However, it does not explicitly contrast with list_accounts or other alternatives, but the sibling list offers enough context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds crucial behavioral context: the API does not return a paid/status field, and explains how payments[] relate to billing cycles in Brazilian Open Finance. No contradiction with annotations.

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

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

The description is somewhat long but front-loads the core purpose. Every sentence provides unique value (fields, exclusions, cross-bill semantics). Minor redundancy could be trimmed, but overall efficient for the complexity.

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

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

Given no output schema, the description fully specifies return shape (financeCharges, payments[] with fields, {results,errors} batch shape), what is omitted (individual transactions), and includes important behavioral notes (no paid/status field, payment cycle meaning). Complete for a bill detail 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?

Only one parameter (bill_ids) with 0% schema description coverage. The description fully compensates by explaining it must be an array and instructing to use openfinance_list_credit_card_bills first to discover valid IDs, adding essential usage context beyond the schema.

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

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

The description begins with a clear verb ('Returns') and resource ('bill-level detail for one or more credit card bills by id'). It lists specific fields (financeCharges, payments[]) and distinguishes from sibling tools that list bills or transactions.

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

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

Explicitly tells when to use (get bill detail), when not to (not for individual transactions), and names alternatives (openfinance_list_transactions for itemized transactions, openfinance_list_credit_card_bills for discovering IDs and payment status). The note about payments[] not implying payment status prevents misuse.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds valuable context: it returns 'status, executionStatus, and connector metadata', and explains the two modes of operation. 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, front-loaded with purpose, then usage. No extraneous 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?

For a simple read tool with one optional parameter, the description covers purpose, usage modes, and return content (status, executionStatus, connector metadata). No output schema exists, but the description gives enough for the agent to anticipate the response. Could elaborate on the exact response structure.

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

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

With 0% schema description coverage, the description fully explains the `item` parameter's effect: omission returns all, inclusion returns a single bank. It adds clear meaning beyond the schema's type definition, though it could specify the expected format (e.g., connection ID).

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

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

Clearly states the tool returns the current status of a bank connection, distinguishing between two use cases: omitting `item` returns all linked banks, passing `item` returns a single bank. The verb 'Returns' and resource 'bank connection status' are specific. Differentiates from siblings by focusing on 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 guidance on when to omit vs. pass `item`, but does not mention when not to use the tool or contrast with siblings. The context is clear enough for the agent to decide the appropriate mode.

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, and destructiveHint=false, so the tool is safe and idempotent. The description adds critical behavioral context beyond annotations: it explains that CREDIT balance meaning is connector-dependent and should not be treated as 'this month's bill'. It also clarifies the meaning of `creditData.balanceCloseDate` and `balanceDueDate`. No contradiction with annotations.

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

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

The description is relatively long but packs dense, useful information. It front-loads the core purpose ('Returns accounts for a bank connection...'). Every sentence adds value, including caveats about credit balance and the distinction between name and bank. Some sentences are complex and could be broken down for easier scanning, but overall it's 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?

Given the tool's 2 optional parameters, no output schema, and the complexity of credit card balance semantics, the description covers all necessary aspects: parameter usage (item omission vs. inclusion), return fields (balance, number, type, subtype, bankData, creditData, bank, connector_id, item_id), critical caveats (credit balance meaning), and cross-reference to a sibling tool for standardized billing data. It is complete and actionable.

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 2 parameters (`item` and `type`) with 0% description coverage, so the description must compensate. It does explain `item` thoroughly (omit vs pass, aggregation behavior) and mentions `type` indirectly by listing 'BANK (checking/savings) and CREDIT (credit card)' as the account types returned. However, it does not explicitly state that `type` is a filter parameter; it only describes the return values. Slightly more explicit parameter mapping would improve clarity.

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

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

The description clearly states that the tool returns accounts (BANK and CREDIT) with specific fields like balance, number, type, subtype, bankData, and creditData. It distinguishes between the legal entity name and the brand (bank), which is a key nuance. It also implicitly differentiates from sibling tools like openfinance_list_credit_card_bills by noting when to use that tool instead.

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

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

The description explicitly explains when to omit the `item` parameter (to list accounts across all linked banks) and when to pass it (to target a single bank). It provides a concrete usage scenario: 'use this when the user asks for 'my accounts/cards' without naming a bank'. It also warns against misinterpreting credit card balance and directs to openfinance_list_credit_card_bills for standardized billing amounts.

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

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

The description adds value beyond annotations by disclosing caching behavior, the single aggregated response nature, and the structure of entries. It complements the readOnlyHint, idempotentHint, and destructiveHint 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 (four sentences) and each sentence earns its place: it states the purpose, caching, field details, and a usage tip. No extraneous information.

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

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

Given no output schema, the description provides a clear picture of the expected output (fields and their meanings). It covers the essential aspects for a simple taxonomy retrieval tool, though it could hint at the response format (e.g., array vs. object).

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

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

With zero parameters and 100% schema coverage, the description's focus on the output structure is appropriate. It explains the meaning of each field (id, description, etc.) and their usage, which is helpful 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 the tool returns Pluggy's transaction category taxonomy, cached for the session. It specifies the content of each entry (id, description, descriptionTranslated, parentId, parentDescription) and notes it's a single aggregated response, distinguishing it from batch operations.

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

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

The description indicates that the `id` field is used by `openfinance_update_transaction_category`, implying this tool is a prerequisite. It also advises preferring `descriptionTranslated` for pt-BR users. However, it does not explicitly contrast with other list siblings or state when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the return fields but does not disclose any additional behavioral traits beyond what annotations provide. 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?

One sentence, front-loaded with the action and resource, and efficiently lists key fields. 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?

With no output schema, the description provides the main return fields (connector_id, item_id, bank name, add_connection_url). It does not specify format or array nature, but it is sufficient for a simple list 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?

There are no parameters, and schema coverage is 100%. Per scoring guidelines, 0 parameters gives a baseline of 4. The description does not need to add parameter info.

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

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

The description clearly states the tool returns saved bank connections for the install and lists the specific fields (connector_id, item_id, bank name, add_connection_url). It distinguishes from sibling list tools by specifying 'bank connections' as the resource.

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

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

The description implies usage for viewing connections and provides a hint about linking additional banks via the widget, but does not explicitly state when to use it over alternatives or list exclusions. No sibling comparison 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?

Adds extensive behavior beyond annotations: explains derived payment_status logic (including PAST_DUE_UNCONFIRMED), connector asymmetry, that results are summaries not transactions, and that it returns a warning instead of failing if CREDIT_CARDS is disabled.

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 very long and lacks structure (e.g., bullet points or sections). Important details are present but dense, reducing readability and quick comprehension.

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 (5 params, no output schema, important semantics), the description covers all key aspects: return fields, derived status, open bill feature, connector asymmetry, bulk support, and sibling tool references.

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 include_open_bill parameter is well-explained. However, page and page_size are not described despite 0% schema coverage. account_ids is mentioned but not detailed. Partial compensation lowers the score.

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: 'Returns CLOSED credit card bills for a CREDIT-type account', listing specific fields (dueDate, totalAmount, etc.). It distinguishes from siblings by explicitly advising to use openfinance_list_transactions for itemized purchases.

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 and when-not-to-use guidance, including alternative tools (openfinance_list_transactions), the opt-in nature of include_open_bill, and warnings about interpreting payment_status over raw payments[].

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: graceful error handling (returns structured response instead of throwing) and response shape including warning field, which goes beyond annotations.

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

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

Description is front-loaded with core purpose, then lists asset types and response fields. It is fairly concise for the detail it provides, though some response detail could be moved to an output schema if available. Not overly verbose.

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

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

While output details are covered, the description fails to explain input parameters (item, page, type, page_size), leaving the agent guessing how to invoke the tool. No clarification of pagination or what 'item' refers to, which is essential given no output schema and limited annotations.

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

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

Input schema has 4 parameters (item, page, type, page_size) with 0% description coverage, but the tool description provides no explanation of their meaning, usage, or defaults. This is a critical gap for correct invocation.

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 it returns investment portfolios for connections with INVESTMENTS enabled, lists specific asset types and data fields, and distinguishes from sibling tools by focusing on portfolio overview rather than transactions or regular 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 implies usage for obtaining investment portfolio data but does not explicitly compare with sibling tools like openfinance_list_investment_transactions or state when to use alternatives. No direct guidance on 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 already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by detailing the types of transactions returned, the fields included (e.g., agreedRate, expenses), and bulk support. It does not contradict annotations and provides useful behavioral context 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 concise with two paragraphs: the first detailing the output fields and purpose, the second mentioning bulk support. It is front-loaded with key information and contains no fluff, though it could be slightly more structured around pagination.

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 (list with many fields), the description covers the return fields and relationships (e.g., via openfinance_list_investments). However, it lacks details on pagination behavior (page, page_size) and does not explain the output format or any rate limits. With no output schema, more info on the response structure would improve completeness.

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

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

Schema has 4 parameters with 0% description coverage. The description explains that investment_id is required and investment_ids supports bulk, but does not describe page and page_size. Since page and page_size are standard pagination parameters, the description partially compensates for missing schema descriptions 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 a specific investment position, listing transaction types (BUY, SELL, etc.) and specific data fields (quantity, value, expenses). It distinguishes itself from siblings like openfinance_list_investments by stating it should be used after that tool to get the 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?

The description explicitly advises to use this tool after openfinance_list_investments to obtain the investment_id, and mentions bulk support via investment_ids. It does not explicitly state when not to use it or name alternatives, but provides clear context for usage.

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

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

Discloses GET method, sequential execution, and return format '{ results, errors }'. Adds rate-limit spacing context beyond annotations which already note read-only and idempotent 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?

Single, well-structured sentence that efficiently conveys purpose, usage, and special behavior without 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?

Covers return format and sequential execution. Could include pagination or error detail, but given no output schema and tool complexity, it is reasonably 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?

Input schema only defines 'items' as an array of strings. Description explains they are connection selectors (item_id uuid, connector_id, connector_name) and the effect of omitting the parameter, adding crucial 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?

Description clearly states the action 'Lists loan contracts per bank connection' and specifies the HTTP endpoint. It differentiates from sibling list tools by focusing on loan contracts.

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 usage modes: pass 'items' for specific connections or omit for all banks. Mentions sequential querying with rate-limit spacing. Does not compare to other list tools or state 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 already declare safe read-only. Description adds: CREDIT PENDING/POSTED variance by connector, error return format, aggregation limit with search, bulk execution, and sync failure indicators. All 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?

Front-loaded with purpose, then logical subsections on CREDIT specifics, filtering, pagination, error handling, bulk support. Every sentence adds value with 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?

Covers input parameters, edge cases (zero results, truncated), relationship to siblings, and error handling. Lacks explicit output schema but mentions key output fields. Sufficient for a complex financial 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 coverage, description adds meaning for from/to (ISO format), search_queries (case-insensitive, OR), and pagination (max 500). However, page and page_size formats are implied but not explicitly described, and account_ids lacks detailed 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?

Clearly states it returns transactions for BANK/CREDIT accounts. Explicitly differentiates from sibling tools: for CREDIT accounts it's the only way to get itemized transactions, and contrasts with openfinance_list_credit_card_bills for standardized totals.

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

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

Provides explicit when-to-use (CREDIT itemized transactions), when-not (use openfinance_list_credit_card_bills for totals), and troubleshooting (check connection health if total=0). Also advises to narrow date range if truncated.

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. Description adds valuable context: it resolves accounts internally, caps at 5000 transactions per account with a truncation flag, and notes that raw granularity is heavier. Does not mention idempotency from annotations, but no contradiction.

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

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

Description is moderately long but front-loaded with core purpose. Every sentence adds value, though some details (like listing return fields) could be more structured. Minor redundancy in explaining the compact summary twice.

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 explains return format: compact summary with total entradas/saídas/saldo_liquido, monthly evolution, top expenses/revenues, and per-account breakdown, plus truncation flag. It also explains raw granularity gives consolidated transactions. Lacks details on nested structures like by_account and por_mes, and does not specify the response format for raw rows.

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 explain all 6 parameters. It covers item, from, to, granularity, and type explicitly, but top_n is only implied as 'largest N each' without naming the parameter or specifying its type. This is a clear omission for a required parameter (though optional, it still needs explanation).

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 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call.' It specifies the verb 'analyze' and resource 'connection transactions', and distinguishes from sibling tools like openfinance_list_accounts by noting that you do not need to call that 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 tells when to use (for anual/mensal analysis, cash flow, etc.), when to omit item for all banks, and when to use granularity raw. It also provides context on avoiding separate account listing calls.

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, ensuring the agent knows this is a safe read operation. The description adds valuable behavioral context: checks a public status page, returns global indicator, degraded components, open incidents, and flags incidents affecting connected banks. 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 paragraph with a clear front-loaded purpose, followed by usage guidance and return details. It is efficient but could be slightly more concise by reducing some redundant phrases. Nonetheless, it is well-organized and 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 parameters and no output schema, the description provides complete information: what the tool does, when to use it, and what it returns (global indicator, degraded components, open incidents, and affected banks). No gaps or missing context.

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

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

The tool has zero parameters, so the description does not need to add parameter meaning. Baseline for 0 parameters is 4. The description focuses on the tool's behavior and output, which is appropriate.

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

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

The description states the tool checks the LIVE operational status of the Open Finance provider, with a specific verb and resource. It clearly distinguishes from the sibling tool openfinance_get_item_status by explaining the provider-side health focus versus connection-specific status.

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

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

The description explicitly outlines when to use the tool: when data looks incomplete or stale despite an UPDATED connection. It contrasts with the sibling tool and explains how it helps diagnose provider-side problems versus connection issues. However, it does not explicitly state when not to use it.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context beyond annotations: it explains plan-based filtering (PF/PJ), output details (connect_url, linked connections), and the exact behavior when keywords are missing. No contradiction with annotations.

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

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

The description is relatively long but every sentence adds value: it defines input, output, behavior, and usage guidance. It is front-loaded with the core action. Could be slightly tightened but is well-structured for the information provided.

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 performs a search with filtering, plan-based visibility, and returns multiple fields including a ready connect_url, the description is comprehensive. It covers input constraints, output summary, default behavior, and use case. No output schema exists, so the description compensates well.

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% (no parameter descriptions in schema). The description compensates by explaining that keywords[] is an array of strings (e.g., ['nubank','btg']) and is REQUIRED, and that include_accounts controls presence of accounts in response. This adds meaning beyond property names.

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 for bank connectors by name, specifying the input (keywords array) and output fields (connector id, access, audience, linked connections, connect_url). The verb 'searches' and resource 'bank connectors' are specific. It distinguishes from siblings (e.g., openfinance_list_connections) by its search-and-filter 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 explicitly instructs 'Call this BEFORE connecting to hand the user a one-click link' and warns that keywords[] is required, returning a hint otherwise. It implies the tool is for pre-selection before connection. While it doesn't list explicit alternatives, the context and sibling names provide enough differentiation.

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 that it overrides automatic categorization, teaches Pluggy by creating a Category Rule, and explains batch behavior with per-item errors. Annotations (destructiveHint=false) are not contradicted. Output shape is specified.

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?

Dense paragraph with all necessary info; every sentence adds value. Could benefit from slight structuring (e.g., bullet points), but not overly verbose.

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

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

Comprehensive for a mutating batch tool with no output schema: covers input, side effects, response format, and error handling. No gaps identified.

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 that transaction_id comes from openfinance_list_transactions and category_id from openfinance_list_categories, and detailing the batch structure.

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

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

Description clearly states 'Corrects the category of one or more transactions' with HTTP method and path, and distinguishes from sibling tools by referencing openfinance_list_transactions and openfinance_list_categories as sources for IDs.

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

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

Provides explicit context for use: fixing miscategorized transactions and improving accuracy. Explains side effect of creating Category Rules for future similar transactions. Missing explicit 'when not to use', but clear enough.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false, and description adds that it reports bugs (a write operation). No contradictions, but description adds minimal behavioral detail 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 with no extraneous information. Front-loaded with the core purpose.

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

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

For a simple 3-parameter tool with no output schema, the description covers basic usage but lacks details on response handling, errors, or post-report behavior.

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 explaining the 'conversation' parameter's purpose. However, 'context' and 'message' are not elaborated, leaving gaps.

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

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

The description clearly states the tool's purpose: reporting bugs, missing features, or sending feedback. It distinguishes from sibling tools which are mostly finance or authentication related.

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

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

The description implies usage for bug/feedback reporting and instructs to include the conversation array, but does not provide explicit when-to-use versus alternatives or when-not scenarios.

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 that it shows both platform and adapter versions, but provides no further behavioral details beyond what annotations convey.

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

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

Single sentence, 10 words, directly states the purpose. No waste, front-loaded, and perfectly concise.

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 is provided, and the description only says 'Show...versions' without specifying the return format (e.g., string, object). For a simple version tool, this is adequate but could be clearer.

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 schema coverage is 100%. The description does not need to elaborate on parameters. Baseline score of 4 is appropriate.

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

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

The description 'Show the current MCP platform and adapter versions' uses a specific verb ('Show') and resource ('platform and adapter versions'), clearly distinguishing it from sibling tools 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?

The tool is self-explanatory—use it to check current versions. No explicit when-not or alternatives are needed, as sibling tools are functionally distinct. The description implies usage for debugging or compatibility checks.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds specific return details (installed MCPs, status, catalog counts), which is useful 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 sentence that is front-loaded with action verb 'returns' and specifies exact resource and fields. 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 0 parameters and no output schema, the description fully explains what the tool returns in sufficient detail for a simple info tool.

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

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

No parameters exist, so full schema coverage; description adds no param info but none is needed. Baseline 4 for 0 params.

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 current toolkit state including installed MCPs, connection status, and catalog tool counts, distinguishing it from sibling tools that perform different 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?

While no explicit when-not or alternatives are given, the tool is unique among siblings as a meta-info tool, so usage context is implicit and clear.

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