Toro MCP

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

Adds behavioral context beyond annotations: explains permanent vs session usage, token as header. No contradiction with idempotentHint=true (multiple calls give same link).

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, efficiently describes both methods. Could be slightly more structured but concise enough.

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?

Simple tool with one optional param, description covers both usage modes and authentication flow. No output schema needed; complete for the use case.

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, but description fully explains the 'token' parameter: optional JWT for session login, or no args to get link. Adds full 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?

Clearly states the tool's purpose: authenticate by browser login and token. Distinguishes from siblings (mostly finance tools) and explains both permanent config and session token methods.

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 guidance on when to use permanent config vs session token, and calling with no args to get link. Lacks explicit 'when not to use' but context is clear.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds valuable state-specific behavior, enhancing transparency.

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

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

Two sentences, no wasted words. Efficient and 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?

For a status-check tool with no output schema, description covers all needed information: return values in different states.

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 description doesn't need to add param info. 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?

Description clearly states it returns connection status and URLs, with specific behavior for connected vs missing credentials. No ambiguity.

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 when to use (check connection status), but lacks explicit comparison to siblings like authenticate or toolkit_info. Still effective.

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 provide minimal behavioral hints (readOnlyHint false, etc.), but the description adds substantial transparency: it discloses that invoke runs tools one-off without adding to toolkit, returns connect links when auth is needed, and that install makes MCPs permanent. No contradiction with annotations.

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

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

The description is lengthy but information-dense, with every sentence serving a purpose. It front-loads the core purpose and flow, though it could benefit from more structured formatting (e.g., bullet points). The length is justified by the tool's 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 params, no output schema, 0% param coverage), the description does a good job covering the overall workflow and key behaviors. However, the lack of parameter-level detail and no output schema explanation leaves gaps that reduce completeness. It adequately conveys the tool's role and usage but isn't fully comprehensive.

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

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

Schema coverage is 0% with 13 parameters. The description contextually explains the 'action' enum and key parameters like tool_id and arguments within the workflow, but fails to describe other parameters (e.g., limit, query, mcp_id, message, immediate, tier_slug, conversation, request_name, report_context, request_details). This leaves a significant gap in parameter understanding.

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

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

The description clearly identifies the tool as the official mcp.ai marketplace for discovering and running MCPs, and distinguishes it from sibling tools by stating it should be used first. It enumerates specific actions (search, describe, invoke, install, etc.) and their roles, providing a precise verb+resource definition.

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 offers explicit guidance: use this tool first for capability needs, outlines the core flow (search → describe → invoke), explains when to prefer invoke over install (single/occasional use), and notes that writes require workspace owner/admin. It also clarifies that invoke works even if the MCP is not installed.

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

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

The annotations already indicate destructiveHint=true, and the description adds value by specifying that data will no longer be available and that an add_connection_url is returned for reconnection. This provides clear 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?

Two sentences with no fluff. The action is front-loaded, and every sentence provides essential information (purpose, effect, return value).

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

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

For a simple tool with one parameter and no output schema, the description covers the action, consequences, and return value. The only gap is the missing explanation of the 'item' parameter, but the overall context is mostly sufficient.

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

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

The schema has one parameter ('item') with 0% description coverage, and the description does not explain what 'item' represents (e.g., bank identifier). No additional meaning is added to the parameter, leaving ambiguity for the agent.

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

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

The description clearly states the verb ('Revokes' and 'deletes') and the resource ('Open Finance consent for a specific bank' and 'connection data'). It effectively distinguishes this tool from siblings like 'openfinance_list_connections' (listing) and 'openfinance_force_sync' (syncing).

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

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

The description implies usage for disconnecting a bank and offers a reconnection URL, but lacks explicit guidance on when to use this tool versus alternatives (e.g., when to disconnect vs. just listing). No concrete 'when-not-to-use' or alternative tool references.

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 fully discloses the behavior: it performs a PATCH, polls until completion up to ~60s, returns final status, executionStatus, lastUpdatedAt, synced, and flags needs_action or timed_out. It also explains the wait parameter effect. Annotations are all false, so description carries full burden and meets it completely.

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

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

