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

With no annotations at all, the description carries the full burden. It discloses that this is an owner-scoped mutation with a precondition, which is genuinely useful, but says nothing about irreversibility, what happens to pending responses on the RFQ, or what error is returned if a deal already exists.

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

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

A single sentence with zero filler; the action and its precondition are front-loaded so the agent can decide immediately.

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 one-parameter mutation with no annotations and no output schema, the agent still lacks post-call expectations: whether the RFQ is gone permanently, whether funds/responses are released, and what success looks like. Adequate but noticeably thin.

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

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

Schema description coverage is 0%, but there is only one parameter whose name (rfq_id) and uuid format are largely self-documenting. The description adds the meaningful ownership constraint implicit in 'your own,' yet never mentions rfq_id or how to obtain a valid one.

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?

Specific verb ('Cancel') plus specific resource ('your own RFQ / private order'), with a temporal qualifier that narrows scope. It separates itself from create_rfq/respond_to_rfq by verb alone, but never names a sibling or explicitly contrasts with adjacent tools like get_rfq or deal_status.

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

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

The parenthetical '(before a deal is agreed)' gives an explicit precondition for use, and 'your own' implicitly excludes cancelling other parties' RFQs. It stops short of naming an alternative path (e.g. negotiate) for RFQs already past that stage.

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 carries the burden and mostly meets it: it discloses the irreversible side effect ('reveals the secret on-chain') and the downstream consequence (counterparty/keeper can settle the other leg), plus an API reporting step. It does not cover failure behavior or what happens if the claim tx reverts, but the critical irreversibility is front and center.

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 dense sentences, front-loaded with an ALL-CAPS label and ending with the return value. Every sentence adds information; the shouting is stylistic noise but costs nothing in length.

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 one-parameter settlement action with no annotations and no output schema, the description supplies the return value ('on-chain tx id'), the prerequisites, and the side effect. Only error/revert handling is missing, which an agent would otherwise need.

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% and there is one undocumented parameter. `swap_id` is self-describing and its uuid format is in the schema, but the description never mentions it or the fact that it is the sole required input. Adequate by implication, not by statement.

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

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

