Inter MCP

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

Discloses behavior beyond annotations: explains two invocation modes (with/without token), persistence (permanent vs session). Annotations already indicate idempotency, and description aligns. 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 informative and front-loaded with purpose. Each sentence adds value. Slightly long but well-structured for a simple 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?

Covers key aspects: purpose, invocation methods, token source. No output schema exists, so missing return value details is acceptable. Lacks error handling notes, but overall complete 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 explains the token parameter: a JWT access token. Also explains that omitting it returns a link. Adds full meaning to the only parameter.

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 is for authentication of MCP.AI for IDE agents. Describes two methods: permanent via config or session via token parameter. No explicit differentiation from sibling tools, but the purpose is 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?

Provides clear usage guidance: best method (config) and alternative (token parameter). Also mentions calling with no args to get a link. However, no comparison with sibling tools or when not to use this tool.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context about the return values based on connection state (authenticated:true vs connect_urls), providing additional value beyond annotations.

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

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

The description is a single, well-structured paragraph of two sentences with no unnecessary words. Every sentence adds meaningful 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 tool with no parameters and simple behavior, the description adequately covers the two main states and return values. No output schema exists, but the description explains what to expect. Complete for this level of 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 exist, so schema coverage is effectively 100%. Baseline for 0 parameters is 4 per instructions. Description adds nothing about parameters, but none are needed.

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

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

The description clearly states it returns connection status and URLs, with specific details on return values based on connection state. It distinguishes itself from siblings like 'authenticate' by focusing on status checking.

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

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

No explicit guidance on when to use this tool versus alternatives such as 'authenticate' or 'openfinance_list_connections'. The description implies it's for checking connection status but does not specify when other tools would be more appropriate.

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=false, openWorldHint=true, etc. Description adds significant context: invoke works even when MCP not installed, returns connect/top-up links, writes require admin, and explains how install adds permanence. 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 long (several paragraphs) but well-structured with a clear flow. Could be more concise; some redundancy (e.g., 'installed_in_toolkit vs installed_in_workspace' is mentioned but not explained). However, the complexity justifies the length.

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 (15 parameters, no output schema), the description covers the main behavioral aspects and flows but lacks detailed parameter documentation. It could benefit from parameter descriptions and return value explanations.

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 compensate. While it explains the purpose of action, mcp_id, tool_id, and arguments in the flow, it does not detail 15 parameters like limit, tier_slug, cancel_reason, etc. Partial compensation but incomplete.

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

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

The description clearly states it is the official mcp.ai marketplace and catalog, and outlines the core flow (search, describe, invoke). It distinguishes from sibling tools by positioning itself as the primary tool for discovery and execution before external registries.

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

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

Explicitly says to use this tool first, before any external registry. Provides detailed guidance on when to use each action (search, describe, invoke, install) and explains the tradeoff between invoke and install. Also mentions prerequisites for write operations (workspace owner/admin).

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

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

Annotations already mark the tool as destructive. The description adds value by specifying that connection data is deleted and a reconnection URL is returned, aligning with and expanding on the destructive hint.

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 comprised of three short, front-loaded sentences with no unnecessary information, achieving high 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 simple tool with one parameter and no output schema, the description covers the main action and return value. It lacks error scenarios or prerequisites but is largely complete for its 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?

The single required parameter 'item' has no schema description and the tool description only vaguely refers to 'a specific bank', without clarifying the expected format or source (e.g., bank ID, connection ID). Given 0% schema coverage, more detail is needed.

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

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

The description explicitly states the tool revokes consent and deletes connection data for a specific bank, clearly distinguishing it from sibling tools like openfinance_list_connections or openfinance_force_sync.

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 (when you want to disconnect a bank) but provides no explicit guidance on when to use it versus alternatives or when not to use it. No mention of prerequisites or 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 are minimal (no readOnly, destructive, or idempotent hints). The description richly details behavior: polls up to ~60s, fire-and-forget with wait:false, return fields (status, executionStatus, lastUpdatedAt, synced, needs_action, reconnect_url, timed_out), and error handling. This fully compensates for lack of annotation detail.

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 it is front-loaded with the core action and adds essential details. Every sentence adds value, though it could be slightly more structured (e.g., separate sections for parameters and return values). Not overly verbose.

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

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

