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

No annotations provided. Description mentions idempotency via client_request_id but does not detail side effects, error states, or what happens on failure. The tool's impact on state machine is implied but not fully explained.

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?

Concise and well-structured: main purpose, usage guidance, then parameter notes. No redundant information, each 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?

No output schema. Description explains purpose and param notes but lacks details on return value, error handling, or how this tool fits into the overall trade lifecycle. Could be more complete for a complex settlement tool.

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

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

Schema coverage is 100%, baseline 3. Description adds value with notes on role requirements, txHash format, and chainType defaults, clarifying usage beyond schema definitions.

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's purpose: recording the on-chain HTLC lock tx hash to advance settlement, with DVP guarantee. Differentiates from siblings like refund_htlc and withdraw_htlc by focusing on the lock step.

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 USE WHEN and DO NOT USE WHEN conditions, specifying the prerequisite (trade accepted, lock tx broadcast). Provides clear context for correct invocation.

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

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

With no annotations provided, the description fully discloses behavioral aspects: sealed-bid auction, non-custodial nature, cross-chain support, zero slippage, and pre-call steps. It also covers idempotency and the requirement to confirm before calling, ensuring the agent understands the tool's behavior comprehensively.

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 with clear headings, examples, and logical flow. It is detailed but every section adds essential information for proper tool usage. The front-loading of the core purpose and the use of tables and examples make it efficient for an AI agent to parse.

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 the detailed description, it lacks an explanation of the tool's return value. There is no output schema, and the description does not mention what the response contains (e.g., RFQ ID, status). For a complex tool with no output schema, this omission creates a completeness gap, though the rest of the context is thorough.

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

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

The description adds immense value beyond the input schema, with detailed intent mapping, chain inference, language-specific instructions, handling of edge cases like USD amounts, and explanations for each parameter. This helps the agent correctly populate parameters even from ambiguous user input.

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: creating an RFQ for OTC swaps. It specifies the type of auction (sealed-bid), distinguishes from siblings like swap_execute, and provides explicit use and non-use cases, making the purpose unambiguous.

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

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

The description provides comprehensive usage guidelines, including explicit 'USE WHEN' and 'DO NOT USE WHEN' sections, alternatives like DEX aggregator, and detailed intent-to-parameter mapping with language support and chain inference rules. It also instructs when to ask for clarification, ensuring proper tool selection.

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 read-only nature and safety to call anytime. Explains empty array behavior for unknown tradeId (not an error), and details the structure and interpretation of the result array. Since no annotations exist, the description carries the full burden and excels.

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 into sections (purpose, returns, usage, interpretation). Some verbosity in the interpretation section, but every sentence adds value. Front-loaded key info effectively.

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?

Highly complete: covers purpose, return format, edge cases, interpretation per leg, and usage guidance. Despite no output schema, the description compensates thoroughly for a one-parameter query tool.

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

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

Schema coverage is 100% with a clear description for tradeId. The description repeats the empty-array behavior already in the schema, adding no new parameter-level meaning. Thus baseline 3 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?

Clearly specifies 'Real-time trade observability — per-leg HTLC settlement state for a trade' with specific details on what is returned. Distinguishes from sibling tools like list_my_trades and list_open_rfqs by stating it covers settlement-leg state only.

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 'USE WHEN' scenarios (showing trade status, deciding next action, polling) and a 'DO NOT USE WHEN' section naming alternative tools, guiding appropriate invocation.

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

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

Annotations are absent, so the description must cover behavioral traits. It only states 'Read-only' and 'list the caller's trades.' No mention of output ordering, pagination behavior beyond schema, rate limits, or authorization needs. For a list operation, more detail on what to expect would be helpful.

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 and front-loaded with the core purpose in the first sentence. It then provides use-case guidance, exclusions, and a follow-up hint. Could be slightly more structured, but every sentence serves a clear purpose.

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

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

Given no output schema, the description could explain what fields the returned trades contain or default sorting. It mentions a follow-up tool (get_htlc) but lacks details on output format or behavior when no trades exist. Still, it covers usage context and alternatives well.

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

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

Input schema has full description coverage (100%), so baseline is 3. The description adds 'Optional status filter narrows the page,' which restates what the schema already says about the status parameter. No additional meaning is provided for page or pageSize beyond schema descriptions.

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

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

The description clearly states 'List the caller's trades (active + historical). Read-only.' It identifies the specific resource (caller's trades) and scope (active+historical). It explicitly distinguishes from sibling tools like list_open_rfqs and get_htlc.

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

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

Provides explicit when-to-use scenarios: 'when an agent restarted/lost context and must resync in-flight settlements, or showing the user their trade history.' Also gives clear when-not-to-use: 'DO NOT USE WHEN: you need open market demand (use list_open_rfqs) or per-leg HTLC detail for one trade (use get_htlc).' Includes follow-up 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?

