InfinitePay MCP

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

Annotations indicate idempotentHint=true, and description confirms calling with no args returns a link (idempotent). Also explains the distinction between permanent and session login, adding context 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?

The description is somewhat lengthy but packs essential details (MCP.AI context, two methods, token format). It is front-loaded with the target audience. Could be slightly trimmed without losing clarity.

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

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

No output schema is provided, and the description does not specify what the tool returns upon success or failure. However, for an authentication tool, the primary action (saving a token) is understood. Additional details on return values would improve completeness.

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

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

Although schema coverage is 0%, the description fully explains the 'token' parameter: it is a JWT string to be pasted, and clarifies that omitting the token yields a login link. This compensates well for the missing schema documentation.

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

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

The description clearly states the tool's purpose: authentication by providing an access token either via config (permanent) or by pasting a JWT (session). It distinguishes from siblings like 'connect' which likely handles other integration flows.

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

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

Explicitly describes two usage scenarios: adding token to config for permanent connection, or calling with token argument for session login, or with no args to get a link. Provides clear 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 (readOnlyHint=true, idempotentHint=true, destructiveHint=false) align with description. Description adds value by specifying exact return fields (authenticated, pending[], connect_url) under different conditions. No contradiction.

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

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

Two sentences, front-loaded with main purpose, no wasted words. Efficiently covers multiple cases.

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 0 params and no output schema, description sufficiently explains behavior and output. Could mention whether authentication is required, but overall complete for a status-check tool.

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

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

No parameters (schema coverage 100%), so baseline 4 is appropriate. Description adds no param info, but none 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?

Description clearly states verb 'Returns' and resource 'connection status and URLs', with concrete examples of output scenarios. It distinguishes from siblings by focusing on overall connection status rather than specific actions like authenticate or openfinance 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?

Implied usage: use to check connection status before other operations. However, no explicit guidance on when not to use or alternatives, nor prerequisite conditions like requiring authentication.

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

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

Annotations indicate readOnlyHint=false, consistent with write operations. The description discloses critical behaviors such as invoke running tools without installation (non-destructive), returning connect/checkout links for credentials/payment, and the fact that writes require workspace owner/admin. It adds context 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?

The description is comprehensive but dense, packing many details into a single paragraph. While every sentence adds value and the main purpose is front-loaded, a more structured format (e.g., bullet points for actions) would improve scanability. It is appropriately sized for the complexity.

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

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

Given the tool's complexity (13 parameters, multiple actions, no output schema), the description covers the core flow, action purposes, and edge cases like credential/payment handling. However, it lacks explicit details on return values or output structure, which would help agents parse results. It is almost complete but has minor 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 compensates by explaining the action enum and its values (search, describe, invoke, etc.) and how they orchestrate the flow. It references key parameters like mcp_id, tool_id, and arguments in context, but does not detail all 13 parameters individually. This adds sufficient meaning for an agent to understand the tool's operations.

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 explains its dual role: catalog for discovering MCPs/tools and a runtime to run them. It specifies the core flow (search→describe→invoke) and distinguishes it from sibling tools by stating 'use THIS tool FIRST, before any external/generic registry', making the purpose unequivocal.

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 is provided: 'use THIS tool FIRST' for capability searches, preference of invoke over install for one-off use, and specific when-to-use for each action (e.g., 'Use install only to make an MCP PERMANENT'). It also covers edge cases like credential/paid requirements and instructs to retry after user action.

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

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

Description adds context beyond annotations: it specifies that consent is revoked, data deleted, and data becomes unavailable. It also mentions the reconnection URL. No contradiction with annotations (destructiveHint: true).

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

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

Three sentences, no wasted words. Action is stated first, followed by consequence and return value. Highly efficient.

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

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

Covers the core action and outcome, but lacks parameter explanation, error conditions, or required permissions. For a simple destructive tool, it's adequate but has room for improvement.

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 one parameter 'item' with 0% description coverage. Description does not explain what 'item' represents (e.g., bank ID or connection ID). It only refers to 'specific bank' without linking to the 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?

The description clearly states the verb ('Revokes'/'deletes') and the resource (bank consent/connection). It also mentions the return value (add_connection_url). This distinguishes it from sibling tools like openfinance_list_connections.

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

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

