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=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context beyond annotations by describing the two possible response scenarios and what is returned. No contradiction.

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

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

Two sentences deliver all necessary information efficiently. Front-loaded with the main purpose, followed by specific scenarios. 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?

Despite no output schema, the description fully explains the return format and behavior for both success and failure cases. No gaps given 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?

Input schema has 0 parameters (100% schema coverage). Baseline 4 applies; description adds no param info but explains the output meaningfully, which is sufficient.

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 connection status and URLs, differentiating between successful connection and missing credentials. It specifies the return fields (authenticated, pending, connect_url) and distinguishes it from sibling tools like authenticate.

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 (check connection status) but no explicit guidance on when to use vs siblings like authenticate or openfinance_list_connections. No exclusions or alternatives provided.

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

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

Discloses key behaviors: invoke works even if MCP not installed, returns connect links for credentials, checkout links for payments. Notes permission requirements for writes (workspace owner/admin). 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 informative but lengthy; it covers many points in a single paragraph. Could benefit from bullet points or clearer segmentation, but the logical flow is coherent.

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

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

Covers purpose, workflow, edge cases (auth, billing, permissions), and alternative actions. Without an output schema, the description adequately informs about what each action returns (e.g., full profile, run results).

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

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

While the schema has 0% description coverage, the text explains the core parameters (action, query, mcp_id, tool_id, arguments) and their roles in the flow. It does not enumerate every parameter but compensates with contextual usage 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?

The description explicitly states it is 'THE official mcp.ai marketplace' and the primary tool for discovering and running MCPs. It clearly distinguishes itself from siblings by instructing to use this tool first before any external registry.

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 guidance ('When the user wants a capability... use THIS tool FIRST') and outlines a core flow (search → describe → invoke). Also specifies when to prefer invoke over install and mentions alternatives like report_bug and request_mcp.

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

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

The description goes beyond the destructiveHint annotation by detailing what is destroyed (consent, data) and what is returned (add_connection_url). This adds valuable context for the agent about the irreversible nature and the way to re-connect.

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: the first covers the core action and effect, the second covers the return value. No wasted words; information is front-loaded and easy to parse.

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 simplicity (one param, no output schema) and existing annotations, the description provides the essential purpose and effect. However, the lack of parameter documentation leaves a gap in completeness, as the agent must guess the input format.

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

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

The single parameter 'item' is left completely undocumented in the description. With 0% schema description coverage, the description fails to clarify what 'item' represents (e.g., bank ID). The agent must infer from context that it identifies the bank, but no explicit guidance is given.

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

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

The description clearly states the action ('revokes consent', 'deletes connection data') and the resource ('specific bank'), and it distinguishes from sibling tools like openfinance_list_connections (list) and openfinance_force_sync (sync). The consequence ('data will no longer be available') and return value are also specified.

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

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

The description implies usage (to disconnect a bank), but provides no explicit guidance on when to use this tool versus alternatives like connect or openfinance_list_connections. No when-not-to-use or prerequisites are mentioned.

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

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

The description discloses numerous behavioral details beyond annotations: polling mechanism, 60s timeout, return fields like synced, needs_action, timed_out, and wait parameter effects. 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 front-loaded with the core action and use case, then adds detailed behavioral and parameter info. While comprehensive, it is slightly long but every sentence adds value.

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

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

Given no output schema, the description explains the return format ({ results, errors }) and key fields. It addresses parameters, behavior, error conditions, and integrates with sibling tools, making it complete.

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

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

Schema coverage is 0%, but the description fully explains both parameters: wait (boolean for fire-and-forget) and items (array of selectors with examples like item_id, connector_id, connector_name, and omission means sync all).

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

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

The description clearly states the tool forces a bank to re-sync connections, distinguishes from siblings by explicitly mentioning alternatives like openfinance_get_item_status, and specifies it pulls fresh data without disconnecting.

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

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