No annotations exist, so description carries full burden. Declares 'Read-only', describes return fields, and mentions pagination. Does not detail rate limits or authentication, but is sufficient for typical use.

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 only 3 sentences, front-loaded with the core purpose. Every sentence provides 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?

Even without an output schema, the description names the return fields and links to the next logical action (respond_rfq). Pagination is explained, and the tool's role in the workflow is clear.

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 100% with well-described parameters (page and pageSize). Description does not add additional meaning beyond the schema, so baseline score of 3 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?

Clearly states 'List currently open (ACTIVE) RFQs' with specific verb and resource. Distinguishes from siblings like list_my_trades and respond_rfq by mentioning when each should be used.

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 provides use cases: 'USE WHEN: acting as a market-maker agent deciding what to quote on... DO NOT USE WHEN: you want your own trade history (use list_my_trades).' Also directs to respond_rfq for quoting.

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 read-only nature and no auth side effects. Explains that same symbol on different chains are distinct markets, which is a behavioral trait beyond basic description. No rate limits or pagination mentioned, but acceptable for a simple list with no parameters.

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 paragraphs with clear front-loaded first sentence. Each sentence adds value, though could be slightly more concise by merging some lines. Overall well-structured.

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

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

Complete context for a parameterless list tool: explains entry format (SYMBOL/chain), usage hints, and distinctions between chains. No output schema needed as purpose is clear.

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

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

No parameters in schema, so description does not need to add parameter info. Schema coverage is 100% (no params). 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?

Description clearly states the tool lists chain-qualified token pairs supported for RFQ/swap. The use of specific verb 'list' and resource 'token pairs' sets a precise scope, distinguishing it from siblings like create_rfq or swap_quote.

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 provides when to use ('before create_rfq if unsure a token/chain is supported', 'to show available markets') and when not to use ('if already know the pair is supported'), including the rationale that this is for discovery, not a precondition.

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?

Without annotations, the description carries full behavioral burden. It explains the refund mechanism (non-custodial, trustless, no preimage needed) and conditions. However, it omits details on idempotency or success/failure behavior beyond the parameter note for client_request_id.

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

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

