Quietwork Swap

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

With no annotations, the description carries the full burden and does disclose useful traits: the order is unsigned, signing is via eth_signTypedData_v4, an approval tx may be bundled, and no gas is needed for the swap. It does not cover order expiry, whether quotes/allowances are validated, or what state (if any) is changed by the approval tx.

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 dense sentences with the core capability front-loaded and no filler. 'No gas for the swap itself' is terse to the point of being slightly ambiguous, but it earns its place as a differentiator.

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?

An output schema exists, so return values need not be explained, and the description names both artifacts the caller receives. However, for a 7-parameter build tool at 14% schema coverage with no annotations, the missing next-step guidance (sign, then submit via cow_post_order) and undefined parameter units leave real 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 description coverage is only 14% (just 'sender'), and the description adds nothing about the 7 parameters. Critical ambiguities remain: whether 'amount' is human-readable or base units, that 'recipient' defaults to 'sender', and what slippageBps=50 means. The phrase 'market order' only loosely implies tokenIn/tokenOut/amount roles.

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 an unsigned CoW market order') plus the exact output format (EIP-712 typed data for eth_signTypedData_v4) and an optional companion artifact (vault-relayer approval tx). The word 'unsigned' implicitly separates it from cow_post_order, but no sibling is named, so the differentiation is left 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?

There is no statement of when to call this versus cow_quote, cow_post_order, or cow_order_status, and no prerequisite such as 'requires a prior cow_quote' is mentioned. The only contextual hint is 'plus the one-time vault-relayer approval tx if needed', which describes an output, not usage guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only lookup but does not state that explicitly, nor does it mention that chain is required to identify the order, what happens if the uid is unknown, or any auth/rate considerations.

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

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

The description is a single front-loaded sentence with no wasted words. Its brevity is efficient, though it borders on under-specification for a tool with two required parameters.

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?

An output schema exists, so return values need not be explained. However, with no annotations and 0% schema description coverage, the description should at least clarify the required chain parameter and the read-only nature of the lookup; it does neither.

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 both parameters. The description mentions uid only, adding no format or meaning beyond the parameter name, and completely omits the required chain 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?

The description names a specific resource (CoW order) and the lookup key (uid), so an agent can tell this is a status-check tool. It does not explicitly differentiate from sibling status tools like debridge_order_status or shift_status, but the CoW qualifier does most of the work.

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 guidance on when to use this tool versus the sibling status tools, nor any prerequisite context. The phrase 'by uid' implies it is used after an order exists, but no conditions or alternatives are stated.

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 behavioral burden. It discloses that the tool submits to an order book and returns orderUid plus an explorer link, but it does not describe permission requirements, irreversibility, idempotency, or failure behavior for this write operation.

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

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

The definition is a single, front-loaded sentence with no wasted words. It communicates the action, prerequisite source, target system, and return values efficiently.

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?

An output schema exists, so the description does not need to explain return values in detail beyond its brief summary. However, given five parameters, only 20% schema coverage, nested object input, and no annotations, the description leaves too much unsaid about the required inputs and mutation behavior.

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%, and the description only adds meaning for the order parameter by saying it comes unchanged from cow_build_order. It does not explain chain, sender, signature, or the optional quoteId, so it does not compensate for the sparse schema documentation.

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: submit a signed CoW order to the CoW Protocol order book. It also identifies the workflow source, cow_build_order, and names the return values, making the tool distinct from sibling quote/build/status tools.

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 'from cow_build_order' clearly tells the agent this is the submission step after building an order, which is useful workflow guidance. It does not explicitly state when not to use it or name alternatives such as cow_order_status, so it falls short of a 5.

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 MEV-protected batch-auction execution and a 0.1% partner fee, but never says whether quoting submits anything, whether quotes expire, or what permissions/signing are required — critical for a tool sitting next to cow_post_order.

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 tight sentences with the core purpose and chain scope front-loaded, plus fee disclosure. Slightly dense abbreviation ('ERC-20 sell tokens') but no wasted sentences.

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?