No explicit guidance on when to use this tool vs alternatives. It does not mention prerequisites, when disconnection is appropriate, or when to use other tools like openfinance_force_sync or openfinance_list_connections.

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 the HTTP method (PATCH), polling behavior up to ~60 seconds, and explains the returned fields including `needs_action`, `timed_out`, and `synced`. It adds behavioral context beyond annotations, consistent with the non-read-only, non-idempotent nature of the operation.

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 with no extraneous words. It is front-loaded with the core action and every sentence adds critical information. Efficient and to the point.

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

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

Given no output schema, the description provides a complete picture of return values (results, errors, status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out). It covers error states and sync outcomes. Both parameters are fully explained. No gaps remain.

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

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

Schema description coverage is 0%, but the description fully compensates. It explains the `items` parameter as an array of selectors (item_id, connector_id, connector_name) and that omitting it syncs all. It explains `wait`: false means fire-and-forget. No parameters lack explanation.

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

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

The description clearly states the tool forces a bank to re-sync connections and waits for it to finish. It uses specific verbs ('Forces', 're-sync', 'WAITS') and identifies the resource ('connections'). It distinguishes itself from sibling tools like openfinance_get_item_status and mentions that it does not involve 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?

The description explicitly tells when to use ('when a balance or transaction list looks stale') and how to use it (pass `items` as an array or omit to sync all). It provides an alternative for timed-out syncs (openfinance_get_item_status) and explains fire-and-forget mode (wait: false).

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, idempotent, non-destructive. The description adds value by disclosing real-time nature, potential BALANCE_FETCH_ERROR for credit accounts, and structured warning instead of throwing, plus response shape including errors. No contradiction.

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

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

Three sentences: purpose, parameter usage, error/response. No redundancy, front-loaded with core function. Every sentence 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?

Provides response shape and error structure. Missing details on the balance payload fields (e.g., available vs current balance), but for a single-parameter tool, it 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?

Schema has 0% description coverage. The description adds meaning by specifying 'account_ids' as array of strings with size limit 1-50, and indicates it represents account IDs. This compensates 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 it returns real-time balance per account id, using a specific verb and resource. It does not explicitly differentiate from sibling tools like openfinance_list_accounts or openfinance_get_accounts_detail, 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?

The description provides usage context: pass 'account_ids' as an array (1-50) and notes error behavior for credit accounts. However, it does not give explicit guidance on when to use this vs alternatives, such as when to use openfinance_get_accounts_detail instead.

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 false, indicating a safe read operation. The description adds batch behavior (`results, errors` shape) and data content (extended creditData), but does not elaborate on auth or side effects beyond what annotations imply.

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 (30 words) convey the return value, usage, and structure. Every sentence earns its place without redundancy. 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 no output schema, the description describes the batch shape `{ results, errors }` and mentions extended creditData. It does not detail error codes or authentication, but annotations and the tool's read-only nature make this sufficient for agent use.

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

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

With 0% schema description coverage, the description adds meaning by specifying the array type (though inferred from schema) and a size limit (1-50). It does not explain that items are account IDs, but this is reasonable from context. The description partially compensates for 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 it returns full account objects with extended creditData per ID, distinct from sibling tools like openfinance_list_accounts which likely return summaries. It specifies the HTTP endpoint and batch shape, making the resource and action explicit.

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 usage guidelines: pass `account_ids` as an array with a 1-50 limit, and notes the batch response shape. It does not explicitly contrast with alternatives like list_accounts, but the context and sibling names imply when to use this tool (getting detailed records by ID).

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 show readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds nuanced behavior: notes Pluggy does NOT return a paid/status field, explains payments[] reflects payments registered during THIS bill's cycle typically of the PREVIOUS bill, and suggests using openfinance_list_credit_card_bills for paid status. No contradiction with annotations.

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

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

