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

Annotations already cover read-only/idempotent/non-destructive, but the description adds material behavior beyond them: the definition of 'stuck' (not enough gas to move the tokens), the per-chain partial-failure signal ('a chain that did not answer has error: true'), and the hard blocker that frozen tokens are unfixable by any available tool. That is exactly the mutation/failure context an agent needs before chaining into a rescue flow.

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 purpose, then usage, then the safety note, then the return shape — a sensible order with no filler. The single long paragraph is dense and the inline return signature is syntactically heavy, but no sentence is disposable given 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 output schema, the description compensates by spelling out the return object and the per-chain error flag. Combined with the stuck/frozen semantics and the pointer to quote_send/quote_swap, an agent has everything needed to call it and act on the result.

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% and the address-format guidance (0x…, base58, T…) is already in the schema, so the description gets no credit there. It does add one thing the schema does not say: the address is checked on every chain 'where it is valid', implying per-chain applicability filtering rather than a uniform sweep.

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 ('Checks one address on every supported chain') and enumerates exactly what it reports: stablecoin holdings, gas balance, stuck status and issuer freeze. An agent can distinguish it from quote_send/quote_swap/get_transfer 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 usage: 'Use it before quote_send or quote_swap to find the chain and token to rescue', naming the downstream siblings and the condition that selects them. It also states the exclusion case — a frozen token cannot be moved by any tool here, only the issuer can lift it — so the agent knows when to stop rather than trying further tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds real behavioral value beyond that: no input required, the exact shape of what comes back (network, fees, limits, tokens per chain, quote validity), and the non-obvious gasDrop case where BNB Chain has no gasrescue contract and the wallet must send two plain transfers itself. Only gap is error/rate-limit behavior, which is minor here.

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 supported-assets summary, then usage conditions, then ordering guidance, then return shape. Dense but every clause carries information; the gasDrop explanation is long but covers a genuinely surprising execution path, so it 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?

With no output schema, the description takes on the burden of describing the return payload and does so field-by-field (fees percent/min/max, USD per transfer, transfers per wallet per day, quote validity, gasDrop flag). Combined with zero-param simplicity and covered annotations, nothing needed to invoke and interpret this tool is 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?

Zero parameters, so the schema carries everything and the baseline is 4. The description correctly states 'takes no input', which prevents an agent from inventing arguments.

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 — chains, stablecoins per chain, swap-capable gas coins, fees and limits — and positions itself relative to siblings by saying the chain keys and token symbols it returns are what the other tools expect. An agent can immediately tell this is the discovery/config tool rather than a quote or execution tool.

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

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

Gives an explicit trigger scenario (wallet holds USDC/USDT/USDG but no native gas coin, error 'insufficient funds for gas') and an explicit ordering rule ('call this first') before quote_send/quote_swap/get_transfer etc. The when-not case is implicit but the alternative is clearly the rest of the sibling set.

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

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

Beyond the annotations, it discloses per-kind signing behavior, required ordering of signatures and transactions, the gas-drop funding prerequisite, and the expired-quote failure condition. These details materially help an agent invoke the tool and follow up correctly, and they are consistent with readOnlyHint=true.

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 core purpose and every clause is relevant to a different signing kind or workflow step. It is dense and semi-colon heavy rather than cleanly structured, but given the multi-kind behavior it is not wasteful.

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?

There is no output schema, and the description compensates by naming the relevant response fields and structures for each kind: kind, steps[].typedData, steps[].transaction, steps[].tx, funding.needed, and binding. It is complete enough for an agent to know what to do with the returned signing request across the supported chains.

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

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

The input schema has 100% description coverage for transferId, including pattern, example, and source, so the schema already carries the parameter meaning. The tool description does not add parameter-level detail beyond referencing quotes from quote_send or quote_swap, so the baseline of 3 is appropriate.

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

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

It states a specific verb and resource: returns the signing payload the sender's wallet must sign for a quote from quote_send or quote_swap. It distinguishes this from the quote-producing siblings and from submit_signatures, so an agent can identify its role without opening the schema.

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

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

The description places the tool clearly in the workflow: use it on a quote from quote_send or quote_swap, then pass the result to submit_signatures. It also covers the expired-quote failure path by telling the agent to request a new quote. It does not explicitly say when not to use it, but the surrounding workflow is clear.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), but the description adds the full lifecycle state machine, tells the agent to poll again after a few seconds for submitting/sent, and explains what expired means and what to do about it. It also documents error behavior for unknown, malformed, or 30-day-old ids returning 'Transfer not found', which nothing in the structured fields 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?

Front-loaded with the core operation, then states, then usage routing, then constraints — a sensible order with no filler sentences. The state enumeration is dense but each state carries an actionable parenthetical, so it earns its space; only the explicit returns shape slightly duplicates what a caller would learn from the response.

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 read tool with no output schema, the description supplies everything an agent needs: scope, state semantics with polling advice, sibling routing, mutation limits, the top-level response shape, and the exact error condition. There is no ambiguity left that would cause an incorrect 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 coverage is 100% and the transferId property already explains the 24-hex-character format and that it is not a transaction hash, so the baseline is 3. The description adds meaning beyond the schema by clarifying that the same id space covers both quotes and transfers and by documenting the failure mode ('Transfer not found') for an id that is well-formed but unknown or older than 30 days.

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 current state of a quote or transfer by id — and enumerates exactly what comes back (fees, transaction hash, explorer link once sent). An agent can distinguish it from quote_send, quote_swap, and submit_signatures purely from the description.

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

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