An output schema exists, so return-value explanation isn't required, but the definition still leaves gaps on quote lifecycle and the semantics of amount/sender/slippageBps. Adequate as a minimum-viable definition, incomplete for a 6-parameter quoting 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 only 17% across 6 parameters, so the description must compensate. It explains tokenIn's ERC-20-only constraint, but says nothing about 'amount' (units/decimals), 'sender', or 'slippageBps' (default 50, meaning unclear), leaving four parameters undocumented in both places.

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+resource — 'Gasless CoW Protocol market-order quote' — and scopes it to five named chains and ERC-20 sell tokens. That distinguishes it from write-path siblings like cow_build_order and cow_post_order, but it doesn't explicitly contrast with the other quote siblings (swap_quote, zerox_quote, velora_quote).

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

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

'Gasless' and 'ERC-20 sell tokens' imply usage constraints, and 'quote' implies a pre-trade read, but the description never states when to use this versus the sibling quote tools or that it precedes cow_build_order/cow_post_order. Usage is inferable rather than specified.

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 that this is a variable-rate order, returns a deposit address, settles directly to settleAddress, and is non-custodial for us, but it omits important creation behavior such as rate expiration, refund handling, address validity requirements, and 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?

The description is two short, front-loaded clauses with no wasted language: it states the action, the return value, and the settlement model 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 7-parameter creation tool with no annotations and 0% schema description coverage, the description is too thin. The output schema covers the return value, but the description still lacks parameter semantics, prerequisites, and behavioral details needed to invoke it safely.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate. It only clarifies that funds settle to settleAddress, leaving depositCoin, settleCoin, networks, refundAddress, settleMemo, and depositNetwork unexplained.

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: 'Create a variable-rate SideShift order,' and distinguishes it from siblings like crosschain_rate and shift_status by stating this creates an order and returns a deposit address.

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 purpose implies when to use it—to initiate a cross-chain shift—but it does not explicitly say when to use this versus crosschain_rate for quoting or shift_status for tracking, nor does it list any exclusions.

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 rate source and that the result matches sideshift.ai, which implies a non-mutating lookup. However, it never states that no shift is created, whether a quoted rate expires, or how unsupported asset/network pairs fail — gaps that matter for a quote 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 short sentences with the core resource named first, followed by the provider and the trust-equivalence note. Nothing is padded and nothing important is buried.

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?

An output schema exists, so return values need not be explained, and 80% parameter coverage reduces the burden. Still, for a quote tool sitting among fifteen siblings, there is no statement routing the agent between this and crosschain_create_shift or the other quote providers, leaving a real selection gap.

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 80%, so the baseline is 3; the schema already documents settleCoin/depositCoin/depositNetwork/settleNetwork with examples. The description's asset list adds a little value by hinting at valid coin symbols, but says nothing about how networks pair with coins or about the optional amount 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 resource (cross-chain/cross-asset rate) and names the provider (SideShift.ai), plus enumerates supported assets, so the agent knows this is a pricing query rather than a shift. It is distinguishable from the many *_quote siblings only by the provider name, not by an explicit scope statement, which keeps it just 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 when-to-use/when-not guidance and no mention of the obvious alternative, crosschain_create_shift, or of the cow/debridge/swap/velora/zerox quote siblings. The agent must infer that this is a pre-trade pricing call from the word 'rate' alone.

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

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

With no annotations, the description carries the full burden and does disclose the important traits: the output is unsigned, an approval transaction may be bundled, fees match debridge_quote, and an orderId is returned for tracking. It does not mention whether the transaction expires, whether it reserves liquidity, or any prerequisite ordering (quote-first), which matters for a transaction-building 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, front-loaded with the core action and the approval-tx caveat. No filler, though the fee-parity sentence is more useful than the return-value sentence given an output schema exists.

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 presence of an output schema excuses it from explaining return values, and the signing flow is well described. However, for a 7-parameter cross-chain build tool with 29% schema coverage, the missing parameter and prerequisite detail leaves the definition only minimally sufficient.

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

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

