Crefisa MCP

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

Description explains the two behavioral modes (link generation vs token acceptance) and notes the permanent config option. Annotations already indicate non-destructive and idempotent; description adds context about the login flow.

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?

Information-dense single paragraph that front-loads purpose. Could be slightly better structured (e.g., bullet points), but every sentence adds value without redundancy.

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

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

Covers input and usage modes thoroughly, but lacks description of the output/return value (e.g., confirmation, token). With no output schema, the description should inform the agent about what the tool returns.

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 only parameter 'token' is explained as a JWT string. The description specifies when to provide it (after user pastes) and how it's used (session-only login). Compensates well for the 0% schema coverage.

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

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

The description clearly states the tool handles authentication for IDE agents, providing a login link or accepting a token. It distinguishes from sibling tools like 'connect' and 'marketplace' by focusing solely on credential handling.

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

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

Explicitly describes when to use (to log in), how to use (with or without token), and recommends a best practice (adding to config for permanent access). Clearly explains the two modes: session-only vs permanent.

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

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

The description adds significant behavioral detail beyond the annotations: it explains the two possible return states (authenticated:true with empty pending[] vs connect_urls) and the conditions for each. Annotations already declare readOnlyHint=true and destructiveHint=false, but the description fills in what the agent will actually receive.

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

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

The description is extremely concise at two sentences with no wasted words. It front-loads the core purpose and then details the conditional behavior. Every sentence provides essential information.

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

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

For a simple read-only status tool with no parameters and no output schema, the description is complete. It covers both normal and missing-credentials scenarios, specifying the exact return structure. An agent can fully understand what to expect without additional documentation.

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

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

The tool has zero parameters, so the input schema is empty and fully covered. Per the rubric, baseline is 4 for zero-param tools. The description does not add parameter info because none exist, but this is appropriate.

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

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

The description clearly states it returns connection status and URLs, with specific conditions for different states. This is a specific verb+resource combination that distinguishes itself from sibling tools like 'authenticate' which likely performs authentication rather than status checks.

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's purpose is self-explanatory as a status check, and the description provides clear context about when it returns which type of output (authenticated vs missing credentials). However, it does not explicitly state when not to use it or mention alternatives, though the context is sufficiently 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?

Discloses key behaviors beyond annotations: invoke works even if MCP is not installed, handles credential/payment links, writes require workspace owner/admin. No contradictions with annotations (readOnlyHint=false, destructiveHint=false).

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

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

The description is comprehensive but somewhat verbose; it could be condensed while retaining key information. However, it is well-structured with clear sections and front-loaded with the most important concepts.

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

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

Given the tool's complexity (13 parameters, many actions, no output schema), the description covers all necessary context: core usage, special cases (credential/payment), administrative actions, and how it relates to sibling tools. Very 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?

Despite 0% schema coverage, the description explains the purpose of many parameters (action, query, mcp_id, tool_id, arguments) and how they fit into the flow. However, some parameters like limit, immediate, tier_slug are not detailed, so there's room for improvement.

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 marketplace is 'THE official mcp.ai marketplace' and the primary tool for discovering and running MCPs. It lists specific actions (search, describe, invoke, etc.) and distinguishes from sibling tools by emphasizing its role as the first stop for capability discovery.

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 using this tool FIRST before external registries, differentiates between invoke (one-off, no installation) and install (permanent), and outlines the core flow: search → describe → invoke. Also explains when to use related tools like 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?

The description discloses that data will no longer be available and returns a re-connect URL, going beyond the destructiveHint=true annotation. 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 are concise and front-loaded with the main action. Every word adds value, no fluff.

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

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

Given no output schema and one parameter, the description covers the essential behavior and return value. It would benefit from parameter format detail, but overall it is sufficient for a simple tool.

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

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

With 0% schema description coverage, the description must explain the parameter 'item'. It only says 'for a specific bank', but does not specify the format (e.g., ID, name) or provide examples. This leaves ambiguity.

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 revokes consent and deletes connection data for a specific bank, distinguishing it from siblings like openfinance_list_connections or openfinance_force_sync. The verb 'revokes' and resource 'bank connection' are specific and unambiguous.

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

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