Despite lacking an output schema and having simple parameters, the description covers purpose, usage, parameters, return value semantics, error states (needs_action, timed_out), and even an alternative usage (wait:false). It is comprehensive for a tool of this 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 coverage is 0%, so the description carries full burden. It thoroughly explains both parameters: 'wait' as fire-and-forget vs. wait, and 'items' as an array of selectors (item_id, connector_id, connector_name, custom_label) with omission syncing all. No parameter is left undocumented.

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's purpose: 'Forces the bank to re-sync one or more connections NOW and WAITS for it to finish'. It uses a specific verb (force, sync) and resource (connections), and distinguishes from siblings by explaining it avoids disconnecting/reconnecting.

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 when-to-use guidance: 'Use this when a balance or transaction list looks stale'. It also explains what it avoids and gives a fire-and-forget option. However, it does not explicitly state when not to use or compare to specific sibling tools.

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

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

Adds significant detail beyond annotations: real-time indicator, specific error for credit accounts with warning, degradation to last-synced when upstream unavailable, and response shape. No contradiction with readOnlyHint and idempotentHint.

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

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

Well-structured with front-loaded purpose sentence. Slightly verbose but every sentence adds value. Could be more concise but not wasteful.

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

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

Covers all relevant behaviors: error states, degradation, response format. No output schema, so description appropriately explains return structure. Complete for a balance retrieval tool.

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

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

Schema coverage is 0% but description compensates by clarifying account_ids is an array of strings with 1-50 limit. Adds meaning beyond schema's basic type definition.

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

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

Clearly states it returns real-time balance per account id with endpoint. Distinguishes from sibling tools like list_accounts or get_accounts_detail by focusing on balance retrieval.

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

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

Specifies array input (1-50) and describes error handling (BALANCE_FETCH_ERROR) and degradation behavior. Lacks explicit when-not or alternative tool recommendations but provides adequate 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?

The description goes beyond annotations by disclosing the batch response shape, a provider_incident block that may indicate unreliable credit limits, and warns not to present those values as real. This fully informs the agent of important behavioral traits.

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

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

The description is concise (3 sentences), front-loaded with the main action, and contains no unnecessary information. 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 the simple input schema and no output schema, the description adequately covers input constraints, response shape, and a critical caveat about data reliability. It could optionally describe account object fields in more detail, but it is sufficient 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?

The description adds meaning beyond the schema by specifying the allowed range (1–50) for the account_ids array and that the response is a batch with results and errors. Since schema coverage is 0%, this is valuable 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 clearly states the tool returns full account objects including extended creditData per ID. It uses specific verbs and distinguishes from siblings like openfinance_list_accounts (which likely returns summaries) and openfinance_get_account_balance.

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

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

The description implies usage for retrieving detailed account data when full objects are needed, but it does not explicitly state when to use this over siblings or provide exclusions. The context is clear but lacks explicit alternative guidance.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds key behavioral details: batch shape {results, errors}, missing paid/status field, and the correct interpretation of payments[] (not indicating payment of this bill). 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 detailed and front-loaded with the main purpose, but it becomes lengthy with multiple warnings and usage notes. Every sentence serves a purpose, but it could be streamlined slightly without losing 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 the tool's complexity (credit card billing) and lack of output schema, the description covers all critical context: output fields, batch shape, missing status field, billId inconsistency, and guidance to sibling tools. It is fully self-contained for correct agent usage.

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

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

The only parameter, bill_ids, is fully explained: it's an array of strings, required, and the description advises how to discover the IDs using openfinance_list_credit_card_bills first. Since schema coverage is 0%, the description compensates 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?

The description clearly states that the tool returns bill-level detail for credit card bills by ID, listing specific fields (financeCharges, payments). It explicitly distinguishes itself from the transaction listing tool by stating what it does NOT return, and it names the sibling tool for 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?

Provides explicit when-to-use (need bill-level detail) and when-not-to-use (need individual transactions). Names specific alternatives: openfinance_list_transactions for transactions and openfinance_list_credit_card_bills for paid status. Warns about misinterpretation of payments array.

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 useful behavioral details: what fields are returned (executionStatus, connector metadata, reconnect_url) and the specific behavior of the reconnect_url for re-authentication without consuming a slot. This goes beyond the annotations without contradiction.

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

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

The description is somewhat lengthy but well-structured, front-loading the main purpose and then providing detailed behavior. It balances completeness with clarity, though 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?