Description is moderately long but well-structured: starts with purpose, then exclusions, usage guidance, and behavioral note. Every sentence adds value; could be slightly more concise but still effective.

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; description explains response fields (financeCharges, payments with their subfields), batch shape, and critical behavioral insight about payments array. Comprehensive for a single-parameter 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%; description compensates fully by explaining bill_ids is an array of strings, advises how to obtain IDs (via openfinance_list_credit_card_bills), and mentions batch response shape { results, errors }. 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 explicitly states it returns bill-level detail for credit card bills by id, lists included fields (financeCharges, payments), and clarifies it does NOT return individual transactions. It distinguishes from sibling tool openfinance_list_transactions, making purpose clear and 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 explicit when-to-use (bill-level detail) and when-not-to (individual transactions, pointing to openfinance_list_transactions). Advises to first use openfinance_list_credit_card_bills to discover ids and specifies bill_ids parameter format as an 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 readOnly=true and idempotent=true, so the description adds value by detailing the response structure (status, executionStatus, connector metadata) and the two-mode behavior. No contradictions, and it enriches the behavioral understanding.

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 efficient sentences front-load the key return values and usage instructions. No redundant or irrelevant information. Every sentence 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?

For a simple tool with one optional parameter and no output schema, the description is sufficient to understand functionality and usage. It could elaborate on executionStatus and connector metadata fields, but given the complexity, it is adequately 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 single parameter 'item' lacks schema description, but the tool description fully explains its semantics: omitting returns all banks with a specific output format, passing it returns a single bank. This compensates completely for the schema gap.

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

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

The description clearly states it returns the status of a bank connection, listing specific values (UPDATED, UPDATING, LOGIN_ERROR) and distinguishes between two usage modes (all vs single bank). It differentiates from sibling tools like openfinance_list_connections by focusing on status rather than mere listing.

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 omit vs pass the 'item' parameter, and describes the output format for each case. It does not compare with alternatives or specify when not to use, but the context is clear.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description reveals that balance value is connector-dependent and warns against treating it as the current month's bill. Explains meaning of creditData fields.

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, front-loads the main purpose, and each sentence adds essential guidance without redundancy.

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

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

Given no output schema and complex behavior (item aggregation, credit balance dependency), the description is fully complete, including explanation of bank vs. brand naming.

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?

Both parameters are thoroughly explained despite 0% schema coverage. Describes the effect of omitting vs. passing 'item', and the meaning of 'type' enum values.

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 a bank connection, specifying types (BANK, CREDIT) and fields. It distinguishes from sibling by noting when to use openfinance_list_credit_card_bills for standardized amounts.

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 omit or include the 'item' parameter to list all banks vs. a single bank. Provides alternative tool for standardized credit card bill amounts.

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

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

Annotations already mark the tool as read-only and idempotent. The description adds value by revealing that the response is cached for the session, is a single aggregated response (no batch ids), and details the structure of each entry. No contradictions with annotations.

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

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

The description is three sentences with no wasted words. It front-loads the main purpose and then details fields and caching, each sentence earning 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?

For a zero-parameter read tool, the description is complete. It covers what is returned, field semantics, relationships to other tools, and caching behavior. Annotations cover behavioral traits, so no gaps remain.

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

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

The input schema has zero parameters, so baseline is 4. The description correctly adds no parameter information since none exist, and schema coverage is 100%.

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' and specifies the source (GET /categories). It details each field including the crucial `id` used by the sibling tool openfinance_update_transaction_category, distinguishing it from other list tools like list_accounts or list_transactions.

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

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

The description implies usage for obtaining category IDs before calling openfinance_update_transaction_category, but does not explicitly state when to use versus alternatives or provide exclusions. It notes caching behavior, which hints at one-time usage, but lacks direct 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 readOnlyHint true, idempotentHint true, destructiveHint false. The description adds the specific returned fields and the purpose of add_connection_url, but no additional behavioral traits like rate limits or error conditions.

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

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

Single sentence that is front-loaded with the main purpose and includes key details without redundancy.

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

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

For a parameterless, read-only tool with clear annotations, the description sufficiently covers what the tool does and returns. No output schema needed given simplicity.

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

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

No parameters in schema (0 params, 100% coverage). Baseline 4 applies; description adds no parameter info 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 saved bank connections with specific fields (connector_id, item_id, bank name, add_connection_url). This distinguishes it from other list tools like 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?

No guidance on when to use this tool versus siblings. The description only mentions the return value, not usage context or 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, idempotentHint, destructiveHint. The description adds significant behavioral context beyond annotations: it explains that Pluggy does not return a paid/status field, details payment cycle logic for payment assignment, describes derived payment_status, warns about connector asymmetry for open bills, and mentions the extra scan for include_open_bill. 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 very long but well-structured with clear sections (payment status, open bill, connector asymmetry). It is front-loaded with the core return. However, some redundancy exists (e.g., payment_status explanation repeated), and the length could be trimmed slightly without losing essential 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 all output fields, derived values, and edge cases. It provides complete behavioral context. However, it lacks documentation for the page and page_size parameters, which is a gap in completeness. Also, the description covers error scenarios (warning if CREDIT_CARDS not enabled) and references to other tools.

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

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

