Warden Token Terminal

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

Annotations already establish readOnlyHint, non-destructive and closed-world, so the safety profile is covered. The description adds value by disclosing the payload contents, which matters because there is no output schema, but it says nothing about freshness, what happens when no wallet is connected, or whether pending session requests are reflected.

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

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

A single compact clause listing the three returned facets, with the owning resource front-loaded. Nothing is wasted, though the sentence is a sentence fragment and could open with a verb to signal that it retrieves rather than configures.

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

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

With no output schema and no parameters, the description is the only place to learn what comes back, and it only names three categories without structure, value shapes, or the relationship to the sibling session tools. Adequate to recognise the tool, insufficient to know exactly what calling it yields.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies the wallet scope is implicit from the connection rather than passed in.

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 (agent permissions on the connected wallet) and enumerates three concrete contents: agent authorisations, unattended trading session state, and daily limits. It is a noun phrase rather than a verb, so the read intent comes only from context and annotations, and it does not distinguish itself from session_request_status, which also deals with session 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?

There is no indication of when an agent should call this versus request_session or session_request_status. The likely precondition (a wallet must be connected, and this is a pre-trade safety check) is left entirely 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?

Annotations already flag destructive and idempotent, but the description adds context structured fields cannot: it spends real funds, requires an explicit permission state, requires reusing idempotencyKey on retry, and behaves differently on Solana (agent Solana wallet, SOL/USDC/USDT pairing). These are the operational facts an agent needs before invoking a real-money mutation.

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 the permission gate, then proceeds through edge cases in rough priority order. Dense but nearly every clause carries operational weight; the Solana sentence and the cross-chain sentence could be split for readability but are not padding.

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 real-funds tool with no output schema and zero schema descriptions, this covers prerequisites, failure paths, retry semantics, and chain-specific behavior well. Gaps remain around slippageBps semantics and what a successful result contains, though swap_status is named as the follow-up.

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 8 parameters, and the description covers idempotencyKey (reuse on retry), gasless, buyChainId, and sellToken (native coin address from list_chains). It leaves chainId, buyToken, sellAmount format, and slippageBps (with its 1–300 bounds) unexplained, so several parameters still carry no meaning beyond their names and types.

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 precise verb and resource — 'Sign and broadcast a swap from the user's wallet' — and implicitly separates itself from prepare_swap and quote_swap by referencing the limits inherited from prepare_swap. An agent can tell this is the final execution step, not a quoting or preparation step.

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 gating condition (handsFree must be on), an explicit fallback when it is off ('tell the user how to turn it on'), a required precheck (agent_permissions first), and a follow-up step (swap_status). It also gives conditional routing: use gasless=true when the wallet has no gas coin, and set buyChainId to land the token on another chain.

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 and non-destructive, so the bar is lower, yet the description adds real semantics: what an empty gas balance implies, that 'unrecognised' means unsolicited transfers, and which wallet Solana swaps execute from. It omits freshness/caching and payload size expectations for a wallet spread across every chain.

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 returns, then adds conditional rules. Dense but every sentence carries an operational constraint; only the phrasing around 'sellAmount' and the Solana clause is slightly tangled.

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, so the description must describe return values — and it does, down to per-chain gas coin, token amounts, USD pricing where available, and the special `solana` sub-object. For a zero-parameter read tool this leaves nothing an agent needs 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?

The tool takes zero parameters, so the baseline is 4; the description correctly reflects a no-argument read and adds no misleading input expectations.

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 ('The connected wallet') and enumerates exactly what is returned: X handle, gas coin, each token with raw amount and USD value. This is clearly distinguishable from siblings like list_chains or search_tokens, which serve different lookups.

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 concrete decision rules for interpreting the result: a chain with no gas coin means use gasless=true or fund it first, and 'unrecognised' tokens must never be counted as money or suggested for sale. It also ties `solana` to the agent wallet that execute_swap trades from. It does not explicitly say when to call this versus a quote/swap tool, but the interpretive guidance is unusually strong.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds useful context about what each entry contains, but says nothing about ordering, completeness, caching/staleness of the chain list, or whether the set is static — minor gaps for a reference call with no 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?