Given no output schema, the description adequately describes the return structure for both single and bulk modes. It covers the main fields and the reconnect_url functionality. Minor gaps like error handling or permissions are not critical for this read-only tool.

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

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

The input schema has no descriptions (0% coverage), but the description compensates by explaining the effect of omitting `item` (returns all), passing `item` (single result), and using `item_ids` for bulk. This adds meaning beyond the schema alone.

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 fields like UPDATED, UPDATING, LOGIN_ERROR, executionStatus, and reconnect_url. This differentiates it from sibling tools like openfinance_list_connections which list connections rather than providing detailed status.

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

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

The description provides explicit guidance on usage: omit `item` to get all linked banks, pass `item` for a single bank, and accepts item_ids for bulk execution. It does not explicitly mention when not to use or compare to alternatives, but the usage patterns are 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 readOnly, idempotent, non-destructive. Description adds batch behavior and error structure, but no additional side effects, rate limits, or auth details. Adds moderate value beyond annotations.

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

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

Description is a single sentence that efficiently conveys purpose, usage context, fields, and batch shape. No wasted words, but could be slightly more structured (e.g., bullet points for fields).

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 lists key return fields (interestRates, charges, etc.) and batch result shape. Adequate for a retrieval tool with annotations covering safety. Minor omission: no error detail beyond {results, errors}.

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 explaining loan_ids is an array of strings (1-50 items) and how it's used in batch. Adds meaning beyond schema structure.

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

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

Description explicitly states it returns full loan detail by ID, lists specific fields (interestRates, charges, etc.), and distinguishes from sibling openfinance_list_loans by saying 'Use after openfinance_list_loans to deep-dive on a specific contract.'

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

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

Provides clear usage context: use after openfinance_list_loans for deep-dive. Specifies batch input (1-50 loan_ids) and output shape ({results, errors}). Lacks explicit when-not-to-use or alternatives, but context is 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?

Discloses important behavioral traits beyond annotations: provider_incident block indicating unreliable values, identity_notice requiring deduplication, connector-dependent credit balance meaning, and the distinction between account name (legal entity) and bank (brand).

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?

While lengthy, the description is well-structured with clear sections and front-loads the core purpose. Every sentence adds value given the complexity, so it is appropriately concise but could be slightly more succinct.

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 covers return fields, edge cases (provider_incident, identity_notice), and cross-references related tools. It is complete for a tool with 4 parameters and nuanced 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?

Adds meaning to all four parameters (item, type, item_id, item_ids) beyond the schema. Explains omission vs. passing item, type enumeration, and bulk support via item_ids. Schema coverage was 0%, making the description essential.

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

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

The description clearly states the tool returns accounts for bank connections, specifies types (BANK/CREDIT), and lists included fields. It distinguishes from siblings like openfinance_get_account_balance and openfinance_get_credit_card_bill by noting when to use those instead.

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

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

Provides explicit when-to-use guidance: omit item for all accounts, pass item for a single bank, and directs to openfinance_list_credit_card_bills for standardized bill amounts. Also warns about credit balance interpretation.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral details: cached for the session, single aggregated response, no batch ids, and field structure. This provides 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?

The description is concise at three sentences, front-loaded with the main action, and every sentence adds value by describing the output fields and caching behavior.

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

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

Given no output schema, the description adequately explains the return structure (fields: id, description, descriptionTranslated, parentId, parentDescription). It also covers caching and aggregation behavior. Slightly missing explicit mention that it returns a list, but 'taxonomy' implies it. Overall complete for a simple read-only tool.

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

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

There are zero parameters, and schema coverage is 100%. The description does not need to add parameter info; baseline for 0 params is 4. The description effectively explains what the tool returns without 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 'Returns Pluggy's transaction category taxonomy', specifying the verb and resource. It mentions caching and links the categoryId to the sibling tool openfinance_update_transaction_category, distinguishing its purpose from other tools.

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

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

The description implies usage before calling openfinance_update_transaction_category via the mention of categoryId. It also notes caching and single aggregated response. However, it does not explicitly state when to avoid using it or provide alternatives, but given its simplicity and read-only nature, the context 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?

Annotations already indicate safe read operation. Description adds that reconnect_url does not consume a slot or require disconnecting, which is non-obvious. 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?