The description implies usage for disconnecting a bank, but does not explicitly mention when not to use it or alternatives. However, the context is clear from the tool name and sibling list, making it adequately helpful.

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 explains the non-read-only nature (forces sync, waits), timeout up to ~60s, and return structure including status fields. Annotations show readOnlyHint=false, destructiveHint=false, idempotentHint=false; description adds context about polling and fresh data without disconnecting, with 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 informative but somewhat verbose. However, it is well-structured with front-loaded purpose, followed by usage notes and return details. Every sentence adds value, but 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?

For a tool with no output schema and moderate complexity (2 params, polling behavior), the description is complete. It explains the return object structure (results, errors), key fields (status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out), and edge cases (timeout, user action needed).

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

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

Despite 0% schema description coverage, the description fully explains both parameters: 'wait' (boolean, default true, set false for fire-and-forget) and 'items' (array of selectors, omit for all banks). This adds substantial value beyond the bare schema.

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

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

The description clearly states the tool forces a re-sync of connections and waits for completion. It distinguishes from siblings like openfinance_get_item_status and openfinance_list_connections by specifying unique behavior (pulling fresh data without disconnecting) and mentioning the PATCH endpoint and polling mechanism.

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/transaction list), what it does without disconnecting, and how to customize behavior (omit items for all banks, set wait:false for fire-and-forget). Also provides guidance on interpreting results (e.g., needs_action means reconnect, timed_out means re-check with openfinance_get_item_status).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral context: real-time nature, endpoint, array limit, special warning behavior for CREDIT accounts, and response shape. 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?

Three well-structured sentences. The first sentence states purpose and endpoint, the second gives parameter constraints, and the third details error handling and response format. Every sentence adds value; no wasted words.

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

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

For a simple tool with one parameter and no output schema, the description covers the key points: what it does, how to call it (array limit), error handling, and response shape. It is nearly complete, though it could mention authentication prerequisites.

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

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

The input schema has no descriptions (0% coverage). The description compensates by explaining that account_ids is an array of 1-50 account IDs and notes that CREDIT accounts may return warnings. This adds meaningful context beyond the raw schema.

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

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

The description clearly states it returns real-time balance per account id and specifies the endpoint. It distinguishes itself from sibling tools like list_accounts (which lists metadata) but does not explicitly differentiate from get_accounts_detail.

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

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

The description gives guidance on the parameter (array of 1-50 account_ids) and explains error handling for CREDIT accounts. However, it does not explicitly state when to use this tool versus alternatives or provide usage context beyond the parameter.

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 batch result shape, ID count limit, and inclusion of creditData, providing useful context beyond annotations.

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

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

Two concise sentences: first describes the tool's purpose and endpoint, second provides parameter usage and output 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 one-parameter tool without output schema, the description provides adequate overview of output shape and key data included. Could be improved with error handling details.

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 specifies the array size constraint (1-50) and confirms it's an array of strings, adding meaningful constraints beyond the bare schema.

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

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

The description clearly states the tool returns full account objects with extended creditData for given IDs, and distinguishes from listing tools by specifying the batch detail retrieval and 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 implies usage for fetching detailed data for specific accounts (1-50 IDs), but does not explicitly contrast with openfinance_list_accounts or provide when-not-to-use 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?

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds critical behavioral context: the batch response shape `{ results, errors }`, that Pluggy lacks a paid/status field, and the correct interpretation of payments[] as typically reflecting the previous bill's payment. 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 longer than average but every sentence serves a purpose, front-loading the main function then adding nuanced details. It is well-structured and not overly verbose for the complexity of the tool.

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 (credit card bills, payment status nuance), no output schema, and only one parameter, the description covers all essentials: what it returns, what it doesn't, usage steps, caveats, and cross-references to sibling tools. It is fully complete.

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

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

The input schema has 0% description coverage for the single parameter 'bill_ids'. The description fully compensates by explaining it should be an array of bill IDs, and directs users to a sibling tool to discover those IDs, adding essential 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 bill-level detail for one or more credit card bills by ID, listing specific fields like financeCharges and payments. It distinguishes itself from sibling tools by explicitly stating it does NOT return individual transactions and directing users to openfinance_list_transactions for itemized data.

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

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

