Woop MCP

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

Annotations declare idempotentHint=true, and description reinforces idempotency by noting calling with no args gives link. Description adds behavioral context beyond annotations (browser login flow, permanent vs session). 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, each essential. Front-loaded with purpose, then usage, then parameter behavior. No filler, 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 authentication tool with no output schema, the description covers the entire authentication flow. Lacks error handling details, but acceptable given pro-level agent usage.

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

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

The single optional parameter 'token' is thoroughly explained: used for pasting JWT from browser, or omitted to get login link. Schema coverage is 0%, but description fully compensates with clear meaning.

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

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

The description clearly states the tool's purpose: authentication for MCP.AI IDE agents. It explains two modes (permanent token via config, session token via argument) and distinguishes from sibling tools by being the only authentication tool.

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 instructions on when to use each authentication method, including best practice (config) and session-only option. Does not explicitly state when not to use, but contextually clear it's the sole authentication 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 indicate readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context: explains the two possible states (authenticated:true with empty pending[] vs connect_url returned). This is beyond what annotations provide.

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

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

The description is two sentences, front-loaded with the main purpose, and conveys all necessary information without any wasted words. 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?

Given no parameters and no output schema, the description covers the two main use cases. It could potentially mention other states (e.g., partial connection), but for a simple status check it is sufficiently complete.

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

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

No parameters exist, so schema coverage is 100%. According to guidelines, baseline for 0 parameters is 4. The description does not need to add parameter semantics as there are none.

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

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

The description clearly states it returns connection status and URLs, and distinguishes behavior for two scenarios (all connected vs missing credentials). The verb 'returns' and resource 'connection status and URLs' are specific. Among siblings like authenticate or marketplace, this tool's purpose is distinct.

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 checking connection status, but does not explicitly guide when to use this tool over alternatives like authenticate or openfinance_provider_status. No exclusions or when-not-to-use advice 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?

The description reveals key behavioral traits not present in the sparse annotations: invoke runs a tool without installing it, returns connect/checkout links that require user action and retry, writes require owner/admin, and the prompt library is about text prompts rather than MCPs. This goes far beyond the minimal annotations (readOnlyHint=false, openWorldHint=true, etc.) and provides essential operational 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 lengthy (~300 words) but warranted given the 14-action tool surface. It is organized around core flow, key behavior, then per-action summaries, and every sentence carries meaningful information without filler.

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 meta-tool with 14 actions, 23 parameters, no output schema, and minimal annotations, the description provides a solid operational model: it explains the search-describe-invoke pipeline, permission requirements, billing/credential retry flow, and the separate prompt library. Missing details include the 'resume' action and exact parameter syntax, but the overall guidance is sufficient for an agent to select and invoke the correct actions.

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

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

With schema description coverage at 0%, the description must compensate for 23 undocumented parameters. It clarifies the meaning of most action enum values (search, describe, install, uninstall, invoke, etc.) and the relationship between tool_id and arguments, but it leaves some parameters unexplained (e.g., resume, immediate, tier_slug, conversation) and does not specify formats like arguments as a JSON 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 identifies the tool as the official mcp.ai marketplace and the in-platform catalog/runner for MCPs, with a concise statement of the core flow (search → describe → invoke). It distinguishes itself from the finance-specific sibling tools by positioning itself as the general-purpose catalog and runtime.

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 given: prefer invoke for one-off use, use install for permanent additions, and writes require owner/admin. It also explains what happens on missing credentials or empty wallet, and defines the roles of subscribe/cancel, report_bug, request_mcp, and list_tools, giving clear decision rules.

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?

Descriptive beyond annotations: details the effect (data no longer available) and the return URL, adding useful context to the destructiveHint annotation.

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, front-loaded sentences with no redundancy; each sentence adds essential information.

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

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

Adequate for a simple destructive tool but lacks details on prerequisites (e.g., must have an active connection) and does not fully describe the return value format.

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

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