Schema description coverage is only 29% — just 'sender' and 'recipient' are documented in the schema — and the description adds nothing about amount units, token address format, or the meaning of srcChain/dstChain selection. Four required parameters (amount, tokenIn, tokenOut, and the chain pair) remain semantically thin, so the description fails to compensate for the low coverage.

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: builds an unsigned deBridge DLN cross-chain order transaction, including an ERC-20 approval tx when needed. The phrase 'Same fees as debridge_quote' implicitly separates it from the sibling quote tool, so an agent can tell what it produces versus what a quote produces.

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?

Clearly positions the tool at the signing step ('for sender to sign on the source chain') and distinguishes it from debridge_quote by noting fee parity, which implies this is the execute-path counterpart to a quote. It also hints that the returned orderId feeds debridge_order_status. It stops short of explicitly saying a quote must precede it or 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 are provided, so the description carries the full burden and does a poor job: it does not say the call is read-only, whether status is polled until filled/refunded, whether a missing order errors or returns an empty status, or whether it works across all supported chains. Only the word 'Status' hints at the operation's nature.

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 tight sentence, front-loaded with the resource and scoped to the protocol, with zero filler. Its brevity is a virtue structurally even though the content is too thin overall.

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 presence of an output schema means return values need not be described, and a one-parameter lookup is simple. However, with no annotations and an undocumented orderId format, an agent cannot confidently supply the id or interpret failure cases from the description alone.

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 parameter has no description, so the definition needs to explain orderId. It only says 'by orderId', repeating the parameter name, and gives no hint whether this is a deBridge order id, a hash, or which chain's id to use for a multi-chain DLN order.

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: returns the status of a deBridge DLN order, keyed by orderId. That distinguishes it from the build/quote siblings, though it never explains how it differs from cow_order_status or shift_status, which serve the same lookup role for other protocols.

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 call this versus the sibling status tools (cow_order_status, shift_status) or when a status lookup is warranted at all. The agent must infer usage purely from the name and the one required parameter.

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 valuable work itemising the total cost stack (0.1% affiliate fee, 4 bps protocol fee, flat native-coin fee, ~4 bps solver margin, solver gas), but it never states that this is a non-mutating price query, how long a quote stays valid, or that the result feeds debridge_build_tx — all critical for a quote 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 sentence that names the mechanism first, then the chain coverage, then the fee breakdown. Dense but every clause carries information; only the parenthetical fee enumeration is slightly cramped.

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?

An output schema exists, so return values need not be described. But for a 5-required-param quote tool with 40% schema coverage and no annotations, the description leaves quote validity, amount units, and the downstream build-tx handoff unexplained.

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 40%, so the description must compensate, and it largely doesn't. The chain list merely restates the srcChain/dstChain enums, and the description says nothing about the 'amount' parameter — whether it is human-readable decimals, base units, or which token's decimals apply — which is the highest-risk ambiguity here.

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 (cross-chain EVM swap quote) and names the exact protocol (deBridge DLN), plus enumerates the six supported chains and gives a concrete example pair. It clearly distinguishes itself from single-chain quoting siblings like swap_quote, cow_quote, velora_quote and zerox_quote.

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

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

The word 'cross-chain' implies this is the tool for bridging between chains rather than same-chain swaps, so the routing versus swap_quote is inferable. However, it never explicitly says when to use this instead of crosschain_rate or when to prefer debridge_build_tx directly, and no prerequisites are stated.

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 and delivers almost none: it does not say whether the lookup is read-only for unaffiliated orders, what statuses exist, how unknown/expired ids are handled, or whether any auth is needed. The presence of an output schema excuses it from describing return values, but the behavioral gaps remain substantial.

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 identifying detail (SideShift) is front-loaded. It is terse to the point of under-specification, but nothing is wasted.

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?

Output schema exists, so return values need not be explained, and the tool is a single-parameter lookup. However, given zero annotation coverage and zero schema description coverage, the description should at least state where the id originates and that the call is a read; it does not.

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 both schema and description. With no annotations to lean on, the description should clarify that 'id' is the order identifier returned by the order-creation tool, but it only hints at this with "created here".

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 (a SideShift order) and operation (fetching its status), and the provider name distinguishes it from cow_order_status and debridge_order_status siblings. The verb is nominalized ("Status of...") and "created here" leaves the originating tool implicit, but the intent is decipherable.

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 explicit when-to-use or when-not-to-use guidance, and no named alternative is offered. "created here" weakly implies the id comes from another tool on this server, but the agent must infer that crosschain_create_shift is the producer.

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 key traits: the output is unsigned and must be signed by the caller, custody never transfers, an approval transaction may be bundled, and fee parity with swap_quote. Missing are allowance/expiry behavior, failure modes, or gas handling, which keeps it from 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?

