Agent Data Tools: Prices and DeFi

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true and idempotentHint=false. The description adds real value beyond that: it explains why calls are not idempotent ($0.01/call via x402, first 25 free, failed calls free), confirms nothing is signed or sent, and notes that fromAddress yields an unsigned transaction. It stops short of describing rate limits, quote expiry, or route-failure behavior, which matters for a live-priced quote.

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 core capability and cost are front-loaded and the semicolon-chained field list is dense but readable. It loses a point for redundancy: 'A quote only: nothing is signed or sent' and 'Reads or computes only and changes nothing' say the same thing, and the per-call charge is restated 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?

There is no output schema, and the description compensates by enumerating the returned fields, the optional unsigned transaction, and the pricing/credits model. Combined with the safety signal and a usage example, an agent has everything needed 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 baseline is 3; the description earns an extra point by tying fromAddress to the unsigned transaction returned and by noting swaps occur when from/to tokens differ (toToken semantics). The example also shows the expected string form for chain and token fields, though per-parameter format detail largely duplicates 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 — the cheapest cross-chain route via LI.FI across 20+ bridges — and enumerates what comes back (amount received, minimum, gas, fees, total cost, time, steps, approval address). The domain is clearly distinct from single-chain siblings such as swap_quote, and the swap-inclusion behavior is spelled out.

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

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

Gives an explicit trigger ('Use before an agent moves funds across chains') plus a concrete worked example with fromChain/toChain/fromToken/amount. It does not name alternatives or exclusions, e.g. when to prefer swap_quote for same-chain swaps or bridge_status after execution, so routing against siblings 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 already cover read-only, non-destructive, open-world and non-idempotent behavior; the description adds genuinely new context with cost semantics ('$0.01/call via x402 USDC or a card key, first 25 free; failed calls free') and the warning that 'each call is charged, so repeats are not free,' which explains the idempotentHint=false in practical terms. It does not discuss latency, rate limits, or how long a PENDING result may take to resolve.

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 purpose and scope in the first clause, then layers states, use case, example, pricing, and safety notes. The long sample hash is the bulkiest element but serves format clarity; the parenthetical router list and dual pricing mention border on 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?

With no output schema, the description carries the burden of describing returns and does so thoroughly: status values, sub-status and message, both transaction hashes, chains, tokens, amounts, and explorer links. Combined with pricing, failure-state coverage (NOT_FOUND), and the read-only assurance, nothing essential for correct invocation 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 both parameters are already documented in structured form; the description only adds a concrete example hash that clarifies the expected format. The optional fromChain parameter is never mentioned in the description, so no extra meaning is layered on top of 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: retrieve the status of a cross-chain transfer by source transaction hash. It enumerates the supported routers (LI.FI, Stargate, Across, CCTP, Hop, Polymer) and the exact return states (DONE, PENDING, FAILED, NOT_FOUND), which clearly separates it from bridge_quote and other siblings.

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 gives the operational context: 'Use to check whether funds arrived before an agent continues,' which tells an agent when to reach for it. It does not name an alternative or state when-not to use it (e.g., for quotes use bridge_quote), so it stops short of full routing guidance.

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

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

Beyond the readOnlyHint/openWorldHint/idempotentHint annotations, it discloses the billing model ($0.002/call via x402 USDC or card key, first 25 free), that failed calls are free, and that repeating a call is charged again — behavior that directly explains the idempotentHint=false signal. It also confirms the operation is read/compute-only, consistent with 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?

The first sentence front-loads what is returned, followed by use cases, an example, then cost/behavior notes. It is dense but every sentence carries information; the pricing clause is the only part that could be trimmed for some audiences, though it is decision-relevant here.

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 enumerates the return fields (per-currency prices, sats per USD, price time) and covers cost, failure handling, and side-effect profile. An agent has everything needed to call it 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% and the schema already explains that the seven listed currencies come from the source while others are converted at the ECB reference rate. The description adds only an example value (currency=SEK) and the list of currencies, so the baseline of 3 is appropriate.

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

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

The description states a specific resource and scope: current BTC spot price in seven named currencies, averaged across major exchanges, plus satoshis per USD and a timestamp. That is concrete enough for an agent to distinguish it from generic siblings like crypto_price, price_token, or fx without opening a 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?

It gives three explicit use cases (sats/fiat conversion, valuing a Bitcoin or Lightning payment, pre-trade price check) and a concrete call example with currency=SEK. It stops short of naming a fallback tool or stating when not to use it, so it does not reach the 'alternatives' bar of a 5.

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

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

Goes well beyond annotations: unreadable reads return null, EOAs return not-applicable, pricing model ($0.01/call, 25 free, failed calls free), and the warning that repeat calls are charged (consistent with idempotentHint=false). This tells the agent the cost and failure semantics, which annotations alone cannot.

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 and what it is for, then adds usage, example, pricing, and safety notes. Dense but nearly every clause carries information; the pricing sentence is the longest but is genuinely relevant to repeat calls.

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 does the work of naming the returned fields and their edge-case values. It is nearly complete for a single-param read tool, though the exact shape/ordering of the response payload is left implicit.

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 single `address` param is already documented, so the schema does the heavy lifting. The description still adds value by pinning the chain to Base and giving a real example address, which prevents cross-chain misuse among the many arb/eth/op/polygon siblings.

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 — risk check of a Base contract — plus the exact outputs (risk tier, named flags, bytecode size, EIP-1967 slot, ERC-20 reads). Clearly distinguishes itself from siblings like base_proxy, base_is_contract, and base_token_info, which each cover only one piece of this 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?

Explicitly says when to use it ('before approving a spender or calling an unfamiliar Base contract') and states a boundary ('Limited heuristics, not a full security audit'), with a concrete example invocation. It does not name sibling alternatives for deeper analysis, which keeps it short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this ('Reads or computes only and changes nothing'). Beyond that it adds information annotations cannot express: per-call billing ($0.002 via x402 USDC or card key), 25 free calls, failed calls free, and that repeated calls are charged — which explains the idempotentHint=false in practical terms.

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 sentence is dense but front-loaded: the resource and scale (0-100) come first, then return contents, then use cases, then commercial terms. Nothing is filler, though the billing clause lengthens a one-parameter read tool more than strictly necessary for invocation.

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 one optional parameter and no output schema, the description does the work of explaining what comes back (value, label, multi-horizon changes, window statistics, up to 90 days of history) and how it is priced. The only missing piece is disambiguation from the similarly named sibling 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%, with 'Days of history, 1-90 (default 30)' already in the schema. The description restates the 90-day cap and gives a usage example, but adds no new semantics such as what a longer window costs or how partial windows behave. Baseline 3 is appropriate since the schema carries the specification.

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 concrete resource and source ('Crypto Fear and Greed Index today ... from alternative.me') and enumerates the returned fields (value, label, 1/7/30-day change, window low/high/average, daily history). However, it never distinguishes itself from the near-identically named sibling 'crypto_fear_greed', so an agent faced with both must guess.

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 use cases ('a market-sentiment input for a trading agent, a dashboard or a daily brief') and a concrete invocation example ('days=30'), which is genuine context. It offers no when-not guidance and no routing rule against the sibling fear-and-greed tool, so selection is still implied rather than specified.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=false; the description reinforces the read-only contract ('reads or computes only and changes nothing') and usefully explains why it is non-idempotent — every call is charged, so repeats cost money. It adds real operational context (once-a-day refresh, $0.002/call, 25 free, failed calls free) that annotations cannot express. However, it stops short of describing response shape or ordering, so it is a solid but not exceptional add on top of the structured 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?

One dense, front-loaded paragraph: what it is, what it returns, cadence, usage, example, pricing. Every sentence carries information, though the pricing/credits sentence is long and mixes commercial mechanics with functional guidance, which slightly dilutes the front-loading.

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 must enumerate return values — and it does: today's value and label, 1/7/30-day change, window low/high/average, and up to 90 days of daily history. Refresh cadence, upper history bound, cost model, and safety profile are all covered, leaving no meaningful gap for a single-optional-parameter read 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?

The single parameter is fully documented in the schema (1-90, default 30), so the baseline is 3. The description adds the notion of a 'window' that the low/high/average statistics are computed over and supplies a concrete invocation example (days=30), which meaningfully connects the parameter to the returned aggregates.

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

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

States a specific resource (Crypto Fear & Greed Index), its source (alternative.me), its scale (0 = extreme fear, 100 = extreme greed), and exactly what is returned: today's value and label, deltas at 1/7/30 days, window low/high/average, and daily history. An agent can distinguish this from price-oriented siblings at a glance.

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 names the use cases (market-sentiment input for a trading agent, dashboard, or daily brief) and routes elsewhere for a different need: 'for live prices use price_token.' It also warns that repeats are billable, which is a usage constraint rather than a description of behavior.

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 read-only, open-world and non-destructive status, but the description adds real value beyond them: an explicit cost ($0.002/call, first 25 free, failed calls free) and the warning that repeats are not free, which explains the idempotentHint=false in practical terms. It does not cover rate limits, latency, or response shape details, so it is strong but not 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?

Front-loaded with the resource definition, then use cases, then commercial/safety terms — a sensible order with no filler. Every clause carries either scope, use, cost, or safety 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, so the description compensates by listing the returned fields and the extra trending-categories section. Combined with cost terms and the read-only guarantee, an agent has everything needed to decide and call correctly for a single-optional-param 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?