A single compact sentence with zero waste and the resource front-loaded. The phrasing is a sentence fragment ('Chains Warden supports, with...') that reads slightly awkwardly as a description but delivers the content 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?

With no input parameters, no output schema, and a read-only annotation set, the definition supplies enough for correct invocation: it tells the agent the call enumerates supported chains and what fields come back per chain. Only minor detail (ordering or freshness of the list) is absent, which is not essential for calling it.

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

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

The tool takes zero parameters, so the schema baseline of 4 applies. The description correctly adds no parameter information because there is none to add.

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

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

The description names the resource plainly ('Chains Warden supports') and enumerates the attributes returned for each entry (native coin, dollar stable, gasless support). It is immediately distinguishable from swap-oriented siblings like quote_swap or execute_swap, though the verb 'list' is only implied by the title rather than 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?

There is no explicit when-to-use guidance, no statement that this is a prerequisite lookup before quoting or swapping, and no mention of alternatives or exclusions. The agent must infer that this is a discovery/reference call from the content 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?

Annotations only declare readOnly=false, destructive=false, openWorld=false; the description goes well beyond them by disclosing that nothing is broadcast, the permission requirement, the gasless typed-data payload variant, cross-chain via buyChainId, and Solana-specific quoting/signing behavior. That is exactly the mutation-safety context an agent needs before proposing a trade.

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

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

Front-loaded with the core action and the no-broadcast guarantee, and every sentence carries operational content. It is dense rather than tidy — the Solana note lands last as an afterthought and mixes platform behavior with parameter guidance.

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 mutation tool with no output schema, the description covers the reviewUrl hand-off, platform variants, and the escalation path to execute_swap. It stops short of saying what the tool returns besides reviewUrl (calldata vs typed data), which the agent must infer.

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 carry parameter meaning, and it only partially does: it explains gasless (typed-data payloads), buyChainId (cross-chain), and the Solana wallet implication. chainId, sellToken, buyToken, sellAmount, and slippageBps receive no explanation at all, leaving half the surface inferred.

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 a swap for the user to sign') plus the critical boundary 'Does not broadcast', which separates it from broadcast tools. It names the sibling it is not (execute_swap), so an agent can route 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?

Explicit conditional routing: 'If hands-free trading is on, use execute_swap instead', plus the prerequisite 'Requires the "swap" permission' and the instruction to hand the user reviewUrl. The one gap is quote_swap, a close sibling whose distinction from this tool is never addressed.

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 and destructiveHint=false, so the closing 'Read-only' adds nothing and is slightly redundant. It does, however, disclose genuinely useful behavior beyond the annotations: the data source is the token's deepest pool (so prices are pool-specific, not an aggregate), results are ordered oldest first, values are USD-denominated, and a summary block with drawdown/breakout metrics is returned alongside the candles.

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 front-load what is returned and how it is ordered before explaining the summary metrics. The trailing 'Read-only' is wasted space given the annotations, but otherwise there is little 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?

The description usefully covers the return payload, which matters because there is no output schema. But for a call with 0% schema coverage on four parameters and a bounded limit, omitting interval/limit/token-format guidance leaves an agent guessing on inputs it must supply.

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 four parameters, and the description says nothing about chainId, token address format, the interval enum (5m through 1d), or the limit range of 10-300 with a default of 96. It spends its detail budget on output fields instead of compensating for the undocumented inputs, leaving interval and limit semantics unexplained anywhere.

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

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

Names a specific resource and narrows it precisely: candles for one token, sourced from its deepest pool, ordered oldest first, denominated in USD. That scope distinguishes it from siblings like trending_tokens or search_tokens, though it never explicitly names an alternative.

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?

Offers an implied use case ('to judge a pullback or a breakout before buying'), which positions it as pre-trade analysis, but gives no explicit when-to-use/when-not rules and names no alternative for obtaining price data on other pools or aggregated venues.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered; the description's 'Read-only' is largely redundant. It does add genuinely new behavioral context: the native-coin address must come from list_chains, and Solana mints are case-sensitive base58. It says nothing about rate limits, quote expiry, or freshness.

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 non-committal guarantee, then the chain-specific caveats. No filler or repetition.

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

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