Two short sentences, front-loaded with the core action, zero filler. Parenthetical for the conditional approval tx is an efficient way to convey the branch.

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?

An output schema exists so return values need not be explained, but for a 7-parameter transaction builder with 5 required fields at 14% schema coverage, the description leaves critical input semantics (token formats, amount units, slippage, recipient default) undocumented. Given the complexity, this is a substantive gap.

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 14% (just 'sender' is documented), so the description must compensate and does not — it never explains tokenIn/tokenOut format (address vs symbol), amount units/decimals, slippageBps semantics, or the recipient default. Only the vague phrase 'caller's wallet' loosely maps to sender.

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 (not send) an unsigned, non-custodial swap transaction, and adds that an ERC-20 approval tx may be included. It clearly contrasts with swap_quote via 'Same fee as swap_quote'. It does not, however, distinguish itself from the sibling *build_tx tools (debridge_build_tx, velora_build_tx, zerox_build_tx), leaving protocol/route selection 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 reference to swap_quote implies the intended workflow (quote first, then build), and 'for the caller's wallet to sign' implies the caller submits, not the tool. But there is no explicit when-to-use versus the other build_tx siblings or when a quote is a prerequisite.

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 0.1% integrator fee and that pricing comes from the KyberSwap aggregator, which are real behavioral facts beyond the schema. But it omits quote expiry/refresh expectations, rate limits, and explicit confirmation that this is a read-only price lookup with no on-chain effect.

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, front-loaded with the core action and provider, then the cost disclosure. 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?

An output schema exists, so return values need no explanation, and the fee disclosure is a welcome addition. Still, an agent lacks the lifecycle context a quote tool needs: whether the quote is time-sensitive, how it relates to swap_build_tx for execution, and what distinguishes it from the other quote siblings.

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% — tokenOut has no description and amount/tokenIn are partly documented. The description adds no per-parameter meaning; its chain list merely repeats the enum already in the schema and does nothing to compensate for the undocumented tokenOut.

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 ('Best-price same-chain token swap quote') plus the named aggregator (KyberSwap) and the supported chain set. The 'same-chain' qualifier and provider name let an agent separate it from cross-chain siblings (crosschain_rate, debridge_quote) and from other aggregators like zerox_quote or cow_quote.

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

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

The description never says when to pick this over cow_quote, zerox_quote, velora_quote, or zerox_quote for the same pair, nor does it mention that swap_build_tx is the follow-up step to execute the quote. Usage is only implied by the word 'quote'.

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 important traits: the transaction is unsigned (the agent must sign/broadcast) and an ERC-20 approval tx may be appended. It does not say whether the approval is exact-amount or unlimited, whether calldata must be sent to a specific contract, or whether any state is mutated server-side.

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, zero filler, and the core capability plus the notable side effect (approval tx) are both 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?

The tool builds and returns transaction payloads with an output schema and no annotations, on 7 parameters with near-zero schema documentation. The description leaves the most failure-prone details (amount units, token identifier format, default recipient, slippage semantics) unaddressed, so an agent can call it correctly only by guessing.

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 14% (only `sender` is documented) across 7 parameters, so the description must compensate and does not. Critical ambiguities remain: is `amount` human-readable or base units, are tokenIn/tokenOut addresses or symbols, what happens if `recipient` is omitted, and what slippageBps=50 means in practice.

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+resource: 'Build an unsigned Velora Augustus v6.2 swap tx plus ERC-20 approval tx if needed.' The protocol name and version distinguish it from velora_quote and from the other *_build_tx siblings at a glance. It stops short of explicitly saying which sibling to pick when several aggregators are available, but the resource 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?