The description is a single dense paragraph but every sentence is informative. It could be more structured with bullet points for readability, but it front-loads the core action and is reasonably concise given the complexity.

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

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

Given no output schema, the description fully explains the return format (results, errors, fields) and important details like needs_action, timed_out, and alternative tool (openfinance_get_item_status). The agent has all necessary context to use this 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?

Schema coverage is 0%, so description must explain parameters. It does so excellently: 'items' is described as array of selectors (item_id, connector_id, or connector_name) and omitting syncs all. 'wait' is described as fire-and-forget when false. This adds full meaning beyond the simple schema.

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

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

The description clearly states the tool forces a re-sync and waits for completion. It uses specific verbs ('forces', 're-sync', 'waits') and distinguishes from sibling tools like 'openfinance_get_item_status' for re-checking and implies it's different from disconnecting.

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

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

Explicitly says when to use ('when a balance or transaction list looks stale') and when to set wait:false for fire-and-forget. It also explains omitting items syncs all. However, it could more explicitly state when NOT to use this tool vs specific siblings, though it provides good 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 non-destructive. Description adds real-time nature, potential error in credit accounts with structured warning instead of exception, and the response shape with results/errors. Adds value beyond annotations.

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

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

Three concise sentences. First sentence states purpose and endpoint. Second gives input format and constraint. Third adds error handling and response shape. No unnecessary words.

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

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

With no output schema, the description provides the full response structure and error format. Single parameter is fully described. No gaps 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 has 0% description coverage, but the description specifies the parameter name, type (array), and size constraint (1–50). This compensates well, though it could explicitly state that each element is an account ID.

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, specifies the HTTP endpoint, and the name uniquely identifies it among siblings. No other balance tool exists in the list.

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

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

Provides explicit array size limit (1–50) and explains error behavior for credit accounts. Lacks explicit alternative usage guidance, but the context makes it clear this is the dedicated balance tool.

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

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds behavioral details: batch shape { results, errors }, extended creditData, and the endpoint path. Provides value beyond annotations.

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

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

Three sentences concisely cover purpose, usage, and return shape with no extraneous information. Front-loaded with key functionality.

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 batch get tool with one parameter and no output schema, the description covers input constraints, return shape, and extended data. Could mention error handling more explicitly, but overall adequate.

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

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

Schema has 0% description coverage; the description compensates by specifying that account_ids should be an array of 1–50 items, clarifying cardinality and format not 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 it returns full account objects with extended creditData per ID, and specifies the HTTP endpoint. It distinguishes from sibling tools like openfinance_list_accounts by focusing on detail retrieval for specific IDs and batch shape.

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

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

It specifies how to use the tool (pass account_ids as array of 1-50) but does not explicitly guide when to use it vs alternatives like openfinance_list_accounts. The purpose implies it, but no direct comparative 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 mark as read-only, idempotent, non-destructive. Description adds critical context: batch shape { results, errors }, notes that Pluggy does not return paid/status field, and explains payments[] semantics (previous bill payment). 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?

Well-structured and front-loaded, but relatively long. However, every sentence adds value (output description, caveat, cross-reference). Slightly verbose but justified.

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, yet description explains output fields (financeCharges, payments with subfields). Warns about edge cases (payment interpretation). References sibling tools for discovery and transactions. Fully adequate for a 1-param 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?

Single parameter bill_ids is described beyond schema: must be an array, use prior tool to discover ids. Schema coverage is 0% but description fully compensates.

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?

States clearly: 'Returns bill-level detail for one or more credit card bills by id' and distinguishes what it does NOT return (individual transactions) with explicit reference to sibling tool openfinance_list_transactions. Also mentions the specific fields returned (financeCharges, payments).

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 (need bill-level detail by id) and when not (for transactions). Provides prerequisite: use openfinance_list_credit_card_bills to discover ids. Warns about payments[] interpretation, preventing misuse.

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 behavioral details beyond annotations: how omitting `item` returns `{ count, items }` and including `item` returns single bank status. This aligns with the readOnlyHint and idempotentHint annotations, and no contradiction exists.

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 wasted words. The main purpose is front-loaded, and the optional parameter behavior is clearly explained.

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

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