With 0% schema coverage, the description only vaguely references 'specific bank' without explaining what the 'item' parameter is (e.g., bank ID, connection ID) or how to obtain it.

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 revokes consent, deletes connection data, and returns a re-connect URL. Distinct from siblings like connect or 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?

Implies usage for permanently disconnecting a bank, but lacks explicit when-to-use or when-not-to-use guidance, and does not mention 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?

Discloses polling up to ~60s, fire-and-forget option, return fields (status, executionStatus, etc.), error states (needs_action with reconnect_url), and timed_out behavior. Adds significant context beyond annotations.

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

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

Well-structured and front-loaded, but slightly verbose. Every sentence adds value, though could be tightened slightly without losing information.

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

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

Comprehensive for a sync tool: covers async behavior, error handling, return format, and cross-reference to get_item_status. No output schema exists, but description covers all needed info.

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

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

With 0% schema coverage, description fully explains both parameters: 'items' as array of selectors (including omission for all banks) and 'wait' for fire-and-forget. No ambiguity.

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

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

Clearly states the verb 'Forces re-sync' and resource 'one or more connections', with explicit behavior of waiting or fire-and-forget. Distinguishes from siblings like get_item_status and list_connections.

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

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

Explicitly says when to use: 'when a balance or transaction list looks stale'. Mentions alternative for timed_out results. Could be improved with explicit when-not-to-use, but sufficient.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds substantial behavioral context: the snapshot nature, the meaning of updateDateTime, credit-specific error handling, structured warnings instead of throws, and degraded responses when the upstream is unavailable. This goes well beyond what annotations or schema convey.

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

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

The description is long but each sentence carries meaningful behavioral or error-handling information. It is front-loaded with the core purpose. The density is justified given the nuanced error modes, though it could be slightly more scannable with list separators.

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 and one parameter, the description compensates fully by specifying the response shape, error structure, degradation behavior, and edge cases. An agent has enough context to invoke the tool correctly and interpret its results, including unexpected warnings.

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 only defines account_ids as an array of strings with no descriptions. The description adds crucial meaning: 'Pass `account_ids` as an array (1–50)', clarifying both the expected type and the cardinality limit. It also implies each element is an account id, tying the parameter to the per-account response.

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 opens with a specific verb and resource: 'Returns the latest available balance per account id' and gives the endpoint. It clearly distinguishes this tool from siblings like openfinance_list_accounts or openfinance_get_accounts_detail, which serve different purposes.

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 practical guidance on when to use it and what to do if data seems stale: call openfinance_force_sync and re-read. It also warns about consent errors and degraded fallbacks. It does not explicitly enumerate when to choose alternative tools, but it names the relevant sibling (openfinance_force_sync) and gives concrete trigger 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds critical behavioral context: the provider_incident block, potential unreliable data during incidents, and the batch shape with errors. This goes well beyond annotations.

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

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

The description is concise: three sentences with no unnecessary words. It front-loads the purpose, constraints, and important caveats about provider incidents.

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 one parameter and no output schema, the description adequately explains the return shape (full account objects, creditData, batch errors, provider_incident). It could mention more about possible fields, but the coverage is sufficient for agent understanding.

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

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

The input schema has 0% description coverage, so the description must compensate. It adds the array range constraint (1–50) and explains that account_ids are used 'per id' and returns batch results. This provides meaningful guidance 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 it returns 'full account objects including extended creditData' by ID, distinguishing it from sibling tools like openfinance_list_accounts which likely provides summaries. The verb 'Returns' and specific resource 'account objects' make the purpose unambiguous.

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

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

The description provides usage instructions ('Pass account_ids as an array (1–50)') but does not explicitly state when to use this tool over alternatives like openfinance_list_accounts or openfinance_get_account_balance. The context is clear, but exclusions are absent.

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?

Despite readOnlyHint and idempotentHint annotations already covering safety, the description adds critical behavioral context: the bill payload has no transactions (they live on the account), the transactions_basis field explains estimate vs exact matching, the 'do NOT rebuild totalAmount' warning, and the Pluggy payment/status caveat. This goes far beyond annotations and prevents misinterpretation.

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

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