With no output schema, the description should indicate what a quote contains (rate, expected buy amount, route, fees, expiry), but it only says it prices a swap. Combined with the undocumented chainId and sellAmount parameters, an agent can call it but cannot anticipate the response shape.

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 only partly does: it explains buyChainId (cross-chain pricing), the sellToken/buyToken formats for native coins and Solana mints. chainId and sellAmount (a string matching ^\d{1,78}$, presumably base units) are left entirely 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?

States a specific verb and resource ('Price a swap') and immediately scopes it as non-committal, which implicitly separates it from execute_swap and prepare_swap. It stops short of naming those siblings explicitly, so the differentiation is inferred rather than stated.

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

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

Gives clear when-to-use context ('without committing to it') and adds chain-specific applicability: native coin via list_chains address, EVM cross-chain via buyChainId, Solana base58 mints. It does not explicitly say when to prefer prepare_swap or execute_swap instead, so the routing guidance is incomplete.

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

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

Annotations only declare readOnlyHint=false, destructiveHint=false and openWorldHint=false; the description goes well beyond that by disclosing the return payload (approveUrl plus a code), the human-in-the-loop consent step in Warden, the guarantee that 'nothing changes until they do', and the request's 10-minute expiry. The one gap is what happens if the request expires or is declined, which matters for a grant that unlocks trading.

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 and the dependency, then the return values, then the human instruction, then the polling step, then parameter semantics. Every sentence carries load-bearing information (URL, code, expiry, poll target, limits default); 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?

No output schema exists, and the description compensates by naming the returned approveUrl and code and telling the agent how to relay them. For a consent-gated session grant with a nested limits object, it covers timing, human interaction, default behavior and follow-up polling — enough to invoke and drive the flow correctly.

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 carries the load: it defines hours as session duration and limits as an optional override of the wallet's daily and per-trade limits in whole dollars, with an explicit keep-default behavior. Two weaknesses remain — the per-trade wording does not map cleanly to the nested humanApprovalAboveValue field, and agentName (max 40 chars) is never explained at all.

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 ('Ask the wallet owner to turn on hands-free trading') and immediately links it to the sibling it unblocks ('so execute_swap works'). An agent can distinguish this from session_request_status or agent_permissions without reading 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 frames the call as a prerequisite to execute_swap, names the follow-up tool to poll ('poll session_request_status every few seconds') and even supplies the cadence and the 10-minute window. It also gives an explicit omit rule for the optional limits parameter ('leave it out to keep them'), so both inclusion and exclusion paths are 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 declare read-only/non-destructive/open-world; the description adds the non-obvious hazard that tickers are not unique and that result rows carry safety signals (verifiedByWarden, establishedAsset, warning). With no output schema, this result-semantics disclosure is exactly the value the description should add.

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 purpose in the first clause, followed by safety guidance; no filler sentences. The middle sentence is dense and chains several clauses, which slightly hurts scannability 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?

For a two-parameter, no-output-schema search tool, the description covers the searchable fields, the ambiguity of results, and how to rank or reject rows — enough to call it safely. The only real omission is the optional chain-filtering 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 0%, so the description must carry parameter meaning: it does explain that `query` matches name, ticker or contract address (and its practical ambiguity). However, `chainId` is never addressed — whether omitting it searches all chains or narrows to one is left to inference.

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 ('Find tokens') plus the three search axes (name, ticker, contract address) and the scope (across supported chains). It is clearly distinguishable from siblings like trending_tokens or list_chains.

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: prefer verifiedByWarden or establishedAsset rows, never treat a warned row as the real asset, and use `cash`/`native` from list_chains for dollars and gas. That is a named alternative tool plus a when-not condition.

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 the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description is free to add the operationally important part: the exact four result states (pending/approved/denied/expired) in a tool with no output schema, plus the downstream constraint that execute_swap only works until the session ends. What is missing is timing behavior — how long 'expired' takes, whether polling is expected, and whether the code is single-use.

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

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