With one optional parameter at 100% schema coverage, the schema fully documents `only` including its comma-separated syntax and empty-match fallback, so baseline 3 applies. The description only indirectly helps by enumerating the result fields an agent could project, but never mentions the `only` parameter itself.

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

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

States a specific resource and its exact provenance: coins most searched on CoinGecko in the last 24 hours, in rank order, with the named fields (price, 24h change, market cap, volume, rank, categories). That is clearly distinct from price-lookup siblings like crypto_price or price_token, and from dex_trending's on-chain pool focus.

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 use cases (spot market attention, feed a news/trading agent, pick research targets), which tells the agent when this is the right tool. It stops short of naming an alternative tool or an explicit when-not-to-use condition, so it misses the top band.

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 and destructiveHint=false, so 'reads or computes only' repeats structured data and earns no credit. The description does add genuinely new behavioral context, however: the cost model ($0.01/call via x402 USDC or card key, first 25 free, failed calls free) and the warning that repeats are not free, which meaningfully explains the idempotentHint=false flag. Nothing contradicts 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 resource and both modes in the first sentence, then usage, then pricing, in a logical order with no filler. The pricing sentence is long and slightly repetitive ('each call is charged, so repeats are not free' restates the per-call fee), keeping it from a 5.

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 available, the description usefully enumerates the returned fields (TVL, share of total, native token, chain id) and caps the result set at 100. It covers both modes and cost, leaving only minor unknowns such as whether the ranking is sorted descending or how failures surface.

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

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

Schema description coverage is 100%, with both parameters documented (chain by name, limit 1-100 default 25), so the baseline is 3. The description reinforces the intent of omitting chain to get the ranking and supplies the example chain=Base, but adds no syntax, casing or validation detail beyond 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 resource (TVL per blockchain from DefiLlama) plus both operating modes: a ranked list of up to 100 chains with share of total, native token and chain id, or a single chain by name. That level of specificity distinguishes it from chain-agnostic siblings like defi_tvl without the agent needing to open either schema.

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

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

Gives concrete selection guidance: 'Use to compare L1s and L2s, size an ecosystem or pick where to deploy,' plus a worked example (chain=Base). It stops short of naming an explicit alternative or a when-not condition (e.g. protocol-level TVL via defi_tvl), so it lands just under the top band.

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

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

Goes well beyond the annotations by disclosing commercial behavior: "$0.01/call via x402 USDC or a card key", "first 25 free", "failed calls free", and "each call is charged, so repeats are not free" — directly explaining the idempotentHint=false consequence. It also restates the no-side-effects contract ("reads or computes only and changes nothing"), which is consistent with readOnlyHint/destructiveHint rather than contradicting 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?

Purpose and modes are front-loaded and every clause carries information — outputs, filters, pricing, safety. The main weakness is that it is one long run-on sentence chain ("…top chains; or list…") with no separation between capability, billing, and safety, which makes it denser than it needs to be.

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

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

There is no output schema, so the description carries the return-shape burden and does so: TVL, 1h/1d/7d change, market cap to TVL, top chains, or a ranked list. Combined with cost and safety disclosure, an agent has everything needed to call it correctly without surprises.

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, and the description's parameter content is largely redundant (naming Aave/Lido/Uniswap as protocol examples, Lending/Dexs as category examples, tvl/1d/7d as sort values). Marginal added meaning is the protocol-versus-ranking framing, which the schema's protocol description already states.

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

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

Opens with a specific verb+resource ("Total value locked of DeFi protocols from DefiLlama") and then spells out the two operating modes: single-protocol lookup versus ranked list. It even scopes out a whole category ("CEXs are left out unless asked for"). The only gap is that the near sibling defi_chains is never named, so an agent must infer which tool owns per-chain TVL rankings.

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 use cases ("size a protocol, compare competitors or track where liquidity moves") plus a worked example ("protocol=aave"). It implies when to leave protocol empty for a ranking. It stops short of explicit when-not/alternative routing, e.g. pointing chain-level questions at defi_chains.

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

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

Beyond the readOnly/openWorld annotations, the description discloses cost mechanics (\$0.01/call via x402 USDC or card key), the 25-free-call allowance, that failed calls are free, and that repeats are not free because each call is charged — an unusual and highly decision-relevant trait. It also disclaims 'not investment advice' and affirms 'reads or computes only and changes nothing', and with no output schema present it still previews the return payload (APY base and reward, 30-day mean, TVL, exposure, risk flags).

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, coverage and use case are front-loaded, and every clause carries information (filters, output fields, pricing, safety). The single run-on paragraph mixes commercial and legal caveats into the functional description, which slightly dilutes scanability, 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?

For a 5-parameter read-only lookup with no output schema, the description covers purpose, filters, return fields, payment model and safety. The remaining gap is inter-tool disambiguation from defi_yields and defi_yield_history, and the ranking/sort semantics implied by 'best'.

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 on top: it clarifies that chain, project and symbol are all optional filters ('Filter by chain, protocol or another stablecoin'), that USDC is the implicit default, and gives a concrete call example (symbol=USDC). It does not explain ordering/scoring logic behind 'the best' or how limit interacts with minTvl ranking.

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 and resource ('USDC yield right now: the best stablecoin APY across DeFi lending, vault and LP pools'), enumerates the covered protocols and chains, and states the returned fields. An agent can tell this is a ranked stablecoin-yield lookup rather than a general TVL or historical-yield tool.

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

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

'Use to find where an agent can earn yield on USDC or any stablecoin' plus the note that it can be re-scoped to USDT/DAI/other chains gives clear trigger conditions. It stops short of naming when NOT to use it — the siblings defi_yields and defi_yield_history are never mentioned, so the agent must infer the boundary between this curated USDC view and the generic/historical yield tools.

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

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

Beyond the readOnly/openWorld annotations it discloses data source (DefiLlama), window cap (365 days), billing model ($0.01/call via x402 USDC or card key, first 25 free, failed calls free) and explicitly explains why repeats are not free — which reconciles with idempotentHint=false. It also notes the tool only reads/computes and changes nothing, consistent with destructiveHint=false.

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

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

One dense paragraph that front-loads what is returned, then usage, then pricing. All sentences carry information, though the 'Not investment advice' clause is peripheral and the pricing/auth tail could be trimmed.

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, but the description enumerates the return payload (daily APY base and reward, TVL, average/min/max/latest APY) so the agent knows what comes back. Combined with the window limit, source and cost model, nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so both `pool` (UUID or URL) and `days` (1-365, default 30) are already documented in the schema. The description only restates the pool-id-or-URL form and adds a sample UUID; it adds no syntax or edge-case meaning beyond that, so baseline 3 applies.

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

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

States a specific verb and resource: 'Daily APY and TVL history of one DeFi pool', and pins the scope to a single pool id. It explicitly routes pool discovery to the sibling /defi/yields endpoint, so an agent can separate it from defi_yields or liquidity_pool_audit without opening a 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 a concrete decision context: 'Use to check whether a yield is steady or a short spike before an agent deposits', and names the source of the pool identifier. It does not state explicit when-not conditions or name a direct alternative for the history question, so it stops short of a 5.

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

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

Beyond readOnlyHint/destructiveHint, the description discloses the data source (DefiLlama), the auth/cost model ($0.01/call via x402 USDC or card key, first 25 free, failed calls free), and explicitly explains why idempotentHint=false — 'each call is charged, so repeats are not free.' It also names the returned fields, which matters since there is 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?

Front-loaded with what the tool returns, then filters, then a use case, then cost/auth. Dense but nearly every clause carries information; only the 'Not investment advice' line is boilerplate that could be dropped.

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 an 11-parameter, zero-required, read-only tool with no output schema, the description covers data source, return fields, filter surface, default behavior implied by the schema, and the billing/auth model. An agent has everything needed to call it correctly and understand the cost implication of repeating a call.

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

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

Schema description coverage is 100%, so the schema already documents every one of the 11 filters including defaults (minTvl 1M, maxApy 1000, limit 20). The description mostly restates the same filter set and sort options rather than adding syntax or interaction semantics, so the baseline 3 applies; the chain=Base example is a small bonus.

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 best DeFi yields now across ~15,000 lending, staking, LP and vault pools' — and enumerates the returned fields (APY base/reward, 30-day mean, TVL, stablecoin flag, IL risk). The word 'now' implicitly separates it from the sibling defi_yield_history, but no sibling is named explicitly, which keeps it just short of a 5.

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

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

'Use to find where to earn yield on a token or stablecoin' gives a clear triggering scenario, and the example (chain=Base) shows a concrete invocation. However, it never names an alternative tool (defi_yield_history, liquidity_pool_audit) or states when not to use it, so routing is left partly 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, and the description reinforces this without contradicting it ('Reads or computes only and changes nothing'). It adds behavior the annotations cannot express: majors are filtered by default, symbolClash flags copied symbols so results must be matched by address, and every call is billed ($0.01 via x402/card, first 25 free, failed calls free, repeats not free).

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?

Dense but front-loaded: purpose, data sources, exclusions, then caveats and pricing. Every sentence carries information, though the pricing/payment clause is long and sits mid-paragraph where it competes with the usage guidance for attention.

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 usefully enumerates the return fields (swaps, pools, share of swaps, symbol, name, busiest pool) and explains the symbolClash field, which an agent could not otherwise interpret. Remaining gaps are minor: result ordering, behavior on thin/empty windows, and whether the per-call charge applies to rate-limited or retried calls.

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 baseline is 3, but the description adds real meaning: it frames 'blocks' as a live lookback window over swap events ('default 5, up to 10' minutes, matching the 30-300 block range) and clarifies that the majors filter defaults to exclusion 'unless asked'. It stops short of explaining how 'limit' interacts with ranking or tie-breaking.

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 and scope ('Trending tokens on Base now') and defines it operationally: tokens with the most DEX swaps counted live from Uniswap v2/v3, Aerodrome and Slipstream events. It also separates itself from siblings by pointing at token_report for the follow-up check, so an agent can choose between them without reading 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?