The description is long but every section adds value: bill-level fields, opt-in transaction behavior, basis semantics, payment caveat, and batch shape. It is front-loaded with the core purpose and then layers details. Slightly long, but each sentence earns its place due to high information density.

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 complex tool with no output schema, this description is extraordinarily complete. It covers return fields, batch shape, transaction linkage methods, estimation confidence, payment interpretation, and alternatives. An agent has everything needed to invoke it correctly and interpret results appropriately.

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 carry the full burden. It explains bill_ids, account_id, and include_transactions thoroughly, but completely omits transactions_detail (the enum compact/rich/raw). No definition or guidance for this parameter is given, leaving a meaningful gap for agents trying to use it correctly.

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

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

The description clearly states 'Returns bill-level detail for one or more credit card bills by id' with a specific resource and verb. It immediately distinguishes itself from sibling tools by referencing openfinance_list_credit_card_bills for ID discovery and openfinance_list_transactions as an alternative for transactions, so an agent can tell them apart without opening schemas.

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: 'Pass bill_ids as an array — use openfinance_list_credit_card_bills first to discover ids' and 'you can also fetch them yourself via openfinance_list_transactions'. It also specifies when to use include_transactions (opt-in) and the required account_id, making the selection and invocation path crystal clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the tool is clearly safe and non-destructive. The description adds behavioral context beyond annotations, such as the reconnect_url behavior (reopens widget in UPDATE mode without disconnecting or consuming a slot) and the bulk support behavior. This adds transparency about side effects and capabilities.

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

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

The description is concise, with two sentences that convey the core functionality, usage distinction, and bulk support. It is well-structured and front-loaded with the main purpose. Slightly more structure (e.g., bullet points) could improve readability, but it remains efficient and informative.

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

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

Given the lack of an output schema, the description provides essential details about the returned data (count, items, reconnect_url) and the tool's behavior. The annotations cover safety and idempotency. However, it could mention that the response includes executionStatus and connector metadata explicitly. Still, it is sufficient for an AI agent to use the tool correctly.

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

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

The input schema has 0% description coverage, so the description must compensate. It explains that `item` is for a single bank, `item_ids` for batched execution, and omitting `item` returns all banks. However, the parameter `item_id` (singular) is present in the schema but not mentioned in the description, which is a minor gap. Overall, it adds significant meaning beyond the raw schema.

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

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

The description explicitly states the tool returns the current status of a bank connection with specific statuses like UPDATED, UPDATING, LOGIN_ERROR, and distinguishes between single and bulk operations (omit `item` for all, pass `item` for one). It also mentions executionStatus, connector metadata, and reconnect_url, making the purpose very clear.

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 clear guidance on when to use `item` vs omitting it, and mentions bulk support with `item_ids`. However, it does not explicitly state when NOT to use this tool or compare it to sibling tools like openfinance_list_connections, which could be confusing. Still, the usage context is well explained.

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

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

Annotations declare readOnlyHint, idempotentHint, destructiveHint. Description adds value by specifying batch limit (1-50 loan_ids), return format { results, errors }, and listing key returned fields. This goes beyond annotations.

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

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

The description is a single paragraph with clear sentences: first lists return fields, then usage guidance, then parameter format. It is efficient and front-loads key information, though could be slightly more structured.

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

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

Given one parameter, no output schema, and read-only nature, the description is comprehensive: explains input constraint, expected output fields, and batch result shape. It adequately covers the tool's context.

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

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

Schema coverage is 0%, but description explains loan_ids parameter as an array of strings with size limit 1-50. This adds essential semantics 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 it returns full loan contract detail by ID, listing many specific fields. It explicitly distinguishes from sibling openfinance_list_loans by suggesting usage after listing, making purpose and differentiation very clear.

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 'Use after openfinance_list_loans to deep-dive on a specific contract,' providing clear when-to-use context. It lacks explicit when-not-to-use or alternatives, but the guidance 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?