For a tool with one parameter and no output schema, the description covers input behavior completely. The exact return format for a single bank is not explicitly detailed, but the context (e.g., `items` for bulk) is inferable. Overall adequate.

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

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

Despite 0% schema coverage, the description fully explains the `item` parameter's meaning and effect on output. This adds significant value beyond the schema, which only defines the parameter as type string.

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 with specific statuses like UPDATED, UPDATING, LOGIN_ERROR. It also distinguishes between getting status for all linked banks vs a single bank, which differentiates it 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 explicitly tells when to omit or include the `item` parameter, providing clear usage scenarios. It could be enhanced by noting when not to use this tool (e.g., for detailed transaction data), but the given guidance is sufficient for the 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?

Annotations indicate read-only, idempotent, non-destructive. Description adds critical context: aggregation behavior, that `name` is legal entity not brand, credit balance connector-dependency, and billing cycle fields. 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 somewhat long but front-loaded with the main purpose. Every sentence adds value, though could be slightly more concise. Structure is logical: purpose, then parameter guidance, then behavioral notes.

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, but description covers return fields (balance, number, type, etc.), mentions `bank` and `connector_id`, and explains credit balance meaning and billing cycle fields. It also points to sibling tool for more detail. Given complexity, it's 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 2 parameters with 0% coverage. Description compensates by explaining `item` usage (omit for all, include for single bank) and `type` enum values (BANK/CREDIT) with their meanings. It doesn't define each parameter separately but integrates usage context effectively.

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

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

The description clearly states it returns accounts for bank connections with specific details (balance, number, type, etc.). It distinguishes between listing all accounts across banks versus targeting a single bank, and contrasts with sibling tool openfinance_list_credit_card_bills. The verb 'returns' and resource 'accounts' are specific.

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

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

Explicitly says when to omit or include `item` parameter, and that `type` filters by BANK/CREDIT. It advises using `bank` field for user-facing text, warns about credit balance interpretation, and recommends openfinance_list_credit_card_bills for standardized billing. This covers when to use and alternative 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, idempotentHint, and destructiveHint. The description adds valuable behavioral details: caching per session, single aggregated response (no batch ids), and structure of returned entries (fields like descriptionTranslated). 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?

Three sentences with no wasted words. First sentence states purpose, second details fields, third clarifies response format. Ideal front-loading and efficient communication.

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

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

For a parameterless tool with no output schema, the description covers all essential aspects: what it does, what it returns (with field descriptions), caching behavior, and its relationship to update_category. No gaps.

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

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

No parameters exist, so baseline is 4. The description adds meaning by detailing the output fields (id, description, descriptionTranslated, parentId, parentDescription), which compensates for the 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 returns Pluggy's transaction category taxonomy. Specifies the resource (categories) and the GET /categories endpoint. Distinguishes from sibling tool openfinance_update_transaction_category by noting that the category `id` is used as input there.

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

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

Implies usage context by mentioning caching for the adapter session and the connection to updating categories. However, does not explicitly state when to use or when to avoid, nor list alternatives for listing categories (though there are no direct siblings).

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, so the safety profile is clear. Description adds value by revealing the return fields including the add_connection_url for linking additional banks, which is non-obvious behavior.

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 action and resource, immediately followed by specific return fields. Every part is informative with no wasted words.

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

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

For a simple list tool with no parameters and no output schema, the description sufficiently explains what is returned (fields and a URL). It is complete given the tool's low complexity.

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

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

The tool has zero parameters, and schema description coverage is 100% (trivially). Description adds no parameter info, but with no parameters, the baseline is 4. No further semantic explanation 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 the action ('returns') and resource ('saved bank connections'), listing specific fields (connector_id, item_id, bank name, add_connection_url) and scope ('for this install'). It distinguishes from sibling tools like openfinance_list_accounts by focusing on 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?

The description implies usage for retrieving bank connections but provides no explicit guidance on when to use this tool versus alternatives among the many sibling list tools. No exclusions or prerequisites are mentioned.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description details that only closed bills are returned, explains the derived payment_status logic, the open_bill derivation from pending transactions, and connector asymmetry where open bill may be unavailable. No contradiction with annotations.

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

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