Explicitly says to use it to follow up after submit_signatures or to see whether a quote is still open, and names the alternatives for starting a flow (quote_send or quote_swap). It also closes off misuse by stating it cannot start, change, or cancel anything, so when-not-to-use is covered alongside when-to-use.

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

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

Beyond the annotations it discloses that the quote is free, expires in 10 minutes, and that nothing executes on chain until the wallet signs, which matters given readOnlyHint=false. It also lists concrete failure conditions — amount bounds, insufficient balance, frozen token, and a 10-transfers-per-24h limit — that an agent cannot derive from structured fields.

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 quote_swap alternative are front-loaded, then return shape, then failure modes — a sensible order. It is dense and slightly long, with the return-value enumeration bordering on over-specification, but nearly every clause carries decision-relevant 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?

With no output schema, the description supplies the return shape ({ summary, transfer }, net amount, status "quoted"), which the agent would otherwise lack. Combined with the approval workflow, expiry, and error cases, nothing material is missing for a 5-parameter quote 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, but the description adds real meaning: the sendable token set is narrowed to USDC/USDT/USDG, and the amount parameter gains bounds ($2–$1,000, Tron from $10) plus the note that fees come out of it. That goes beyond what the schema states.

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 concrete verb and resource (prices sending a stablecoin from a gasless wallet to another address) and names the exact scenario it covers, e.g. exchange deposits. It also explicitly distinguishes itself from quote_swap, so the agent can separate the two without reading schemas.

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

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

Gives an explicit when-not rule: use quote_swap when the user wants gas in the same wallet. It additionally prescribes the workflow step (show the summary to the user and get approval before signing), leaving little 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?

Goes well beyond the annotations: the quote is free, valid for 2 minutes, nothing moves on chain until the wallet signs, output always returns to the same wallet, and the swap reverts if the minimum output is not met. That is exactly the safety and lifecycle context an agent needs before presenting a quote, and it does not conflict with readOnlyHint=false/destructiveHint=false.

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

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

Front-loaded with what is priced and for whom, then constraints, then return shape and the approval step. Every sentence carries a distinct fact (scope, sibling routing, chain exclusion, expiry, return payload, revert condition, approval) with no filler.

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

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

For a 5-required-parameter quoting tool with no output schema, the description still discloses the return shape ({ summary, transfer } with transfer id, fees, expected and minimum output) and the signing-approval step. Nothing essential to selecting or invoking it correctly is 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 description coverage is 100%, with per-parameter examples and cross-references to gasrescue_info, so the schema already carries the parameter burden. The description only restates the tokenOut concept (gas coin vs another stablecoin) and adds no format, default, or validation detail beyond the schema, so baseline 3 applies.

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 (swap of a stablecoin into the chain's gas coin or another stablecoin) plus the concrete scenario (wallet with no gas paying its own fees). It explicitly contrasts itself with the sibling quote_send, so an agent can distinguish 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 both when-to-use and when-not-to-use: use this when the result should return to the same wallet, use quote_send to pay someone else, and it is not available on Tron. It also states the workflow prerequisite ('get approval before signing'), which is the key routing condition for this family of tools.

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

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

Beyond the annotations, the description discloses that funds move irreversibly ('cannot be undone'), that the server broadcasts and pays gas, that the call blocks up to 3 minutes, and that re-submission is rejected. It also describes the return payload (status confirmed or failed, hash, explorer link), which annotations alone would not convey.

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

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

The description is front-loaded with the action and the consequence, then preconditions, then the parameter routing, then the return value. Every sentence carries distinct information and nothing is repeated from the annotations or 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?

For a destructive, non-idempotent, one-shot mutation tool with five parameters and no output schema, the description covers the safety warning, the timing behavior, the re-call behavior, the per-chain parameter routing, and the shape of the response. Nothing an agent needs before invoking it is 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 100%, so the baseline is 3, and the description adds genuine routing logic beyond the schema: signatures for EVM/Tron, signedTransaction for Solana, or fund: true followed by txs for a gas drop. That conditional mapping across the 5 parameters is meaningfully additive, though it stops short of detailing formats already present in the schema.

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

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

The description names a specific verb and resource ('Submits the wallet's signatures for a quote') and explains the downstream effect ('gasrescue broadcasts the transaction, pays the gas'). This is clearly distinguishable from the quoting siblings (quote_send, quote_swap) and from get_signing_request, which produces rather than consumes the signatures.

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 precondition ('call it only after the user approved the quote summary') and an exclusion via the once-per-transfer rule ('a second call is refused'). It does not explicitly name which sibling to call first (get_signing_request) or what to do if submission fails, but the sequencing context is clear enough to act on.

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