Far exceeds the readOnly/idempotent annotations by documenting connector-dependent balance semantics, balance_notice, provider_incident, identity_notice, and stale provider-reported fields. It tells agents what not to present as real and how to dedupe joint-account rows.

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?

Despite being long, the description is front-loaded with the core return contract and each subsequent paragraph earns its place by addressing a real correctness or interpretation risk. It is structured around response fields, notices, and bulk behavior rather than being a wall of repetition.

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 an unusually complete picture of returned fields, caveats, and how to route to sibling tools. An agent has enough to select the tool, invoke it correctly, and interpret ambiguous responses safely.

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

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

With 0% schema coverage, the description compensates well for `item` (omit for all, pass for one) and `item_ids` (bulk support). However, it does not explicitly explain the singular `item_id` parameter or the filtering semantics of the `type` parameter beyond what the enum shows.

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 first sentence states an exact verb and resource: returns BANK and CREDIT accounts for a bank connection with specific fields. It further clarifies the brand-vs-legal-entity meaning of `bank` and `name`, and the text distinguishes this tool from openfinance_list_credit_card_bills.

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

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

Explicitly says when to omit `item` (user asks for 'my accounts/cards' without naming a bank) and when to pass `item`. It names openfinance_list_credit_card_bills as the alternative for standardized bill amounts and openfinance_force_sync for reconciling stale derived fields.

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 readOnlyHint and destructiveHint. Description adds caching, single aggregated response, and no batch ids, providing useful behavioral context beyond annotations.

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

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

Four sentences, front-loaded with purpose, no redundant words. Efficient and well-structured.

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

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

Given no parameters and no output schema, description covers source (Pluggy), caching, field details, and relationship to another tool. Sufficient for task.

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?

Zero parameters, so baseline 4 applies. Description adds no parameter info (unnecessary) but explains output structure, which is acceptable.

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, cached for the session, and lists fields (id, description, etc.). It distinguishes from siblings like openfinance_list_transactions by focusing on categories specifically.

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

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

Implicitly indicates usage when needing category taxonomy, especially for openfinance_update_transaction_category. No 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 indicate readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context about the reconnect_url (opens widget in UPDATE mode, does not consume a slot) and the add_connection_url, which goes beyond what annotations provide.

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

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

The description is two sentences, front-loaded with the primary purpose, and provides necessary details. The second sentence is slightly long but well-structured. No wasted words.

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

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

Given the lack of output schema, the description covers all key aspects: the fields returned and the purpose of the two URLs. It does not mention error conditions or pagination, but for a simple list tool this is 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?

There are zero parameters, so baseline is 4. The description fully compensates by detailing the return structure (connector_id, item_id, bank name, URLs) and their meanings, which the empty schema cannot convey.

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 saved bank connections with specific fields (connector_id, item_id, etc.) and explains the two URLs. However, it does not explicitly distinguish itself from sibling list tools (e.g., list_accounts), though the resource type is different.

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 guidance on using the reconnect_url for re-authentication cases, but does not give when-to-use or when-not-to-use this tool versus alternatives like other list tools. The context for tool invocation is implied but not explicit.

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) are consistent. The description adds rich behavioral context: payment logic, derived payment_status, open_bill derivation, connector asymmetry, bill grouping reliability, and warnings. 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 and detailed, front-loaded with main purpose but then dense with nuances. While informative, it lacks conciseness and could be better structured for quick scanning.

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

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

Given the complexity (5 params, no schema coverage, no output schema), the description is thorough. Covers result fields, derived fields, open_bill option, connector asymmetry, payment_status logic, warnings, and bulk support.

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

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

Schema description coverage is 0%, so the description must compensate. It adds value for include_open_bill and account_ids (bulk support), but does not explain page, page_size, or account_id explicitly. Partial compensation.

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, listing specific fields like dueDate, totalAmount, payments, etc. It distinguishes from siblings like openfinance_get_credit_card_bill and openfinance_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?