It states the intended use ('spot what traders buy now'), the required follow-up ('check token_report before trading'), and a default the caller may not expect (majors left out unless asked). It even gives a worked invocation ('blocks=150'), which is unusually explicit routing guidance.

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

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

Annotations already declare readOnly, openWorld and non-destructive, and the description usefully adds the data source (ECB), a freshness signal ('the date the rates apply to'), and a detailed cost model ($0.002/call, first 25 free, failed calls free). That billing note also explains the non-obvious idempotentHint=false. The line 'reads or computes only and changes nothing' largely restates the annotations, and nothing is said about rate limits or staleness beyond the returned date.

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 source, scope and return shape, then usage, then pricing. Nothing is truly wasted, though 'reads or computes only and changes nothing' duplicates the annotations and the pricing sentence is dense.

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 still tells the agent what comes back (rates, converted amounts, and the date the rates apply to), where data originates (ECB) and how it is billed. For a three-parameter read tool that is sufficient 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 from/to/amount, ISO 4217 format and comma-separated targets are already documented. The description restates the same facts (base currency, optional targets, amount, default all currencies) with only the from=USD example as added value, 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+resource (fetch ECB foreign exchange rates, return converted amounts) plus scope (~30 major currencies, examples USD/EUR/GBP/JPY). The terse tool name 'fx' is fully disambiguated. It does not, however, contrast itself with the visible siblings fx_all and fx_symbols, leaving the agent to guess which of the three to pick.

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 usage contexts ('currency conversion, invoice and price calculations, and reporting in another currency') and a worked example (from=USD). It stops short of explicit exclusions or routing to fx_all/fx_symbols, so the agent gets context but no negative guidance.

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

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

Adds substantial context beyond annotations: source is ECB daily reference rates, values are mid rates not live bid/ask, the applicable date is returned, and billing is $0.002/call with 25 free and failed calls free. The 'each call is charged, so repeats are not free' line usefully explains the idempotentHint=false flag.

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 core capability and data source lead, and the pricing and safety notes follow in a compact block. Dense but every sentence carries information; only the pricing detail runs slightly long for a single-parameter tool.

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 convey what comes back, and it does: cross rates plus the date they apply to, at mid-rate basis. Pricing, safety, and the default currency set are all covered, leaving only the exact response shape unstated.

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 already documents the single parameter, including the 2-12 bound and the eight-major default. The description reinforces this and adds a concrete example (currencies=USD,EUR,GBP), which is modest but genuinely useful value on top of 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: cross rates for every pair among the eight majors or up to 12 chosen currencies, in one call. The 'all pairs in one call' scope implicitly separates it from the singular fx and fx_symbols siblings, though no sibling is named 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?

Gives three concrete use cases (fill a forex rate table, batch conversion, check a cross rate), which is clear positive guidance. It does not state when to prefer the plain fx tool for a single pair, so the boundary with its nearest sibling 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 already declare readOnly, non-destructive, open-world, and non-idempotent; the description reinforces the read-only nature ('reads or computes only and changes nothing') and adds genuinely new information about billing: $0.002/call via x402 or a card key, 25 free calls, failed calls free, repeats are not free. That billing detail explains and justifies the idempotentHint=false in a way annotations cannot. It does not mention rate freshness or whether ECB reference rates are daily rather than truly 'live', which the title implies.

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 purpose and scope are front-loaded in a single dense sentence, followed by usage, an abbreviated example, and pricing. The 'Example: from=USD.' fragment is slightly awkward, and the pricing sentences, while useful, add length, but every line 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?

There is no output schema, and the description does not say what the response looks like: whether it returns a rates map per currency, a converted amount, a timestamp, or both. For a conversion tool that an agent may parse programmatically, that omission is a real gap, though the pricing, safety, and currency coverage are complete.

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 from, to (comma-separated codes, default all), and amount (default 1). The description adds the list of supported currencies and an example (from=USD), but nothing about syntax or defaults beyond the schema. 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 clear verb+resource: fetch exchange rates from a base currency to many targets and optionally convert an amount, sourced from ECB reference rates. It does not differentiate itself from the sibling tools fx, fx_all, and fx_symbols, which is the main clarity gap.

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 concrete usage contexts ('convert prices, settle an invoice... show a rate in an agent's answer') and an example call, so when-to-use is implied. It never says when to prefer a sibling such as fx_all or fx_symbols instead, so selection between the FX tools 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 already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=false. The description reinforces a few of these ('reads or computes only and changes nothing', 'each call is charged, so repeats are not free') and adds genuinely new cost context: $0.01/call via x402 USDC or a card key, first 25 free, failed calls free. However, the explicit restatement of annotation-covered safety traits dilutes the added value, and no return shape or pagination detail is given, so a 3 is appropriate rather than 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?

Front-loads the resource definition before use guidance and pricing, which is the right order. It is a dense single paragraph with no wasted sentences, though the pricing sentence is long and could be tightened.

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 the return: ~30 currencies, ISO code, English name, and pair counts. Combined with cost, safety, and sibling routing, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the sole parameter 'only' is fully documented in the schema, including its example and edge-case behavior. The description says nothing about 'only' and adds no meaning beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource: the list of ~30 currencies with ECB daily reference rates, ISO 4217 code, English name, and pair counts. This clearly distinguishes it from the sibling conversion tools /fx and /fx/all, which it names directly.

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 explicit when-to-use guidance: check which currencies /fx and /fx/all can convert before calling them, or populate a currency picker. It names the alternative tools and the condition that selects this one over them.

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, non-destructive and open-world, and the description reinforces this with 'Reads or computes only and changes nothing'. It adds meaningful behavior beyond annotations: data is public on-chain info from Hyperliquid's info API read live, cost is $0.01/call with the first 25 free and failed calls free, and repeats are not free (consistent with idempotentHint=false). It stops short of describing latency, rate limits, or behavior when the address has no account.

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 payload contents, but the first sentence is an extremely long enumerated list packed with a dozen field names. The payment/pricing material and the 'reads or computes only' disclaimer consume meaningful space, some of which partly restates the readOnly annotation.

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 must carry return-value disclosure itself — and it does, field group by field group, including the parenthetical clarifying that cumulative funding corresponds to Hyperliquid's cumFunding. For a single-parameter read tool, an agent has everything needed to call it 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% and there is only one parameter, so the baseline is 3; the description earns an extra point by clarifying that the address may be any Hyperliquid account (a trader, a vault, or an agent's book) and by supplying a concrete example address that demonstrates the expected 0x format.

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

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

States a concrete verb+resource (fetch any Hyperliquid account by address) and enumerates exactly what comes back: perp account value, notional, margin used, withdrawable, leverage, unrealized PnL, every open position with side/size/entry/value/PnL/ROE/liquidation price/leverage/cumFunding, spot balances, and up to 50 open orders. This clearly separates it from sibling tools like hyperliquid_market, hyperliquid_prices and hyperliquid_candles, which are market-data rather than account-data endpoints.

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 usage contexts — 'track a trader, a vault or your own agent's book' — and a runnable example with an address. It does not name an alternative or state exclusions (e.g., use hyperliquid_funding_history instead for funding-only queries, or hyperliquid_candles for price series), so routing decisions against siblings are left largely implicit.

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, openWorldHint=true and idempotentHint=false, and the description usefully explains the non-idempotency ('each call is charged, so repeats are not free') plus the data source (Hyperliquid's public API). That cost/rate context is genuine added value, but the description cannot itself explain why a read is non-idempotent beyond billing, and it adds little else over the annotation set for a pure read tool.

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

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

Front-loaded with the resource and payload, then limits, then usage, then cost — a sensible ordering with little filler. It is a single dense paragraph where the pricing and example clauses ('Example: coin=BTC') could be tightened, but no sentence is truly wasteful.

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

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

Covers everything an agent needs with no output schema: what a bar contains, interval granularity, the 1-500 bar cap with default, ordering, source, cost/free tier, and confirmation of no side effects. Nothing material for a correct call 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 nevertheless adds the bar ordering ('newest last') and the 500-bar/50-default ceiling in the prose, both of which the schema does not state. Its interval list ('1m, 5m, 15m, 30m, 1h, 4h, 1d, 1w and more') is vaguer than the schema's exhaustive enumeration, 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?

Gives a specific resource (historical OHLCV candles for a Hyperliquid perpetual) and spells out the payload fields (open, high, low, close, volume in coins, trade count). It does not differentiate itself from sibling tools such as hyperliquid_indicators or hyperliquid_prices, so an agent must infer which one to use for computed indicators vs. raw bars.

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?

Names concrete use cases — charts, backtests, volatility and trend checks, context for a trading agent — which is a clear positive context. It stops short of explicit when-not guidance or naming an alternative tool (e.g. hyperliquid_indicators for derived metrics), so usage is contextual rather than fully directed.

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 the read-only/destructive profile, and the description adds what they don't: the upstream source ('Hyperliquid's public API'), the 500-hour lookback cap, and a detailed cost model ($0.01/call, first 25 free, failed calls free, repeats charged). The 'each call is charged, so repeats are not free' line is consistent with idempotentHint=false.

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

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