Two sentences, no filler. The core question and its possible outcomes are front-loaded, and the second sentence carries the one piece of follow-on context the agent actually needs.

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

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

For a one-parameter read-only poller with no output schema, enumerating the return states and the approval gate is the essential content, and both are present. The remaining gap is that the 'code' parameter's origin is undocumented, which for a 0%-coverage schema is a real (if small) hole.

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 'code' has 0% schema description coverage — only a regex pattern — and the description never mentions it, so nothing explains that it is the request code returned by request_session. The agent must infer the parameter's origin and format from the sibling tool name, which the description does not compensate for.

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?

"Whether the person has answered a request_session" states the resource (a session request) and the question being answered, and the sibling request_session is named explicitly so the pairing is unmistakable. It is clear without the input schema, though the verb is implicit (no "check" / "poll") rather than stated outright.

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 only implied: by naming request_session the description suggests this is called after creating a request to check for an answer, and the second sentence routes the agent onward to execute_swap once approved. There is no explicit when-to-use statement, no guidance on polling/retry cadence, and no mention of which sibling (e.g. swap_status) to use once approved versus while pending.

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 establish readOnly/openWorld/non-destructive, so the safety profile is covered; the description adds genuinely new behavior — that this is a polling endpoint with an expected cadence and a terminating condition (done is true), and that it exists precisely to track swaps execute_swap left unconfirmed. It stops short of saying what a failed/expired/refunded status looks like or how long it remains queryable.

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 with no filler, and the purpose leads. The only cost is readability: the first sentence is a long noun phrase rather than a clean statement, so the agent has to re-parse it before extracting the intent.

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 three-required-parameter read-only status lookup this is close to sufficient: purpose, cadence, terminating condition, and the not-needed case are all present. The gap is that it references a `done` field with no output schema to define it, and leaves chainId's expected value undocumented.

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 has to carry parameter meaning and only partly does. It clarifies that kind="solana" carries a Solana signature in `hash` and implicitly maps the enum to gasless vs cross-chain flows, but `chainId` is never explained — notably what value is expected for a Solana swap — and `hash` is otherwise undefined for the EVM kinds.

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

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

The description names the specific resource (gasless/relayed, cross-chain/bridged, and Solana swaps) and states it reports where the trade 'stands', which an agent can read as a status check. It ties itself to execute_swap and the three kind values, distinguishing it from the quote/prepare siblings. The opening clause is grammatically tangled ('a Solana swap (kind "solana", its signature) that execute_swap left unconfirmed'), which slightly blunts the clarity.

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 explicit operational guidance: poll every few seconds until done is true, and it states the negative case — plain EVM same-chain swaps confirm on-chain and need no polling. No competing sibling tool is named as an alternative, but for this tool the alternative is simply 'don't call it', which is 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 already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. Beyond that the description adds only 'right now', which weakly signals live/recency semantics; it says nothing about result ordering, pagination, rate limits, or data freshness, which matter for an open-world trending feed.

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

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

One short sentence with no filler and the key qualifier front-loaded, so it is efficient. The problem is under-specification rather than verbosity: the brevity is bought at the cost of the enum and parameter information an agent needs.

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

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

With no output schema and 0% schema description coverage on two parameters, the description is the only place semantics could be explained, and it covers only the default 'trending' case. An agent cannot tell what the return shape is or what 'new' and 'top' produce, which is a real gap for a tool with an enum and a bare numeric id.

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 carry the parameter burden and it largely fails. It hints that a chain is involved (mapping loosely to chainId) but never says whether chainId is a numeric network id versus a name, and it completely ignores the 'list' enum, leaving 'new' and 'top' undefined while implying only 'trending' exists.

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 fragment identifies the resource (tokens) and a qualifier (trending right now on a chain), so an agent can guess it returns a ranked token list. But it uses no verb and never acknowledges that the same tool also serves 'new' and 'top' lists, so the stated purpose is narrower than the tool's actual behavior. It also does nothing to distinguish it from sibling search_tokens.

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 guidance, no mention of when to prefer search_tokens or price_history, and no stated prerequisites. The only implicit signal is 'on a chain', hinting a chainId is needed, which the schema already enforces as required.

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