Explicitly tells when to use (to get closed bills) and when not (for individual transactions, use openfinance_list_transactions). Also warns about connector asymmetry, open_bill availability, and to check the echo block and name the bank.

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), description details error handling (returns template on 403), data integrity checks with suspect_zeroed flag, and cross-referencing transaction history. 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 front-loaded with purpose, then covers error handling and data integrity. Some redundancy (e.g., listing asset types twice), but generally structured. Could be slightly more concise.

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

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

Covers key aspects (error handling, bulk, data integrity) but misses parameter explanations. No output schema, but description briefly mentions return fields. For a complex tool, parameter documentation is needed.

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

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

With 0% schema description coverage, description only explains item_ids for bulk support. Other parameters (item, page, type, page_size, item_id) are not described, leaving ambiguity. This is a significant gap.

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

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

Description clearly states the tool returns the investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.). Differentiates from sibling tools like openfinance_list_investment_transactions by focusing on portfolio holdings rather than transactions.

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

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

Description specifies when to use (for connections with INVESTMENTS enabled) and describes fallback behavior when not enabled. Implicitly distinguishes from list_investment_transactions, though could explicitly mention alternatives. Bulk support via item_ids is noted.

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 it as read-only and idempotent. The description adds valuable detail: the specific fields returned and bulk execution support, which aids the agent in understanding 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?

Two concise paragraphs: first describes purpose and fields, second mentions bulk support. No waste, front-loaded with key information.

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

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

Given no output schema, the description provides a thorough list of returned fields and requisite usage. Missing pagination details slightly reduces 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?

With 0% schema description coverage, the description explains investment_id and investment_ids, but omits pagination parameters (page, page_size). It partially compensates but is incomplete.

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

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

The tool clearly states it returns movement history for an investment position, listing transaction types and fields. This distinguishes it from sibling tools like openfinance_list_transactions for regular transactions.

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

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

Explicitly says to use after openfinance_list_investments to get the investment_id, and mentions bulk support via investment_ids. Could be more explicit about 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?

The description adds substantial behavioral context beyond annotations: it discloses sequential querying with rate-limit spacing and the return format { results, errors } per connection. Annotations already indicate readOnly and idempotent, and the description does not contradict them.

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

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

The description is a concise three-sentence paragraph with no wasted words. It is front-loaded with the core action and each sentence adds essential information.

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

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

Given the tool has one optional parameter and no output schema, the description is complete: it explains the parameter, the querying behavior, and the return structure. No gaps remain for agent understanding.

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

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

The input schema has 0% description coverage, but the description fully explains the parameter: items is an array of connection selectors (item_id, connector_id, or connector_name) and the behavior when omitted. This adds critical meaning beyond the bare schema.

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

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

The description clearly states the tool lists loan contracts per bank connection using a specific endpoint. It distinguishes between listing for specific connections (via items) and for all connections, differentiating it from sibling tools like openfinance_get_loan_detail.

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

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

The description provides clear guidance on using the items parameter: pass an array of connection selectors for specific connections or omit for all. It explains sequential querying with rate-limit spacing. However, it does not explicitly mention when to prefer this tool over alternatives like get_loan_detail.

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, and the description enriches them substantially: error envelope '{ total:0, results:[], warning, error }' instead of throwing, the 5000-row ceiling with truncated:true, per-connector PENDING/POSTED variability, descending date order with scheduled:true flags, and a provider_incident block. The PENDING/POSTED and 'top-of-list-is-future' caveats are exactly the kind of non-obvious behavioral context an agent needs to interpret output correctly.

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

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

The description is long, but it is well-structured: it front-loads the core purpose, then moves through the credit-card caveat, ordering pitfalls, pagination, detail variants, and failure behavior. Nearly every sentence covers a real usage pitfall that would cause a mis-call. It loses a point for redundancy — the billId caveat is stated twice — and for the sheer size, which adds token cost for an agent that just needs a straightforward listing.

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

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