The core capability and return shape lead, followed by usage and cost; nothing is buried. The pricing/payment sentence is dense boilerplate but does carry decision-relevant cost 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, but the description fully describes the return payload (per-rate fields plus aggregate average and APR), the data source, the history cap, and the cost model — everything an agent needs to call and interpret 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% with both parameters documented (coin default ETH, hours 1-500 default 24). The description restates the example coin=ETH and the default window but adds no syntax or edge-case meaning beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource: 'Past hourly funding rates of a Hyperliquid perpetual', and enumerates the return contents (rate, premium, time, average rate, APR). It also explicitly disambiguates from the sibling hyperliquid_market, which serves the current rate.

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?

Names concrete use cases ('compare carry over time, spot funding regime changes, or backtest basis and funding-arbitrage strategies') and gives an explicit exclusion redirect: 'for the current rate use hyperliquid_market'. Window bounds and default are also 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 already cover read-only, non-destructive, non-idempotent and open-world. The description adds genuinely useful context beyond that: it is computed from Hyperliquid's public candles, costs $0.01/call via x402 or a credits key, the first 25 are free, and failed calls are free — which explains the non-idempotent hint. The sentence 'Reads or computes only and changes nothing' largely restates readOnlyHint, keeping it 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?

It front-loads the indicator inventory, which is what an agent needs to decide relevance, then follows with usage, pricing and a disclaimer. The pricing/disclaimer sentences are somewhat dense and could be trimmed, but nothing is wasted or buried.

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

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

No output schema exists, so the description carries the return-value burden and does so by listing every computed indicator and the plain-language readings. Combined with full schema coverage and existing annotations, 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% and both parameters are documented in the schema. The description only adds the interval range (1m–1w) and the note that candles are closed, plus a coin=BTC example; that is marginal added meaning over the schema, 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?

The description names a specific resource (technical indicators for a Hyperliquid perpetual) and enumerates exactly what is computed: RSI 14, MACD 12/26/9, SMA/EMA sets, Bollinger 20/2 with %B, ATR 14 and realised volatility. That enumeration cleanly distinguishes it from hyperliquid_candles, which returns raw candles rather than derived indicators.

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 intended consumer (trading agent or market dashboard) and a usage example (coin=BTC), so the purpose context is implied. But it never states when to prefer this over hyperliquid_candles or hyperliquid_market, nor any exclusions or prerequisites beyond the pricing note.

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 read-only and non-destructive status, but the description adds substantive behavior the annotations cannot express: the data comes from Hyperliquid's public API, the call costs $0.002 via x402 USDC or a card key with the first 25 free and failed calls free, and repeats are charged (which explains the non-idempotent hint in practical terms). 'Reads or computes only and changes nothing' reinforces the safety profile, and the cost/rate detail is exactly the operational context an agent needs before retrying.

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 field enumeration is front-loaded and dense with information, and the default behavior follows immediately. The closing sentence on pricing and read-only behavior is long and partly duplicates the readOnlyHint annotation, but the cost terms are genuinely load-bearing and worth the 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?

For a single-parameter read tool with no output schema, the description effectively doubles as a return-value contract by listing every metric and its units (coins and USD, hourly funding, APR). Payment mechanics and the no-coin default are covered; only minor gaps remain, such as response shape for the multi-market default case or handling of unknown symbols.

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 a single optional parameter at 100% schema description coverage, the schema already defines the coin symbol and its default. The description restates example symbols and the default market list, adding only the illustrative 'Example: coin=BTC' beyond the schema, so it sits at the baseline rather than adding new semantic depth (e.g., case sensitivity or unsupported-symbol behavior).

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 exact resource (live Hyperliquid perpetual futures data for a coin) and enumerates the returned metrics: mark/oracle/mid price, hourly funding and APR, premium, open interest in coins and USD, 24h volume and price change, max leverage. It also states the no-argument default (20 most traded markets by 24h volume), which separates it behaviorally from history-oriented siblings. It never names hyperliquid_prices, hyperliquid_funding_history, or hyperliquid_orderbook explicitly, so the agent must infer the snapshot-vs-history distinction from the word 'Live'.

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 concrete use cases ('funding-rate checks, basis trades, derivatives dashboards and market context') and a worked invocation ('Example: coin=BTC'), plus the implicit when-to-use signal of omitting the coin for a market-wide leaderboard. There are no explicit exclusions or named alternatives, so an agent has clear context but no routing rules against the sibling Hyperliquid tools.

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

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

Annotations already declare readOnly, non-destructive and open-world, and the description reinforces that nothing is changed. Beyond annotations it adds the information an agent most needs to know: per-call cost, a 25-call free tier, failed calls free, and the 20-level cap, which also explains why idempotentHint=false despite being a read (repeat calls incur charges). It stops short of stating data freshness or latency.

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

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

Purpose and returned fields are front-loaded in the first sentence, with usage and cost following, so the ordering works. The pricing/billing tail is denser than strictly needed for tool selection and slightly blurs the focus, though it is genuinely actionable 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?

There is no output schema, so the description carries the return-shape burden itself — and it does so by enumerating bids, asks, mid, spread in USD and bps, and summed depth per side. Combined with the level cap, source (public API) and cost model, an agent has everything needed to call this 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 both parameters (coin, levels) are already fully documented with defaults and the 1-20 range, establishing the baseline of 3. The description only restates the defaults and adds a redundant 'Example: coin=BTC' rather than adding new meaning.

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

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

The description names a specific verb and resource — the live order book of a Hyperliquid perpetual — and enumerates the delivered fields (best bid/ask with price, size, order count, mid, spread in USD and bps, per-side depth). That is enough to separate it from siblings such as hyperliquid_prices, hyperliquid_candles, hyperliquid_market and polymarket_orderbook 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?

It gives concrete use cases: judging liquidity and slippage before a trade, market-making and arbitrage checks. It does not name an explicit alternative or a when-not condition (e.g. use hyperliquid_prices for a spot quote), so routing is clear but not fully disambiguated.

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 read-only, destructive, open-world and idempotency; the description adds the data source (Hyperliquid public API), the return shape (coin-to-price map), and a cost model (per-call pricing, first 25 free, failed calls free, repeats charged). The cost and idempotency-per-call disclosure is valuable context beyond structured data. Loses a point only because the closing 'reads or computes only and changes nothing' largely restates readOnlyHint.

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 capability and scoped example, then use cases, pricing, and safety in a clean progression. The final clause about charging repeats is slightly redundant with the earlier pricing sentence, costing a small amount of tightness.

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 optional parameter tool with annotations but no output schema, the description covers source, return format, default behavior, filtering, cost, and side-effect profile. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100% and the schema already documents the default ('every perpetual') and the comma-separated symbol format. The description's example (coins=BTC,ETH,SOL) and 'only the coins you name' phrasing mostly repeat the schema, 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 ('Current mid prices of every Hyperliquid perpetual'), quantifies scope (~200 coins), and specifies the return shape (coin-to-price map) plus the filterable variant. The name 'perpetual' plus 'Hyperliquid' distinguishes it from generic siblings like crypto_price or price_tokens without needing the schema.

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

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

Explicitly names intended uses (quick snapshot of many coins, portfolio marks, price ticker) and an exclusion with a named alternative: 'for funding and open interest use hyperliquid_market.' That is a genuine when-to-use/when-not routing instruction.

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 mark it read-only/non-destructive, and the description adds real context beyond them: a DexScreener-primary/Base-fallback source with source and retrieval time in the result, null for missing fields, 404 for unknown pairs, and an explicit cost model (first 25 free, failed calls free, repeats charged) that explains the non-idempotent hint. The scope boundary (market data only, no risk assessment) prevents over-trusting the output.

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 action and its output are front-loaded, followed by scope boundary, alternative routing, example and pricing. It is information-dense rather than padded, though the pricing/commercial clauses make it longer than a pure capability description needs to be.

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

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

