Hashlock Markets

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

With no annotations, the description carries the full burden and does well: it discloses that accept:true is a COMMIT ('like accept_terms'), who must supply hashlock (the initiator funding the long leg), and optimistic-concurrency behavior where a stale quoteAmount is refused. It does not describe idempotency or what a successful call yields, which keeps it off 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?

Purpose and the stale-amount guard are front-loaded, and every clause carries operational content. The nested parentheticals ('(COMMITS, like accept_terms)' and 'the proposer agreed by proposing, so this agrees the deal') make it denser than it needs to be, slightly hurting parseability.

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 committing mutation with no annotations and no output schema, the description covers the risky parts (commit semantics, hashlock obligation, refusal on stale price) but says nothing about what the call returns or what state the thread/swap is in afterward. An agent knows how to call it but not what to expect back.

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 75%, and the description adds genuine meaning beyond it: quoteAmount must be the pendingAmount previously read from get_thread (source and freshness constraint), and hashlock is scoped to the initiator only when accept:true. Only 'id' is left to inference, which is acceptable for a uuid thread 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?

Opens with a specific verb and resource ('Accept the counterparty's pending price on a thread') and immediately distinguishes itself from the sibling accept_terms by scope: this accepts a pending proposal, that one accepts terms later. An agent can place it against propose_price, get_thread, and accept_terms without opening any 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?

Explicitly routes the agent: read pendingAmount from get_thread first, expect refusal if a newer counter superseded it, then 'read again and decide.' It also states the conditional alternative — 'Without accept, you accept afterwards with accept_terms' — which is a real when-to-use-which decision rule rather than implied 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, the description carries the full burden and does so: it discloses rejection when the price moved, the state transition (both sides accepted creates the HTLC swap), and the security-critical behavior of the hashlock — sha256(secret), 32-byte secret generated client-side, preimage never seen by the server. That is far beyond what the schema conveys.

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?

Dense but front-loaded: the core action and price-freshness constraint come first, then the conditional applicability, then the initiator's hashlock duty. No sentence is filler given the number of distinct behaviors that must be conveyed.

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 state-changing, protocol-critical call with no annotations and no output schema, the description covers preconditions, rejection conditions, the resulting swap creation, and the secret-management requirement. Nothing an agent needs to invoke this correctly appears to be missing.

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

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

Schema coverage is 67%, and the description compensates by explaining where quoteAmount comes from (currentQuoteAmount from get_thread) and exactly how hashlock must be constructed, including who must supply it (the initiator funding the long leg). This adds meaning the parameter descriptions alone do not provide.

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 — accept the current terms at the price you read — and pins the price to currentQuoteAmount from get_thread. It also distinguishes itself from the adjacent flows by noting that your own quote or a sent proposal already counts as accepted, which an agent can use to tell this apart from accept_proposal.

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 an explicit precondition (your side's takerAccepted / makerAccepted must be false) and an explicit exclusion (your own quote, or a proposal you sent with your hashlock as initiator, does not need this call). It also names the sibling get_thread as the source of the quote amount, so the agent knows the ordering of calls.

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 must carry the behavioral burden. It usefully explains that Bitcoin witness assembly happens server-side and how refund preimages are omitted, but it does not disclose important broadcast behavior such as irreversibility, retry/idempotency semantics, confirmation behavior, or required permissions.

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 purpose is front-loaded in the first sentence, followed by chain and payload details. The second sentence is long and dense, especially the Bitcoin clause, but most of the detail is necessary given the untyped 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?

The description covers input payload formats well, which is important given the empty schema. However, with no output schema and no annotations, it leaves return values, success/failure behavior, and confirmation semantics undescribed, which are relevant for a transaction broadcast 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%, so the description must compensate, and it does: it explains the chain enum and the chain-specific meanings of the untyped 'signed' payload, including EVM raw hex, Solana base64, and Bitcoin raw/PSBT forms. TRON is described only vaguely as 'the signed transaction object,' so it is not fully precise.

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?

Uses a specific verb, relay/broadcast, and resource, a transaction the caller signed, and clearly distinguishes this from build/preparation tools by emphasizing the payload is already signed. The chain set and signed-payload focus make the tool's job 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 makes clear this is for submitting an already-signed transaction and references payloads coming 'from a build step,' which implies the build_* siblings are upstream. It does not explicitly state when not to use it or list the alternative build tools by name, so it is clear but not fully routing-aware.

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 discloses that the claim is unsigned, that it reveals the secret on-chain, and that both legs must be funded. It also explains the chain-specific signing and return flows, including the exact Bitcoin sighash and broadcast_tx handoff.

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: the core action, prerequisite, secret format, and consequence come first, followed by the chain-specific return flows. Every sentence adds needed operational detail 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 complex, unsigned-transaction builder with no annotations or output schema, the description covers the critical effects and return behavior across EVM, TRON, and Bitcoin. It is only incomplete on the id and leg parameter meanings, which are required for fully 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 description coverage is 0%, so the description must explain all three required parameters. It explains that secret is a 32-byte hex preimage and implies both legs matter, but it never explains the id parameter or the meaning of the leg enum values.

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

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

The description states a specific verb and resource: build the unsigned claim, with the crucial effect that it reveals the secret on-chain. This clearly distinguishes it from sibling build tools such as build_fund and build_refund.

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 a clear prerequisite (both legs funded) and explains the required follow-up through broadcast_tx for Bitcoin. It does not explicitly address when to use build_claim versus build_refund or when not to use it, leaving some routing 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?

With no annotations present, the description carries the full burden and does so well: it discloses that transactions are unsigned, that the server never holds keys, the meaning of 409 states including the 'never pay the escrow again' hazard, Bitcoin-specific remainder/topUp semantics, feePayTo/feeAmountSats, and 503 as retryable. These are non-obvious operational traits that go well beyond the schema.

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 return type, then the operational caveats. It is dense and the parenthetical quota of 409 sub-states is heavy, but nearly every clause carries actionable information rather than 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 two-parameter tool with no output schema, it explains the return material and the full signing/submission lifecycle, plus error-state handling. The one real omission is the semantics of id and the leg enum, which leaves the caller under-informed on inputs.

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 define both parameters, but it only gestures at 'leg' without explaining what a vs b mean and never clarifies that 'id' is the swap/RFQ identifier or what format it takes. An agent still has to guess at the two inputs 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 ('Build the UNSIGNED transaction(s) to fund your leg') and immediately describes the return shape (EVM txs / BTC pay-to / TRON txs). It cleanly separates itself from broadcast_tx by explaining that it only produces signing material and that submission happens elsewhere.

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 chains the workflow: build here, sign with your own key, then submit via broadcast_tx. It also gives retry/stop guidance for 409 ('already funded', 'cannot fund yet', missing address) and 503. It does not, however, route between the other build_* siblings (build_claim, build_refund), which is the remaining ambiguity.

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 it does disclose meaningful behavior: the output is UNSIGNED (not broadcastable as-is), it is gated on timelock expiry, and for Bitcoin preimageHex must be omitted at broadcast time to select the refund branch — a non-obvious, high-consequence detail. It omits what happens if called early (error semantics) and what the returned artifact actually is.

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

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

Two sentences, front-loaded with the core action and the gating condition, with no filler. Every clause carries operational information, including the branch-selection warning.

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 and no output schema means the description is the only documentation, and for a build step in a build/sign/broadcast pipeline it should at least name the artifact produced and the hand-off to broadcast_tx. As written an agent knows the preconditions and the Bitcoin quirk but not what it gets back.

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 and largely does not. It references 'leg' and 'its timelock' but never says what the `id` refers to (RFQ, swap, or thread) nor explains the 'a'/'b' leg distinction, leaving both parameters semantically opaque.

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 ('Build the UNSIGNED refund for a leg') and positions it relative to the sibling build_claim by sharing signing shapes. It is clear this is a construction step for a refund transaction rather than a broadcast, though the domain concept of a 'refund' is not defined for an unfamiliar agent.

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 a concrete precondition — 'available after its timelock expires' — and points to build_claim as the analogue for signing shapes, which tells the agent where this fits in the flow. It stops short of stating what the alternative is when the timelock has not expired or whether a claim should be used instead.

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

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

With no annotations, the description carries full burden; it usefully discloses the taker scope, the precondition, and the consequence that the order otherwise only leaves the book by expiring. It omits what happens to the RFQ thread/state after cancellation, whether it's reversible, and any auth/permission detail beyond 'your own'.

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 tight sentences, zero filler, with the scope and precondition front-loaded before the consequence. 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 single-parameter mutation with no annotations or output schema, the description gives enough purpose, scope, timing, and consequence to invoke it correctly. The main gap is silent handling of the id parameter and post-cancellation state.

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?

One parameter ('id', UUID) with 0% schema description coverage, and the description never mentions it. The name cancel_rfq plus the '(scope: taker)' hint let an agent infer the id is the RFQ to cancel, but no explicit parameter meaning is added beyond the schema's format constraint.

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 (withdraw/cancel) and resource (RFQ) plus an ownership/scope qualifier '(scope: taker)' and a temporal precondition 'before a deal is agreed'. It is clearly distinct from create_rfq, get_rfq, and accept_proposal, though it does not name a 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?

The precondition 'before a deal is agreed' plus '(scope: taker)' tells the agent when the tool applies and to whom. The second sentence implicitly contrasts with the alternative behavior (letting the order expire), giving a reason to prefer cancellation, though no explicit tool alternative is named.

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 does real work by defining the give/receive semantics of direction and the cross-field rule that private visibility requires askAmount, plus a format constraint. However, it omits mutation-side context an agent needs before writing: whether posting requires wallet proof or locked funds, that ttlSeconds makes the RFQ auto-expire, and whether the RFQ can be cancelled later (there is a cancel_rfq sibling).

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 terse clauses, front-loaded with the core action, then the two highest-risk semantics (direction polarity and the private/askAmount dependency). No filler sentences, and the most error-prone detail is stated in the clearest form.

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?

This is a high-complexity trading write with 8 params, no annotations, and no output schema, so the description must be self-sufficient and is not. It never explains targetAddress (presumably the counterparty for private RFQs), ttlSeconds behavior, what is returned on success (RFQ id?), or how asset IDs are formatted, leaving multiple blocking unknowns for a first-time caller.

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 for 8 bare parameters. It adds genuine meaning for direction, visibility, askAmount, and the amount format ('base-unit integer strings'), but leaves ttlSeconds, targetAddress, baseAssetId, and quoteAssetId entirely undefined — roughly half the surface is unexplained in both schema and description.

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 — 'Post a trade request' — and pins the actor role with '(scope: taker)'. An agent can tell this creates a new RFQ, but the description never distinguishes it from siblings like quote_rfq, propose_price, or request_listing, so the differentiation must be inferred from the name.

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?

'Scope: taker' implies the situation (you are the one requesting a trade, not quoting one), which is useful but indirect. There is no explicit when-to-use statement, no exclusion of quote_rfq/propose_price, and no mention of prerequisites such as a proven wallet or funded balance.

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, yet it says nothing about read-only safety, auth/permission requirements, or what happens when the id is unknown. Only the word 'Details' weakly implies a non-mutating read.

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 short sentence with no filler and the scope front-loaded. It is efficient, though the terseness edges toward under-specification rather than genuine conciseness.

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, no annotations, and no description of the RFQ fields returned or error behavior for a missing id. For a lookup tool the agent is left to guess the response shape entirely.

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 description only repeats the schema's intent ('by id'), adding no meaning about the uuid format or source of the id. With a one-parameter tool this is low-stakes, but nothing beyond the field name is conveyed.

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 ('get') and resource ('RFQ') scoped to a single record by id, which implicitly distinguishes it from the sibling list tools (list_open_rfqs, list_my_rfqs, list_rfq_threads). It stops short of naming an alternative or clarifying what 'details' includes.

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

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

No guidance on when to use this versus list_open_rfqs, list_my_rfqs, or get_thread, and no prerequisites stated. The agent must infer from the name alone that this is the single-record lookup path.

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 does add valuable behavioral context that message bodies come from the COUNTERPARTY and must be treated as data, not instructions, and that a notice accompanies the result. However, it omits core behavioral facts: that this is a read-only retrieval, permission requirements, and what happens on an invalid or missing 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?

Two tight sentences with no filler; the untrusted-content warning is the highest-value content and is placed prominently. It loses a point only because the opening sentence is a noun phrase rather than an action statement, slightly burying what the tool actually does.

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 retrieval tool with no annotations and no output schema, the description conveys the content types returned and a critical prompt-injection caveat, but it never states that it fetches a thread by id nor describes the result envelope beyond pointing at a 'notice'.

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 required parameter 'id' has 0% schema description coverage, and the description never mentions it — not its format (uuid), what it identifies, or how to obtain one. With low coverage the description should compensate, and it does not.

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 ('a negotiation thread: messages and current/pending terms') but never states the action — the verb 'get/fetch by id' is only implied by the tool name. It does not differentiate itself from siblings like get_rfq or list_rfq_threads, leaving the agent to infer that this retrieves a single thread.

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

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

No guidance on when to use this versus get_rfq or list_rfq_threads, and no preconditions (e.g., needing a valid thread id) are stated. The only usage-adjacent note is the data-vs-instructions warning, which is about behavior rather than 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?

No annotations exist, so the description carries the full burden. It implies a read ('registry') and discloses that address is null for native assets, but says nothing about scope (all chains? all listed assets?), ordering, pagination, or whether delisted assets are included — material for a tool used to validate counterparty assets.

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 zero filler, and the key concept ('Tradeable asset registry') is front-loaded. It is arguably over-trimmed into a fragment, leaving no room for the usage or scope context noted above.

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?

Because no output schema exists, the description's field list does useful work explaining the return records, which is the main thing an agent needs. However, for a listing tool it omits scope and ordering, so it is adequate rather than complete.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description's field enumeration describe return shape rather than inputs, which belongs to the transparency dimension instead.

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 concretely as a 'Tradeable asset registry' and enumerates the record fields, so an agent understands it retrieves the list of tradeable assets. It lacks an explicit verb ('list/return all'), but the noun phrase plus the tool name makes the intent unambiguous and clearly distinct from the RFQ/swap siblings.

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

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

There is no statement of when to call this tool, no prerequisites, and no reference to alternatives. With zero parameters there is little to misuse, but an agent gets no signal about whether to call it before quote_rfq or request_listing, which is exactly where this registry would matter.

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 well: it discloses sort order (newest first), filter scope (private + all statuses), and pagination ('cursor-paginated'). It does not state auth requirements beyond 'your own' or mention rate limits, which keeps it from a 5 for an unannotated 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?

Three short sentences, each earning its place: scope, then the timeout-recovery use case, then pagination. The most decision-relevant fact (private/all-status scope) is 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?

For a read-only list tool with no output schema and no annotations, the description covers scope, ordering, pagination, and the key recovery scenario. What an agent still cannot learn from it — page size behavior and what fields an RFQ record contains — are the remaining 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?

Both parameters have 0% schema description coverage, so the description must compensate: 'cursor-paginated' explains the cursor param, but the limit param (1-100) is never addressed, nor is the page size default. Partial compensation for a two-parameter schema, hence the middle score.

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 (implicit list) and resource (your own RFQs) with explicit scope: private ones and every status included, newest first. It also distinguishes itself from the sibling list_open_rfqs by clarifying '(the board shows only public open ones)', so an agent can pick between them without opening either 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 concrete, non-obvious trigger — 'check here before re-posting an RFQ whose create_rfq call timed out' — which directly prevents a duplicate-write error. It also implicitly excludes the board-style listing. It loses a point only because the alternative is referred to as 'the board' rather than named as list_open_rfqs, leaving the routing slightly to inference.

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 it does disclose two useful traits: results are cursor-paginated and amounts are returned as base-unit integer strings (a real gotcha for downstream math). It says nothing about visibility/authorization scope on a 'sealed' board or how the filters interact.

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 short sentences, no filler, with the resource and scope front-loaded before the pagination and encoding notes. Every sentence adds 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?

Five undocumented filter parameters, no annotations, and no output schema leave significant gaps; the description covers pagination and amount encoding but not what the filters do or what a result entry contains. For a listing tool with a rich filter surface, more 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?

Schema description coverage is 0% across five parameters. The description gestures at pagination ('cursor-paginated') but never explains cursor/limit semantics, and it is silent on direction, baseAssetId, and quoteAssetId — including the sell_base/buy_base enum, whose meaning is not obvious.

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 ('Browse') and resource ('the sealed RFQ board') with a clarifying gloss: 'open requests you can quote'. That scope phrase implicitly separates it from list_my_rfqs and list_rfq_threads, but no sibling is named explicitly, 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?

'open requests you can quote' implies the use case (finding something to quote on), so usage is inferable. However, there is no explicit when-to-use versus get_rfq, list_my_rfqs, or quote_rfq, and no stated exclusions or prerequisites.

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 it does disclose real behavior: the ordering guarantee and the role-scoped result set. It stays silent on pagination or result limits, auth requirements, and empty results, which keeps it short of a 5 for an unannotated read 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 resource and ordering come first, the role split follows, then the handoff to get_thread. 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 one-parameter read tool this is close, but two gaps remain: the identity of 'id' (RFQ vs thread) is unstated, and with no output schema the description says nothing about what a thread entry contains. Either addition would make it complete.

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

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

The schema documents a single uuid, 'id', with 0% description coverage, and the description never explicitly says whether that id is the RFQ id or the thread id. The phrase 'threads on an RFQ' implies the RFQ id, but an agent could plausibly pass a thread id and get an error. The implication is the only extra meaning added.

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?

It names the resource precisely ('negotiation threads on an RFQ') and states the result ordering ('newest activity first'), plus the role-dependent scope: a maker sees every quote on their own RFQ, a taker sees their own thread. It also distinguishes itself from get_thread, which retrieves a single thread. The only shortfall is that the verb 'list' is implicit 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?

It gives an explicit use case ('this is how a taker finds the quotes it received') and an explicit next step ('open one with get_thread'). It doesn't rule anything out against alternatives like get_rfq or list_my_rfqs, but the make/take framing effectively routes the agent to the right 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?

No annotations are provided, so the description must carry the behavioral burden. It usefully discloses that results include HTLC settlement state and that the endpoint is cursor-paginated, but it does not mention permissions, read-only safety, ordering, or what the response shape 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 description is two short sentences with no wasted language, and the core purpose is front-loaded. Its terseness contributes to readability even though it leaves gaps elsewhere.

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 annotations, no output schema, and 0% schema description coverage, the description is too sparse. It omits essential details about pagination behavior, the limit parameter, ordering, and what fields are returned for each swap.

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 needs to compensate for two undocumented parameters. 'Cursor-paginated' gives some meaning to cursor, but limit is not described at all, including whether it defaults or caps results.

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 'your swaps' and adds that it covers their HTLC settlement state, which is more specific than the tool name alone. It does not explicitly contrast with the sibling swap_status tool, but an agent can reasonably infer this is a listing endpoint for the caller's swaps.

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 by saying 'Your swaps,' but it gives no explicit guidance on when to use this tool versus swap_status or other list tools. There are no exclusions, prerequisites, or alternative-selection cues.

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 well: it discloses that proposing is a binding agreement once accepted and explains the initiator's hashlock requirement. It does not cover authorization needs, failure modes, or return behavior, which are material gaps for a mutation 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?

It is three compact sentences with the core action front-loaded, followed by the consequential acceptance semantics and the hashlock note. Every sentence adds distinct 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 mutation tool with no annotations and no output schema, the description covers the key behavior an agent needs: countering on a thread, binding acceptance, and the initiator's hashlock. It still omits what the tool returns and any permission or failure conditions, so it is not fully complete.

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

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

Schema coverage is low at 33%, but the description compensates by clarifying that quoteAmount is a total price in base units and that hashlock is sha256(secret) for the initiator. The id parameter is only implicitly described as the thread identifier, leaving minor 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?

The description states a specific verb and resource: 'Counter with a new total price on a thread (base units).' It clearly identifies this as a counter-proposal action rather than an initial quote or an acceptance, though it does not explicitly contrast with siblings like quote_rfq.

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 provides clear usage context: use it to counter a price on a thread, and it explains that the counterparty must accept via accept_proposal(accept: true). It does not explicitly state when not to use it or name alternative tools for similar actions.

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 well: it discloses the effect of the optional authorization (multi-chain payouts, Bitcoin/Solana refunds, TRON funding), the response marker `authorised: true`, and the 409 conflict meaning. It omits idempotency (what happens if the wallet is already proved) and permission/auth requirements for the login wallet.

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 the core action and input source, then the two-mode distinction, then the error case. Every clause carries information, though the telegraphic phrasing ('Alone it lets you give from that wallet') costs a little readability.

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 5-parameter nested-object mutation with no annotations and no output schema, the description covers the input flow, the optional path's consequences, the success marker, and the main failure code. Remaining gaps (repeat-proof behavior, other error codes, full response shape) are minor.

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 only 20%, so the description must compensate and largely does: it identifies `message` as the wallet_proof_message output, `signature` as its signature, and `authorization` as the login wallet's signed authorizationMessage plus its consequence. `family` and `address` are left to the schema's enum/pattern, which is acceptable given they are self-documenting.

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 ('Record a wallet you proved') and immediately ties it to the sibling that produces its input ('the message from wallet_proof_message'), so the agent can tell it apart from wallet_proof_message and remove_wallet_proof without opening a 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?

Explains the prerequisite flow (message must come from wallet_proof_message) and the decision between the two modes: without authorization it is EVM-only for giving, with authorization it counts on every chain. It gives clear context but never explicitly says when to prefer remove_wallet_proof or when not to call it at all.

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 well: it discloses that the call opens a settlement thread, that the quote itself constitutes acceptance, that the deal is agreed upon requester acceptance, and the conditional follow-up via accept_terms with a hashlock. It still omits permission requirements, failure modes, or whether quotes can be revised or cancelled.

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

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

The description is front-loaded with the action and scope, then moves efficiently through parameter semantics, business consequence, and conditional next steps. Every sentence adds distinct, useful information without redundancy.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the description covers purpose, key parameter semantics, business consequence, and immediate follow-up behavior. It could be stronger by explicitly identifying the 'id' parameter and noting permission or error conditions, but it is largely complete 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 description coverage is 0%, so the description must compensate. It explains quoteAmount clearly as the total quote-asset amount in base units, which adds meaning beyond the '^\d+$' pattern. The 'id' parameter is only implicitly described as the RFQ identifier via context, not explicitly defined.

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 ('Quote') and resource ('open RFQ') with an explicit scope ('maker'), so an agent knows what action is being taken. It does not, however, distinguish this tool from likely alternatives like propose_price or accept_proposal, leaving sibling selection to inference.

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 makers quoting open RFQs and gives a clear conditional next step: if the returned thread shows makerAccepted: false, call accept_terms with your hashlock. It does not state when to choose this over sibling tools or when not to use it, so guidance is present but incomplete.

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 usefully discloses the state change (wallet stops being tradeable) and a key boundary (login addresses are not removable), but says nothing about permissions/auth, what happens if the proof doesn't exist, or whether the removal is reversible by re-proving.

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 tight sentences with the purpose front-loaded and the caveat last; nothing is redundant. The 'leaked key' framing is narrow but still earns its place as a usage cue.

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 tool with no annotations, no output schema, and one undocumented parameter, the description covers intent and one exclusion but leaves the parameter meaning and failure/reversibility behavior unexplained. Adequate but with clear 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?

There is one required parameter with 0% schema description coverage and only a regex pattern. The description never explains what 'address' should be — the wallet address, the proof identifier, or something else — so it fails to compensate for the undocumented parameter.

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

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

States a specific verb (withdraw) and resource (a proof) plus the concrete effect: the wallet no longer counts as one this account can trade from. It implicitly distinguishes itself from the inverse sibling prove_wallet, though it never names that 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?

'Reach for it after rotating a leaked key' gives a clear when-to-use trigger, and 'Login addresses are not proofs and are not removable' supplies a when-not-to-use exclusion. It stops short of naming prove_wallet as the alternative for the reverse operation, so routing is only partly 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?

With zero annotations, the description carries the full burden and mostly does: it discloses the rate limit (20 an hour), the caller scope, the re-check cadence (hourly for a week), and which statuses are terminal (rejected/delisted). It does not say whether the call has side effects (creating a listing request, cost, or persistence), which is the main remaining gap.

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 rate limit, then status semantics, then the auto-check exclusion. Dense but every clause carries information; the long status enumeration is justified because there is no output schema.

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 annotations and no output schema, the description supplies the essential return semantics (listed/pending/closed/rejected/delisted and the `reasons` field) plus lifecycle behavior. Only the side-effect/response-shape question (is a request id returned? is it a write?) is left open.

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%: chain has examples, address is bare. The description compensates by defining address as an EVM contract address or a Solana mint address, which is exactly the missing semantics and explains the chain/address dependency.

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: list a token by contract (EVM) or mint (Solana) address, via Hashlock. No sibling tool (all RFQ/swap/wallet operations) covers token listing, so the agent can route here unambiguously without opening a 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?

Explicitly scopes the caller ("scope: taker") and gives a when-not rule: Bankr/Virtuals/Clanker launches in their first week are checked automatically, so "after that, or for any other token, ask here." No sibling alternative is named, but the automatic-vs-manual boundary 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?

With no annotations, the description carries the full burden and does well: it discloses the authorization constraint (address must be one signed in with or proved from a signed-in web session), the ordering requirement before funding, and the maker/taker leg mapping. It does not say whether setting an address again replaces a prior one or how failures surface, so it falls short of full behavioral disclosure.

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 action and its prerequisite are front-loaded, and every sentence carries operative information (format, auth rule, leg rule). The auth sentence is dense and slightly convoluted, but no sentence is 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 4-parameter mutation tool with no annotations and no output schema, the description covers the auth model, sequencing, and leg roles well. It stops short of explaining what `id` refers to or whether the address can be changed after it is set, which 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 25%, so the description must compensate and largely does: it defines `address` format per chain and explains `leg` semantics (maker funds a, receives on b; taker the reverse) beyond the schema's terse 'Required when both legs are on this chain'. `id` and `chain` remain undefined in both places, leaving one real 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 and resource — set the receive/refund address for a swap leg — and immediately clarifies the Bitcoin format (compressed pubkey hex). It is clearly distinguishable from siblings like prove_wallet and build_fund, which it references by contrast.

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 it is 'Required before funding', names the auth exclusion (a prove_wallet proof made with the API key does not count), and gives the conditional rule for passing `leg` when both legs share a chain. When-to-use, when-not, and the alternative are all present.

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 burden; it does disclose the returned data shape (legs, timelocks, addresses, tx hashes) and implies a read-only lookup. It says nothing about auth requirements, behavior for unknown/expired swap ids, or freshness of the state, which matter for a lifecycle-status 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?

A single front-loaded fragment with zero filler; the most useful content (what state is returned) comes first. It is a noun phrase rather than a sentence, which is terse but efficient.

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

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

With no annotations and no output schema, the field list in the description does real work as a stand-in for return documentation. Still missing are permission/auth expectations and failure behavior for a nonexistent swap, which an agent needs before calling.

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 the single 'id' parameter is undocumented in the schema, but 'one swap' combined with the tool name makes clear the id identifies a swap; type and uuid format come from the schema. No extra meaning (e.g., which id namespace, whether off-chain or on-chain id) is added.

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?

Names a specific resource (one swap) and enumerates exactly what the response covers: legs, timelocks, addresses, tx hashes. The scope word 'one' implicitly separates it from list_swaps, but no verb (fetch/get) and no explicit sibling differentiation keeps it from 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 description says what the tool returns but never says when to call it, when not to, or which sibling (list_swaps, get_rfq) to prefer. An agent must infer from the tool name that this is for polling a known swap 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 carries the full behavioral burden and does so well. It discloses that the nonce is single-use and short-lived, that it is not a login nonce and cannot open a session, and that signing the authorization message makes the wallet belong fully to the account.

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

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

The description is front-loaded with the main action and return values, and every sentence contributes useful workflow detail. It is dense as a single paragraph and could be more scannable, but it avoids 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 no output schema, the description fills the gap by explaining what is returned: the exact message, the nonce, and optionally the authorization message. It also explains the next step and the significance of the authorization path, making it complete for this 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%, so the baseline is 3. The description adds meaningful semantics beyond the schema, especially for `login`: it explains the resulting `authorizationMessage`, what signing it does, and how the wallet becomes fully linked to the account.

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 action and resource: it starts proving a wallet and returns the exact message to sign plus the nonce. It explicitly distinguishes this step from `prove_wallet` by saying the signed message must be passed there unchanged.

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 explains the workflow: call this first, sign the returned message with the correct chain-specific method, then pass it to `prove_wallet`. The optional `login` branch is also explained, though there is no explicit statement of when not to use the 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?

With no annotations, the description carries the full burden and does well: it discloses the scope model, the login-vs-proven distinction, the rule that giving is allowed from a login wallet on any chain but from a proven wallet only on EVM, and that proving requires an authorization from the login wallet. What it omits is any statement that this call is side-effect-free/read-only and how large the response may be.

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 definition is front-loaded in the first sentence, but the rest of the text drifts into wallet-proving workflow that belongs to the sibling tools (wallet_proof_message, prove_wallet), making the description longer and denser than an identity call warrants.

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

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

For a zero-parameter, no-output-schema tool, the description is essentially complete: it names the fields returned and the permission model that determines what the caller may do. Only the read-only nature and any auth-failure behaviour are unstated.

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 is nothing for the description to disambiguate. Its explanation of the returned `login` and `proven` fields is a bonus rather than a parameter clarification.

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 makes clear this reports the identity behind the API key: its scopes (read/taker/maker) and, per chain, `login` (paid wallet) and `proven` (proved wallets). It is specific about the returned resource and explicitly references the sibling tools (wallet_proof_message, prove_wallet) used for the adjacent workflow, though it never states in a single clean clause that this is a read of the current credential.

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 concrete when-to-use guidance: 'Verify auth, and check what you may give before quoting,' and explains the alternative path for trading on non-EVM chains via wallet_proof_message then prove_wallet. There are no explicit when-not-to-use exclusions, but the routing to siblings is clear.

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