Single paragraph with clear front-loading of purpose and output fields. Every sentence is informative with no redundancy.

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

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

Describes output structure and reconnect/add URLs. Lacks mention of error cases or pagination, but given no parameters and typical use, adequate. Could mention that list is all saved connections.

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; schema coverage is 100%. Baseline score of 4 applies as description adds no extra parameter info nor is needed.

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

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

Clearly states the tool returns saved bank connections and lists specific fields (connector_id, item_id, etc.). Differentiates from sibling tools like openfinance_list_accounts and connection-related tools.

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

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

Provides explicit when to use reconnect_url (re-authentication, LOGIN_ERROR) and what it does not require. Lacks direct comparison to all siblings but gives sufficient context for the main use case.

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=true, idempotentHint=true, destructiveHint=false. Description adds critical behavioral context: complex payment_status derivation, connector asymmetry, bill_grouping_reliability warning, and open_bill availability nuances. 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, covering many edge cases. While front-loaded with main result, it could be more concise and better structured with sections or bullet points. Some redundancy (e.g., repeating 'do not assume' multiple times).

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 meticulously details return fields, derived values (payment_status, open_bill, future_bills), warnings, and limitations. Completeness is high for a complex financial tool.

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

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

Schema coverage 0% means description must compensate. It deeply explains include_open_bill, account_id, account_ids, but page and page_size are not described. Main parameters are well-covered, but minor gap prevents a 5.

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

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

The description clearly states the tool returns closed credit card bills for CREDIT-type accounts, listing specific fields. It distinguishes from siblings like openfinance_get_credit_card_bill (single bill) and openfinance_list_transactions (transactions vs bills), and mentions bulk support via account_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?

Extensive guidance on when to use, including opt-in for open_bill, connector asymmetry, and when not to use (e.g., not to reconstruct total by summing transactions). Provides alternatives like openfinance_list_transactions for itemized purchases.

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 read-only and idempotent. The description adds crucial behavioral traits: error handling for 403 when investments not enabled, and a detailed data integrity mechanism for mass zeroing (cross-checks transaction history, flags suspect_zeroed). This exceeds 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 front-loaded with purpose and structured in clear sections (return values, error handling, data integrity, bulk). It is somewhat lengthy but every sentence adds value. Could be slightly more concise while retaining detail.

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

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

Given no output schema, the description thoroughly explains return format (total, results, warning) and data integrity flags. It covers edge cases (suspect zeroed), error handling, and bulk execution, making it complete for an agent to understand behavior and outputs.

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 6 parameters with 0% description coverage. The description only partially adds context by listing investment types that align with the 'type' enum, and mentions item_ids for bulk. It does not explain page, page_size, item, or item_id individually, leaving agents uninformed about their usage.

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

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

The description clearly states the tool returns an investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.) and details (balance, rates, issuer). This distinguishes it from siblings that handle accounts, transactions, or 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?

Usage is clear: for investment portfolio retrieval. The description mentions graceful error handling (returning warning instead of throwing) and bulk support via item_ids. However, it does not explicitly state when not to use it or suggest alternatives, though the purpose is specific enough.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds useful context like return field details and bulk capability, which augments 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?

Efficient two-paragraph structure with key info front-loaded. Could be slightly leaner but contains 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?

Covers purpose, prerequisite, and bulk support, but lacks details on pagination parameters, error handling, and response 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 description coverage is 0%, so description must compensate. It explains investment_id and investment_ids, but does not describe page or page_size parameters.

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

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

Clearly states it returns movement history for a specific investment position, listing types and fields, and distinguishes from sibling openfinance_list_investments by mentioning prerequisite.

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 a clear prerequisite ('Use after openfinance_list_investments to get the investment_id') and mentions bulk support, but 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?

Adds significant context beyond annotations: sequential queries with rate-limit spacing, return format as '{ results, errors }' per connection, and behavior when 'items' is omitted. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint all consistent).

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

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

Two sentences front-load the purpose and then provide usage and details. Every sentence adds value with no redundancy or wasted words.

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

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

Given no output schema, the description explains the return structure ('{ results, errors }' per connection). Does not detail the fields within results or mention pagination, but for a list tool with one parameter, this is largely 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?