It provides explicit when-to-use guidance ('when a balance or transaction list looks stale'), when-not-to-use (fire-and-forget via wait: false), and alternatives (checking with openfinance_get_item_status if 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, idempotentHint=true, destructiveHint=false. Description adds that it is real-time and mentions structured error handling (warning instead of throwing) and the response shape with results and errors arrays.

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

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

Four sentences, each containing essential information: purpose/endpoint, parameter usage, error handling, response shape. No unnecessary words.

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

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

For a simple read tool with one parameter and no output schema, description covers response shape, error cases, and parameter details. Missing information about authentication or rate limits, but these may be standard across tools.

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

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

Schema has 0% description coverage. Description adds that account_ids is an array with size constraint (1-50), but does not explain the format or what account_ids represent. Adds some value but not comprehensive.

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 'Returns real-time balance payload per account id' with the endpoint path. This specifies the verb (returns) and resource (balance per account id). Sibling tools like openfinance_get_accounts_detail and openfinance_list_accounts handle different resources, so this tool is well-distinguished.

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 parameter usage: 'Pass account_ids as an array (1–50)'. Also explains error handling for CREDIT accounts with BALANCE_FETCH_ERROR. However, does not explicitly state when to use this tool vs alternatives, though context with siblings implies 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 true, idempotentHint true, and destructiveHint false. The description adds behavioral details: it is a batch operation with a size limit (1-50) and returns a batch shape of { results, errors }, which is 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 concise with three sentences, covering the purpose, endpoint, input specification, and output shape without any unnecessary words.

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

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

Given no output schema, the description effectively explains the batch response shape { results, errors }. It covers the input constraint and the nature of the data returned. Could mention that each result is a full account object, but it is implied.

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

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

The input schema has 0% description coverage with no descriptions on the single parameter. The description adds that account_ids is an array (1-50), providing necessary context, but does not elaborate on the format of IDs or other constraints.

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, specifying it is a batch GET operation. It distinguishes from sibling tools like openfinance_list_accounts by mentioning 'extended creditData' and the per-ID endpoint.

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 to pass account_ids as an array (1-50), giving a clear usage constraint. It does not explicitly state when to use versus alternatives, but the context of 'full account objects' implies it is for detailed retrieval, unlike list_accounts.

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

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

Beyond annotations (readOnly, idempotent), description discloses important behavioral traits: Pluggy does not return a paid/status field, payments[] reflects payments registered during this bill's billing cycle (typically payment of previous bill), and returns batch shape { results, 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?

Description is front-loaded with main action, then provides caveats and usage guidance in a logical order. Every sentence adds value without redundancy. Length is appropriate 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 the complexity (batch operation, financial semantics, lack of output schema), the description covers return values (financeCharges, payments[] fields), batch shape, and important service-specific behavior. It is complete for the agent to use correctly.

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

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

Schema has 0% description coverage, but description compensates by explaining that bill_ids come from openfinance_list_credit_card_bills, and should be passed as an array. It gives context on how to obtain and use the parameter effectively.

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 'Returns bill-level detail for one or more credit card bills by id' and specifies returned fields (financeCharges, payments[] with subfields). It explicitly distinguishes from sibling tool openfinance_list_transactions that returns individual transactions.

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

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

Description provides explicit guidance: use openfinance_list_credit_card_bills first to discover IDs, pass bill_ids as an array, and for paid status prefer openfinance_list_credit_card_bills. It also tells when not to use (for individual transactions, use openfinance_list_transactions).

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 context about response structure ({ count, items } vs. single object) and conditional behavior, which is valuable beyond annotations.

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

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

Two sentences with zero waste. Purpose is front-loaded, followed by concise usage guidance.

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 both modes, response structure, and possible status values. Given a single optional parameter and no output schema, it is reasonably complete. Could mention that status values are enums, but not essential.

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

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

Schema description coverage is 0%, but the description compensates by explaining the effect of the `item` parameter (omit vs. pass). This is sufficient for a single optional param, though type/format not stated.

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

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

The description clearly states it returns the current status of a bank connection with specific possible values, and distinguishes behavior when item is omitted vs. provided. This differentiates it from sibling tools like openfinance_list_connections.

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

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

Explicitly instructs when to omit `item` (all banks) vs. when to pass `item` (single bank), guiding correct invocation. Does not mention alternatives but context is clear.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it's a safe read operation. The description adds behavioral context by warning that CREDIT balance meaning is connector-dependent and not to be treated as the monthly bill, and explains creditData fields for billing cycle. This goes beyond annotations.

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

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

The description is detailed and front-loaded with the main purpose. It is somewhat lengthy but necessary given the complexity of differentiating account types and providing warnings. Every sentence adds value, but it could be slightly more 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, so the description must explain the return format. It lists all key fields (balance, number, type, subtype, bankData, creditData, bank, connector_id) and clarifies the difference between 'name' and 'bank'. It also describes behavior when 'item' is omitted vs passed, and links to a related tool for standardized credit card bills. This is complete for a list tool with safe read 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?

The input schema has 2 parameters with 0% schema description coverage, so the description carries the full burden. It explains the effect of omitting or passing 'item' and the meaning of 'type' (BANK/CREDIT). However, it doesn't explicitly state that 'type' is an optional filter to scope results, though it's implied. Overall, it adds significant value but has a minor gap.

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

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

The description explicitly states the tool returns accounts for a bank connection, listing specific fields like balance, number, type, subtype, bankData, creditData. It distinguishes between BANK and CREDIT types and clarifies the difference between 'name' (legal entity) and 'bank' (brand). It also explains how to list across all banks or target a single bank, differentiating from sibling tools like openfinance_list_credit_card_bills.

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

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

The description provides clear guidance on when to omit 'item' (when user asks for accounts without naming a bank) and when to pass 'item' (target a single bank). It warns against treating CREDIT balance as the monthly bill and suggests using openfinance_list_credit_card_bills for standardized billing amounts, giving explicit alternatives.

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

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

Annotations already declare idempotent and read-only. Description adds that the result is cached for the session and is a single response, which provides 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?

Four sentences, front-loaded with main purpose. Every sentence adds value: cache, response fields, sibling tool reference, batch note.

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 covers all necessary aspects: what it returns, caching, field descriptions, and relationship to other tools.

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

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

No parameters, baseline is 4. Description explains the response structure, which adds value for the agent.

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

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

Description clearly states it returns the transaction category taxonomy, cached, and explains key fields like id, description, parentId. It distinguishes from siblings by calling it a single aggregated response with no batch 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?

Implicitly guides usage by noting the id is used by openfinance_update_transaction_category, and mentions caching for the session. Does not explicitly state when not to use, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds concrete return fields and the purpose, which is consistent with the annotations. No contradictions.

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

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

The description is a single concise sentence that immediately states the main function and lists returned fields. 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?

The description lists key fields returned, compensating for the lack of an output schema. It could mention if there's pagination or ordering, but for a simple list operation with no parameters, 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?

Since the tool has no parameters and schema coverage is 100%, the description doesn't need to explain parameters. It correctly omits parameter 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?

The description clearly states it returns saved bank connections with specific fields like connector_id, item_id, bank name, and an add_connection_url. This distinguishes it from sibling tools that list accounts, transactions, etc.

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

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

The description implies usage for viewing saved connections and provides context (add_connection_url for linking more banks). However, it doesn't explicitly state when not to use it or suggest alternatives among the many list 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; description adds critical non-obvious behaviors: payment assignment to bills based on cycle, derived payment_status calculation, connector asymmetry for open bill, and that failure returns warning instead of error. 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?

Description is very long and dense, with extensive details on payment logic and connector asymmetry. While structured with section headers, it could be more concise; the length may overwhelm users, but the complexity likely justifies it.

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, description fully explains return fields (payments[], payment_status, aggregates), derived values, and error behavior. Covers edge cases like PAST_DUE_UNCONFIRMED and connector asymmetry, making it complete for the tool's 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?

Schema has 0% description coverage; description compensates by thoroughly explaining include_open_bill (including availability flags and rationale), account_ids for bulk, and implied pagination via page/page_size. Missing explicit format details for page/size but adequate given context.

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 closed credit card bills with specific fields (dueDate, totalAmount, etc.) and distinguishes from sibling tools like openfinance_get_credit_card_bill and openfinance_list_transactions by clarifying scope (bill-level vs itemized) and purpose.

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 detailed payment cycle semantics, derived payment_status logic, and instruction to use openfinance_list_transactions for itemized data. Also explains the opt-in include_open_bill parameter and connector asymmetry.

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 provides behavioral context beyond annotations: it details error handling (returns a specific object instead of throwing on 403 or other upstream errors) and lists the types of returns (balance, amount, rates, etc.). Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description adds value without contradiction.

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

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

The description is a single paragraph that efficiently conveys the purpose and return structure. It is front-loaded with the main purpose and includes necessary detail. However, it could be slightly more concise by omitting some return field specifics that are not critical for tool selection.

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 covers the tool's purpose, output, and error handling well, but it lacks parameter documentation. Given the complexity (multiple asset types, error cases), the absence of parameter semantics creates a gap. With no output schema, the description of return fields is helpful but not sufficient for full 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 description coverage is 0%, meaning the parameters (item, page, type, page_size) are undocumented. The description does not explain their meaning, usage, or constraints. It only describes the output structure, failing to compensate for the lack of parameter documentation.

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

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

The description clearly states it returns the investment portfolio for a connection, listing specific asset types like FIIs, stocks, ETFs, fixed income, etc. The verb 'list' and resource 'investments' are precise, and it differentiates from sibling tools such as openfinance_list_accounts or 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?

The description does not explicitly state when to use this tool versus alternatives. It implies usage for retrieving investment portfolios but lacks guidance on prerequisites or exclusions, such as when not to use it (e.g., if the connection doesn't have INVESTMENTS enabled, it returns an error object).

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, destructiveHint, so safety profile is clear. Description adds value by detailing the type of data returned (transactions, fields like netAmount, expenses, etc.), which goes beyond annotations without contradicting them.

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

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

Two paragraphs, each sentence serves a purpose. First paragraph states the return and key fields, second connects to sibling tool and bulk capability. No fluff, information is front-loaded.

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

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

Description covers return data, usage order, and bulk support. Lacks explanation of pagination parameters (page, page_size), which are important for a list tool. With no output schema, a bit more detail 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 0% description coverage, so description must compensate. It explains investment_id (required) and mentions investment_ids for bulk, but does not clarify page/page_size parameters. Thus adds some meaning but leaves 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?

Description clearly states it returns movement history for an investment position, listing transaction types (BUY/SELL/etc.) and key fields. Distinguishes from sibling tools by specifying it is used after openfinance_list_investments to get the investment_id, differentiating from openfinance_list_transactions and other siblings.

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

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

Description gives explicit usage context: use after openfinance_list_investments and supports bulk with investment_ids. It does not explicitly mention when not to use or list alternatives, but the context is clear enough for an agent to decide.

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, destructiveHint=false, idempotentHint=true. The description confirms read-only via '(GET /loans)' and adds behavioral details: sequential querying with rate-limit spacing and per-connection return format `{ results, errors }`. 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 with zero waste. Purpose is front-loaded. Every clause adds value: endpoint, parameter usage, omission behavior, rate-limit note, return format. Ideal conciseness.

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 optional parameter and no output schema, the description covers all essentials: what it does, how to parameterize, side effects (rate-limit spacing), and return shape. The complexity is low and the description is complete.

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

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

Schema has 0% description coverage and only one parameter `items` (array of strings). The description compensates fully by explaining that `items` are connection selectors (item_id uuid, connector_id, or connector_name) and describing the behavior of omitting the parameter. This adds critical 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 explicitly states 'Lists loan contracts per bank connection (GET /loans)', specifying the HTTP method and endpoint. It distinguishes from sibling list tools by focusing on loan contracts and the 'per bank connection' aspect. The mention of passing `items` as connection selectors clarifies the resource scope.

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?

Clear guidance is provided: pass `items` to list for specific connections, omit to list across all banks. The rate-limit spacing behavior is noted. However, no explicit alternatives or when-not-to-use scenarios are mentioned, but the guidance is sufficient for typical 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?

Discloses nuances: CREDIT PENDING vs POSTED varies by connector, auto-pagination with a 5000 ceiling may truncate with `truncated:true`, upstream errors return a non-throwing response, and `detail` levels add tokens/coverage variance. No contradiction with readOnlyHint and idempotentHint 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-organized and front-loaded with core purpose, but verbose in parts (e.g., detailed credit card processing notes). Every sentence adds value, but some sections could be tightened 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?

Extremely complete: covers edge cases (truncation, errors), cross-references sibling tools, explains bank/connector variability, and details search behavior. Given 8 complex parameters and no output schema, the description leaves no important gaps.

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

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

Despite schema description coverage of 0%, the description thoroughly explains each parameter: ISO date formats for from/to, pagination with page and page_size (max 500), enum values for detail (compact/rich/raw) with semantics, and search_queries with OR semantics across substring matches. It adds significant meaning beyond the schema.

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

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

Description clearly states 'Returns transactions for a bank account (BANK or CREDIT type)' and distinguishes from siblings like openfinance_list_credit_card_bills and openfinance_list_transactions_by_item by specifying when each alternative is appropriate.

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

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

Provides extensive usage guidance: when to use this vs openfinance_list_credit_card_bills for standardized open bill total, how to handle pagination (auto vs manual), details on the `detail` parameter (when to use each level), and how to check sync health via openfinance_get_item_status for missing credit card transactions.

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

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

The description goes well beyond annotations by disclosing the aggregation behavior, the default granularity returning a compact summary with specific fields, the cap of 5000 transactions per account with a truncated flag, and the effect of detail and granularity parameters. This provides thorough behavioral transparency.

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

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

The description is front-loaded with the core purpose, then systematically details parameters and output. While lengthy, each sentence adds value. A minor improvement could be separating parameter explanations more explicitly, but overall it is well-structured and efficient.

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

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

Given the tool's complexity (7 parameters, no output schema, multiple sibling tools), the description is remarkably complete. It explains the output fields (entradas, saídas, saldo_liquido, por_mes, top_despesas, top_recebimentos, by_account), the effect of each parameter, and the truncation limit. No gaps remain.

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 must compensate and does so by explaining almost all parameters: item (connector_id/connector_name/item_id or omit for all), from/to (ISO dates), granularity (monthly vs raw), detail (compact/rich/raw), type (BANK/CREDIT). The top_n parameter is only implicitly mentioned via 'largest N each' in the output description, not explicitly clarified as controlling the count.

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 does consolidated cash-flow analysis for a whole bank connection in one call, resolving accounts internally and fanning out transactions. It distinguishes itself from openfinance_list_accounts by noting the user does not need to call that tool 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?

The description provides explicit use cases (e.g., 'análise anual/mensal', 'fluxo de caixa') and explains when to use granularity:'raw' for itemized rows. It does not directly compare to the sibling tool openfinance_list_transactions, but the purpose is clear enough to infer when this aggregated tool is preferred.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. The description adds details about checking a public status page, returning global indicator, degraded components, incidents, and affected banks. 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?

Single paragraph that is informative but slightly dense. Could be split into purpose and usage sections, but no wasted words. Efficient overall.

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 input schema and no output schema, the description thoroughly covers what the tool returns (global indicator, degraded components, incidents, affected banks) and when to use it. 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 in input schema (0 params, 100% coverage). Description adds no param info, but that is appropriate. 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 it checks the LIVE operational status of the Open Finance provider, distinguishing it from openfinance_get_item_status which checks the user's own connection. It specifies the resource and action unambiguously.

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 when data looks incomplete or stale despite an UPDATED connection, helping differentiate provider-side problems from connection issues. Provides clear context with examples like missing accounts or transactions.

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 significant behavioral context beyond annotations: explains plan-based filtering, caveat warnings for credential connectors, and that omitting keywords returns a hint instead of dumping the catalog. All aligns with readOnlyHint, idempotentHint, etc.

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

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

Every sentence adds value; the description is dense but well-structured, starting with the core function and progressively adding details. No redundant 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?

Covers purpose, parameters, return fields, and usage flow. Missing potential error cases or response structure, but given no output schema and low complexity, the description is sufficiently complete for an agent.

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

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

With 0% schema description coverage, the description compensates by providing an example for keywords and explaining include_accounts' effect. Could be more precise about array formats but adds meaningful value.

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

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

The description clearly states the tool searches bank connectors by name keywords, distinguishes itself from sibling tools like 'connect' or 'list_accounts', and specifies the return fields (connector id, access type, audience, etc.).

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

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

Explicitly advises to call this before connecting and that keywords is required; provides context about surfacing caveats for non-Open-Finance connectors. Could be improved by stating when not to use, but current guidance is solid.

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 important behavioral traits beyond annotations: it overrides Pluggy's automatic categorization and teaches Pluggy by creating a Category Rule (case-insensitive exact match). This adds significant context for the agent, especially since annotations only show basic hints.

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

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

The description is a single, dense paragraph but every sentence adds value. It could be slightly more structured with line breaks, but it is appropriately sized and front-loaded with the action.

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 output schema and 0% schema coverage, the description provides complete context: input format, side effects (rule creation), and response shape (updated, results, errors). The agent can use this tool correctly without additional information.

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 structure of the items array, the source of transaction_id and category_id, and the batch behavior including per-item error handling. This adds critical 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 it corrects the category of transactions via PATCH, specifying the HTTP method and the exact resource. It distinguishes from siblings by referencing openfinance_list_transactions and openfinance_list_categories for obtaining 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?

The description provides explicit instructions on how to form the items array with required fields and mentions the side effect of creating Category Rules for future transactions. However, it does not explicitly state when not to use this tool or mention alternatives beyond the referenced list 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 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 readOnly, idempotent, and non-destructive behavior. The description adds value by specifying the exact content returned (installed MCPs, connection status, catalog tool counts), which is beyond the annotations.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose and return 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 tool with no parameters and no output schema, the description adequately explains what is returned. It could be considered complete, though some details about the format of the output might be beneficial.

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, so schema coverage is 100% by default. The baseline for zero parameters is 4, and the description does not need to add parameter semantics.

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 toolkit state including installed MCPs, connection status, and catalog tool counts. This is specific and distinguishes it from sibling tools which are operational or finance-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?

No guidance is provided on when to use this tool versus alternatives. The description only explains what it returns, not when it should be invoked or when other tools might be more appropriate.

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