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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds meaningful context beyond that: it takes no input, it is a prerequisite bootstrap call for other tools, and it enumerates the return surface (fees, limits, quote validity). It does not mention rate limits, caching, or whether the supported set changes over time, which keeps it just short of a 5.

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

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

Content is front-loaded: the resource listing comes first, then the usage trigger, then the return shape. 'Read-only' partially restates readOnlyHint and 'takes no input' restates the empty schema, but these are minor and the rest of the text is dense with actionable detail.

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, so the description carries the burden of describing returns, and it does so concretely: network, fees (service percent, minimum, maximum), limits (USD per transfer, transfers per wallet per day, quote validity), and chains with tokens and gas coin. For a zero-parameter metadata tool this is complete enough that an agent knows both why and what it will get.

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?

With zero parameters the baseline is 4, and the description correctly reinforces this with 'takes no input.' There is no parameter meaning to add, and the description does not waste space inventing any.

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

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

The description opens with a specific verb+resource ('Lists what gasrescue supports') and enumerates the exact content: chains, stablecoins, gas-coin swap support, fees and limits. Nothing here could be confused with check_wallet or quote_send, since it describes a static capability/metadata listing rather than a per-wallet or per-transfer operation.

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 trigger scenario ('when a wallet holds USDC, USDT or USDG but no ETH, SOL, TRX or HYPE for the network fee') plus the exact error string an agent would encounter. It also states ordering relative to siblings: 'Call this first to get the chain keys and token symbols the other tools expect.'

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, but the description adds substantive behavior beyond them: per-kind signing semantics, the required ordering of signatures, what "binding" means (order committed fields — recipient, fee, minimum — can be verified first), and the expired-quote failure mode. That is meaningful operational context not present in 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 is front-loaded in the first clause and every sentence carries information (kinds, ordering, next step, failure path). It is dense and slightly run-on in the middle where the three kind variants are enumerated, but there is 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?

With no output schema, the description must describe the return shape and does so per kind (steps[].typedData, steps[].transaction with fee-then-transfer ordering, base64 solana transaction), which is the critical information. It omits the response envelope details (whether transferId, expiry, or binding metadata appear as siblings of steps), leaving a small 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?

The single parameter has 100% schema description coverage, including the regex pattern and an explicit warning that it is not a transaction hash. The description adds only the linkage to quote_send/quote_swap, which the schema already states, so the baseline of 3 applies — the schema does the heavy lifting.

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 what the sender's wallet has to sign") and anchors it to the producing siblings ("a quote from quote_send or quote_swap"), so an agent can distinguish it from submit_signatures, get_transfer, and the quote tools 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 forward ("Pass the result to submit_signatures") and backward on failure ("Fails when the quote expired; then request a new quote"). It also gives per-kind handling instructions, so the caller knows exactly what to do with each response shape rather than inferring 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?

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?

Goes well past annotations by disclosing that the quote is free, valid 10 minutes, and nothing moves on chain until signing, plus a concrete list of failure conditions ($2–$1,000 range, Tron $10 minimum, insufficient balance, frozen token, 10 transfers per 24h rate limit). None of that is inferable from the schema or the readOnly/destructive hints.

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-loads what the tool does and the sibling disambiguation, then packs contract terms, return shape, and failure modes into tight clauses. Slightly dense as a single block, but every sentence carries 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?

No output schema exists, yet the description describes the return shape ({ summary, transfer }, net amount, 'quoted' status) and the error surface. For a 5-parameter quote tool 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%, so the baseline is 3, but the description adds genuine meaning beyond it: accepted token symbols, fee deductions from the amount, and per-chain amount limits (Tron minimum $10) that the schema does not state.

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 ('Prices sending USDC, USDT or USDG from a wallet without gas') and explicitly contrasts with its sibling quote_swap. An agent can distinguish intent without reading the schema.

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

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

Gives an explicit alternative with the condition that selects it ('Use quote_swap instead when the user wants gas in the same wallet') plus a directive to show the summary and get approval before signing. When-to-use and next-step routing are both covered.

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 only say readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, which leaves the actual mechanics unstated. The description fills that gap with the quote's 2-minute validity, the fact that nothing moves on chain until the wallet signs, the revert-below-minimum-output behavior, and the required user-approval step — all behavior an agent could not infer from the annotations.

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-loads the core purpose, then the sibling distinction, then the availability caveat, then the mechanics and return shape. It is dense but nearly every clause carries information; the return-shape enumeration is slightly list-like but earns its place 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 supplies the return shape ({ summary, transfer }) including transfer id, fees, expected output and minimum output. Combined with the quote validity window and the signing/approval requirement, an agent has everything needed to call this 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 description coverage is 100%, so every parameter is already documented with examples and format guidance. The description adds only marginal semantic context, such as the result returning to the same wallet and fees coming out of the amount, both of which are already implied or stated in the schema. Baseline 3 is appropriate.

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

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

States a specific verb (prices/quotes a swap) and a precise resource (stablecoin into the chain's gas coin or another stablecoin) and names the exact scenario (a wallet without gas paying its own fees). It also explicitly distinguishes itself from the sibling quote_send by noting the result always returns to the same wallet.

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 the selecting condition (wallet has no gas and must pay its own fees), an explicit alternative with its own condition ("use quote_send to pay someone else"), and an exclusion ("Not available on Tron"). It also states the next step in the workflow: show the summary and get approval before signing.

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 flag destructiveHint and non-idempotent, but the description adds substantive context on top: funds move irreversibly, a third party pays gas, there is a ~3 minute wait, and duplicate submission is rejected. It also discloses the return shape (summary/transfer with confirmed or failed, hash, explorer link) absent an output 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 action and its cost, then the precondition and the chain-specific input rule. The third sentence is dense and packs several ideas, but every clause carries information an agent needs before committing funds.

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 high-risk, no-output-schema mutation tool, the description covers cost, irreversibility, timing, retry limits, per-chain input requirements, and return contents. Nothing an agent needs in order to invoke it safely 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; the description goes further by explaining the mutual exclusivity between signatures and signedTransaction per chain and tying signatures to the ordering of get_signing_request steps. It stops short of restating the transferId format, which the schema already handles.

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 (submits signatures) and the downstream consequence (gasrescue broadcasts, pays gas, waits up to 3 minutes), which is far more than a restatement of the name. It is clearly distinguishable from get_signing_request (which produces signatures) and get_transfer (which only reads state).

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

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

Explicit preconditions: call only after the user approved the quote summary, and only once per transfer since a second call is refused. It also routes by chain (signatures for EVM/Tron vs signedTransaction for Solana), 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.