Description is well-structured into a title, usage conditions, parameter notes. Every sentence adds value, no redundancy. Appropriate length for 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 no output schema and moderate parameter count, the description covers usage context, parameter semantics, and behavioral intent. It lacks error scenarios or return value details, but is sufficient for an agent to invoke correctly in the stated conditions.

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 100% (baseline 3). Description adds value by clarifying that 'txHash' is on-chain 0x-prefixed and that 'chainType' should be 'bitcoin' or 'sui' for non-EVM legs, which is not obvious from the schema alone. Also explains 'client_request_id' as an idempotency key.

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: 'Trustless unwind — recover locked funds after the HTLC timelock expires.' It distinguishes from sibling 'withdraw_htlc' by specifying when NOT to use it, providing a specific verb-resource pair and scope.

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 'USE WHEN' and 'DO NOT USE WHEN' sections with concrete conditions (timelock deadline passed, counterparty didn't lock) and an alternative tool named (withdraw_htlc). Also notes that only the original lock sender can call refund, and only after deadline.

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 sealed-bid privacy, no funds locked until acceptance, losing bids not revealed, and idempotency key behavior. No annotations provided, so description fully covers safety and 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?

Concise, well-organized with USE WHEN, DO NOT USE, PARAM NOTES sections. No redundant information, every sentence adds value.

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

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

For a tool with 5 parameters and no output schema, the description covers purpose, usage, parameter details, and behavioral notes comprehensively. No obvious 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?

Schema coverage is 100%, baseline 3. Description adds clarifying context: price format with example, amount as base token, and funds-lock semantics for idempotency key. Exceeds baseline.

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 is a market-maker tool for submitting sealed-bid price quotes on open RFQs. Differentiates from sibling tools like create_rfq and list_open_rfqs.

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 USE WHEN and DO NOT USE conditions, including specific alternatives (create_rfq). Guides agent on correct invocation 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?

Despite no annotations, the description discloses key behaviors: no funds locked, idempotency via client_request_id, and that settlement for executed swaps is governed by HTLC timelock. No contradictory information.

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

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

The description is concise, front-loaded with the main action, and uses bullet-style headers ('USE WHEN', 'DO NOT USE WHEN', 'PARAM NOTES') for clarity. Every sentence adds value 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 the tool's simplicity and lack of output schema, the description covers all necessary aspects: purpose, usage conditions, parameter notes, and idempotency. No gaps are apparent.

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 100%, so the description adds only incremental value by explaining swap_handle as 'RFQ id' and client_request_id as 'Idempotency key. Best-effort within this session.' This is helpful but not essential.

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

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

The description uses a specific verb ('Abort') and resource ('open swap'), clearly distinguishing from sibling tools like swap_execute or swap_quote. It also clarifies no funds are locked.

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 (backing out of unexecuted swap_quote) and when not to use (swap already executed), with examples like limit not met or user changed mind. Provides clear exclusion criteria.

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

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

With no annotations, the description fully discloses behavioral traits: real funds, non-custodial (doesn't lock funds), acceptance behavior with missing parameters (CONFIRMATION_REQUIRED), warning about accepted_amount exceeding requested amount, and fact that limit_price is re-supplied and not stored.

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

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

Description is well-structured with sections (description, use when, param notes, warnings) and front-loaded with the core action. Though slightly long, each sentence adds necessary value for a real-funds tool.

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

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

Despite no output schema, the description covers return value (trade_id) and next step (create_htlc). It also addresses edge cases (missing parameters, size exceeding request) and constraints (non-custodial). Fully sufficient for an agent to use 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 has 100% coverage with descriptions. The description adds significant meaning: limit_price is sealed reservation and must be re-supplied, quote_id is exact bid from swap_status, client_request_id is idempotency key. This goes beyond the schema's basic 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?

Clearly states it accepts the winning sealed bid and creates a trade, differentiating from sibling tools like respond_rfq. The verb 'accept' and resource 'swap' are specific, and the description distinguishes from maker-side quoting.

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 provides USE WHEN (swap has acceptable bid and user confirmed) and DO NOT USE WHEN (price not surfaced or want maker-side quoting), with alternative tool named (respond_rfq). This gives clear decision criteria.

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?

Describes async nature, no synchronous price, zero slippage, ghost auction mechanism, limit_price secrecy, parameter defaults, and idempotency. No annotations provided, so description carries full burden and does so comprehensively.

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

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

Well-structured with front-loaded summary, usage guidelines, parameter notes, and follow-up calls. Slightly lengthy but every sentence adds value; could be tightened slightly but overall effective.

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

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

For a complex tool with 11 parameters, no output schema, and no annotations, the description covers return value, async behavior, privacy, parameter details, and post-call actions. Complete enough for proper 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 coverage is 100%, but description adds extra context in PARAM NOTES: limit_price as floor/ceiling, private default meaning, client_request_id best-effort idempotency, max_wait_seconds and expiresIn caps. This adds value beyond schema.

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

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

The description clearly states the tool as a one-call OTC swap intake that opens a sealed-bid Ghost Auction, returning a swap_handle and best bid. It distinguishes from sibling tools like create_rfq and DEX aggregators, providing specific verb and resource.

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 provides USE WHEN and DO NOT USE conditions, naming alternatives (create_rfq, DEX aggregator) and contexts (privacy-sensitive, large flow). Also maps follow-up tools (swap_execute, swap_status, swap_cancel).

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 no annotations, the description explicitly states read-only and stateless, describes output fields (best_bid, bids_seen, still_open, rfq_status), and explains the follow-up action with swap_execute, providing comprehensive 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?

Well-organized with distinct sections; each sentence adds necessary information without redundancy. The description is compact and front-loaded.

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

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

Given no output schema, the description covers purpose, usage, parameters, output, and follow-up actions adequately. It could mention error handling but is complete for its complexity.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds value by explaining response fields and how to use them with swap_execute, enhancing semantics 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 re-polls an open swap using swap_handle, returning the current best sealed bid and bid count. It distinguishes from siblings by referencing get_htlc and list_my_trades for different needs, 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?

Explicit 'USE WHEN' and 'DO NOT USE WHEN' sections provide specific scenarios and alternative tool names (get_htlc, list_my_trades), offering clear decision 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?

Reveals that revealing the preimage makes the swap atomic and simultaneously unlocks the counterparty leg. Lacks mention of irrevocability or on-chain txHash requirement, but sufficient for the operation.

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

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

Compact description with clear structure: one-line summary, use/don't-use section, and param notes. Every sentence provides necessary information.

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

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

Covers purpose, usage, and key parameters adequately. No output schema, but for a claim operation, missing return value info is acceptable given the straightforward nature.

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 100%, so baseline is 3. Adds value by specifying preimage format (0x-prefixed 32-byte hex) and chainType for non-EVM legs beyond 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?

Clearly describes the tool as an atomic claim that reveals the preimage to unlock both legs. Distinguishes from sibling 'refund_htlc' by mentioning timelock expiry.

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 and when not to use, including a specific alternative tool (refund_htlc) for expired timelocks.

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