The description provides explicit guidance on when to use the tool (to get bill detail), when not to (for transactions), and alternatives (use openfinance_list_transactions). It also instructs users to first use openfinance_list_credit_card_bills to discover IDs, and explains the nuance about payments not indicating bill paid status.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds context about the response structure for both cases (all banks returns { count, items } and single bank returns status and metadata) and lists possible status values, enhancing transparency beyond annotations.

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

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

The description is two concise sentences, front-loaded with the core functionality and key details. Every word adds value; no redundancy or unnecessary information.

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

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

Given the simplicity of the tool (one optional parameter, no output schema), the description covers the return format for both use cases, lists possible statuses, and mentions included fields. It does not detail the exact single-bank response structure beyond mentioning fields, but this is sufficient for agent invocation.

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

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

With schema coverage at 0%, the description fully explains the sole parameter 'item': omitting it returns status for all banks (with count and items), passing it returns status for a single bank. This provides complete semantic understanding.

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

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

The description clearly states the tool returns the current status of bank connections, listing specific status values (UPDATED, UPDATING, LOGIN_ERROR), executionStatus, and connector metadata. It distinguishes between getting status for all banks versus a single bank, making purpose unambiguous.

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

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

The description explains when to omit or include the 'item' parameter to get all banks or a single bank. However, it does not explicitly compare to sibling tools like openfinance_list_connections or provide scenarios for alternatives, though the use case 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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and description reinforces that the tool returns data without modification. Adds critical behavioral context about CREDIT balance meaning and connector-dependent behavior, which annotations do not cover. 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 comprehensive but slightly verbose. It front-loads the main purpose and then provides detailed caveats and examples. Could be trimmed without losing critical information, but the structure is logical and all information earned its place.

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

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

Given the complexity of financial accounts, the description covers return fields, parameter semantics, behavioral nuances, and points to a sibling tool for missing functionality (standardized bill amounts). No output schema exists, so description compensates fully. All essential aspects for correct agent invocation are addressed.

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

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

Schema has 0% description coverage, so the description carries full responsibility. It explains both parameters: `item` (optional, filters by bank, with effect when omitted vs present) and `type` (enum with implied values BANK/CREDIT). Adds meaning beyond the raw schema by clarifying usage patterns and consequences.

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 accounts for a bank connection, specifying account types (BANK and CREDIT) and the data fields (balance, number, type, etc.). Explicitly distinguishes between listing all accounts across banks (omit item) vs a single bank (pass item), differentiating it 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?

Provides explicit guidance on when to omit or pass the `item` parameter based on user intent. Warns against misinterpreting CREDIT `balance` as the current month's bill, and directs to the sibling tool `openfinance_list_credit_card_bills` for standardized bill amounts. Offers clear when-to-use and when-not-to-use instructions.

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 caching behavior, response structure details (fields), and Portuguese translation note. Annotations already declare readOnlyHint, idempotentHint, destructiveHint; description complements 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?

Two sentences, no waste. Front-loaded with purpose, then key details. 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?

Fully explains output fields, caching, and linkage to sibling tool. No output schema but description covers return structure adequately. Complete for a read-only 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?

No parameters; schema coverage 100%. Per guidelines, baseline 4 is appropriate. Description adds no param info but none needed.

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

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

The description clearly states it returns Pluggy's transaction category taxonomy, cached for the session, and lists the fields. It distinguishes from other list tools by specifying the resource (categories) and the connection to update_transaction_category.

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 field is used by openfinance_update_transaction_category, and that it's a single aggregated response (no batch ids). No explicit exclusions but clear 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. Description adds context about returned data (fields and add_connection_url) but doesn't cover authentication needs or rate limits.

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

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

Single sentence, front-loaded with main purpose, no wasted words. Efficient and clear.

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

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

For a zero-parameter tool with annotations, description covers returned fields adequately. Minor gap: no mention of pagination or limits, but acceptable given 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?

No parameters; baseline 4 as per guidelines. Description doesn't 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?

Clear verb 'Returns', specific resource 'saved bank connections', and explicitly lists returned fields (connector_id, item_id, bank name, add_connection_url). Distinguishes from sibling tools like connect/disconnect.

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

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