There is no output schema, so the description carries the full burden and does so: it enumerates the returned fields, source/provenance, null and 404 behavior, and the scope limit. Nothing an agent needs in order to call this correctly or interpret its result 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% and the single parameter's format (0x-prefixed 20-byte hex) is fully documented in the schema, so the baseline of 3 applies. The description restates 'give a pair address' and adds a concrete example value, which is mildly helpful but contributes no new semantics.

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 (check/audit) and a tightly scoped resource (a Base DEX pair's liquidity, volume, trades, age), and lists exactly what comes back. It explicitly bounds itself ('Market data only, no risk assessment') and names token_report as the sibling for token red flags, so an agent can separate it from token_report, price_token and wallet tools without opening a 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?

'Use to confirm a pair is real and deep enough before trading' gives a concrete trigger, and 'token red flags: token_report' names the alternative with the condition that selects it. The 'no risk assessment' clause tells the agent when this tool is not enough.

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, openWorldHint=true and idempotentHint=false; the description goes further by disclosing cost ($0.01/call via x402 or card key, first 25 free, failed calls free), the HTTP 400-without-charge behavior on invalid values, and that repeat calls are billed (consistent with idempotentHint=false). That is real added value. However, it never says what the response contains or whether fee data is cached/stale, so it does not fully carry the behavioral burden left by 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-loaded with the core action, then assumptions, valid values, exclusions, usage, example, and pricing in a logical order with no filler sentences. It is dense to the point of feeling packed — pricing and error-handling details sit in the middle of the capability description — but nothing is redundant given the lack of an 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?

For a one-parameter tool this covers scope, assumptions, valid inputs, cost, and failure behavior well. The clear gap is the return value: with no output schema, the description should say roughly what a gas estimate response looks like (fields such as gas cost, priority fee, total), and it only says 'estimates gas costs'.

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 enum values are already listed, so the schema establishes the baseline. The description nonetheless adds meaning: high-mev means 3x priority fee, low-gas means half, and invalid values return HTTP 400 without charge — semantics an agent cannot infer from the bare enum. It does not explain what 'standard' maps to beyond 'current fees', which keeps it short of 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 — 'Estimates Base gas costs from current fees and priority-fee presets' — and immediately bounds the claim by noting the fixed gas-unit assumptions are typical rather than transaction-specific. It also rules out adjacent capabilities ('No transaction simulation, mempool observation, or MEV/sandwich-risk measurement'), so an agent can distinguish it from the risk/analysis siblings despite the MEV-flavored name.

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?

'Use to budget gas for a Base transaction' gives the positive trigger, and the negative clauses (no simulation, no mempool, no sandwich-risk measurement) tell the agent when this tool is the wrong pick even though its title mentions MEV. An example invocation (scenario=standard) anchors the call.

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 carry readOnlyHint=true and destructiveHint=false, and the description reinforces that with 'Reads or computes only and changes nothing.' The genuinely additive disclosure is the billing model - paid per call via x402 USDC, first 25 free, failed calls free - which explains why idempotentHint is false and warns that repeats are not free. It does not cover failure modes or output shape beyond the unit conventions, so it adds real but not exhaustive context.

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: capability and outputs come first, then inputs, then usage, then a concrete example, then the payment note. Sentences are dense and each carries information, though the payment and free-tier detail slightly bloats an otherwise tight definition.

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 burden of describing return values and does so precisely, including Greek units (vega per vol point, theta per day) which would otherwise be ambiguous. For a 10-parameter, two-mode arithmetic tool it covers inputs, outputs, usage and cost with 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?

Schema description coverage is 100%, so the schema already documents every parameter including defaults, the 'instead of days' alternatives and percent units. The description's parameter sentence ('spot, strike, expiry date or days, volatility, interest rate and dividend or funding yield in percent') largely restates that. The only marginal value is stressing percent-based units and the three-way expiry input, 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 - 'Price a European call and put with Black-Scholes-Merton' - and enumerates the exact outputs (delta, gamma, vega, theta, rho, d1, d2, ITM probability), plus the inverse mode returning implied volatility from a market price. No sibling tool in the list prices options, so the differentiation is implicit but unambiguous.

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

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

Explicitly scopes use: 'Use for crypto, stock or FX options, to price a quote or size a hedge,' which tells the agent the asset classes and the two intents. It also signals the alternative mode ('or give a market price and get the implied volatility') and that no external data source is needed. It stops short of naming when NOT to use it or a sibling alternative, keeping it at 4.

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, openWorldHint=true, and idempotentHint=false. The description adds meaningful behavioral context beyond that: pay-per-call pricing, free failed calls, first 25 free, payment via x402 USDC or card key, and that repeated calls are not free. It still omits rate limits, latency, and data 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?

The description is front-loaded with purpose and output scope, then usage, example, pricing, and safety. The first sentence is long but each listed data category earns its place; minor redundancy exists around read-only behavior and billing.

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-coin research tool with no output schema, the description does a good job enumerating returned data categories and disclosing billing and safety behavior. It would be stronger with explicit sibling alternatives and a hint at response shape or data freshness.

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 single `coin` parameter is already documented as a symbol with a BTC default. The description adds only an example (`coin=ETH`) and the scope of single-coin Hyperliquid research, which is useful but does not substantially deepen parameter semantics.

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: research a single Hyperliquid-traded coin. It enumerates the data returned (price, funding, depth, technicals, sentiment), making the purpose clear. However, it does not explicitly name or differentiate itself from sibling tools such as hyperliquid_indicators, pack_crypto_market, or token_report.

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 a clear use case: 'Use before a trade or for a coin brief,' and provides an example call (coin=ETH). It does not state when not to use it or name alternatives for narrower tasks, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint/destructiveHint=false and openWorldHint=true, and the description adds material context beyond them: x402 USDC billing at $0.002/call, a card-key (/credits) alternative, first 25 free, failed calls free, and an explicit explanation of why repeats are not free — which is exactly what makes idempotentHint=false intelligible. It also credits the upstream source (alternative.me) for the Fear & Greed data. Rate limits, latency and partial-failure behavior are the remaining gaps.

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 payload inventory is front-loaded in the first clause before pricing and use cases, and every section earns its place. Minor redundancy between "Cheaper than the five tools bought one by one" and the later per-call pricing sentence, and the sentence is long enough that the x402/credits detail runs on.

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-value burden and does so by enumerating each data block the caller gets back, plus the cost model and read-only guarantee. For a composite tool that fans out to several upstreams it is nearly complete; it stops short of saying what happens when one upstream (e.g. fee rates) is unavailable.

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 single parameter already documents the comma-separated format, the three-coin cap and the BTC,ETH,SOL default. The description only restates that with an example ("coins=BTC,ETH,SOL"), so it adds confirmation rather than new meaning — the baseline 3 for a fully described parameter set.

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?

"Market sentiment, prices and signals in one call" is followed by an explicit itemization of the payload: Fear & Greed with 7-day change, the 10 most traded Hyperliquid perpetuals with price/24h change/funding/open interest, RSI/MACD/moving averages for up to three coins, and BTC fee rates. This distinguishes it from single-purpose siblings like crypto_fear_greed, hyperliquid_indicators or btc_fees without the agent needing to open a 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?

It names concrete situations ("daily market brief, a trading agent's context or a dashboard") and states the economic rationale for choosing it over "the five tools bought one by one." What it omits is the inverse rule: if the agent only needs one signal, it should call the individual sibling, which is only weakly implied by the pricing comparison.

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/destructive/openWorld, and the description adds materially beyond them: per-call pricing ($0.03/call, first 25 free, failed calls free) and the explicit warning that repeats are not free, which explains the idempotentHint=false. It also discloses chain-dependent behavior — honeypot and contract risk checks only on Base — and confirms 'changes nothing' for an open-world external call.

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 highest-value clause (what one call returns) and each subsequent sentence covers a distinct need: inputs, when to use, example, cost. The parenthetical risk-check list and the pricing sentence are dense but earn their place; the whole thing runs long for a 2-parameter tool.

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 must describe returns itself — and it does, naming every field class the agent will get back plus the chain-conditional risk block. Combined with cost and safety disclosure, an agent has everything needed to call it correctly and to justify the spend.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the token param accepts either a ticker or a 0x contract address, and the chain param governs which checks run (Base unlocks honeypot/blacklist/owner-fee analysis). It omits the 'base is default' detail the schema carries, which is why it isn't 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?

Starts with a specific verb+resource ("One call to analyse an ERC-20 token") and enumerates the exact outputs: metadata, supply, USD price from the deepest Uniswap v3 pool, proxy/upgrade authority, and chain-specific risk checks. This clearly separates it from narrower siblings like price_token, token_supply, and contract_risk without the agent needing to open their schemas.

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

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

Gives an explicit triggering condition: "Use before buying, listing or accepting an unknown token," which tells the agent the decision context. It also specifies the required inputs (ticker or 0x address plus network) and gives a worked example, but never names the sibling alternatives it supersedes, so the routing guidance stops short of a full when-not-what-instead statement.

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

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

Beyond the readOnlyHint=false and openWorldHint annotations, it discloses a full cost model: $0.01 per call via x402 USDC or card key, first 25 free, failed calls free, and repeats are billed, which explains the idempotentHint=false. It also states the tool only reads or computes and changes nothing. That is exactly the billing behavior an agent needs to plan calls.

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: it defines the event concept first, then what is returned, then uses, then pricing. It is dense but nearly every clause adds information. The only redundancy is 'each call is charged, so repeats are not free', which repeats the price sentence.

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 must explain the return contents, and it does: volume, liquidity, end date, tags, open-market count, and leading outcomes by price. It also covers cost and read-only behavior. The only minor gap is whether results are sorted strictly by 24-hour volume when a query is supplied.

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 q, limit, the 1-10 range, and the default 5; the baseline is therefore 3. The description reinforces the default behavior ('without it the busiest events by 24h volume') and gives an example value, but it adds no meaning beyond the schema.

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

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

The description gives a concrete verb and resource: it returns the busiest open Polymarket events by 24-hour volume, or events matching a search, and it explains that an event is one question containing one or several markets. It also lists the fields returned: volume, liquidity, end date, tags, count of open markets, and five leading outcomes. That detail lets an agent tell this tool apart from sibling tools such as polymarket_markets, polymarket_orderbook, and polymarket_price_history.

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 states clear use cases: 'see who leads a multi-candidate market' and 'browse what is being traded now', plus a concrete example (q=president). It does not explicitly say when to use polymarket_markets or polymarket_orderbook instead, so the agent must infer the split between event discovery and market-level detail.

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 and destructiveHint=false, and the description reinforces that with 'Reads or computes only and changes nothing' plus 'each call is charged, so repeats are not free', which corroborates idempotentHint=false. It adds genuinely useful non-annotation context: per-call pricing ($0.01 via x402 USDC or card key), the first 25 free, and that failed calls are free. What it does not cover is pagination or default/limit behavior.

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

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

Purpose and the returned field list are front-loaded, followed by use cases, an example, then pricing. One running paragraph, and the billing sentence is a bit dense, but almost every clause carries 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, the description compensates by enumerating the return fields explicitly. Combined with usage triggers, an example query, read-only semantics and the cost model, an agent has everything needed to decide to call it and 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 q, limit (1-20, default 10) and closed are already fully documented. The description only echoes the q example ('q=bitcoin') and otherwise adds no semantics beyond the schema, 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: lists the most traded open Polymarket markets by 24h volume or markets matching a search, and enumerates the returned fields (outcome prices, best bid/ask, last trade, day change, volume, liquidity, end date, slug, CLOB token ids). This is distinguishable from siblings like polymarket_orderbook and polymarket_price_history 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?

Gives concrete when-to-use triggers ('get the odds on an election, sports, crypto or news event') and a sequencing rule ('find a market before reading its order book'), which implicitly routes to polymarket_orderbook. It does not explicitly say when to prefer polymarket_events or polymarket_price_history instead, so the sibling differentiation 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 already declare readOnlyHint/destructiveHint=false, and the description reinforces it with 'reads or computes only and changes nothing'. Beyond that it discloses the commercial behavior an agent cannot see anywhere else: $0.01/call via x402 or a card key, first 25 free, failed calls free, and that repeats are billed because nothing is cached.

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 call returns, then the input modes, then use cases, then pricing — a sensible order with no filler. The pricing sentence is long and packed with three separate facts in one clause, which slightly slows scanning 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?

There is no output schema, but the description enumerates the returned fields (bids, asks, best bid/ask, mid, spread, depth within 5 cents), the level cap, and the outcome selection rule, so an agent knows what it will get. Payment, safety, and caching behavior are all covered, leaving nothing material for a call decision unstated.

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 four parameters, and this sets the baseline at 3. The description adds only a concrete example slug value and frames slug+outcome as an alternative to token_id, which the schema already states with 'Instead of slug'.

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: bids/asks up to 50 levels, best bid/ask, mid, spread, and USD depth within 5 cents of mid for one market outcome. The contrast with 'the last trade' price hints at the difference from polymarket_price_history, but no sibling is named explicitly, so an agent must infer the boundary.

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 when-to-use contexts — checking liquidity and slippage before a trade, or getting a sharper price than the last trade — and explains the two mutually exclusive input routes (slug+outcome vs token_id). It does not state when to prefer polymarket_price_history or polymarket_markets instead, leaving that routing 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 declare readOnly=true, destructive=false and idempotent=false, so the safety profile is covered; the description adds genuinely non-obvious context: the return shape (time/price points plus first, last, change, high, low), the per-call price ($0.01 via x402 USDC or card key), first 25 free, failed calls free, and the explicit warning that repeats are not free because each call is charged. That last point meaningfully explains the non-idempotent hint. It does not cover rate limits, point density/downsampling, or error behavior for a bad slug.

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 core capability and the required inputs are front-loaded, with the example and pricing pushed to the back where they belong. There is some redundancy — "Price $0.01/call" is restated as "each call is charged, so repeats are not free," and "Reads or computes only and changes nothing" largely echoes readOnlyHint — but both restatements carry a practical instruction effect, so the waste is minor.

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 correctly shoulders the burden of explaining return values, and it also covers the cost model, interval range and the slug-vs-token-id input fork. Missing pieces are edge-case behavior: what happens with an unknown slug, whether long intervals are downsampled, and any cap on returned points.

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 it already documents slug/URL acceptance, outcome defaulting to the first outcome, the interval enum and its 1w default, and that token_id substitutes for slug. The description only adds a real example slug value and restates the slug-or-token-id choice, so it is a modest increment over the schema. Baseline 3 applies when 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?

The description names a specific verb and resource ("Polymarket price history of one market outcome from the CLOB") and immediately scopes it to a single outcome's time-series, which cleanly separates it from sibling tools like polymarket_markets, polymarket_events and polymarket_orderbook (current book, not history). It also enumerates the returned aggregates (first, last, change, high, low), so an agent knows exactly what it gets without opening a 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?

It gives concrete use cases — "chart how the odds moved, spot a swing after news, or backtest a signal" — which is a clear picture of when to reach for it, plus a worked example slug for the slug-based call path. It stops short of explicitly naming alternatives or exclusions (e.g., use polymarket_orderbook for live depth), so routing versus siblings is still 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?

Beyond the annotations it discloses pricing ($0.01/call, free tier of 10 requests, free failures), which usefully explains the non-idempotent hint, and restates that the call is read-only. That is meaningful cost and side-effect information an agent needs for planning; it does not cover result pagination or rate-limiting beyond the flat price.

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?

It front-loads the action and return payload, then moves to use cases and pricing, with almost no wasted wording. The parenthetical keyword list and the multi-clause first sentence make it denser than necessary, but nothing is truly redundant.

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 3-parameter search tool with no output schema, the description covers what comes back, how to use it, what it costs, and that it is non-mutating — everything needed to invoke it correctly and budget for 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 parameters are already fully documented in the schema, including the 1-20 limit range and the closed flag. The description only adds an example query value and the implication that results default to open markets, which is marginal added meaning.

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 — 'Search Polymarket prediction markets by keyword' — and enumerates the returned fields (odds as implied probabilities, bid/ask, volume, liquidity, end date, token ids). The line 'find a market before reading its order book' implicitly separates it from polymarket_orderbook, and the keyword framing distinguishes it from plain listing siblings.

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 names three concrete use cases (look up odds on an event, locate a market before reading the order book, feed a forecasting agent) and gives a worked example (q=bitcoin). It stops short of naming a named alternative for when keyword search is the wrong choice (e.g., browse-all vs search), so no explicit exclusion.

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 read-only/open-world/non-idempotent safety flags; the description adds real operational context: billing per call ($0.002 via x402 or card key, first 25 free, failed calls free), that 404 on no pool is uncharged, that repeats are not free, and the returned fields (pool, fee tier, quote reserve, thin-liquidity flag). It also explains the non-idempotent hint in billing terms rather than contradicting it.

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 dense paragraph that front-loads purpose, then identifiers, chains, method, return shape, errors, usage, and pricing in a sensible order. Slight redundancy between 'Price $0.002/call ... first 25 free; failed calls free' and the closing 'each call is charged, so repeats are not free' costs 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 and no required parameters, the description must carry the burden of what comes back and what can go wrong — and it does, naming the returned pool/fee tier/reserve/liquidity flag and the 404-on-no-pool behavior. It is complete enough for an agent to call this 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 baseline is 3, but the description adds accepted identifier forms beyond the raw schema — coin name and CoinGecko id in addition to ticker and 0x address — plus a concrete invocation example (symbol=ETH). Minor ambiguity: the schema exposes only 'symbol' and 'address', so an agent must infer that coin names and CoinGecko ids go into 'symbol'.

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 ('Token price in USD for a crypto token') plus the exact mechanism and scope: deepest Uniswap v3 pool against USDC or WETH, live read, on Base/Ethereum/Arbitrum/Optimism. That mechanism detail is what separates it from generic siblings like crypto_price, btc_price, price_tokens, or uniswap_pool without opening their schemas.

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

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

'Use to value a token or check a quote before a swap or payment' gives a clear usage context, and 'Spot price, not a time average' rules out a common misuse case. It does not explicitly name a sibling alternative (e.g. when to prefer crypto_price or price_tokens for a batch), so it stops short of full routing guidance.

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

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

Goes well beyond the annotations: names the price source (deepest Uniswap v3 pool against USDC or WETH), states that tokens without a pool land under 'unpriced' instead of failing, and lists returned fields (pool, reserve, thin-liquidity flag). It also discloses cost ($0.002/call, first 25 free, failed calls free) which explains the idempotentHint=false in practical terms — repeats cost 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-loads the headline capability and batch limit, then layers in source, error handling, cost, and the read-only guarantee in a tight sequence. Some density, but no sentence is filler — even the paywall line changes agent behavior.

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 3-param, no-output-schema tool, the description covers everything an agent needs: input formats, chain options, partial-failure semantics ('unpriced'), the shape of returned data, and the billing model. 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 coverage is 100%, so baseline is 3; the description adds a concrete example (symbols=ETH,BTC,AERO), enumerates the supported chains by name, and clarifies that symbols and addresses can be combined within the 20-token total. That is modest but real added 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+resource (USD prices for up to 20 crypto tokens in one call) with scope qualifiers: ticker or ERC-20 address, four chains, deepest Uniswap v3 pool. An agent can distinguish this batch-pricing tool from single-price siblings like price_token or crypto_price from the text alone.

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 names the use case ('value a basket of tokens or refresh a watchlist in one paid call') and the batch limit of 20, which implies when this beats a single-token call. It does not name alternative sibling tools such as price_token or crypto_price, so routing is inferred rather than 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 already declare readOnlyHint=true/openWorldHint=true/destructiveHint=false, and the description adds genuinely new context: explicit pricing ($0.01/call via x402 USDC or card key, first 25 free, failed calls free) and the statement that each call is charged so repeats are not free — which explains the idempotentHint=false annotation. It also clarifies 'reads or computes only and changes nothing.' It does not describe pagination, row caps, or error responses, so it is not 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?

The opening clause front-loads resource and return shape, then use cases, then cost/behavior — a sensible ordering with little filler. The pricing sentence is dense and mixes payment channels, free-tier, and failure policy in one breath, but every element is actionable.

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 3-parameter tool with no output schema, the description covers purpose, use cases, return fields, cost model, and side-effect profile, which is nearly everything an agent needs to invoke it correctly. Gaps are minor: no guidance on symbol ambiguity (company name vs ticker), no note on response size for max-range queries, and no error semantics beyond 'failed calls free.'

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% and both enums document every allowed value including the intraday ~60-day lookback, so the schema carries the parameter semantics. The description restates the axis bounds ('1-minute to monthly bars over 1 day to the full history') and adds an example symbol, but contributes no format details, symbol-resolution rules, or range/interval compatibility guidance beyond 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 — OHLCV price history for any ticker or company name — and enumerates the returned fields (open, high, low, close, adjusted close, volume plus first/last/change/high/low). It is clearly distinguishable from siblings like stock_quote (a point quote) and polymarket_price_history (prediction markets).

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 use cases — chart a stock, backtest a signal, compute returns, feed indicators — plus a worked example (symbol=AAPL), which tells the agent exactly when this tool fits. It stops short of naming the sibling to use instead for a current quote (stock_quote) or for token prices, so routing between near-neighbors is left partly 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 declare readOnly=true, destructive=false, openWorld=true and idempotent=false; the description reinforces the read-only nature ("Reads or computes only and changes nothing"). More importantly it adds cost behavior the annotations cannot convey: $0.01/call, first 25 free, failed calls free, and that repeats are charged — which explains the non-idempotent hint in practical terms. No latency or rate-limit detail, but the billing disclosure is substantive.

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 returned fields and coverage, then usage, then pricing — a sensible order. It is dense and somewhat run-on (the coverage sentence packs four asset classes), but every clause carries information; nothing is filler.

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

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

For a one-parameter tool with no output schema, the description does the work the schema cannot: it enumerates the returned fields, states asset-class coverage, gives an example call, and discloses the billing model. An agent has everything needed to decide to call it and how to 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% and the single parameter already documents accepted formats (AAPL, VOLV-B.ST, ^GSPC, BTC-USD) or a company name. The description's example (symbol=AAPL) and format list largely restate that, adding little new syntax or constraint detail.

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?

Opens with a specific verb and resource ("Stock price and quote for any ticker or company name") and enumerates the returned fields, so the agent knows exactly what it gets back. It also states asset coverage (US/world stocks, ETFs, indices, FX, crypto pairs). It does not name the obvious sibling (stock_history) or explain how it differs from btc_price for crypto pairs, so sibling differentiation is implicit rather than explicit.

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 usage contexts: "price a stock in an agent, check a move, or value a portfolio line", plus a worked example (symbol=AAPL). There are no explicit exclusions or named alternatives, so an agent must infer on its own that stock_history or btc_price might be preferable in some cases.

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 readOnly, openWorld and destructive=false, so the description's job is additive, and it delivers: pricing ($0.01/call, first 25 free, failed calls free) and the explicit note that repeats are not free, which explains the idempotentHint=false in practical terms. It stops short of describing result shape or matching behavior (fuzzy vs exact, ambiguity handling), which matters for a name-based lookup.

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 routing, then the example, then cost. Every element is relevant, though the pricing sentence is dense and could be trimmed since cost is billing rather than selection 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 single-parameter read-only lookup with no output schema, the description covers purpose, sibling routing, returned fields, and cost model. An agent has everything needed to decide to call it and to expect a charged, side-effect-free symbol lookup.

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 schema already documents q with an example, so the baseline is 3. The description adds only a slight amount beyond it — extending eligible entity types to include crypto and providing the same q=volvo example — without clarifying match semantics or partial-name behavior.

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 the ticker symbol') plus the accepted entity types (company, fund, index, crypto) and the fields returned (exchange, type, sector, industry). It explicitly positions itself against the siblings stock_quote and stock_history, so an agent can separate them 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?

Gives a clear trigger condition — 'use before /stock/quote or /stock/history when you only have a company name' — and a second distinct use case, finding a company's listings across several exchanges. The alternative tools are named rather than 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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=false; the description reinforces that nothing is signed or sent and explains the non-idempotent flag's practical meaning (every call is billed, failures are free, first 25 free, $0.01/call via x402). That cost/rate-limit disclosure is real added value beyond structured fields. It does not cover latency, quote expiry, or rate limiting under load, keeping it below 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?

Front-loaded with the core value proposition and output list, then usage, then pricing; nothing is padding. The single dense sentence with semicolon-chained clauses and the trailing pricing/redisclosure of read-only behavior make it slightly harder to scan than it needs to be, but it stays proportionate to the tool's surface.

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 compensates by enumerating return fields, and it also covers safety (quote-only), cost, and the fromAddress transaction behavior. For a 7-parameter financial quote tool an agent has everything needed to decide to call it and to interpret 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?

With schema coverage at 100% the baseline is 3, but the description adds semantics the schema does not: 'Tokens by symbol or address,' 'amounts in token units,' and crucially that fromAddress makes the response include an unsigned transaction for the wallet to sign. A concrete example (fromChain=base, fromToken=USDC, amount=1000, toToken=ETH) further anchors the required params.

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

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

States a specific verb and resource (best-price swap quote across 30+ chains via LI.FI) and enumerates concrete outputs (amount out, min after slippage, gas/fees, route, approval address). It is readily distinguishable from the sibling bridge_quote by framing itself as a same-pair swap price, and the parenthetical chain list plus a worked example remove ambiguity.

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 usage context: 'Use before a trading agent swaps' and 'A quote only: nothing is signed or sent,' which tells the agent this is a pre-trade read step. It does not explicitly name an alternative or exclusion (e.g. use bridge_quote when moving a token across chains), so it stops short of full when/when-not routing.

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, destructiveHint=false and openWorldHint, and the description is consistent, adding that it 'reads or computes only and changes nothing'. It contributes genuinely new behavior beyond annotations: the x402/card pricing model, first 25 calls free, failed calls free, and the note that repeated calls are charged — which explains the idempotentHint=false flag. Missing only return-shape or latency/liveness caveats, largely covered by the field enumeration.

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 chain restriction, then the returned fields, then usage, then pricing — a sensible order for an agent scanning it. It is dense but each sentence carries information; the field enumeration is slightly list-heavy but justified since no output schema exists.

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

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

With no output schema, the description fully compensates by enumerating every returned field and the risk heuristics, including proxy implementation/admin details. Cost and free-tier behavior are also stated, so an agent knows both what it gets and what it costs before calling.

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% for the single 'address' parameter, so the schema already carries the meaning. The description adds value beyond it with a concrete worked example address and the Base-only constraint, clarifying that the address must be a Base contract, though it does not state what happens for a non-contract or wrong-chain address.

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 ('Live on-chain facts for an ERC-20 token on Base') and enumerates the exact fields returned: name, symbol, decimals, supply, owner, renounced/paused state, proxy detection with implementation and admin, and bytecode heuristics. It also disambiguates from other chains by naming the '<chain>_token_info' pattern, so an agent can separate it from token_report or token_supply.

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 'for token due diligence and rug-pull or honeypot screening before a swap', giving a clear trigger context, and routes other chains to the '<chain>_token_info' alternative. It does not explain when to prefer sibling tools like contract_risk, token_report or pack_token_analysis, so the differentiation against same-chain siblings 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 already declare read-only, non-destructive, non-idempotent, open-world, and the description goes well beyond: contracts are excluded, plain wallet-to-wallet transfers only count in netAll, per-call billing with the first 25 free and failed calls free (which explains why repeats aren't free despite being a read), and default chain/blocks behavior.

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 question it answers, then scoping, then usage, then pricing. It is dense but nearly every clause carries information; 'reads or computes only and changes nothing' partly restates readOnlyHint, which is the only real redundancy.

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 returned fields (bought, sold, net, transfers) and the netAll nuance, plus cost and chain defaults. Nothing an agent needs to call this correctly and interpret the result 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 still adds interpretation by stating Base is the default chain and that the default 1800 blocks is roughly an hour on Base versus six hours on Ethereum, plus an address example. It doesn't clarify what limit means for ordering or whether netAll is a field versus a mode.

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+resource: the wallets that bought or sold an ERC-20 from DEX pools/routers over recent blocks, with the chains covered and the metrics returned. It is clearly distinct from siblings like wallet_audit (single wallet) or token_report (token fundamentals), so an agent can route without opening schemas.

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

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

Gives a concrete when-to-use rule: 'Use to see who accumulates or dumps a token before you trade it.' It does not explicitly name an alternative tool or state when not to use it, so it stops short of full routing guidance.

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

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

Goes well beyond the annotations: discloses the pricing model ($0.002/call via x402 USDC or card key, first 25 free, failed calls free), warns that repeats are not free (explaining the practical effect of idempotentHint=false), and names returned fields (pool, fee tier, reserve, thin-liquidity flag). It also reiterates the safety profile consistently with readOnlyHint/destructiveHint.

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 resource and scope, then usage, then cost. Dense and mostly waste-free, though the first sentence is an overlong run-on carrying chains, sources and return fields at once.

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 usefully enumerates returned fields, the supported chains, defaults (implicitly via schema), and the billing model, which is what an agent needs before paying per call. Minor gaps: behavior for unsupported symbols or a missing/ambiguous symbol-vs-address combination are not described.

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 chain/symbol/address are already documented, including the note that ETH and BTC mean wrapped tokens. The description adds little beyond restating accepted inputs, and its mention of 'coin name' alongside 'symbol' is slightly looser than the schema, which describes symbol as a ticker. 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+resource (USD token price) and precise scope: symbol/coin name/ERC-20 address across base, eth, arb, op, sourced from the deepest Uniswap v3 pool. This is far more specific than the name alone. It does not, however, distinguish itself from very close siblings such as price_token, price_tokens, btc_price and token, which an agent could easily confuse it with.

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 ('for a quote, a portfolio valuation or a trade check') plus a concrete example (symbol=ETH). It offers no exclusions and never names an alternative, which is a real gap given siblings like price_token/price_tokens/btc_price that appear to overlap.

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

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

Beyond the readOnly/idempotent annotations, the description discloses the heuristic nature ('not a safety guarantee'), the billing model ($0.01/call, first 25 free, failed calls free), and warns that repeats are not free — behavior an agent cannot derive from annotations. Nothing contradicts the declared readOnlyHint.

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 verdict and red-flag taxonomy are front-loaded, which is the right ordering. It is dense but nearly every clause carries information; the only waste is mild repetition of 'before swapping into a Base token,' stated both early and late.

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 full burden and does so: it specifies the verdict tiers, enumerates the red-flag categories, and names the market fields returned (price, liquidity, volume, FDV). An agent knows both what it gets and how much it costs before calling.

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% for the single address parameter, and the description reinforces that the address must be a Base token contract with a worked example (0x4200...0006). It adds small value over the schema's 'Token contract address on Base (0x...)' but nothing about address normalization or non-token addresses.

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 and resource — 'Check a Base token before you swap into it' — and enumerates the exact output (risk verdict plus named red flags and live DexScreener metrics). This clearly distinguishes it from siblings like token_info, contract_risk, or price_token, which each cover only part of the picture.

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 states the trigger condition explicitly ('Use before swapping into an unfamiliar Base token') and supplies a concrete example address. It doesn't name which sibling to use instead for plain metadata or price-only lookups, so an agent must infer the boundary against token_info/price_token, keeping it short of a 5.

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

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

Annotations already declare readOnly/destructive/openWorld, so the safety profile is covered; the description still adds real value by disclosing the cost model ($0.01/call via x402 or card key, first 25 free, failed calls free, repeats are not free), which explains why idempotentHint is false. It also states data is read live from the contract. It does not cover rate limits or what happens for an unrecognized ticker.

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 front-loaded sentences with no filler: scope/returns first, then inputs and use case, then cost and safety. It is dense but each sentence carries distinct information; the 'Example: token=USDC' fragment is the only near-redundant piece.

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 read-only tool with no output schema, the description covers inputs (address or ticker, chain choices), return contents, cost implications and side-effect profile. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the chain enum-like list is documented there, so the baseline is 3. The description adds meaning by naming accepted ticker forms (USDC, USDT, WETH, DAI…) and giving a concrete call example, which reduces malformed input more than the schema alone would.

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 (total supply of any ERC-20), enumerates the supported chains, and lists exactly what is returned (raw and decimal-adjusted supply, decimals, name, symbol). An agent can distinguish this from price/token-info 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?

Gives explicit when-to-use framing: 'Use to check a token's circulating maximum or compare supply across chains,' plus an input example. It does not name a when-not-to-use case or point at alternatives such as token_info, price_token or stablecoin_supply, which would be needed for a 5.

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

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

Annotations already declare readOnly/openWorld/non-idempotent, and the description reinforces and enriches them: 'Reads or computes only and changes nothing' corroborates readOnlyHint, while 'each call is charged, so repeats are not free' plus 'first 25 free; failed calls free' explains why idempotentHint is false. It also discloses the pricing mechanism (x402 USDC or card key), which no annotation covers, and states the return shape (rating, reasons, AI summary) despite 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?

Dense but front-loaded: what it does, what it returns, which chains, when to use it, and the billing model, in that order. Every clause carries information an agent needs, including the 'not investment advice' disclaimer and the example address, with no filler.

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

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

With no output schema, the description steps in to describe the return values (rating tiers, reasons, AI summary) and the caveats that matter before calling (cost per call, free tier, Base-only flags). The only real gap is the absence of a boundary against the overlapping siblings contract_risk and token_report.

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 both parameters are already documented; the description adds genuine meaning on top: the chain default, the expanded network names, and the important constraint that risk flags are Base-only, which changes how an agent should interpret a non-Base result. The token parameter only gets an example address, adding little beyond the schema's ticker-or-address note.

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+resource (rug check on an ERC-20 token) and enumerates the artifact: a rating from fixed rules over honeypot/contract flags, liquidity, upgradeable proxy, and last-hour DEX buys/sells, plus reasons and an AI summary. It is distinguishable from generic siblings like price_token or token_supply, but it never explicitly contrasts itself with the close neighbors contract_risk, token_report or pack_token_analysis, so an agent still has to infer the boundary.

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 a concrete trigger ('Use before buying or accepting an unknown token') and a scoping caveat that risk flags exist on Base only, which steers chain selection. It stops short of naming an alternative or saying when NOT to use it (e.g. for tokens with deep liquidity or for held positions), so there is no explicit routing to a sibling.

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

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

Beyond the annotations (readOnlyHint, destructiveHint, openWorldHint, idempotentHint), the description discloses the pricing model ($0.01/call, first 25 free, failed calls free), that repeated calls are charged, what the tool does not do (buy/sell recommendations, calibrated confidence, holder concentration), and the limitation of account nonce. This provides substantial behavioral context for a paid, composable read tool.

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

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

The description is front-loaded with the composition and return behavior, then moves to limitations and pricing. It is appropriately sized for the tool's complexity, though 'Reads or computes only and changes nothing' partially repeats the readOnlyHint annotation, and the pricing sentence is slightly verbose. No sentence is wasted, but minor tightening is possible.

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 needs to convey what is returned, and it does: a combination of risk tiers, flags, market data, nonce, and balance. It also covers key limitations and cost. It stops short of describing the output structure (e.g., field names or grouping), which would be helpful, but an agent can still understand what to expect from the 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%: the input schema already documents both 'token' and 'wallet' as 0x-prefixed 20-byte hex addresses on Base. The description mentions 'Base token-report' and 'wallet-audit' but adds no new parameter-level semantics. With the schema doing full documentation, a baseline of 3 is appropriate.

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

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

The description specifies exactly what the tool combines: Base token-report risk tier and flags, DEX market data, and wallet-audit risk tier, flags, nonce, and balance. It clearly states it returns these indicators separately and does not generate recommendations. However, it does not explicitly say how it differs from calling the sibling tools token_report and wallet_audit individually, so sibling differentiation is implied 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?

It gives a clear usage context: 'Use as one input before a Base trade.' It also clarifies that it is not a standalone decision-maker. Yet it does not name explicit alternatives (e.g., 'use token_report for token-only risk') or state when not to use it, so the guidance is contextual but not exhaustive.

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, openWorldHint=true, and idempotentHint=false. The description adds important context beyond those annotations: pricing, first 25 free, failed calls free, repeats not free, read/compute-only behavior, and scope limitations around token contracts and address type. Nothing contradicts 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?

The description is front-loaded with what the tool does and is generally efficient. It includes useful routing, limitations, example, and pricing details, though it is somewhat dense and has minor repetition around screening and call charging.

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 still explains the return contents sufficiently: risk tier, named flags, balances, nonce, and separate address type. It also covers scope limits, alternatives, and billing behavior. An agent has enough information 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?

There is one required parameter, and schema description coverage is 100%, so the schema already documents the address format. The description adds an example address and clarifies Base chain screening scope, but it does not materially expand parameter semantics beyond 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?

The description states a specific verb and resource: screen a Base address for fresh/throwaway-wallet signals, returning a risk tier, named flags, balances, and nonce. It also distinguishes scope from check_counterparty and clarifies that token contracts are not audited, so an agent can differentiate it from sibling wallet tools.

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

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

It explicitly says to use this for screening a Base address, names check_counterparty for OFAC and other chains, and gives a concrete address example. It also states limitations: address type does not affect tier and token contracts are not audited. This is strong when-to-use and alternative guidance.

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

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

Beyond the annotations (readOnly, openWorld, destructive=false), the description discloses the pricing source (deepest Uniswap v3 pool), that reads are live from the chain, that unpriceable assets are returned rather than silently dropped, and a full cost model ($0.005/call, 25 free, failed calls free, every call charged). The per-call charge also explains the idempotentHint=false in practical terms.

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

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

Purpose and scope are front-loaded in the first sentence, and the exclusion and usage guidance follow. The closing pricing/billing sentence is long and carries some duplication ('charged, so repeats are not free'), but the cost information does affect agent behavior, so it largely 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?

There is no output schema, so the description carries the return contract itself: holdings, a total, and anything that could not be priced. Combined with chain coverage, token limits, pricing source and cost model, an agent has everything needed to call it 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 the parameters and their defaults are already documented; the description adds a realistic example address illustrating the expected format and restates chain coverage and the 20-token cap, which is partly redundant with the schema. Baseline-plus-example is the right level here.

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

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

The description names a specific verb+resource (USD value of a wallet) and pins down scope precisely: four chains, native ETH plus named major tokens, up to 20 user-supplied tokens, priced from Uniswap v3. It explicitly rules out being a full token inventory, which separates it from siblings like wallet_audit, token_report and price_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?

It states the concrete decision context ('Use to check what a wallet is worth before trading, lending or paying') and a negative bound ('Not a full token inventory'), which tells the agent when this tool is the wrong choice. It does not, however, name the alternative tool to use for a full inventory, so the routing is implied rather than explicit.

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