Tollkit Crypto

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds material context beyond them: cost ('Free'), custody guarantees ('Tollkit never holds anyone's funds or keys'), and the fact that it moves nothing. It also previews the return payload. Missing only deeper operational detail like failure modes when the address is malformed.

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?

Well front-loaded and organized into labeled sections (When to use / Use instead / Parameters / Returns). Slightly wasteful: 'Free.' appears twice and the return payload is described in the opening sentence and again under 'Returns'.

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 stating what is returned (the USDC balance and whether it falls below low_below). Combined with full parameter coverage and the safety profile, an agent has everything needed to invoke and interpret this tool.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema, including defaults and the enum. The description restates them (address 'the wallet you pay from', network default base, low_below default 1) with only slight added framing, so the baseline of 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 and resource with scope: 'Check how much USDC is left in your own wallet on Base.' It explicitly contrasts itself with the sibling 'wallet_balance for any wallet, chain or token,' so an agent can route correctly 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?

Provides an explicit 'When to use' trigger (you pay for tools from a wallet and want to know if it's running low) and an explicit 'Use instead' alternative (wallet_balance) with the condition that selects it. Nothing is left 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 only declare readOnlyHint and openWorldHint, so the description carries real added weight: it states the cost ($0.003 USDC per call over x402), that failed calls are free, and the two-step payment flow (call without `payment` to get a quote, then sign and call again). That is substantive auth/cost context an agent needs before invoking. It stops short of describing latency, caching, or partial-failure behavior, so it is strong rather than exhaustive.

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?

Usage and alternative routing are well front-loaded, but the payload contents are enumerated twice — once in the opening sentence and again in the 'Returns:' sentence — which is pure duplication. The cost and payment details are the only novel content in the middle block; trimming the repetition would make this much tighter.

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 is right to enumerate the returned fields in detail, and it does so thoroughly enough for an agent to know what it will get. The payment prerequisite and its quote-first workflow are also covered. The only gap is that quantities/shape of the aggregates (e.g. how many gainers/losers, formatting of the index) are unspecified.

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

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

There is a single optional parameter with 100% schema description coverage, so the baseline is 3. The description reinforces the quote/payment workflow already documented in the schema, but adds no syntax or format detail beyond it. The line 'Takes no parameters' is a slight overstatement given the optional `payment` field, though it is defensible as 'no required parameters'.

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 verb ('Get') and an enumerated resource (Fear & Greed, BTC/ETH/SOL perp data, funding extremes, gainers/losers, Hyperliquid totals) rather than a vague 'market data'. It also explicitly distinguishes itself from siblings by naming perps_market and crypto_news as the alternatives for narrower or adjacent needs.

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?

Contains an explicit 'When to use' clause ('you want the state of the crypto market in one call, for example before deciding anything else') and an explicit 'Use instead' clause routing to perps_market for specific coins/more markets and crypto_news for headlines. Both the selection condition and the alternatives are stated, leaving nothing 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 only declare readOnlyHint/openWorldHint; the description adds the x402 pricing model ($0.004 USDC per call, failed calls free) and the quote-then-sign payment flow, which is essential behavioral context. It also discloses the two-step payment dance and the 'not advice' boundary on the AI read.

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

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

Front-loaded with the core action and cleanly sectioned (When to use / Use instead / Parameters / Returns). The Returns line largely repeats the field list already given in the opening sentence, which is minor redundancy rather than bloat.

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 carries the return shape (articles[] fields plus mood/summary/themes) and does so explicitly. Combined with the payment and routing guidance, an agent has everything needed to call it 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 100%, so all four parameters (including the enum and min/max on num) are already documented. The description's parameter lines restate the same defaults and ranges without adding syntax, format, or edge-case detail, so the 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+resource (get recent crypto news) and immediately scopes it (up to 10 articles from the past hour/day/week), then names the sibling it is not — web_search for non-crypto and crypto_market_pulse for numbers. An agent can distinguish it from all 38 siblings 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?

Explicit 'When to use' clause plus a 'Use instead' clause routing to web_search and crypto_market_pulse by condition. Nothing about tool selection is left 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?

Beyond readOnlyHint/openWorldHint, the description discloses metered pricing ($0.001 USDC per call via x402), that failed calls are free, the two-step quote/payment handshake, the sign convention for funding, and the not_found error shape. This is rich behavioral context the annotations do not provide and there is no contradiction with them.

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 one-line summary followed by clearly labeled sections (When to use, Use instead, Parameters, Returns), which is easy to scan. It runs long and restates several schema-level parameter details, so it isn't maximally tight, but 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?

With no output schema, the description supplies a Returns breakdown covering every returned field, plus error handling and the payment lifecycle. For a 5-parameter, 0-required, open-world read tool, an agent has everything needed to invoke it 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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: the funding sign convention, that sort/limit only apply when coins is omitted, and that funding_hours requires exactly one coin (and pulls history). Some parameter text is redundant with the schema, which keeps it from a 5.

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 ('Hyperliquid perpetuals') and enumerates exactly what data is returned: mark/oracle price, funding, open interest, volume, leverage. It explicitly distinguishes itself from siblings crypto_market_pulse and token_price, 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?

Contains dedicated 'When to use' and 'Use instead' sections naming two concrete alternatives and the condition that selects each. It also clarifies the payment flow (call without payment to get a quote) and the coins-vs-top-markets branch, leaving nothing 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 only declare readOnlyHint and openWorldHint, but the description adds material context the annotations cannot: $0.01 USDC per call over x402, failed calls are free, and the two-step quote-then-pay flow via the `payment` parameter. It stops short of saying whether results are cached or how stale the on-chain reads can be, so not a full 5.

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

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

Purpose is front-loaded and the labeled When/Use-instead/Parameters/Returns blocks scan well. However 'Facts, not advice' appears twice and the Returns summary largely repeats the opening sentence's output list, which is avoidable duplication.

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

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

For a read-only, five-parameter tool with no output schema, the description covers everything an agent needs: what comes back, the payment handshake, chain defaults, and the one required field. Nothing material is left to inference.

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 the baseline is 3; the description goes slightly beyond by grouping the parameters into a usage narrative (amount_usd drives price impact against pool depth, wallet drives holdings display) and reminding that token is required. Much of that overlaps the schema text, which caps it at 4.

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 ('pre-trade check of a token on Base, Ethereum or Solana') and enumerates the concrete outputs: price, liquidity, chain warnings, price impact, holdings, web results. It also names the sibling token_check as the non-trading alternative, so the agent can separate the two 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 'When to use' line ties it to the moment right before a trade with a sizing question, and an explicit 'Use instead: token_check when you aren't trading yet' exclusion. Both the positive and negative conditions 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?

Annotations only cover readOnlyHint and openWorldHint, but the description adds the critical non-structured behavior: $0.002 USDC per call over x402, failed calls are free, and omitting `payment` returns a quote that must be signed and resubmitted. That payment/auth handshake is exactly the kind of trait annotations cannot express.

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 and clearly partitioned into purpose, pricing, when-to-use, alternatives, parameters and returns. Slight redundancy: return contents (first/last/high/low/percent change) appear in both the opening paragraph and the 'Returns' line, costing a little space without new 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 compensates by describing the return payload precisely (points[] with time, price_usd, Chainlink round, plus first, last, high, low and percent change) and covering the paid-call flow end to end. An agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the asset must have a Chainlink USD feed (narrowing valid symbols), points are 'evenly spaced' prices, and the payment quote-then-sign flow is restated in prose. It stops short of explaining edge cases such as what happens when fewer than `points` rounds exist in the window.

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 (past USD prices for a crypto asset) with concrete scope: up to 365 days, up to 100 points, sourced from Chainlink's on-chain Ethereum feed. It explicitly distinguishes itself from the sibling token_price, so an agent can route correctly 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?

Includes explicit 'When to use' (trend, high/low, change over a period for a major asset) and 'Use instead' naming token_price for the current price of any token, including those without a Chainlink feed. The condition that selects the alternative is spelled out, not inferred.

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 and openWorldHint; the description adds substantial behavior beyond that — the $0.004 USDC x402 cost model, that failed calls are free, the quote-then-sign payment flow via the `payment` param, and a free tier of 3 calls/day. This is exactly the kind of cost/auth context annotations cannot carry.

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 purpose and payment terms, and organized into clear labeled sections. Mild redundancy: the warning list (owner, upgradeable, mint/pause/blacklist/fees, Solana mint/freeze authority) is stated twice, once inline and again under 'Returns'.

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 fully covers the return contents in plain language, plus payment flow and free-tier limits. An agent has everything needed to quote, pay, call and interpret 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 the schema already documents all three params including the chain enum and default. The description restates token/chain meaning and defaults, adding little beyond the structured fields, so the 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 and resource ('Check a token') plus scope (which chains, what is returned: identity, USD price, liquidity, chain-read warnings). It distinguishes itself from siblings by explicitly contrasting with token_info and pretrade_check.

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 to use' trigger (before buying, accepting or sending an unfamiliar token) and a 'Use instead' section naming pretrade_check for sized trades and token_info for basics only, with the differentiator for each. No inference required.

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 and openWorldHint. The description adds information they cannot carry: the x402 payment model ($0.002 USDC per call, failed calls cost nothing, first 3 calls/day free, call without `payment` to get a quote), data freshness ('read live from the chain'), and the limits of what is returned versus crypto_market_pulse.

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 verb/resource, then pricing, routing, params and returns in a scannable order. It loses a point for mild duplication: 'Use it to confirm what an address actually is before acting on it' and 'When to use: ... before acting on it' say the same thing twice.

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, but the description enumerates the return fields itself, and it covers the payment/quote flow, chain options and sibling routing. Nothing needed to invoke this tool 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%, so the baseline is 3. The description restates the token and chain parameters (including the 'base' default) but says nothing about the `payment` parameter beyond the separate pricing paragraph, adding marginal meaning over 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?

States a specific verb and resource ('Look up a token on Base, Ethereum (ERC-20 contract) or Solana (SPL mint)') and enumerates the exact fields returned (name, symbol, decimals, total supply, Solana authorities). It also names the sibling tools it is not (token_check, token_price), so an agent can route 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?

Contains an explicit 'When to use' line ('You have a token address and need to know what it is before acting on it') and an explicit 'Use instead' line directing safety/liquidity queries to token_check and price queries to token_price. Both the trigger and the alternatives are 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?

Annotations cover only readOnlyHint and openWorldHint, so the description carries real weight and does: it discloses the data source and pool type, the thin-liquidity trust caveat, the x402 pricing ($0.001 USDC per call, free failures, 3 free calls/day), and the quote-then-pay flow. This is exactly the behavioral context an agent needs before spending money.

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 answer and cleanly sectioned under 'When to use', 'Use instead', 'Parameters', and 'Returns'. It is on the long side for a three-parameter tool, and the Returns paragraph partly repeats the liquidity/thin-pool detail already stated in the opening sentence, costing a point.

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 enumerating the return fields (price_usd, pool, liquidity, thin_liquidity flag), the chains, the pricing model, and the quote/pay workflow. An agent has everything needed to call it correctly and interpret 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 3 is the baseline and the description's parameter section largely restates the schema ('SOL' on Solana, chain default). It earns one step above baseline by explaining the payment round-trip — omit `payment` to receive a quote, then sign and call again — which the schema only implies.

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 ('Get a token's current USD price'), names the supported chains, and discloses the non-obvious methodology (deepest on-chain pool via Uniswap v3 / Orca Whirlpools rather than a price API). It is clearly distinguishable from price_history, token_check, and crypto_market_pulse.

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?

Has explicit 'When to use' and 'Use instead' sections that route the agent to three named alternatives with the conditions that select each (past prices, price plus safety warnings, BTC/ETH/SOL batch). Nothing is left 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?

The annotations already mark it read-only and open-world, and the description adds important behavioral details: per-call pricing, free failed calls, quote behavior, and a free daily allowance. It also discloses what is returned even without 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?

The description is front-loaded with purpose and return contents, followed by concise payment and usage notes. There is some repetition between the opening sentence and the final Returns line, but the structure remains efficient.

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

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

For a lookup tool with no output schema, the description is complete enough: it covers chains, hash formats, return fields, pricing, and payment flow. An agent has what it needs to decide whether and how to call 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?

Schema coverage is 100%, so the schema already documents the parameters well. The description still adds useful semantics by clarifying hash formats, chain defaults, and the critical constraint that the chain must match the hash.

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: look up a transaction on Base, Ethereum, or Solana. It also spells out the core outcome and return contents: success status, time, sender, fee, and token movements. This is clearly distinguishable from sibling tools such as wallet_balance or token_check.

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 explicitly says when to use the tool: when you have a transaction hash and need to know if it went through and what moved. It also explains the payment/quote flow, but does not name alternatives or explicit when-not conditions.

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 readOnlyHint/openWorldHint annotations by disclosing pricing ($0.002 USDC per call over x402), that failed calls are free, the 3-free-calls-per-day policy, and the quote-then-pay flow via the payment parameter. This is exactly the extra context annotations cannot carry.

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 the tool does, then cleanly sectioned into when-to-use, alternatives, parameters, and returns. Some content (chains, tokens, returns) is repeated across the body and the Parameters/Returns sections, but every section is useful.

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 carries the return shape itself (native coin, USDC/USDT, listed tokens with symbol, decimals, amount), and it covers payment flow, pricing, and alternatives. An agent has everything needed to call it 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 coverage is 100%, so the schema already documents address formats, chain enum, and the 20-token cap. The description largely restates these ('address is required', 'chain: base default', 'tokens: up to 20'), adding only the cross-parameter constraint that the address format must match the chain, which the schema already implies.

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 a wallet's token balances) and scopes it precisely across chains, naming exactly which balances are returned. It distinguishes itself from wallet_portfolio and check_my_balance by naming both.

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?

Has explicit 'When to use' and 'Use instead' sections that route the agent to wallet_portfolio for USD totals and check_my_balance for the caller's own USDC. Alternative selection is fully specified, not inferred.

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 openWorldHint, but the description adds genuine operational context the annotations don't carry: x402 pricing ($0.005 USDC per call), that failed calls are free, and the quote-then-sign flow. It also discloses the thin-pool and oversized-position warning behavior. It stops short of describing latency, caching, or pool-source reliability.

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, then pricing, then usage, then parameters and returns in clearly labeled blocks. Slight redundancy: the holdings/total/warnings output is stated both in the opening sentence and again in the Returns line, which costs a bit of space.

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 return contract and does so: holdings[] shape, the USD total, and the warning conditions. Combined with the pricing and payment workflow, an agent has everything needed to invoke it 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 coverage is 100%, so every parameter is already documented in the schema, including the base default, the 20-item token cap, and the address formats. The description restates these (address required, chain default, tokens up to 20) without adding format or syntax meaning beyond what the schema provides, so the 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 and resource ('Value a wallet in USD'), names the supported chains, and enumerates what is produced (per-holding prices, total, warnings). It explicitly differentiates itself from the sibling wallet_balance, 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?

Contains an explicit 'When to use' line and a 'Use instead' line naming wallet_balance with the selecting condition ('when amounts are enough (cheaper)'). No inference is required to choose between the two.

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