States a specific verb and resource ('claim YOUR receive leg of a swap using the preimage') and adds distinguishing scope (signs with the agent's own key, reports to the API). It stops short of naming the obvious sibling `reveal_claim`, so an agent must still infer which of the two settles a leg, but the purpose itself is unambiguous.

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

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

Prerequisites are stated explicitly: both legs must be funded and the preimage must be available (you are the initiator or the initiator already revealed it). That is a real gating condition an agent can check. No exclusion is given against `reveal_claim`, which is the one alternative that matters here.

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 carries the full behavioral burden. It discloses the wallet prerequisite, the distinct outcomes of public vs private visibility, the returned shareable link, and optional target_address locking. It does not clarify whether funds are escrowed at creation, how ttl_seconds affects the order, or what cancellation/expiry behavior looks like.

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 text is front-loaded with the core action, then uses compact lines for direction semantics, visibility modes, and prerequisites. Every sentence contributes operational meaning, with 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?

For an eight-parameter creation tool with no annotations and no output schema, the description covers the essential calling context: direction meaning, visibility behavior, ask_price requirement, target_address locking, returned link, and the wallet prerequisite. Remaining gaps are ttl_seconds semantics and whether any funds are committed or escrowed at creation.

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 important meaning beyond the 63%-covered schema: it explains direction semantics ('GIVE' vs 'RECEIVE'), visibility consequences, the requirement that ask_price applies to private orders, and the counterparty-locking role of target_address. It omits explanation of ttl_seconds and adds little on base_amount or quote_asset 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 opens with a specific verb and resource: 'Post a trade request.' It clearly establishes this as an RFQ creation tool and elaborates direction and visibility modes, though it does not explicitly differentiate itself from sibling tools such as respond_to_rfq or negotiate.

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

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

It gives clear mode-selection guidance: visibility=public creates an open board RFQ with optional price, while visibility=private creates a fixed-price link-only order requiring ask_price. It also states the prerequisite of a proven wallet for the asset given, but does not name alternative tools or when not to use this one.

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 are provided, so the description carries the full burden. It discloses the shape of returned data and notes that swap details exist only 'once agreed', implying a read-only lookup, but says nothing about access restrictions (e.g., must you be a party to the deal) or side effects.

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?

Front-loaded with the resource and its contents, with the usage hint as a short trailing sentence. Nearly zero waste, though the parenthetical list is slightly dense.

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

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

With no output schema, the description usefully enumerates what is returned, which is its main value. However, it omits how to identify the deal (thread_id semantics) and any access constraints, leaving gaps for a single-parameter state tool.

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

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

Schema description coverage is 0% and the sole parameter is a UUID thread_id. The description uses 'thread' only as returned content, never clarifying that thread_id is the deal identifier, so it does not compensate for the schema gap.

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

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

States a specific verb+resource ('Full state of one deal') and enumerates the returned contents (thread, negotiation history, HTLC swap details). An agent can distinguish it from list-style siblings like my_deals or list_open_rfqs, though it never names them explicitly.

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 closing phrase 'Use this to track settlement' implies a usage context, but there is no explicit when-not guidance or routing to alternatives such as get_rfq or my_deals. Usage must be inferred from the settlement framing.

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 carries the full load and does well: it discloses that the agent signs with its own per-chain key, enumerates the exact on-chain action per chain, states the return value (on-chain tx id), and lists prerequisites including a cross-party dependency. It omits irreversibility/failure handling and what happens if only one side is funded.

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?

Front-loaded with the core action and the per-chain mechanics packed efficiently into one paragraph; the trailing initiator-ordering hint is well placed. It is dense but nearly every clause carries operational information, with only the 'AUTONOMOUS SETTLEMENT' label adding little.

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, cross-chain, key-signing mutation with no annotations and no output schema, the description covers signing keys, per-chain behavior, prerequisites, ordering, and the return value. Remaining gaps (failure modes, irreversibility, gas/fee handling) are real but secondary for correct invocation.

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% on a single required swap_id, and the description never explains that parameter — it only indirectly implies it via 'the deal is agreed'. Worse, 'Funds the leg you give' and 'that leg's chain' suggest a leg selector that does not exist in the schema, which could mislead an agent about what it must supply.

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

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

States a specific verb and resource ('fund YOUR side of an agreed swap on-chain') plus the exact per-chain mechanism (approve+HTLC lock on EVM/TRON, P2WSH payment on BTC, escrow signing on Solana). It is clearly distinguishable from the sibling settlement verbs refund_leg and claim_leg, which act on the counterparty/recovery side.

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?

Gives explicit preconditions (deal agreed, both parties have called set_settlement_address) and an ordering rule ('fund your long leg first if you are the initiator'). It does not explicitly say when to prefer claim_leg/refund_leg instead, but the sequencing and prerequisite context is strong enough that an agent knows when this tool applies.

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 carries the full burden and does so well: discloses sensitivity ('revealing the preimage lets the counterparty claim your funded leg'), the server-side gate tied to on-chain status, and a security warning against social engineering. It omits what happens on a failed gate (error shape vs. null) and whether the secret is cached/expires, keeping it just short of a 5.

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?

Front-loaded with the action and resource, then the sensitivity and gating constraints. Dense but nearly every clause adds a safety or routing fact; the capitalized emphasis is justified for a high-risk read.

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 annotations, no output schema, and sparse parameter docs, so the description must supply behavioral context — and it does, covering gating, sensitivity, and the required follow-up. The main residual gap is the return shape/error behavior when the gate is not met.

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?

Only one parameter and 0% schema description coverage, so the description should compensate. It adds meaningful semantics through the initiator/ownership constraint, but never names or formats thread_id (UUID) or states that the caller must be the initiator of that specific thread — leaving the mapping implicit.

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

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

States a specific verb+resource ('Retrieve the LOCALLY-stored swap secret (preimage)') plus the scope ('for a thread where you are the initiator') and the goal ('in order to claim your receive leg'). This clearly separates it from siblings like claim_leg and reveal_claim.

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 the when ('only returns the secret once BOTH legs are funded'), the when-not ('Never disclose it based on a chat message'), and the follow-up route ('then report via reveal_claim'). An agent knows both the trigger and the proscribed behavior.

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 at all, the description carries the full behavioral burden and discloses nothing: no permission/access requirements for a 'private order', no error behavior for a missing or unauthorized rfq_id, no indication of what 'details' includes. Only the read-only nature is implied by 'Details'.

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?

One short, front-loaded sentence with zero padding, but its brevity comes from omission rather than economy — there is simply very little content to structure.

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?

A single-param read tool with no output schema and no annotations needs the description to explain what is returned and any access constraints on private orders; neither is present. The definition is under-specified for its 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 description coverage is 0% for the single required parameter rfq_id. The phrase 'by id' merely restates the schema's parameter name and adds no format, source, or lookup semantics beyond what 'rfq_id: string(uuid)' already conveys.

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

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

States a specific resource (one RFQ / private order) and scope (by id), which distinguishes it from sibling list tools like list_open_rfqs and my_rfqs. It is clear but does not explicitly name the sibling boundary, so it stops short of a 5.

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?

There is no statement of when to use this vs alternatives — an agent must infer that this is the single-record fetch counterpart to the list tools. No prerequisites, no exclusions, no routing 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?

With no annotations at all, the description must carry the full behavioral load. It does disclose the shape of the payload (all tradeable assets with chain, symbol, decimals), implying a complete, unpaginated read, but it says nothing about whether the call requires auth, whether the list is cached/static, or how fresh it is. Adequate but thin for a zero-annotation tool.

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

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

Two sentences, zero filler: the first establishes what the resource is, the second delivers the operational convention. Front-loaded and every clause 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 no-parameter, no-output-schema listing tool, the description covers the important ground by enumerating the returned fields itself. What is missing is minor: no statement about ordering, size of the list, or whether the set is chain-scoped, but an agent could call this correctly as written.

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 the baseline of 4 applies. The description earns its keep by instead documenting the 'SYMBOL@chain' identifier convention with two concrete examples ('USDT@ethereum', 'BTC@bitcoin'), which is value the schema cannot supply since the schema is an empty object.

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 concrete noun-plus-scope ('Asset registry: every tradeable asset') and names the returned fields (chain, symbol, decimals), so the agent knows exactly what it gets. It is unmistakably distinct from the RFQ/deal siblings, which are all workflow actions. It stops short of an explicit verb phrase like 'list all supported assets', which is why it is a 4 rather than a 5.

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 second sentence gives actionable context: assets are referenced elsewhere as 'SYMBOL@chain', so the agent knows this tool is how you learn valid identifiers before calling create_rfq, fund_leg, and friends. There is no need for exclusions because no sibling lists assets, but the description never states the trigger explicitly ('call this first to resolve an asset id').

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

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

With no annotations, the description does disclose useful behavior: the board is public, contains open requests, and is intended for price responses. It still omits pagination, ordering, authentication expectations, and result limits, which matter for a browsing endpoint.

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 short sentences, front-loaded with the core purpose. There is no redundant repetition and the optional-filter note is brief but useful.

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

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

For a simple list tool, the description covers the main purpose and scope. However, with no output schema and no annotations, it leaves return contents, pagination behavior, and the direction filter semantics underexplained.

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 documents base_asset and quote_asset, but the direction enum values sell_base and buy_base are unexplained. The description adds only 'Optional filters' and does not clarify what the filters mean or how they combine.

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 gives a specific verb and resource: 'Browse the public RFQ board,' and clarifies that these are open requests the caller can price. This distinguishes it from single-RFQ, mutation, and private-listing siblings, though it does not name any sibling explicitly.

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?

'Open requests you can respond to with a price' implies the use case: finding RFQs before calling respond_to_rfq. However, it does not explicitly say when to use this versus get_rfq, my_rfqs, or other board views, so guidance is only implied.

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 are provided, so the description carries the full disclosure burden. It does not say whether the tool is read-only, whether results are paginated or filtered, or whether authentication is required. Only the data content (current/pending prices) is described, leaving the operational profile largely blank.

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

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

A single compact sentence with the core content front-loaded and no wasted words. It is appropriately sized for a zero-parameter 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?

For a no-argument read tool with no output schema, the description gives a reasonable content overview. However, because there are no annotations and no return-shape documentation, it should say more about what an agent receives (e.g., a list of threads with prices) and whether the operation is safe/read-only.

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 takes zero parameters, so the baseline is 4. There are no parameter semantics to clarify, and the description correctly does not invent any.

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 names the resource ('deal threads') and its scope ('negotiations + agreed deals ... current/pending prices'), which lets an agent distinguish it from siblings like my_rfqs and list_open_rfqs. It stops short of an explicit verb, but the possessive 'Your deal threads' makes the retrieval intent 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?

There is no statement of when to use this tool versus alternatives such as my_rfqs, deal_status, or get_deal_secret. The agent is left to infer from the name alone that this lists the caller's deals rather than, say, a single deal's status.

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 carries the full behavioral burden. It discloses that results are scoped to the caller's private orders and include statuses, but it does not state that this is read-only, whether authentication is required, pagination behavior, or return shape.

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 short sentence with the scope ('Your own') front-loaded and no filler. The slash construction 'RFQs / private orders' is slightly loose but does not obscure meaning.

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

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

For a parameterless retrieval tool, the description says what is returned at a high level: the caller's own RFQs/private orders and their statuses. Without an output schema, it does not specify the result structure, fields, or pagination, leaving meaningful gaps for an agent that needs to interpret results.

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

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

The tool has zero parameters, so there is no parameter semantics to explain; the baseline for 0 params is 4. Nothing in the description contradicts the empty 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 identifies the resource as the caller's own RFQs/private orders and indicates statuses are included. It implicitly distinguishes from list_open_rfqs by saying 'your own,' but lacks an explicit verb such as 'list' or 'retrieve,' leaving list-vs-detail slightly ambiguous.

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 phrase 'Your own' implies scope and contrasts with public/open RFQ tools like list_open_rfqs, but it does not explicitly state when to use this tool versus get_rfq, list_open_rfqs, or my_deals. Usage is implied rather than directed.

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 carries the full burden and does so well: it explains that propose/accept_proposal constitute agreement, that accept triggers HTLC creation, and that the initiator's secret is generated locally with only its hashlock sent, retrievable via get_deal_secret. It also discloses that a stale price causes refusal and that reject closes the deal.

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 bullet-list structure is front-loaded and appropriate for a five-action tool, with no filler sentences. Some clauses are long and nested, especially around accept and hashlock handling, but every part conveys useful semantics.

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 mutation tool with no annotations or output schema, the description covers action semantics, side effects, and secret handling thoroughly. It could go further by explaining the response after each action or explicitly telling the agent where to obtain thread_id, so it is strong but not fully self-contained.

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 descriptions cover only body and price minimally, and action/thread_id have no descriptions. The description compensates by mapping body to message and price to the exact price required for propose, accept_proposal, and accept, including the source (pendingPrice/currentPrice). That adds substantial meaning beyond the schema.

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

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

The description opens with 'Act in a deal thread' and enumerates five concrete actions, so the tool's scope is clear. It references deal_status and my_deals as sources of pricing state, indirectly separating negotiation writes from status reads, though it does not explicitly name every sibling it is not.

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

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

It gives precise conditions for selecting accept vs accept_proposal vs propose, including that accept is only needed when youAccepted is false and that accept_proposal uses pendingPrice. It also tells the agent to re-read the deal if the named price has changed. It stops short of stating when to use negotiate versus RFQ tools like respond_to_rfq.

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 carries the full behavioral burden and does so well: it explains signing with the agent's own key, rail-specific mechanics for EVM, TRON, Solana, and Bitcoin, the Bitcoin MTP delay, payout destinations per rail, and that it returns the on-chain tx 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?

The description is dense but front-loaded, starting with the operation and conditions, then adding rail-specific behavior and return value. Every sentence adds useful operational detail without 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?

For a complex cross-rail settlement tool with no annotations and no output schema, the description is strong on behavior, timing, signing, destination, and return value. The main remaining gap is that it does not document the swap_id parameter.

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

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

The schema has only swap_id with 0% description coverage, and the description never explains what swap_id represents or how to obtain it. The parameter name is fairly self-evident, but the description does not compensate for the schema coverage gap.

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

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

The description states a specific verb and resource: take back a funded leg after its timelock has passed when the counterparty never claimed it. It clearly distinguishes refunding from claiming and gives enough detail to identify the operation without opening the schema.

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

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

It clearly states the triggering conditions: timelock passed and counterparty never claimed. It does not explicitly name sibling alternatives like claim_leg or state when not to use it, but the context is clear enough for correct 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?

With no annotations, the description carries the burden well: it discloses the side effect (opens a private deal thread), the return value (threadId), and the commitment semantics ('your quote is your acceptance ... this tool accepts it for you with your hashlock'). It omits whether the response is retractable, how funds/hashlock are actually committed, and any auth requirements, leaving some behavioral risk undisclosed.

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?

Front-loaded with the action and return value, then the high-risk price semantics, then the commitment consequence — a sensible ordering. The mid-sentence parenthetical about hashlocks is dense but earns its place by explaining why no separate acceptance step is needed.

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 two-parameter mutation tool with no output schema and no annotations, the description covers the essentials: side effect, return handle, unit semantics, and post-acceptance state. It leaves open edge cases (multiple responses per RFQ, validity bounds on price, failure modes) that an agent would want to know.

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

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

Schema coverage is only 50%, but the description fully compensates for the undocumented-critical parameter by clarifying price is the TOTAL quote-asset amount for the whole base amount, not per-unit — a unit ambiguity the schema alone would not resolve. rfq_id remains undocumented in both places, though its uuid type and provenance (get_rfq/list_open_rfqs) make it inferable.

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

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

States a specific verb and resource ('Respond to an open RFQ with your price') and immediately distinguishes itself from siblings by naming the downstream tools it feeds (negotiate/deal_status) and by contrast with create_rfq implicit in 'open RFQ'. An agent knows exactly what action this performs without opening the schema.

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 phrase 'open RFQ' scopes usage and the closing note tells the agent this is the initiator-side action, seeding the alternative path (creator accepts). It also routes follow-up work to negotiate and deal_status. It stops short of explicitly stating exclusions, e.g. what to do if the RFQ is already closed or if you are the creator (cancel_rfq/my_rfqs).

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 carries the full burden. It usefully discloses the consequence that reporting publishes the secret so the counterparty and watchers can settle the other leg, which signals this is a consequential disclosure rather than a benign read. It doesn't state permissions, irreversibility of revealing the secret, or what happens on failure.

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

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

A single front-loaded sentence that leads with the precondition then the action and its purpose. Little waste, though it is slightly dense/run-on.

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 mutation-style disclosure tool with no annotations, no output schema, and low parameter coverage, the description covers the why and when but omits return behavior and the irreversibility of publishing the secret, leaving meaningful 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 only 25% (only 'secret' is documented), so some compensation is expected. The description maps to 'secret' and 'claim_tx' but adds nothing about swap_id or the 'leg' enum, leaving those to the schema's self-evident naming.

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

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

States a specific verb (report) and the resources it takes (revealed secret + claim tx), and frames the task as disclosing the preimage so the counterparty can settle. It implies a sequencing relative to the sibling claim_leg (after the on-chain claim) without naming that sibling directly.

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?

"After you claimed your receive leg on-chain (with your own wallet)" gives a clear prerequisite/timing condition for using this tool, implicitly excluding use before the on-chain claim. It stops short of naming alternatives like claim_leg or fund_leg, or saying when not to use it.

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 the description carries the full disclosure burden. It does add real context: per-leg semantics, the maker/taker leg-role mapping, and the ordering constraint before funding. It omits what happens on a second call (overwrite/idempotency), whether the caller must be a party to the swap, and any address validation or error behavior — gaps that matter for a mutation tool with zero annotation coverage.

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?

Purpose is front-loaded in the first clause, followed by the funding prerequisite and then the leg-disambiguation rule — a sensible priority order. The maker/taker sentence is dense but each sentence carries distinct information; only minor overlap with the schema's own `leg` description.

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 four-parameter mutation tool with no annotations and no output schema, the description covers when and how to call it but not the outcome: nothing about the response, whether the address can be re-set, or what errors arise from an invalid or wrong-chain address. Adequate to invoke, thin on what to expect.

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 50%: `leg` and `chain` are already described in the schema, but the description goes further on `leg` by explaining the maker funds leg a and receives on leg b while the taker is the reverse, and it clarifies that `address` is the caller's own receive/refund address rather than an arbitrary counterparty address. `swap_id` receives no added meaning, but it is a self-evident UUID identifier.

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

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

States a specific verb and resource — set the caller's receive/refund address for an agreed swap, per leg — and scopes it to a prerequisite of HTLC funding, which cleanly separates it from fund_leg, claim_leg and refund_leg in the sibling list. An agent can tell what this does without opening the schema.

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?

Gives a clear trigger ('Required before the HTLC can be funded') and an explicit conditional rule for when to supply `leg` (only when both legs are on the same chain). It does not name an alternative tool or state exclusions, but the sequencing relative to fund_leg is unambiguous.

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 carries the burden and does disclose non-obvious behavior: unreadable keys surface under `localSigners.unusable`, `solanaLink` reports whether the Solana wallet is proven to the account, and naming a key you don't hold makes a leg unsignable. It never states the operation is read-only, but the read semantics are evident from the content returned.

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 core answer is front-loaded, but the middle is a single run-on sentence with parentheticals nested three levels deep (`localSigners.unusable`, `solanaLink`), which hurts scanability. The settlement-address warning is valuable and earns its place, but the packaging could be broken into clearer clauses.

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 no annotations, the description must explain the return shape, and it does: account, linked wallets, local signer addresses, unusable keys, and the Solana linkage proof. For an identity-inspection tool this is nearly complete, missing only a note on whether the listing is exhaustive or paginated.

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 takes zero parameters, so there is nothing for the description to disambiguate at the input level; this sits at the baseline for a no-parameter tool.

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 clause states precisely what is returned: the authenticated account with linked wallet addresses, plus `localSigners.addresses`. The resource is unambiguous and clearly distinct from the RFQ/deal siblings, though the verb ('returns') is implied rather than stated.

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 final sentence gives one concrete usage rule: use `localSigners.addresses.solana` as your settlement address on a Solana leg. However, nothing says when to call this tool versus siblings like `set_settlement_address` or before `create_rfq`, so tool-selection guidance is only implied.

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