The description is lengthy but each paragraph adds necessary context for a complex tool. It is front-loaded with core purpose and structur, but some redundancy could be trimmed (e.g., repeated emphasis on payment_status).

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 semantics (payment_status, open_bill derivation, connector asymmetry), the description is extremely thorough. It covers return fields, edge cases, limitations, and links to related tools. Nothing critical is missing.

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 compensates well: explains account_id (required), account_ids for batch, include_open_bill with opt-in semantics. However, page and page_size parameters are not described, though standard pagination may be inferred.

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 the resource and verb. It distinguishes from siblings like openfinance_get_credit_card_bill (single bill) and openfinance_list_transactions (individual transactions) by noting that results are bill-level summaries.

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 include_open_bill (opt-in for open bill and total debt), warns about payment_status interpretation, explains connector asymmetry, and directs to openfinance_list_transactions for itemized data. Also mentions bulk support via account_ids.

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

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

Annotations already mark the tool as read-only and idempotent. The description adds value by explaining error handling: it returns a warning object instead of throwing on 403 or upstream errors, which is useful behavioral context.

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, front-loading the purpose. It lists many asset types and fields, which is informative but slightly lengthy; still, every detail serves a 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 thoroughly covers return values and error handling, compensating for no output schema. However, it misses parameter guidance, so completeness is moderate.

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

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

With 0% schema description coverage, the description must explain parameters. It does not mention item, page, type, or page_size at all, leaving their usage entirely unclear.

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, listing specific asset types (FIIs, stocks, ETFs, etc.) and detailed field explanations, distinguishing it from sibling tools like openfinance_list_investment_transactions.

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

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

The description indicates when to use the tool (for a connection with INVESTMENTS enabled) but does not explicitly state when not to use it or provide alternatives among sibling tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable details about output fields (quantity, value, netAmount, expenses breakdown) and transaction types, going 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 clear paragraphs: first gives purpose and output details, second adds usage sequence and bulk support. No unnecessary words, front-loaded with key info.

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 purpose, usage sequence, output fields, and bulk support. Lacks explanation of pagination parameters but those are common. Overall adequate given no output schema.

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

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