With 0% schema coverage, the description fully explains the 'items' parameter: an array of connection selectors (item_id uuid, connector_id, or connector_name) and the effect of omitting it. However, it does not explicitly state the parameter is optional, though implied by schema having no required.

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 lists loan contracts per bank connection, specifying the endpoint 'GET /loans'. It distinguishes from sibling 'openfinance_get_loan_detail' by focusing on listing, not retrieving a single loan.

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 pass 'items' (specific connections) and when to omit it (all banks). Does not mention when to use alternatives like 'openfinance_get_loan_detail', but the context is clear enough 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?

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds significant behavioral context: auto vs manual pagination with ceiling and truncation, error return format, search_queries semantics, detail levels and their per-row token cost, account echo block, and credit card pending/posted variation by connector. 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 well-structured, starting with main purpose then detailing parameters and edge cases. It is verbose but every sentence adds value. A slight trimming could improve conciseness without losing clarity, but it remains focused and organized.

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

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

Given the tool's complexity (8 parameters, no output schema), the description covers all essential aspects: response structure (account echo, transactions, truncation), error handling, credit card specifics, bulk support, and integration with sibling tools like openfinance_get_item_status and openfinance_list_credit_card_bills. It is fully comprehensive.

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

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

Schema description coverage is 0%, so the description bears full burden for 8 parameters. It explains from/to ISO format, search_queries case- and accent-insensitive substring OR semantics, detail enum with compact/rich/raw and usage, and pagination parameters (page, page_size) with auto vs manual behavior. All parameters are thoroughly documented.

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 a bank account, distinguishing BANK and CREDIT types. It specifies the verb 'return' and the resource 'transactions', and contrasts with sibling tools like openfinance_list_credit_card_bills and openfinance_list_transactions_by_item.

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 extensive guidance: for CREDIT accounts it is the ONLY way to get itemized transactions, advises against summing by billId, and directs to openfinance_list_credit_card_bills for standardized totals. It also suggests checking connection health via openfinance_get_item_status when total is 0 for CREDIT accounts, and notes provider incidents.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds important behaviors: truncation at 5000 transactions/account with truncated:true flag, and provider_incident block when provider has open incident, affecting data completeness.

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

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

Front-loaded with purpose, well-structured with separate notes on bulk support and provider incidents. Some redundancy (e.g., 'in ONE call' repeated) but overall efficient for a complex 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?

Covers return types (compact summary fields, per-account breakdown, top lists), truncation, provider incidents, and bulk execution. Missing exact structure of nested fields, but adequate given no output schema.

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

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

Schema coverage is 0%, but description explains parameters: item (accepts connector_id, connector_name, or item_id), from/to as ISO dates, granularity and detail enums with meanings, and top_n implied by top_despesas/recebimentos. Adds significant meaning beyond 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 provides consolidated cash-flow analysis for a whole bank connection in one call, resolving accounts internally. It distinguishes from sibling tools by noting it avoids separate calls to list_accounts and individual transaction endpoints.

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

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

Explicit guidance on when to use (e.g., for annual/monthly analysis, cash flow, top expenses) and when not to use alternatives (no need to call list_accounts first). Details granularity options and bulk support.

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. Description adds value by detailing return structure (global indicator, degraded components, incidents, and `your_banks_affected`), but does not mention potential rate limits or authentication specifics, which are minor gaps.

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 well-structured with front-loaded purpose followed by usage context and return details. While slightly verbose, each sentence adds value and no redundant 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?

Despite lacking an output schema, the description comprehensively explains return values and usage context. It covers the tool's role relative to siblings and provides enough detail for effective 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?

No parameters exist, and schema coverage is 100%. Baseline for zero parameters is 4. Description does not need to add parameter info, so this score reflects adequate handling.

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 'Checks the LIVE operational status of the Open Finance provider' with specific verb and resource, and distinguishes it from the sibling tool `openfinance_get_item_status`, 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?

Explicitly explains when to use: 'whenever data looks incomplete or stale... connection shows UPDATED', and contrasts with alternative (`openfinance_get_item_status`), providing clear situational guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds behavioral context: returns connect_url, honors user plan, caveat warnings for manual reconnection, and never dumps full catalog without keywords. 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 relatively long but each sentence adds value. It front-loads the main action and return items. Could trim some redundant phrasing, but overall efficient for the complexity.

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

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