Schema description coverage is 0%, so the description must compensate. It explains include_open_bill and account_ids well, but page and page_size are not described at all. account_id is implied but not explained. This partial coverage means some parameters lack semantic guidance, earning a 3.

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 closed credit card bills for a CREDIT-type account, specifying key fields like dueDate, totalAmount, and payment details. It distinguishes itself from sibling tools like openfinance_list_transactions (for itemized purchases) and openfinance_get_credit_card_bill, making 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?

The description provides explicit guidance on when to use this tool (for closed bills, payment status, open bill opt-in) and when not to (e.g., for itemized transactions, use openfinance_list_transactions). It warns against misinterpreting payment data and explains connector asymmetry, giving 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 indicate read-only and idempotent. The description adds meaningful context: it lists the return fields and explains the non-throwing error handling for disabled products. This goes beyond annotations, though pagination and rate limits are not mentioned.

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 concise given the information load, but it is a single long sentence that could be split for readability. No unnecessary words; every part 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?

While the description covers output format and error handling, it omits details on parameter usage and does not address pagination or filtering by type. No output schema, so the agent relies entirely on the description. Sufficient for basic understanding but not fully complete.

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

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

Schema description coverage is 0%, so the description must explain parameters, but it provides none. The four parameters (item, page, type, page_size) are not mentioned at all, leaving the agent to guess their meaning and 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 is highly specific: it states exactly what the tool returns (investment portfolio) and lists asset types and fields. It clearly distinguishes from sibling tools like openfinance_list_accounts or openfinance_list_transactions by narrowing to INVESTMENTS product.

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

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

The description specifies when to use (for connections with INVESTMENTS enabled) and explains the fallback behavior (returns {total:0} instead of 403). It lacks explicit 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 read-only, idempotent, and non-destructive behavior. The description adds value by detailing the returned fields (e.g., quantity, value, expenses breakdown) and bulk support. This provides behavioral context 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 concise, with about four lines. It front-loads the core purpose, then details returned fields, and ends with usage guidance. Every sentence adds value without redundancy.

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

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

Given the tool's complexity (4 parameters, no output schema, annotations present), the description covers the return data well, including field details and bulk support. However, it does not explain pagination or response structure, leaving a minor gap in 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?

The description mentions investment_id and investment_ids, adding meaning to these parameters. However, it does not describe page and page_size, which are left unexplained. Since schema coverage is 0%, the description partially compensates but misses the pagination 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 that the tool returns movement history for a specific investment position, listing transaction types and fields. It distinguishes itself from sibling tools like openfinance_list_investments, which lists investments, not their 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 explicitly advises using this tool after openfinance_list_investments to obtain the investment_id, providing clear sequential usage guidance. It also mentions bulk support with investment_ids. While it doesn't explicitly state when not to use it, the guidance is sufficient for typical scenarios.

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

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

Annotations already declare readOnlyHint and idempotentHint, so safety is clear. The description adds behavioral context: sequential querying with rate-limit spacing and per-connection response format (results, errors). 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?

Four sentences front-loading the main purpose, then parameter details. Every sentence is necessary and 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?

Given no output schema, the description mentions the return structure { results, errors } per connection and rate-limit behavior. Could benefit from more detail on response fields or pagination, but overall adequate for a simple list tool with good annotations.

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

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

The input schema only shows items as an array of strings with 0% description coverage. The description fully explains it as connection selectors (item_id uuid, connector_id, or connector_name) and usage (one per connection, omit for all), adding crucial meaning.

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

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

The description explicitly states it lists loan contracts per bank connection via GET /loans. It distinguishes from sibling tools like openfinance_list_accounts by specifying the resource (loans) and scope (per connection).

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

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

Clear instructions on when to use: pass items for specific connections, omit for all. However, no explicit mention of when not to use or alternatives, though the sibling context implies other list tools.

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds significant behavioral context: CREDIT transaction behavior varies by connector (PENDING vs POSTED), search_queries semantics, truncation handling, error fallback, and bulk support. No contradictions with annotations.

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

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