Schema description coverage is 0%, so description must compensate. It explains investment_id (from list_investments) and investment_ids (bulk), but page and page_size are left undescribed. Partial coverage, baseline 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 'Returns the movement history for a specific investment position' and enumerates transaction types (BUY, SELL, TAX, etc.), differentiating it from siblings like openfinance_list_investments (which lists positions) and openfinance_list_transactions (general 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 advises to use after openfinance_list_investments to obtain investment_id, and mentions bulk support with investment_ids. However, no explicit exclusion of alternatives or when-not-to-use 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 declare readOnly and idempotent hints. The description adds context about sequential execution with rate-limit spacing and per-connection result structure, exceeding 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?

Two sentences, front-loaded with purpose and key usage details. No wasted words.

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

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

For a tool with one optional parameter and no output schema, the description covers parameter usage, execution behavior, and return shape, making it complete.

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

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

Schema coverage is 0%, but the description thoroughly explains the `items` parameter: acceptable types (item_id uuid, connector_id, connector_name) and omission behavior. This provides critical meaning beyond the schema.

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

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

The description clearly states the tool lists loan contracts per bank connection, specifying the HTTP endpoint. It distinguishes from sibling list tools by focusing on loans.

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 how to use the `items` parameter (array of connection selectors) and the effect of omitting it. Also mentions sequential rate-limited execution. However, it doesn't explicitly contrast with 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, idempotentHint, destructiveHint. Description adds extensive behavioral context: explains PENDING vs POSTED variance by connector, search_queries aggregation up to 5000, error handling with warning/error instead of throwing, detail parameter behavior (compact/rich/raw) and token implications, credit card metadata linking to bills, 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?

Description is long but well-structured: starts with main purpose, then credit card nuances, then parameter details. Each sentence adds value. Could be slightly more concise but is well-organized with clear paragraphs and front-loaded primary usage. Reasonable for the complexity of the tool (8 parameters, multiple behaviors).

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, description explains output structure (total, results, warning, error, truncated flag). Covers error handling, credit card metadata fields (billId, purchaseDate, etc.), and connections to other tools for completeness. Additionally covers bulk support and connection health. Everything an agent needs to use the tool correctly is included.

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

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

Schema has 0% description coverage, so description must fully explain parameters. It does: detail enum values (compact/rich/raw) with use cases, search_queries (case-insensitive substring, OR semantics, aggregation), from/to dates (ISO YYYY-MM-DD), page_size (max 500/page), account_ids (bulk support). Goes beyond schema by explaining behavior and constraints.

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

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

Clearly states it returns transactions for bank accounts (BANK or CREDIT types). Distinguishes from sibling tools by specifying that for CREDIT accounts this is the only way to get itemized transactions, and references openfinance_list_credit_card_bills and openfinance_list_accounts for related data. The verb 'returns' and resource 'transactions' are precise.

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

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

Provides explicit guidance: for CREDIT accounts, this is the only way to get itemized transactions; for standardized totals use openfinance_list_credit_card_bills; for statement dates use openfinance_list_accounts; if total is 0 check connection via openfinance_get_item_status. Also explains when to narrow date range if truncated. Clearly indicates alternatives and conditions.

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

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

Adds significant behavioral context beyond annotations: caps at 5000 transactions per account with 'truncated:true' flag, internally fans out transactions from accounts (no prior account listing needed), and describes output structure in detail (compact summary vs raw rows with fields like entradas, saídas, saldo_liquido, por_mes, top_despesas, by_account). 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?

Packed with information but slightly verbose; first sentence captures main purpose. Redundancy in listing Portuguese terms but overall efficient and well-structured. 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 7 parameters with zero schema descriptions, no output schema, and no required parameters, the description provides complete guidance: explains parameter usage, behavior (truncation, internal fan-out), return fields, and filtering. No gaps for an agent to misuse.

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

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

Despite 0% schema description coverage, the description fully explains all 7 parameters: from/to as ISO dates, item as connector_id/connector_name/item_id, granularity (monthly/raw) with defaults, detail (compact/rich/raw) with behavior, type (BANK/CREDIT), and top_n (largest N in top_despesas/recebimentos). Adds meaning beyond 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?

Description clearly states consolidated cash-flow analysis for a bank connection over a period, resolving accounts internally, and distinguishes from sibling openfinance_list_transactions by being consolidated and not requiring prior account listing. Provides specific use cases like 'fluxo de caixa'.

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 (annual/monthly analysis, cash flow, etc.), default behavior (granularity:'monthly' for summary, 'raw' for itemized rows), and how to filter (type, item). Mentions omitting item for all banks but does not explicitly say when not to use or name alternative sibling.

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. The description adds significant behavioral context: it makes a live call to the provider's public status page, returns global indicator, degraded components, open incidents, and flags affected banks. No contradictions.

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

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

The description is well-structured and front-loaded with purpose, then usage guidelines, then return values. It is informative but slightly lengthy; still earns its place with no redundancy.

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

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

Given no parameters and no output schema, the description fully explains the return value (global indicator, degraded components, incidents, your_banks_affected). Complete for a status-check 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?

No parameters exist, and schema description coverage is 100%. The description does not need to add parameter semantics, but it provides context on what the tool does without parameters. Baseline 4 is appropriate.

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

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

The description clearly states the tool checks the LIVE operational status of the Open Finance provider, distinguishing it from the connection's own status using the sibling tool name. It specifies the resource (provider's status page) and verb (checks), 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?

Explicitly tells when to use: when data looks incomplete or stale despite connection showing updated status. Contrasts with sibling tool 'openfinance_get_item_status' and explains it helps differentiate provider-side problems from connection issues.

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 context that the tool returns a pre-filled connect_url and honors user plan, which adds value 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 three sentences, all substantive. It front-loads the main purpose and details in a logical order, with no fluff.

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

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

Given no output schema, the description fully explains what the tool returns (connector id, access, audience, connections/accounts, connect_url) and the edge case (no keywords yields a hint). This is complete for the tool's complexity.

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

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

