Inter MCP

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

Annotations already provide idempotentHint=true and destructiveHint=false, and the description adds behavioral context: calling with no args returns a link, and with token sets session. No contradictions. It lacks details on error handling or side effects, but overall transparent.

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, front-loads the target audience (IDE agents), and efficiently explains three usage scenarios in three sentences. No wasted words, though slightly dense.

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 lack of output schema, the description doesn't explain return values or behavior after authentication. While annotations cover safety, the description could mention what the tool returns (e.g., success message or token). It is adequate but not 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 schema has 0% coverage for parameter description, but the description explains the 'token' parameter is a JWT from browser login and how to use it for session-only login. This adds meaning beyond the schema's bare definition.

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

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

The description clearly states the tool authenticates the user to the server, explaining two methods: permanent config-based token or session-only token paste. It also describes calling with no args to get a login link. This distinguishes it from siblings like 'connect' by focusing on credential setup.

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 usage guidance: best to add token to config for permanent connection, or paste token for session, or call with no args to get link. It does not explicitly mention when not to use or alternatives, but the context is clear.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds behavioral context (return values for different states) without contradicting 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?

Three concise sentences front-loaded with purpose. 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 zero-parameter, no output schema tool, the description explains the two main output states sufficiently.

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 schema coverage is 100%. Description adds no param info, which is appropriate. Baseline score of 4.

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

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

The description clearly states it returns connection status and URLs, distinguishing it from sibling tools like 'authenticate' or 'openfinance_list_connections'. It gives specific examples of output scenarios.

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?

Guidelines are implicit: use to check provider connectivity. Describes conditions (all connected vs missing credentials) but doesn't explicitly compare to alternatives like 'authenticate'.

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

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

Beyond annotations (readOnlyHint=false, etc.), the description reveals critical behaviors: invoke works even when MCP is not installed, returns connect links for credentials, checkout links for payment, and that install/uninstall/subscribe/cancel/invoke require admin. It also explains how search/describe flag installation status.

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 thorough but somewhat long; it front-loads the core purpose and flow, then expands into specifics. For a complex tool with many actions, the length is justified, though bullet points or clearer separation could improve readability.

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

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

Given the tool's complexity (13 parameters, no output schema), the description covers the overall behavior, core flow, edge cases (auth, payment, admin requirements), and lists all actions. Some parameters remain unexplained, but the description is largely sufficient for an agent to use 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?

With 0% schema description coverage, the description must compensate. It explains action enum and the core flow implicating parameters like query, mcp_id, tool_id, arguments, but does not detail many parameters (limit, message, conversation, request_name, etc.). The workflow is clear, but parameter-by-parameter semantics are 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 identifies the tool as 'THE official mcp.ai marketplace' and the primary entry point for discovering and running MCPs. It distinguishes itself from siblings by stating 'use THIS tool FIRST' before any external/generic registry, and outlines a specific core flow (search → describe → invoke) that sets it apart.

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 this tool vs. alternatives: 'use THIS tool FIRST' for capability queries; 'prefer invoke for a single/occasional use' over install; explains when to use list_tools, subscribe/cancel, report_bug, request_mcp. It also indicates that writes require 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?

The description expands on the destructiveHint annotation by specifying that consent is revoked, connection data is deleted, and a reconnection URL is returned. This adds valuable context beyond the annotation alone, though it does not detail potential side effects or reversibility.

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 concise, consisting of two clear, front-loaded sentences. Every sentence adds essential information: main action, consequence, and return value. No redundancy or unnecessary 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?

While the description covers the core behavior and return value, it lacks detail on the parameter 'item' and does not contextualize usage among siblings (e.g., suggesting listing connections first). For a simple destructive tool, it is adequate but not 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?

With 0% schema coverage for the single required parameter 'item', the description only vaguely references 'a specific bank' without explaining the parameter's format, source, or how to obtain it (e.g., from list_connections). This provides insufficient guidance for correct parameter 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 revokes consent and deletes connection data for a specific bank, making the data unavailable. This distinguishes it from sibling tools like openfinance_list_connections or openfinance_get_item_status, which are read-only or non-destructive.

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

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