Implies usage for viewing existing connections but lacks explicit guidance on when to use this vs siblings (e.g., connect, disconnect). No exclusions or alternatives 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?

Annotations already show readOnlyHint=true, idempotentHint=true. Description adds critical behavioral context: payment semantics (pre-payment, cross-bill matching), derived payment_status logic, connector asymmetry for open bill, and that balance meaning varies. 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 very long and dense, containing essential details but could be more concise. It front-loads main fields but includes lengthy explanations of payment_status logic and connector asymmetry. Some redundancy (e.g., 'Bulk support: accepts account_ids' restated).

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 (multiple return fields, derived status, opt-in, connector asymmetry, cross-referencing), the description is thorough. No output schema exists, so it explains return values, derived fields, and edge cases comprehensively.

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 include_open_bill (opt-in, why), account_ids (bulk), and implies pagination via page/page_size (though not detailed). Adds value beyond schema, but not all parameters are fully elaborated (e.g., page, page_size format).

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

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

The description clearly states the tool returns closed credit card bills with specific fields. It distinguishes from sibling openfinance_list_transactions by noting that this tool provides bill-level summaries, not individual transactions. The verb 'list' and resource 'credit card bills' are precise.

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: use openfinance_list_transactions for itemized purchases; explains when to use include_open_bill (opt-in due to extra scan); describes connector asymmetry (open bill not retrievable). Mentions bulk support via account_ids.

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

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

Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds behavioral context: returns structured object on errors (instead of throwing), lists typical fields in results. 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 reasonably concise, listing many asset types in a compact way. Could be slightly tighter but no wasted sentences.

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 complexity (multiple asset types, pagination parameters, no output schema), description lacks parameter guidance and complete return structure details. Mentions some fields but incomplete.

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% coverage. Description does not explain parameters (item, page, type, page_size) or their formats. Only mentions return fields, not inputs.

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

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

Description clearly states the tool returns investment portfolio for a connection with specific product types (FIIs, stocks, ETFs, etc.), listing many examples. It distinguishes from sibling tools like openfinance_list_accounts and openfinance_list_investment_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 implies usage when needing investment data from a connection with INVESTMENTS product enabled, and mentions error handling behavior. However, it does not explicitly state when not to use or compare to alternatives.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. Description adds detail on returned fields (expenses breakdown) and bulk execution, which goes beyond basic annotation info.

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

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

Two succinct paragraphs; first explains purpose and output fields, second adds bulk support. No wasted words, but could be slightly more 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?

With no output schema, description lists key output fields and bulk behavior. Covers essential usage context. Could mention pagination defaults but otherwise adequate.

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

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

Schema description coverage is 0%, so description must explain parameters. It clarifies investment_id and investment_ids but does not explain page or page_size, which are left undocumented. Insufficient for a 4-parameter tool.

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

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

Clearly states the tool returns movement history for a specific investment position, listing transaction types (BUY/SELL/TAX etc.) and specific fields. Distinct from sibling tools like openfinance_list_investments which returns the investment list.

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 to use after openfinance_list_investments to get the investment_id. Mentions bulk support via investment_ids. Does not explicitly state when not to use, but context implies it's for a specific investment.

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 sequential querying with rate-limit spacing, HTTP method (GET), and per-connection return format. Annotations already indicate readOnly and idempotent, so the description adds useful behavioral context without contradiction.

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

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

Two sentences, concise and front-loaded. First sentence states purpose and endpoint; second covers parameter usage and return. 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?

Adequate for a simple list tool with one optional parameter and no output schema. Covers high-level behavior and return format but omits details like pagination, errors, or result shape.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the `items` parameter as an array of connection selectors (item_id, connector_id, or connector_name) and the effect of omitting it. However, it lacks precise format details for each selector type.

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

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

The description clearly states it 'Lists loan contracts per bank connection' with a specific verb and resource. However, it does not explicitly differentiate from sibling tools like openfinance_list_accounts or openfinance_list_transactions, though the resource differs.

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 guidance on how to use the `items` parameter for specific connections versus omitting it for all connections. Does not mention when not to use or alternatives, but for a straightforward list tool, this is adequate.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description explains CREDIT PENDING vs POSTED variability per connector, search_queries aggregation behavior (up to 5000 transactions before filtering), error handling (returns warning/error instead of throwing), and bulk support with account_ids. 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 lengthy but each sentence is informative and well-structured. It is front-loaded with core purpose, then details for CREDIT accounts, query behavior, edge cases. Slightly verbose but justified by 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 7 parameters, no output schema, and complex edge cases, the description is complete. Covers account types, CREDIT-specific behavior, date filtering, pagination, search, error handling, bulk support, and connection health. Output schema missing but description approximates return 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?