Schema coverage is 0%, so description carries the burden. It explains keywords[] is required (even though schema shows 0 required, this is guidance, not contradiction), and describes include_accounts as a boolean to include accounts. This meaningfully 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 specifies searching 'available bank connectors by name', returning specific fields (id, access, audience, connections, connect_url). It distinguishes from siblings by claiming a unique role: to be called before connecting to get a one-click link.

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 when to use it ('Call this BEFORE connecting') and what happens when keywords are omitted (returns a hint). It also mentions plan-based filtering. However, it does not mention when not to use or provide direct alternatives among siblings.

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 fully discloses the side effect of automatically creating a Category Rule, the override of Pluggy's automatic categorization, and the batch error handling (per-item errors do not fail the whole batch). Annotations provide no contradiction; they are neutral.

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 compact (6 sentences) and well-structured: purpose, input format, side effect, future impact, return shape. Every sentence adds essential information 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, the description provides the exact return structure including updated, results, and errors fields. It covers the input parameter completely, explains side effects, and references sibling tools, making the tool fully understandable.

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 'items' is thoroughly explained: it must be an array of objects with transaction_id and category_id, with explicit references to the sibling tools for obtaining these IDs. This adds 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 starts by clearly stating 'Corrects the category of one or more transactions' and provides the HTTP method and endpoint. It immediately distinguishes the tool's action from siblings by detailing its batch nature and side effects.

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

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

It explicitly instructs to use transaction_id from openfinance_list_transactions and category_id from openfinance_list_categories, and explains the teaching effect of category rules, guiding the agent on when to apply this tool for fixing miscategorizations and improving future accuracy.

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 idempotentHint=true and destructiveHint=false, so the agent knows it's a safe, non-destructive operation. The description adds the detail about including conversation but does not contradict annotations. No additional behavioral context is provided.

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 unnecessary words. The purpose and key usage instruction are front-loaded and 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?

The description covers the main purpose and one parameter (conversation) but lacks explanation for 'context' and the type mismatch for 'conversation' (string vs array). With no output schema, more detail on expected return or confirmation would be helpful.

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 mentions 'conversation array' but the schema defines it as a string, causing potential confusion. The 'context' parameter is not explained. Only 'message' is implicitly 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 explicitly states the tool is for reporting bugs, missing features, or feedback, with a clear verb and resource. It distinguishes from sibling tools which are focused on financial operations and authentication.

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

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

The description gives explicit guidance to include the conversation array with recent messages for reproduction, indicating when to use the tool. However, it does not mention when not to use it or provide alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety traits. The description adds specific content (MCP platform and adapter versions) but no additional behavioral context.

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 with no wasted words. It is appropriately sized for the tool's simplicity.

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

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

Given the tool has no parameters, no output schema, and a straightforward purpose, the description fully informs the agent of what the tool does.

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

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

There are no parameters, and schema coverage is 100%. The description does not need to add parameter information, earning a 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 the tool shows current MCP platform and adapter versions, using a specific verb and resource. It distinguishes itself from sibling tools, none of which are version-related.

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

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

While no explicit when-to-use vs alternatives is given, the tool is self-explanatory. Its purpose is evident, and the context of a version display tool requires minimal 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 indicate the tool is read-only, idempotent, and non-destructive. The description adds value by specifying exactly what information is returned (installed MCPs, connection status, catalog tool counts), providing 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 a single, well-structured sentence that front-loads the core purpose (returns current toolkit state) and immediately lists the key data points. Every word is informative, with no redundancy or unnecessary details.

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 that the tool has no input schema and no output schema, the description fully explains what the tool returns. The information is sufficient for an agent to understand when to call this tool and what to expect from the response.

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, and the schema coverage is complete (100%). Per the guidelines for zero-parameter tools, the baseline is 4, and the description does not need to add parameter information. It sufficiently describes the output without discussing 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 the current toolkit state, including installed MCPs, connection status, and catalog tool counts. This is distinct from all sibling tools, which focus on authentication, open finance operations, or other specific functions.

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 makes it clear that this tool is for retrieving overall toolkit state, which is a read-only informational use case. While it doesn't explicitly state when not to use it or list alternatives, the context of being a state-checking tool is well understood from the description and annotations.

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