Given no output schema, the description adequately lists returned fields (connector id, access, audience, linked connections, connect_url). It also covers caveats and plan behavior. Might miss structure of linked connections, but sufficient for a search tool.

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

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

Schema has 0% description coverage; the description compensates by explaining 'keywords' as an array of bank names (with examples) and noting it is REQUIRED behaviorally. It also explains 'include_accounts' returns linked connections and accounts when true.

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

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

The description clearly states it searches bank connectors by name and returns key details including a connect_url. It explicitly says to call this BEFORE connecting, distinguishing it from sibling 'connect'. The verb 'searches' and resource 'bank connectors' are specific.

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

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

Provides clear usage context: call before connecting, pass keywords (required), and surfaces caveats about non-Open-Finance connectors and plan behavior. Does not explicitly state when not to use, but the required keywords condition implies it should not be used without them.

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 important behavioral details beyond annotations: it overrides automatic categorization, creates category rules for future transactions, and describes batch behavior (per-item errors do not fail the whole batch). This adds significant value since annotations only mark readOnlyHint as 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 front-loaded with the action and endpoint, then provides necessary details. While it is somewhat long, every sentence serves a purpose. Minor redundancy could be trimmed, but overall it is well-structured.

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

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

Given the complexity (batch update with side effects) and lack of output schema, the description covers all essential aspects: how to call it, side effects (rule creation), response format, and error handling. It is complete and leaves no significant 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 0% schema description coverage, the description fully explains the parameter semantics: the items array structure, required fields (transaction_id and category_id), and how to obtain these from other tools. It also details the response shape, thoroughly 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 the resource (transactions). It distinguishes from sibling tools by specifying the use of IDs from openfinance_list_transactions and openfinance_list_categories, making it unique among transaction-related tools.

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

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

Provides clear context for use: to fix miscategorized transactions and improve future categorization accuracy. It explains the input structure and source of IDs, but does not explicitly state when not to use this tool or mention alternatives, which is acceptable given the specificity of the tool.

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

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

The annotations set idempotentHint=true, but reporting a bug is inherently non-idempotent (each call creates a new report). This is a contradiction. The description does not clarify the behavioral traits beyond the action itself, and fails to disclose important details like what happens after reporting (e.g., confirmation, no side effects).

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

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

The description is concise with two sentences. The first sentence states the purpose, and the second provides a usage hint. No unnecessary words. However, it could be more structured by listing all parameters briefly.

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 low schema coverage, no output schema, and the annotation contradiction, the description is incomplete. It fails to explain the return value, what happens after the report is sent, and the 'context' parameter. The agent lacks sufficient information to understand the full 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?

Schema coverage is 0%, so the description must compensate. It adds meaning for the 'conversation' parameter (include recent messages) but does not explain the 'context' field or the format/content of the required 'message'. This is insufficient for a tool with 3 parameters.

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

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

The description clearly states the tool is for reporting bugs, missing features, or feedback, using a specific verb and resource. It distinguishes from sibling tools which are primarily openfinance utilities or authentication tools.

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

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

The description gives a clear usage hint to include the conversation array for reproduction. Since there are no sibling tools with overlapping functionality, it implicitly tells when to use this tool. However, it does not explicitly state when not to use it or provide alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds no further behavioral traits beyond specifying the versions 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?

Single sentence, no wasted words, clearly communicates 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 version info tool with no output schema, the description is complete and sufficient.

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

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

No parameters, so description does not need to add param info. Baseline 4 per schema coverage rules.

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 uses specific verb 'Show' and resource 'current MCP platform and adapter versions'. Clearly distinguishes from sibling tools which handle authentication, financial data, 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 when-to-use or alternatives, but the tool's function is self-evident and simple. Context implies use when version info is needed.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by detailing the return content (installed MCPs, connection status, catalog tools counts). 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?

A single, well-structured sentence that efficiently conveys the tool's function. No wasted words.

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

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

Given the tool's simplicity (no parameters, no output schema), the description sufficiently explains the return value. It covers the key aspects of the toolkit state.

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 baseline is 4. The description correctly implies no input needed and does not need to explain 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 toolkit state (installed MCPs, connection status, and catalog tool counts). It is specific with verb 'Returns' and resource, and it distinguishes from sibling tools which focus on authentication, connections, or data retrieval.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives. However, the purpose is self-evident as a status check, and no competitors exist among siblings. Implicit usage is adequate.

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