Schema coverage is 0%, but description compensates by explaining all parameters: from/to as ISO YYYY-MM-DD, pagination max 500/page, account_id and account_ids for bulk, search_queries as case/accent-insensitive substring match with OR semantics and aggregation behavior. Also explains error response format and truncated flag.

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

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

The description clearly states it returns transactions for bank accounts (BANK or CREDIT). It specifies the resource (transactions) and action (list). It distinguishes itself from sibling tools, notably for CREDIT accounts it's the only way for 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 extensive when-to-use guidance: for CREDIT accounts, use for itemized transactions; use openfinance_list_credit_card_bills for open-bill total. Explains when to check connection health and force sync. Mentions narrowing date range if truncated:true. Explicitly names 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 provide readOnlyHint, idempotentHint, destructiveHint. The description adds important behavioral details: it caps at 5000 transactions per account and flags truncated:true, it resolves accounts internally, default granularity returns a compact summary, and omitting item analyzes all linked banks. No contradictions.

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

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

The description is dense but well-structured: purpose first, then mechanics, then parameter details, then use cases. It is not overly verbose for the amount of information conveyed. Minor redundancy ('consolidated cash-flow analysis' and 'resolves internally') but acceptable.

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 must cover return values. It does: total entradas/saídas/saldo_liquido, por_mes, top_despesas/recebimentos, by_account breakdown, truncated flag. All relevant information is present. With 6 parameters and moderate complexity, this is complete.

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

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

Schema has 0% description coverage, so the description carries full burden. It explains item (connector_id/name/item_id), from/to (ISO dates), granularity (monthly/raw), type (BANK/CREDIT). It mentions top_despesas/recebimentos implying top_n controls N, but does not explicitly describe the top_n parameter. Overall adds significant meaning.

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

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

The description clearly states the tool's purpose: providing consolidated cash-flow analysis for a whole bank connection in one call. It distinguishes itself from siblings like openfinance_list_accounts and openfinance_list_transactions by explaining it handles internal account resolution and fan-out. The purpose is specific and well-defined with verb+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 gives explicit use cases ('análise anual/mensal', 'fluxo de caixa', etc.) and explains when to use it instead of calling other tools first. It mentions alternatives (openfinance_list_accounts) but does not fully list sibling tools. There is clear guidance on when to use granularity 'raw' vs 'monthly'. Lacks explicit 'when not to use' but sufficient.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds value by detailing what the response contains (global indicator, degraded components, incidents, affected banks) and explaining the tool's behavior (checking provider health, not user connection). No contradictions.

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

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

Description is efficient and front-loaded with the main purpose. Every sentence contributes meaningful information. Slightly long but justified given the context needed to differentiate from sibling tool.

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

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

For a parameterless tool with no output schema, the description fully articulates what the tool does, when to use it, and what it returns (global indicator, degraded components, incidents, affected banks). 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?

Tool has zero parameters and 100% schema coverage. Description does not need to explain 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 clearly states it checks the LIVE operational status of the Open Finance provider and distinguishes it from the connection-level status tool (openfinance_get_item_status). Uses specific verb 'Checks' and resource 'LIVE operational status of the Open Finance provider'.

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 specifies when to use: when data appears incomplete/stale despite connection showing updated, missing accounts/transactions/balances, or bank not returning everything. Clearly separates provider-side problems from connection issues and names the sibling tool 'openfinance_get_item_status' as an alternative.

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 plan-based filtering, keyword requirement, and that it never dumps the full catalog. Annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent and the description adds valuable behavioral context beyond 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?

The description is comprehensive yet efficient; every sentence adds value. It front-loads the core functionality, then details outputs and usage notes. No superfluous content.

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

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