The description is well-structured, front-loading the core purpose, then explaining credit-card specifics, filters, pagination, search, errors, and bulk support. Each sentence adds value, though it is somewhat lengthy. Could be slightly more concise but remains clear 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 (7 parameters, no output schema), the description covers purpose, account types, behavior variations, filter usage, pagination limits, search behavior, error handing, and connection health. It does not describe the return structure in detail, but the provided context is sufficient for effective use.

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 thoroughly explains from/to (ISO format), page_size (max 500), search_queries (case-insensitive, OR), and mentions account_ids for bulk. However, it omits details on the page parameter defaults and exact format for from/to. Despite this, it adds substantial 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 returns transactions for BANK or CREDIT accounts, distinguishes between account types, and uniquely positions this tool as the only way to get itemized transactions for CREDIT accounts. It also links to sibling tool openfinance_list_credit_card_bills, providing clear differentiation.

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 when-to-use guidance, including account type applicability and that for CREDIT accounts this is for itemized transactions. It gives when-not-to-use by directing users to openfinance_list_credit_card_bills for standardized totals. It also explains filter usage, pagination limits, search behavior, error handling, and connection health checks.

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

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

Beyond annotations (readOnly, idempotent, non-destructive), the description discloses truncation at 5000 transactions per account with a truncated flag, output structure differences between monthly and raw granularity, and that raw is heavier. It also explains that it internally resolves account IDs, reducing API calls.

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

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

The description is comprehensive but slightly verbose (mix of Portuguese concepts, detailed output breakdown). However, it is front-loaded with the main purpose and each sentence adds value. Minor redundancy could be trimmed, but overall 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?

Despite no output schema, the description thoroughly explains the return format for both granularities, including total metrics, monthly evolution, top expenses/revenues, and per-account breakdown. It also covers truncation behavior and filtering options. Everything needed for correct invocation is present.

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

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

With 0% schema description coverage, the description fully compensates: it explains item (connector_id, connector_name, or item_id), from/to as ISO dates, granularity values and their output implications, type for BANK/CREDIT filtering, and top_n implicitly via top expenses/revenues. Every parameter's purpose and constraints are covered.

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 bank connection in one call, resolving accounts internally. It distinguishes from sibling tools like openfinance_list_accounts and openfinance_list_transactions by emphasizing aggregation and avoiding multi-step workflows.

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 lists use cases ('análise anual/mensal', 'fluxo de caixa', 'maiores gastos/recebimentos') and advises when to choose raw granularity for itemized rows. It contrasts with the need to call list_accounts separately and explains when to omit item for all banks.

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 valuable behavioral context: it queries the provider's public status page, returns global indicator, degraded components, open incidents, and flags affected banks. No contradictions; well-paired 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, front-loaded with purpose, followed by usage guidance and return details. Efficient with no redundant information. Could be slightly tighter but well-structured overall.

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

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

Given no parameters, no output schema, and rich annotations, the description thoroughly explains tool purpose, when to use, what it returns, and how it differs from siblings. Completely sufficient for an AI agent to select and invoke 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?

No parameters (baseline 4). Description goes beyond schema by detailing return fields: global indicator, degraded components, open incidents, your_banks_affected. This adds value for the AI agent despite lack of output schema.

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

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

Description clearly states it checks the LIVE operational status of the Open Finance provider (public status page). Uses specific verb 'checks' and explicitly differentiates from sibling tool openfinance_get_item_status, which checks own connection.

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 scenario for use: when data looks incomplete/stale despite connection showing UPDATED. It explains it helps distinguish provider-side problems from connection issues. While it doesn't explicitly state when not to use, the context is clear enough for an AI agent.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral details: it honors the user's plan (PF hides PJ banks), the behavior when keywords are missing (returns hint, not full catalog), and the output includes a ready connect_url. This enriches agent understanding of side effects and constraints.

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

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

The description is front-loaded with the core action and returns, then adds behavioral details. It is relatively concise given the amount of information conveyed. Minor redundancy (e.g., 'keywords[] is REQUIRED') but overall efficient for the complexity of the tool.

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

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

The description covers the tool's purpose, usage flow, required parameters, output fields, and edge-case behavior (missing keywords). Despite lacking an output schema, the description sufficiently explains return values. It is complete for an agent to select and invoke 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?