For a tool with no output schema, the description compensates remarkably well — response envelopes ({ total, results, warning, error }), payment envelope details, 'account' echo to prevent cross-bank attribution, scheduled_count/notice, truncated, and provider_incident are all described. The result shape is essentially fully specified; account_ids remains an incomplete area, which keeps this from a 5.

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

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

With schema description coverage at 0%, the description correctly carries the full load: ISO format for to/from, 'to = today' to exclude scheduled rows, search_queries matching semantics, the two pagination modes tied to page/page_size, and a detailed breakdown of the detail enum (compact/rich/raw) with the added fields for each value. It loses a point because account_ids (the array `plural` parameter) is never mentioned in the description — 7 of 8 parameters receive rich documentation, leaving one undocumented.

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

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

The first sentence states a specific verb and resource: 'Returns transactions for a bank account (BANK or CREDIT type).' It immediately distinguishes itself from siblings by declaring it is 'the ONLY way to get itemized transactions' for credit accounts, which differentiates it from openfinance_list_credit_card_bills and openfinance_list_transactions_by_item without the agent needing to open those schemas.

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 routing guidance: use openfinance_list_credit_card_bills for 'a standardized open-bill total / total debt', openfinance_list_accounts for 'statement closing/due dates', and openfinance_get_item_status when total is 0 for a CREDIT account. It also tells the agent when NOT to use this tool for bill reconstruction ('Do NOT reconstruct a bill's total by summing transactions by billId'), leaving no inference to 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 already provide readOnlyHint and idempotentHint. Description adds important behavioral traits: 5000/account cap with truncated flag, provider_incident block, and internal account resolution. 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?

Long but front-loaded with main purpose. Every sentence adds value, though could be more structured with clearer separation of sections. Contains redundancies like 'bulk support' line.

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 9 parameters and no output schema, the description covers return structure (compact vs raw), truncation, provider incidents, bulk execution, and use cases comprehensively. Minimal gaps.

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

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

Despite 0% schema coverage, the description explains every parameter's meaning, value options (item as connector_id/name, from/to as ISO dates, granularity with monthly vs raw, detail levels, type filter, top_n, and bulk support). Goes well 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?

Clearly states the tool provides consolidated cash-flow analysis for a bank connection over a period in one call, resolving accounts internally. Distinguishes from siblings like openfinance_list_accounts by stating users do not need to call it first.

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: for annual/monthly analysis, cash flow, etc., and when to omit item for all banks. Mentions alternate approaches (calling list_accounts first) but lacks explicit when-not-to-use for all 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds context: it checks a public status page (not private), and details what it returns (global indicator, degraded components, incidents, your_banks_affected). 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?

Three sentences, each adding value. Front-loaded with purpose. Could be slightly more concise, but overall efficient and well-structured.

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

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

Given no parameters and no output schema, the description covers purpose, usage, and return value comprehensively. Annotations provide safety profile. 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, so schema coverage is 100%. Description adds no param info, but baseline for 0 params is 4, and there is no missing information.

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

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

Clearly states the tool checks the LIVE operational status of the Open Finance provider, specifying the resource and action. Distinguishes from sibling tool openfinance_get_item_status by contrasting provider health vs connection status.

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

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

Explicitly gives usage context: 'Use it whenever data looks incomplete or stale even though a connection shows UPDATED'. Also explains what it reveals (upstream outage, specific bank incidents), helping differentiate from reconnection needs.

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 readOnly, idempotent, non-destructive. Description adds critical context: caveat warnings for non-Open-Finance connectors (manual reconnection needed), and plan-based visibility (PF hides PJ banks, PJ covers both). No contradictions.

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

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

Description is comprehensive but not overly verbose. It front-loads the main action and each sentence adds distinct information. Could be slightly tightened, but well-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?

Despite no output schema, the description fully details return fields (connector id, access, audience, linked connections, connect_url) and behavior (plan handling, caveats). Complete for a search tool with 2 parameters.

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 no property descriptions (0% coverage). Description compensates by explaining keywords[] with examples and stating it's required, and clarifies include_accounts behavior (includes accounts when true). Adds value beyond schema structure.

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

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

The description clearly states it 'Searches the available bank connectors by name' and lists specific return fields (connector id, access, audience, etc.), distinguishing it from siblings like connect or 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?

Explicit guidance: 'Call this BEFORE connecting to hand the user a one-click link to the right bank.' It also explains that keywords[] is required and returns a hint otherwise, and describes plan behavior. Could mention when not to use versus siblings, but overall 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?

Discloses beyond annotations: overrides automatic categorization, creates a Category Rule for the client affecting future transactions. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

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

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

Single paragraph is dense but clear, front-loads the core action then adds context on effect and response format. Every sentence adds value without redundancy.

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

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

Covers purpose, usage, parameter details, side effects, and response shape completely. No output schema needed as description provides expected return structure.

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: explains the items array, required fields (transaction_id, category_id) with their sources, and the response shape including batch error handling.

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

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

Description clearly states the tool corrects categories of transactions via PATCH, specifying the resource (transactions), action (correct categories), and distinguishes from sibling tools like listing or category fetching.

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

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

Explicitly explains when to use (fix miscategorized transactions), how to obtain required IDs from other tools, and describes the side effect of creating Category Rules for future accuracy, guiding appropriate usage.

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 states it reports bugs (a side effect), but the annotation idempotentHint is true, implying repeated calls are safe. This is a contradiction: bug reporting typical creates a ticket and is not idempotent. No other behavioral traits are disclosed.

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

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

The description is only two sentences, with no wasted words. It is front-loaded with the tool's purpose and includes a specific instruction for the conversation parameter.

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 3 parameters, no output schema, and no annotations beyond the contradiction, the description is incomplete. It does not describe return values, success/failure behavior, or whether the bug report is stored immediately.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the 'conversation' parameter (include array with recent messages) but does not explain the required 'message' parameter or optional 'context'. This leaves key parameters under-specified.

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

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

The description clearly states the tool is for reporting bugs, missing features, or feedback, and it mentions including the conversation array for reproduction. It is distinct from sibling tools, which are all OpenFinance-specific 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 does not provide guidance on when to use this tool versus alternatives. There is no mention of prerequisites or exclusions, leaving the agent to infer usage from context alone.

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 information about what is shown (MCP platform and adapter versions), 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?

The description is a single, front-loaded sentence that contains all necessary information without any wasted words.

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

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

Given the tool's simplicity (no parameters, simple version output), the description is complete and sufficient for an agent to use it correctly.

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

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

The tool has no parameters, and the schema coverage is 100%. Per guidelines, 0 parameters results in a baseline of 4; no additional parameter information is needed.

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

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

The description clearly states the tool shows version info. The name and description are aligned with the unique purpose, and there is 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?

The description provides clear context for use (checking versions), but does not explicitly mention when not to use it or alternatives. However, given the tool's simplicity, this is acceptable.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds meaningful detail about what 'state' includes (installed MCPs, connection status, connected accounts, number of exposed catalog tools), which goes beyond the bare annotation and helps the agent predict the response structure.

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 main action and then lists the key output categories. Every phrase adds value, with no repetition of schema or annotation information and no filler.

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

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

Given the tool's simplicity (no parameters, read-only, no output schema), the description fully covers what the tool returns. It enumerates all major aspects of the tool state, making it complete enough for an agent to understand the tool's behavior and likely response format without additional schema or documentation.

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

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

The input schema is empty (0 parameters), so there is nothing for the description to clarify about parameters. Per the rubric, a tool with no parameters receives a baseline of 4; the description adds no unnecessary parameter information, which 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 a specific verb ('Returns') and resource ('current toolkit state'), and enumerates the key components (installed MCPs, connection status, accounts, catalog tool counts). This distinguishes it from sibling tools, which focus on specific actions like authentication, connection, or data 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?

The description clearly conveys that this tool is for obtaining an overall state snapshot, making its primary use case obvious. It does not explicitly state when not to use it or name alternatives, but its unique purpose among the siblings (general state inspection) provides sufficient contextual guidance.

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