Given the tool has only two parameters, no output schema, and annotations cover safety, the description is complete. It covers return fields, prerequisite usage, plan filtering, and keyword necessity, enabling correct agent invocation.

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

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

Despite 0% schema coverage, the description fully explains both parameters: keywords[] (with example and that it's required) and include_accounts (its effect). This adds critical meaning beyond the bare schema.

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

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

The description clearly states the tool searches bank connectors by name and lists the specific output fields (connector id, access type, audience, linked connections, connect_url). It distinguishes itself from sibling tools by emphasizing its role as a pre-connection search step.

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

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

Explicitly states to call this BEFORE connecting, explains plan-based filtering (PF/PJ), and clarifies that keywords[] is required and without it returns a hint. This provides clear when-to-use and when-not-to-use guidance.

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

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

The description adds substantial behavioral context beyond the annotations: it discloses the side effect of creating a Category Rule that affects future transactions, describes the return shape including errors, and explains that per-item errors do not fail the whole batch. 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 packed with useful information but is relatively long. It is front-loaded with the main action, and the structure is logical. Slightly verbose but acceptable.

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 complexity (one nested parameter, no output schema), the description comprehensively covers the purpose, usage, side effects, and return shape. It is complete for an AI agent to understand and invoke the tool correctly.

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

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

Although the schema has 0% description coverage, the description fully explains the items parameter, including the structure and the meaning of transaction_id and category_id, and where to obtain them. It also describes the batch response shape, compensating for the lack of schema descriptions.

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

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

The description clearly states the action 'Corrects the category of one or more transactions' and specifies the HTTP method PATCH. It distinguishes this tool from siblings like openfinance_list_transactions by focusing on updating categories, and explains the side effect of teaching the system.

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 tells when to use (fix miscategorized transactions) and provides context on where to get required IDs (from other tools). It explains the batch behavior but does not explicitly state when not to use or list 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?

The description adds context about including conversation data for reproduction, complementing the annotations (idempotent=true, non-destructive). No contradictions or missing critical behaviors.

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 waste. The first sentence delivers the purpose, the second provides guidance. Front-loaded and efficient.

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

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

The description covers the essential use case for a bug report tool, including reproduction instructions. No return value or confirmation details, but sufficient for the simple action.

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 explains the 'conversation' and 'message' parameters, but the 'context' parameter remains unexplained. This partially compensates for the schema gap.

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

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

The description clearly states the tool's purpose: reporting bugs, missing features, or sending feedback. It differentiates from sibling tools like OpenFinance operations or authentication by specifying this feedback role.

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 tells to include the conversation array for reproduction, giving clear usage context. It doesn't explicitly exclude alternatives but implies the intended scenario.

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 the detail about showing platform and adapter versions, but does not provide additional behavioral traits beyond what annotations convey. It does not contradict annotations.

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

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

The description is a single sentence that is front-loaded with the verb and noun, containing no superfluous words. Every word earns its place.

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

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

Given the tool has no parameters, no output schema, and is a simple info retrieval operation, the description provides complete context. No additional information is necessary.

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

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

There are zero parameters, so the baseline is 4. The schema covers 100% (empty), and the description naturally does not need to add parameter information.

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

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

The description uses a specific verb ('Show') and explicitly names the resources ('MCP platform and adapter versions'). It clearly distinguishes itself from sibling tools like authenticate, connect, etc.

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

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

No explicit guidance on when to use this tool vs alternatives. However, given its purpose is self-evident and it's a standalone query tool, the lack of guidelines is not critical but still reduces the score from a potential 4.

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, so safety is clear. The description adds valuable behavioral context about what exactly is returned (installed MCPs, connection status, catalog tools), going 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?

A single, clear sentence with no filler. Every word 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 read-only info tool with no parameters and annotations providing safety, the description completely explains the output. 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, and schema coverage is 100%, so the description need not add parameter info. A baseline of 4 is appropriate for zero-parameter tools.

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

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

The description uses a specific verb ('Returns') and resource ('toolkit state') and clearly lists the components: installed MCPs, connection status, catalog tool counts. This distinguishes it from siblings like 'show_version' which returns version info.

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 getting overall toolkit state, which is distinct from other tools. However, it does not explicitly state when not to use or name alternatives.

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