Despite 0% schema description coverage, the description compensates well by explaining each parameter's role: keywords is an array of strings (with example), required for search; include_accounts alters output to include accounts. It adds semantic context beyond the raw schema, though it could specify expected values or formats more precisely.

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 verb ('searches'), the resource ('bank connectors'), and the mechanism ('by name'). It details the output (connector id, access, audience, etc.) and distinguishes this tool from sibling tools like 'connect' or 'list' by emphasizing it's a pre-connect search. The purpose is unambiguous and 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?

The description explicitly states 'Call this BEFORE connecting to hand the user a one-click link', providing clear usage context. It also notes that keywords[] is REQUIRED and describes behavior when omitted. However, it does not explicitly mention when to avoid this tool or direct comparisons to siblings, though the context is strong.

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 the critical side effect that recategorizing creates a Category Rule for future similar transactions. It also explains batch error handling behavior. Annotations (readOnlyHint=false, destructiveHint=false) do not conflict, and the description adds significant behavioral context beyond structured fields.

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 yet thorough. Every sentence adds value: main action, parameter details, side effect, and error handling. It is front-loaded with the primary purpose.

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

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

The description is complete given the tool's complexity. It covers the operation, parameter sources, side effects, and response format. No output schema exists, but return shape is described 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?

With 0% schema description coverage, the description fully compensates by explaining the 'items' parameter structure, required fields, and sources for transaction_id and category_id. It also describes the return shape, adding meaning not present in the schema.

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

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

The description clearly states the tool's purpose: 'Corrects the category of one or more transactions' with HTTP method and endpoint. It distinguishes from siblings by referencing where transaction_id and category_id come from (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 provides context on when to use: to fix miscategorized transactions and improve future categorization by automatically creating a Category Rule. It explains the teaching effect and batch behavior. It does not explicitly list when not to use, but 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?

With annotations already indicating idempotentHint=true and destructiveHint=false, the description adds some context about reproduction but does not elaborate on side effects like ticket creation or notification. It is adequate but not enriched 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 clear sentence with an imperative instruction. It is concise and front-loaded, conveying purpose and key usage in minimal 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?

For a 3-parameter tool with no output schema, the description covers basic purpose and one parameter's usage. However, it omits details on parameter formats, return values, and prerequisites, leaving gaps for an AI agent.

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

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

The schema has 0% description coverage, so the description must compensate. It partially explains the conversation parameter but leaves context and message undefined. Given the void, it provides some meaning but insufficiently for all 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 that the tool is used to report bugs, missing features, or provide feedback. This verb-resource combination is specific and distinguishes it from sibling tools which are primarily about authentication and Open Finance 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 provides explicit guidance on when to use the tool by instructing to include the conversation array for reproduction. It implies the context for reporting issues but does not explicitly exclude other use cases or mention alternatives.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the description adds minimal behavioral info beyond confirming the output type (platform and adapter versions).

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

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

The description is a single sentence, front-loaded with key action, and contains 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?

Given no parameters, no output schema, and annotations covering safety, the description fully covers what the agent needs to know.

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 no parameters, so the description does not need to add parameter semantics; baseline 4 applies.

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 'Show' and the resource 'current MCP platform and adapter versions', making the purpose specific and distinct from siblings.

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

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

The description implies usage context for checking versions, and no alternatives are needed; it is clear and straightforward, but does not explicitly state when not to use.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context about the return content (installed MCPs, status, catalog tools) beyond what annotations cover, though it could specify the format of 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 a single, efficient sentence that immediately conveys the tool's purpose and key output fields. 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?

Given no output schema, the description adequately explains the return value (installed MCPs, connection status, catalog tools). It is complete for a simple info tool but lacks detail on data format or examples.

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 is empty with 100% coverage, so no parameter explanation is needed. The description focuses on output content, which is appropriate for a parameterless tool. Baseline 4 is justified.

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 toolkit state, specifying the exact information: installed MCPs, their connection status, and catalog tool counts. The verb 'Returns' is specific, and the tool is easily distinguished from siblings like 'authenticate' or 'connect'.

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, though its purpose as a read-only info tool is implied. The lack of exclusions or alternatives is acceptable for a simple query tool but could be improved.

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