The description implies the tool is used when one wants to disconnect a bank and revoke consent, but it does not provide explicit guidance on when to use it versus alternatives like openfinance_force_sync or connect, nor does it mention prerequisites like having an existing connection.

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, idempotent, openWorld hints). The description adds rich behavioral context: waits up to 60s, returns results/errors, explains statuses (needs_action, timed_out), and clarifies it pulls fresh data without disconnecting. 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 lengthy but well-structured with front-loaded purpose. Every sentence adds value. Minor nit: could be slightly tighter, but uses clear language and logical flow.

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

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

No output schema exists, but description explains return shape ({ results, errors }) and key fields (status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out). Fully covers the two parameters and waiting behavior. Complete 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?

Schema coverage is 0%, so description must compensate. It explains 'wait' boolean (true by default? for waiting, false for fire-and-forget) and 'items' array (pass selectors like item_id, connector_id, connector_name; omit for all). 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 the tool forces a bank to re-sync connections and waits for completion. It specifies the action (forces re-sync) and resource (bank connections), and distinguishes from sibling tools like openfinance_get_item_status (for checking progress) and openfinance_list_connections (no sync triggered).

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

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

Explicitly states when to use (stale balance/transactions), how it differs from disconnecting/reconnecting, and provides alternatives: openfinance_get_item_status for re-checking after timeout, wait:false for fire-and-forget, and omitting items to sync all. Provides clear usage 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. The description adds value beyond these: it specifies the REST endpoint, parameter limit, error behavior for credit accounts (structured warning instead of throwing), and response shape including errors array. No contradictions with annotations.

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

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

The description consists of three concise sentences, each serving a distinct purpose: purpose+endpoint, parameter constraint, and behavioral notes+response format. No filler or 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?

Given the simple tool (one array param) and the presence of annotations, the description covers endpoint, parameter constraints, error handling, and response shape. It omits prerequisites (e.g., needing account IDs from list_accounts) but these are implicit. Overall, it provides sufficient context for correct invocations.

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 adds meaning by specifying the array size constraint (1-50) and explaining that credit accounts may return warnings. This provides essential usage context beyond the schema's bare type definition.

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

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