'Same fee as velora_quote' implies the quote-then-build pairing, and 'if needed' signals the approval tx is conditional, so usage is inferable. However, there is no explicit statement that velora_quote should be called first, no guidance on when to prefer this over swap_build_tx or zerox_build_tx, and no prerequisites (allowance state, signing wallet) spelled out.

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 disclose behavior; it clearly states the 0.1% Quietwork partner fee, Velora's 15% share, and that no other Velora fee applies. It frames the operation as a quote rather than execution, though it does not mention auth, rate limits, or quote expiration.

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

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

The description is a single front-loaded sentence with relevant fee and comparison details rather than fluff. Parenthetical density is high, but every element 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?

An output schema exists, so return values need not be explained, and the description covers purpose, chains, fee, and sibling comparison. However, with no annotations and 0% schema description coverage, it does not fully compensate for missing call-level details such as token format.

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

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

Schema description coverage is 0%, and the description does not explain the amount string format or tokenIn/tokenOut address format. It only adds the same-chain constraint and repeats the chain enum, leaving all four required parameters largely undocumented beyond their names.

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 ('quote') and resource ('same-chain swap via Velora Market'), lists supported chains, and discloses fee terms. It also distinguishes itself from swap_quote and KyberSwap, so an agent can identify it 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?

Explicitly advises comparing with swap_quote and notes Velora is often better than KyberSwap on some pairs, giving clear usage context. It stops short of stating when not to use it or any prerequisites such as quote expiry.

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 that the transaction is unsigned, may include an ERC-20 approval, that output goes to the sender, and the fee structure, but it does not address authentication, rate limits, or whether any state change occurs.

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 single compact sentence is front-loaded with the core action and avoids filler. The fee details are secondary but still relevant, and no sentence is wasted.

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 output schema covers return values, but this is a six-parameter build tool with no annotations and no schema descriptions. The description omits required parameter meanings, auth/rate-limit behavior, and practical usage context, so it is not complete enough for reliable 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 the six parameters. It does not define chain, tokenIn, tokenOut, amount, slippageBps, or the precise role of sender, leaving required inputs undocumented.

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

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

The description states a specific verb and resource: build an unsigned 0x Swap API transaction plus an ERC-20 approval tx if needed. It is clearer than a generic build tool, but it does not explicitly differentiate usage from siblings such as zerox_quote or swap_build_tx beyond mentioning shared fees.

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 guidance on when to use this tool versus zerox_quote or other *_build_tx siblings. The description implies it is for constructing a transaction, but it does not state prerequisites such as whether a quote should be obtained first or when approval handling matters.

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 behavioral burden and does so for the most decision-relevant trait: it discloses the 0.1% integrator fee stacked on top of 0x's ~0.15% Standard-plan platform fee, and notes the platform fee is surfaced as zeroExFee in the response. It omits other behaviors an agent might need, such as quote expiry or rate limits, but the cost model disclosure is substantive and not derivable from 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?

A single dense sentence with the purpose front-loaded and fee caveats trailing as parentheticals. It is compact and every clause adds information, though the nested parentheses make the fee structure slower to parse than a two-sentence split would be.

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?

An output schema exists, so return-value explanation is not required, and the fee/zeroExFee mapping is a useful addition. Still missing for a five-parameter quote tool: what 'sender' does, how amounts are denominated, and any notion of quote validity window, leaving real gaps for an agent constructing a call.

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, so the description must compensate and does not. It adds no semantics for 'sender' (presumably the taker address used for fee/calldata purposes), no format for 'amount' (string, base units vs decimal), and no indication of expected token address format for tokenIn/tokenOut; the chain enumeration is already fully expressed in the schema's enum.

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 ('Same-chain swap quote') plus the venue ('0x Swap API') and enumerates supported chains, so an agent can tell it is a 0x-sourced quote rather than a build/execute step. It does not, however, distinguish itself from sibling quote tools such as swap_quote, velora_quote, or cow_quote; the only comparison drawn is to KyberSwap, which is not a sibling.

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?

Usage is implied by the fee disclosure ('total fees are higher than on KyberSwap'), which hints at when an agent might prefer another aggregator, but no sibling alternative or selection condition is named. There is no guidance on when to call zerox_quote versus swap_quote, nor on prerequisites such as needing a sender address.

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