The description clearly states the tool returns real-time balance per account id, using a specific verb 'Returns' and resource 'balance payload'. It is distinct from sibling tools like openfinance_list_accounts (which lists accounts) and openfinance_get_accounts_detail (which likely provides details not just 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 explains how to use the tool (pass account_ids array of 1-50), but does not explicitly state when not to use it or mention alternative tools. It provides context but no exclusions or comparisons.

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 behavioral context: includes creditData, batch shape with results/errors. No mention of auth or rate limits but annotations cover safety profile.

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 filler. Front-loaded with purpose and key details. Every sentence provides 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?

With one parameter and no output schema, description covers input format, batch handling, and return shape. Minor missing details like item type (strings) are in schema. Overall complete for a simple lookup 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% coverage, so description carries full burden. It specifies array format, size limit (1-50), and that results are per ID. This adds significant meaning beyond the schema's empty property descriptions.

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

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

Description clearly states it returns full account objects with extended creditData by ID. It distinguishes from siblings like openfinance_list_accounts (list vs detail) and openfinance_get_account_balance (balance vs full).

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 for batch account detail retrieval (array 1-50) but does not explicitly state when to choose this over list/balance tools or provide when-not guidance. Sibling context helps but direct guidance is minimal.

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 batch shape { results, errors }, notes that Pluggy does not return a paid/status field, explains the meaning of payments[] (previous bill's payment), and recommends openfinance_list_credit_card_bills for paid status. This adds value beyond the readOnlyHint and idempotentHint annotations.

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

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

Four sentences, front-loaded with purpose, then key details and caveats. No redundancy or fluff. Every sentence adds value.

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

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

Given no output schema, the description explains output fields (financeCharges, payments[] with subfields) and batch shape. Covers all necessary behavioral context and cross-references sibling tools. 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 only parameter is bill_ids (array of strings). With 0% schema coverage, the description compensates by explaining its purpose and usage ('Pass as array, discover ids first'). Could add more detail about id format but it's sufficient.

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

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

The description clearly states 'Returns bill-level detail for one or more credit card bills by id', using the specific verb 'Returns' and resource 'bill-level detail'. It distinguishes from siblings like openfinance_list_credit_card_bills (for discovery) and openfinance_list_transactions (for itemized transactions).

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

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

Explicitly says when to use this tool (to get bill detail) and when not to (for individual transactions, use openfinance_list_transactions). Provides instructions to first discover ids using openfinance_list_credit_card_bills and advises against assuming paid status from 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the tool's safe, read-only nature. The description adds valuable behavioral context by detailing the response format (returns { count, items } vs. single object), which goes beyond what annotations provide. No contradictions.

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

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

The description is extremely concise: two sentences that front-load the main purpose and then immediately clarify the parameter behavior. Every sentence adds essential information with no waste.

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

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

Given the tool's simplicity (one optional parameter, no output schema, read-only), the description is complete. It explains the response shape for both parameter modes, which is sufficient for an agent to understand the tool's behavior and output.

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

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

The input schema has zero description coverage (0%) for the single 'item' parameter. The description fully compensates by explaining that omitting 'item' returns all linked banks (as a list with count) and passing it returns a single bank's status. This is critical for correct usage.

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

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

The description clearly states it returns the current status of a bank connection with specific fields (UPDATED, UPDATING, LOGIN_ERROR, etc.), executionStatus, and connector metadata. It distinguishes between two distinct use cases (single bank vs. all linked banks), setting it apart from sibling tools like openfinance_list_connections which likely list connections rather than their status.

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

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

The description explicitly explains when to omit the 'item' parameter (to get status of all linked banks) and when to pass it (for a single bank). This provides clear context for usage, though it does not mention any alternatives or when not to use 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?

Adds value beyond annotations by explaining aggregation behavior when `item` is omitted, tagging of results, and connector-dependent credit balance meaning. No contradictions with annotations (readOnlyHint, idempotentHint, destructiveHint).

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?

Long but information-dense, front-loaded with purpose. Every sentence adds value given 0% schema coverage. 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?

Complete coverage: return fields, parameter behavior, caveats, cross-reference to sibling tool, and naming conventions. No output schema needed due to thorough description.

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?

0% schema coverage, but description explains `item` usage and indirectly clarifies `type` by listing account types returned. Does not explicitly state that `type` parameter filters results, but enum in schema makes it clear.

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 BANK and CREDIT accounts with specific fields, including balance, number, type, etc. It also distinguishes from sibling tools like openfinance_list_credit_card_bills by noting when to use them.

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 instructions on when to omit vs pass the `item` parameter (all banks vs single bank). Provides warnings about credit balance meaning and directs to another tool for standardized bill data. Includes user-facing naming advice.

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

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

Annotations already declare `readOnlyHint: true`, `destructiveHint: false`, and `idempotentHint: true`. The description adds valuable context: the response is cached for the session, it's a single aggregated response (no batch ids), and it explains the language-locale fields (`description` vs `descriptionTranslated`). 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 two sentences with zero filler. The main purpose is stated first, followed by structured details in the second sentence. Every part adds value, and the information is efficiently packed without being 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?

Given zero parameters and no output schema, the description fully covers the tool's behavior: return type, caching, field meanings, and cross-reference to another tool. It leaves no meaningful gaps for an agent to need further clarification.

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

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

There are no parameters, and schema coverage is 100%. The description adds significant meaning beyond the empty schema by detailing the response fields: `id`, `description`, `descriptionTranslated`, `parentId`, `parentDescription`. It also notes the Portuguese translation preference, which helps agents localize output.

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

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

The description clearly states the tool returns 'Pluggy's transaction category taxonomy (GET /categories), cached for the adapter session.' It distinguishes from siblings by noting it's a 'single aggregated response — no batch ids.' It also explains what each entry contains, making the purpose precise 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 explains the tool is for obtaining category taxonomy and explicitly notes caching behavior. It also links to another tool by stating the `id` is used by `openfinance_update_transaction_category`. It does not explicitly mention when not to use it or name alternatives, but the context is clear enough for most use cases.

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 idempotentHint=true, so the description's mention of returning an add_connection_url adds useful behavioral context. 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?

A single, front-loaded sentence that efficiently communicates the tool's action and output. No extraneous words.

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

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

The description fully explains what the tool returns and includes the add_connection_url detail. It does not discuss pagination or filtering, but given simplicity and no parameters, it is sufficiently complete.

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

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

No parameters exist in the schema, so schema_coverage is 100%. Baseline for zero parameters is 4; the description does not need to add parameter semantics.

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

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

The description clearly states the verb 'returns' and the resource 'saved bank connections', and lists specific fields returned (connector_id, item_id, bank name, add_connection_url). It distinguishes from sibling tools that list accounts or transactions.

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

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

The description implies use for viewing existing connections or getting a URL to add new ones, but it does not explicitly state when to use this tool versus alternatives like openfinance_list_accounts or openfinance_search_bank_connectors. No when-not-to-use guidance is provided.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds extensive behavioral context: no paid/status field from Pluggy, payment date mapping logic, derived payment_status, connector asymmetry for open bills, and that results are bill-level summaries. 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?

The description is long but well-structured with clear sections (IMPORTANT, CONNECTOR ASYMMETRY) and front-loaded main purpose. While every sentence adds value, some details could be condensed or moved, but given complexity, it remains concise.

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

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

No output schema exists, so the description must explain return values. It does so thoroughly: lists fields (dueDate, totalAmount, payments[], payment_status, etc.), explains payment_status_legend, open_bill structure, and contrasts with transactions tool. Provides complete guidance 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?

Schema description coverage is 0%, so the description carries the burden. It explains account_id, account_ids (batch), and include_open_bill in detail. However, page and page_size are not explicitly described, though their context is implied. Overall adds significant value 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 the tool returns closed credit card bills for CREDIT-type accounts, and contrasts with sibling tools like openfinance_list_transactions for itemized transactions and openfinance_get_credit_card_bill for single bills. The verb 'list' is appropriate.

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

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

Provides explicit guidance on when to use (closed bills), when to use alternatives (openfinance_list_transactions for itemized purchases), and explains the opt-in include_open_bill parameter with connector asymmetry. Warns against assuming payment status from payments[].

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds value by revealing error handling: it returns a structured object {total, results, warning} instead of throwing on 403 or other errors. This goes beyond the annotations.

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

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

The description is only two sentences long, front-loading the main purpose and key details. Every sentence adds value: the first specifies the output and scope, the second clarifies error behavior. No superfluous text.

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?

Considering the tool has 4 optional parameters, no output schema, and good annotations, the description covers return structure, error handling, and asset types. It lacks parameter details but is otherwise 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?

Schema description coverage is 0%, so the description should explain the parameters (item, page, type, page_size). It only mentions the enum values for type implicitly via the asset list, but does not explain other parameters or how they affect the results. This leaves a significant 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 returns the investment portfolio for a connection, enumerating asset types (FIIs, stocks, ETFs, etc.) and fields returned. This distinguishes it from sibling tools like openfinance_list_investment_transactions and openfinance_list_accounts.

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

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

The description explicitly defines when to use the tool (for a connection with INVESTMENTS enabled) and what to expect. It does not offer explicit alternatives or exclusions, but the context is clear enough for an AI agent to decide.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral details: lists returned fields, transaction types, and bulk support via investment_ids. This enriches beyond 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?

Two concise sentences. First sentence covers purpose and output. Second sentence adds usage instruction and bulk support. No excess words, front-loaded with key 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?

Covers prerequisite and bulk support, lists return fields and types. However, lacks pagination details (page, page_size behavior), sorting order, and no output schema to supplement. Adequate but has clear gaps for a parameter-rich tool.

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

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

Schema coverage is 0%, so description must compensate. It explains investment_id implicitly and investment_ids explicitly ('bulk support'). However, page and page_size lack any description. The description adds value for half the parameters but leaves gaps.

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

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

The description clearly specifies the resource (investment movement history) and action (returns), lists transaction types (BUY, SELL, etc.), and distinguishes it from sibling tools like openfinance_list_investments and openfinance_list_transactions by focusing on a specific investment position's detailed history.

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 prerequisite: 'Use after openfinance_list_investments to get the investment_id.' This guides the agent on proper sequencing. No negative use cases or alternative tool mentions, but the context is clear enough for correct invocation.

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. Description adds specific behavioral details: sequential querying with rate-limit spacing and per-connection result/error format, which goes beyond annotations.

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

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

Three concise sentences with front-loaded purpose. Every sentence adds value; no redundancy or 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, description explains return structure. Parameter usage is fully covered. Context of sibling tools is respected; tool is self-contained with clear scope.

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 only shows 'items' as array of strings; description enriches with types (uuid, connector_id, connector_name) and usage semantics (one per connection). 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?

Clear verb 'Lists loan contracts' with specific resource 'per bank connection' and endpoint 'GET /loans'. Distinguishes from sibling listing tools by focusing on loans and connection-based query.

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 the 'items' parameter (to fetch specific connections) and when to omit it (to list across all banks). Includes rate-limit behavior. Lacks explicit alternatives among siblings, but context is clear.

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

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

Discloses important behaviors beyond annotations: CREDIT PENDING vs POSTED varies by connector, search_queries aggregation up to 5000 with truncation, error returns on upstream failures, and connection health for zero totals. No contradiction with annotations.

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

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

Well-structured and front-loaded, but slightly long due to detailed explanations of connector-specific behaviors and error handling. 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?

Given the complexity (bank-specific behavior, multiple parameters with no schema descriptions, no output schema), the description fully covers purpose, usage, parameters, error handling, and cross-tool guidance, leaving no critical 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?

Adds comprehensive meaning to all parameters since schema has 0% description coverage: explains date filters (ISO YYYY-MM-DD), pagination (max 500/page), search_queries (case- and accent-insensitive substring OR match), and bulk support via account_ids.

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

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

Clearly states it returns transactions for bank accounts, distinguishes CREDIT vs BANK behavior, and differentiates from 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?

Explicitly states when to use this tool over alternatives: for CREDIT accounts, it's the only way to get itemized transactions; for standardized totals, use openfinance_list_credit_card_bills. Also provides guidance on connection health checks and date filtering.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds valuable behavioral context: truncation at 5000/account, granularity differences (compact vs heavy), and filtering by type. 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 dense but well-structured, front-loading the purpose. Each sentence adds value, though some Portuguese terms may require translation. Length is appropriate for the complexity.

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

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

Given 6 parameters and no output schema, the description covers most aspects but misses explicit explanation of the top_n parameter and does not describe the return format for raw granularity. Could be more complete.

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

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

Schema coverage is 0%, so description must compensate. It explains most parameters: item (connector_id/name/item_id), from/to (ISO dates), granularity, type, and top_n implied via 'largest N.' However, top_n parameter is not explicitly described, and 'from'/'to' format could be more precise.

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

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

Description clearly states it's for consolidated cash-flow analysis over a period, resolving accounts internally. It distinguishes from sibling tools like openfinance_list_accounts and openfinance_list_transactions by emphasizing single-call capability.

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

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

Explicitly tells when to use (one-call analysis for a connection or all banks) and when not to (no need to call list_accounts first). Provides example use cases in Portuguese and explains granularity options.

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, destructiveHint, idempotentHint. Description adds valuable context on return values (global indicator, degraded components, open incidents, your_banks_affected) beyond annotations. No contradictions.

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

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

Description is front-loaded with main purpose and well-structured: what it does, when to use, return details. Slightly long but each sentence adds value. Minor redundancy in repeating 'provider-side problem' but overall concise.

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

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

No output schema, so description covers return values adequately: global indicator, degraded components, open incidents, your_banks_affected. Sufficient for a 0-parameter tool. Could mention more about response format (e.g., fields), but given how comprehensive the description is, it meets needs.

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

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

Input schema has 0 parameters with 100% schema coverage. Description adds no param info as there are none. Baseline for 0 params is 4, and the description is adequate.

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

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

The description clearly states it checks the LIVE operational status of the Open Finance provider, distinguishing it from the sibling tool 'openfinance_get_item_status'. The verb 'Checks' and specific resource 'LIVE operational status' make the 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 states when to use: when data looks incomplete or stale even though a connection shows UPDATED. Contrasts with sibling tool 'openfinance_get_item_status' and explains what it reveals (upstream outage). Provides clear use case and differentiation.

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

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

Beyond annotations (readOnly, idempotent), it adds that the tool honors the user's plan (hiding PJ banks for PF users) and avoids dumping the entire catalog.

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

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

Two sentences, front-loaded with main action, 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?

Given two parameters and no output schema, the description explains the return value per match and plan behavior, fully covering the tool's needs.

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 explains both parameters: keywords usage with examples and include_accounts effect, adding substantial 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 searches bank connectors by name and returns specific fields including a connect URL, distinguishing it from siblings like openfinance_list_connections.

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

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

Explicitly says 'Call this BEFORE connecting' and notes that 'keywords[] is REQUIRED — without it returns a hint', providing clear when-to-use and what happens if misused.

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

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

The description discloses key behavioral traits beyond annotations: it is a PATCH operation (mutating), overrides automatic categorization, and automatically creates a Category Rule for the client, affecting future similar transactions. This adds significant context not covered by annotations (readOnlyHint=false, etc.). 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 relatively lengthy but information-dense. Each sentence adds value: endpoint, parameter structure, side effects, output format, error handling. It could be slightly more concise, but the structure is logical and front-loaded with the core purpose.

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

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

Given the tool has one parameter (nested object) and no output schema, the description provides complete context: parameter format, behavioral side effects, batch output shape, and error handling. It leaves no critical gaps for an agent to 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?

The input schema has 0% description coverage for its parameters. The description fully compensates by explaining that `items` is an array of objects with `transaction_id` and `category_id`, and specifies where to obtain these IDs (from sibling tools). This adds critical meaning beyond the bare 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?

The description clearly states the tool's purpose: 'Corrects the category of one or more transactions (PATCH /transactions/:id).' It specifies the action (correcting categories), the resource (transactions), and how to construct the input using IDs from sibling tools. This distinguishes it from other tools like openfinance_list_transactions and openfinance_list_categories.

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

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

The description explains when to use the tool: to fix miscategorized transactions and improve future categorization by teaching Pluggy. It provides detailed usage instructions (pass items as array of transaction_id and category_id, with sources). However, it does not explicitly state when not to use it or suggest alternatives, though the context is clear enough.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false; the description adds the need for conversation context but does not elaborate on side effects or error behavior, offering moderate additional value.

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

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

Two sentences with no waste: the first states purpose, the second provides a key usage guideline. 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?

For a simple feedback tool with 3 parameters and no output schema, the description should explain parameter formats and return values. It does not cover the 'context' parameter or what happens after submission, leaving 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?

With 0% schema description coverage, the description only mentions the conversation parameter, leaving 'message' and 'context' unexplained. It fails to add sufficient 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 reports bugs, missing features, or feedback, distinguishing it from sibling tools that focus on financial data operations.

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

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

The description explicitly instructs to include the conversation array for reproduction, providing practical guidance. It does not mention when not to use, but sibling tools are unrelated, making usage clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds that the tool shows platform and adapter versions, but no additional behavioral traits are disclosed beyond what annotations provide.

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

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

The description is a single, concise sentence with no unnecessary words. It is front-loaded with the action and resource.

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

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

Given no output schema and no parameters, the description fully specifies what the tool does: it shows platform and adapter versions. No additional information is 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?

With zero parameters and 100% schema description coverage, the description doesn't need to explain parameters. A baseline of 4 is appropriate per guidelines.

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 verb 'Show' and the resource 'current MCP platform and adapter versions', clearly differentiating from sibling tools like authenticate, connect, or openfinance 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?

Although no explicit when-to-use or alternatives are stated, the tool's simplicity and lack of parameters make its usage self-evident. The description implies it should be used when version information 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 provide readOnlyHint, idempotentHint, destructiveHint=false. Description adds specific return content (MCPs, connection status, catalog counts), which is beyond annotations. No contradictions.

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

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

Single sentence, 15 words, front-loaded with action and outcome. 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 no parameters and no output schema, the description adequately states what the tool returns. Could mention it's a JSON snapshot, but not necessary for minimal completeness.

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

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

No parameters exist, so schema coverage is trivially 100%. Baseline score of 4 applies; no additional parameter information needed.

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

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

Description clearly states it returns toolkit state with specific details (installed MCPs, connection status, catalog tools count). Distinguishes from sibling tools which are authentication, open finance, 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?

While it doesn't explicitly state when to use vs alternatives, the read-only informational nature is clear. No exclusion criteria needed given zero parameters and no side effects.

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