Agent Data Tools: Prices and DeFi

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

Explicitly reconciles the unusual annotation set: 'Reads or computes only; not marked read-only because each call is charged.' This explains why readOnlyHint=false and idempotentHint=false despite no mutation, which no annotation could convey. It also discloses the billing model ($0.002/call via x402 USDC or card key, first 25 free, failed calls free), which materially affects agent 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?

Four tight sentences ordered purpose -> use cases -> cost/auth -> behavioral note, with the core value proposition front-loaded. Slightly dense with billing detail, but every sentence carries information an agent needs (especially the cost and free-call terms).

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

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

With no output schema and no parameters, the description carries the full burden and delivers: it enumerates the returned currencies, the sats-per-dollar figure, the timestamp, the averaging method, the cost, and the read-only-but-billed nuance. An agent can call it correctly with no further 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. It uses the space instead to document return contents (sats per USD, time of price), which is useful since no output schema exists.

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

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

States a precise verb+resource: the current BTC spot price in seven named fiat currencies, averaged across major exchanges, plus sats-per-USD and a timestamp. The BTC/fiat-currency scope implicitly separates it from the generic price_token/price_tokens siblings without the agent needing to open 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 three concrete use cases: converting between sats and fiat, valuing a Bitcoin or Lightning payment, and checking the price before a trade. That is clear context for when to reach for this tool, though it names no alternative or exclusion (e.g. when price_tokens would be the better pick).

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?

It discloses a lot beyond the annotations: missing property reads return null, RPC failures return 502, EOAs return not-applicable, empty slots do not prove an uninitialized proxy, and ownership renunciation requires a confirmed zero owner. It even resolves the apparent annotation oddity by explaining "not marked read-only because each call is charged," which directly reconciles readOnlyHint=false with a non-mutating operation.

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 capability, then limitations, then usage, pricing, and the read-only caveat. Every sentence carries information, though the final cluster (example, price, credit key, failed-call policy) is dense and slightly crowded for a single description block.

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

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

With no output schema, the description supplies the return-value semantics itself (null, 502, not-applicable) plus pricing and auth mechanics (x402 USDC, card key, free tier). Nothing an agent needs to call this correctly or interpret its results 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% for the single address parameter, so the schema already carries the format contract. The description only adds a concrete example address, which is illustrative rather than adding semantic meaning 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?

The opening sentence names the concrete resources analyzed (Base contract bytecode, EIP-1967 proxy slot, zero-supply) and the method (heuristics), which clearly separates it from audit-style siblings like wallet_audit and liquidity_pool_audit. An agent can tell this is a contract-level risk heuristic read 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?

"Use before approving or calling an unfamiliar Base contract" gives a concrete trigger, and "Not a full security audit; see endpoint details for coverage limits" draws an explicit boundary on when not to rely on it. No alternative sibling is named by name, 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?

Goes well beyond the annotations by disclosing pricing ($0.002/call via x402 USDC or card key, first 25 free, failed calls free) and pre-empting the readOnlyHint=false confusion by explaining that reads are charged per call. This is exactly the kind of non-obvious behavioral context the annotations alone could not convey.

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

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

Front-loaded with the resource and the input/output contract, then pricing and the example. Every sentence carries information, though the pricing and 'not marked read-only because' clause add some verbosity; still well organized.

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 present, the description supplies the return contract ('the rates, the converted amounts and the date the rates apply to'). Combined with the pricing/auth disclosure and the example, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value on top: the worked example demonstrates the comma-separated multi-target format, the defaults (all currencies, amount 1), and the relationship between base and target codes beyond what the schema states.

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

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

States a specific verb and resource: fetches ECB foreign exchange rates and performs conversion. The scope (about 30 major currencies, base + optional targets + amount) is precise and clearly distinguishes it from siblings like btc_price or price_token, which price crypto assets rather than fiat FX.

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 use cases (currency conversion, invoice and price calculations, reporting in another currency) and gives a concrete invocation example. It lacks an explicit when-not or a named alternative for overlap cases, but the context of use is unambiguous.

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 null handling for missing fields, 404 for unknown pairs, 502 on upstream failure, source and retrieval timestamp, and per-call billing (first 25 free, failed calls free). It even explains why readOnlyHint is false despite the operation being a pure read — resolving what would otherwise look like an inconsistency.

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 capability, then returns, then errors, then pricing; each sentence carries information. It is dense and pricing/example clauses lengthen it somewhat, but nothing is redundant 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 still covers the return shape (fields, nulls, source, retrieval time) and failure modes (404/502), which is exactly what an agent needs. Pricing and idempotency caveats are also addressed, leaving no material gap for a single-parameter 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?

Only one parameter and schema coverage is 100%, so the schema already documents the 0x-prefixed 20-byte hex address. The description supplies an illustrative example value, which is mildly useful, but adds no format or validation detail beyond the schema — 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 — Base DEX pair lookup via DexScreener — and enumerates the returned data (pair identity, tokens, liquidity, volume, trades, pair age). The explicit 'No pool-security or investment-risk assessment' boundary cleanly separates it from contract_risk and the token_* 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?

Gives a direct usage context: 'Use to check a pair's liquidity before trading,' and rules out risk/security use cases. It stops short of naming a specific alternative sibling (e.g., contract_risk) for the excluded scope, so routing is clear but not fully explicit.

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 cost ($0.04/call via x402 USDC or card key, first 25 free, failed calls free), the HTTP 400-without-charge behavior for invalid values, that gas units are fixed typical assumptions rather than per-transaction estimates, and explicitly reconciles readOnlyHint=false ('not marked read-only because each call is charged'). This is exactly the kind of context structured fields cannot convey.

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

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

Front-loaded with the core purpose and scope caveat, then exclusions, then cost. It is dense and slightly list-like, but every clause (assumptions, valid values, 400 behavior, pricing, annotation rationale) earns its place. Minor tightening 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 should ideally hint at the return shape; it says only that it 'estimates' gas costs. However it fully covers pricing, failure modes, input validity, and scope exclusions, so an agent has what it needs to decide to call it, just not to anticipate the response format.

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 is self-documenting, so the baseline is 3; the description adds real meaning by explaining what each preset does ('high-mev (3x priority fee)', 'low-gas (half)'), which the schema does not. It does not state the resolved priority-fee formula or units, keeping it from a 5.

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

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

States a specific verb and resource ('Estimates Base gas costs from current fees and priority-fee presets') and immediately clarifies the scope limiter: it is not a transaction simulator nor an MEV/sandwich-risk tool, which is important given the misleading name 'mev_simulator'. An agent can distinguish it from all siblings (price/audit/report tools) 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 an explicit use case ('Use to budget gas for a Base transaction') plus a concrete example (scenario=standard), and states the negative boundary (no transaction simulation or mempool observation). It does not name an alternative tool to route to instead, but no sibling overlaps meaningfully, so context is clear.

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

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

Exceptionally rich: it enumerates the return payload (pool, fee tier, quote-token reserve, thin-liquidity flag), clarifies the price is spot rather than a time average, states that a missing pool yields 404 with no charge, and documents pricing ($0.002/call, first 25 free, failed calls free). It even justifies the counterintuitive readOnlyHint=false annotation by explaining the per-call charge, which is exactly the contextual disclosure annotations can't carry.

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

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

Front-loads the core purpose and stays dense, but the billing and 404 clauses make it a long single block that packs several unrelated concerns together. Every sentence does carry information, though, so nothing is truly wasted.

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

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

With no output schema, the description fully compensates by describing the return fields (pool, fee tier, reserve, thin-liquidity flag), the failure mode (404), and the cost model. An agent has everything needed 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; the description goes slightly beyond by supplying a real worked example (address + chain=base) that demonstrates format and default behavior. The chain enum values themselves are already in the schema, so the gain is incremental rather than substantial.

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 price of any ERC-20 token) plus the exact computation source (deepest Uniswap v3 pool against USDC/WETH) and the supported chains. That precision separates it from btc_price (BTC only) and price_tokens (plural/batch) without 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 usage contexts: 'Use to value a token or check a quote before a swap or payment,' plus a fully worked example call. It does not explicitly say when to prefer price_tokens or token_report instead, so it lacks the exclusion clause that would earn 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 the annotations: it explains the deepest-pool/USDC-WETH pricing method, spot-not-TWAP semantics, the unpriced fallback instead of call failure, the exact cost ($0.005/call, first 25 free, failed calls free), and explicitly justifies why readOnlyHint=false despite being a pure read ('not marked read-only because each call is charged'). That last point resolves an otherwise confusing annotation.

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 and sourcing first, then fallback behavior, then pricing and usage. Every clause carries information, though the payment/credits sentence is long enough that it slightly crowds the core purpose.

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

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

No output schema exists, yet the description names the returned fields (pool, reserve, thin-liquidity flag, unpriced bucket) so the agent knows the response shape. Combined with pricing, chain and failure semantics, 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it maps the abbreviated enum values to full network names (Base, Ethereum, Arbitrum, Optimism) and reinforces the 1-20 address limit and that addresses are ERC-20 contracts.

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 with scope: USD prices for up to 20 ERC-20 tokens across four named chains, sourced from the deepest Uniswap v3 pool. The batch-of-20 framing and named chains distinguish it clearly from the singular sibling price_token without needing 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?

Explicitly says 'Use to value a basket of tokens or refresh a watchlist in one paid call', which tells the agent when this batch tool is the right pick. It never names price_token as the single-token alternative or states an exclusion, so it stops just 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?

Explicitly reconciles the non-obvious readOnlyHint=false annotation: 'Reads or computes only; not marked read-only because each call is charged.' It also discloses the payment model (x402 USDC or card key, first 25 free, failed calls free), which the annotations do not carry. It does not address idempotency or rate limits beyond the free tier, so not a full 5.

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

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

Front-loads purpose, then usage, then example, then pricing — a sensible ordering. The paragraph is dense but each clause carries information; the pricing detail is the only part bordering on extraneous for tool selection.

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, enumerating every field the agent will receive. Combined with the auth/payment disclosure and the worked address example, 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?

Only one parameter with 100% schema description coverage, so the schema already defines it. The description adds a concrete worked example address confirming the expected 0x format, which is marginal added value over 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 specific resource (ERC-20 token facts on Base) and enumerates the exact outputs: name, symbol, decimals, supply, owner/renunciation, paused state, proxy detection, and bytecode heuristics. That precision lets an agent distinguish it from price-oriented siblings like price_token, though it never explicitly names an alternative to disambiguate it from contract_risk 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?

Gives a clear trigger: 'Use for token due diligence and rug-pull or honeypot screening before a swap.' That is actionable context, but there is no explicit when-not guidance and no named sibling to route to when the agent wants a price rather than risk flags, 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?

Goes well beyond the annotations: discloses the pricing model (x402 USDC or card key, first 25 free, failed calls free) and explicitly reconciles the readOnlyHint=false flag by explaining each call is charged. It also warns about evidentiary limits (a mint selector does not prove callable minting, missing evidence stays unknown, examples are not live quotes, not a safety guarantee) – exactly the caveats an agent needs before trusting 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?

Purpose and the key caveats are front-loaded, and the pricing/commercial details are pushed to the end where they belong. It is dense with caveats and slightly overstuffed, but nearly every clause (free-call policy, non-guarantee, example) earns its place.

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

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

With a single fully-documented parameter and no output schema, the description supplies what is missing: interpretive limits on the returned facts, a usage trigger, pricing/billing behavior, a sample invocation, and a pointer to endpoint details for coverage limits. Nothing an agent needs to call and correctly interpret the tool is absent.

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?

One parameter with 100% schema coverage, so the schema already carries the meaning; per the baseline rule this is a 3. The description contributes only an illustrative example address (0x4200...0006), which adds marginal value and is itself hedged as non-live.

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: heuristic screening of a Base token plus DexScreener market data, enumerating returned facts (owner, paused, proxy, selector checks). It is clear what the tool produces, but it never names or contrasts with the many close siblings (contract_risk, token, price_token, liquidity_pool_audit), so an agent must infer which report 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?

"Use before swapping into an unfamiliar Base token" gives a clear triggering context, and the description scopes itself to Base tokens only. It stops short of exclusion guidance or naming a cheaper/lighter alternative such as price_token or contract_risk when the full report is unnecessary.

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 material context beyond the annotations: it explains the pricing model ($0.05/call via x402 USDC or card key, first 25 free, failed calls free), the failure semantics, and — crucially — why readOnlyHint=false despite read/compute-only behavior (each call is charged). That directly resolves the most confusing annotation signal an agent would see.

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 composition and return contents, then limits, then pricing. Dense but each clause carries signal; the final sentence slightly restates the read-only point already implied by the prior sentence, a minor overlap rather than waste.

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 only two simple parameters, the description adequately previews what comes back (risk tiers, flags, market data, nonce, native balance) and bounds what it does not cover. An agent has everything needed to decide and invoke 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 both parameters are already documented as 0x-prefixed 20-byte Base addresses. The description adds no format, constraint, or validation detail beyond the schema, which lands this at the baseline for a fully-documented 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: it combines Base token-report risk tier/flags, DEX market data, and wallet-audit risk tier/flags/nonce/native balance into one sourced indicator set. This aggregation is distinguishable from the sibling token_report, wallet_audit, and contract_risk tools, and the itemized return contents make the scope 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?

"Use as one input before a Base trade" gives clear context, and the explicit exclusions (no buy/sell recommendations, no calibrated confidence, no holder concentration) tell the agent what this tool will not answer. It stops short of naming which sibling to prefer for those excluded needs, but the boundary is clear.

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

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

Goes well beyond annotations: explains the non-standard readOnlyHint=false ('each call is charged'), discloses pricing/billing behavior (x402 USDC, card key, first 25 free, failed calls free), and clarifies interpretive caveats like nonce semantics for EOAs and that token contracts aren't audited. This is exactly the behavioral context an agent needs.

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 return payload, then caveats, usage, example, and pricing. Dense and mostly waste-free, though the pricing and example sentences make it longer than the core purpose requires.

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

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

No output schema exists, yet the description enumerates the returned fields and flags the interpretive limits (unknown per-token risk, EOA nonce scope). Nothing essential to 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% and documents the address format, so the baseline is 3; the description adds a concrete example address that reinforces the 0x 20-byte hex format and Base-chain scoping. Meaningful but modest value-add.

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

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

Specific verb ('Returns') plus an enumerated resource set: risk tier, named flags, ETH balance, four named tokens, and Base account nonce. This is clearly distinguishable from siblings like wallet_portfolio (balances) and contract_risk/token_report (contract-level risk).

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 use case ('screen an address before paying it') and scopes the tool to Base. No explicit when-not or named alternative (e.g. wallet_portfolio), so it stops short of a 5, but the intended context is clear.

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

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

Goes well beyond the annotations: it explains the unusual readOnlyHint=false ('not marked read-only because each call is charged'), discloses the pricing model ($0.005/call, first 25 free, failed calls free, x402 USDC or card key), and describes the computation ('read live from the chain', 'priced from its deepest Uniswap v3 pool'). It also states failure behavior by noting unpriceable tokens are returned.

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 its scope before pricing and caveats. Dense but largely waste-free, though the pricing clause runs long and the semicolon-chained sentences could be tightened without losing information.

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

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

With no output schema, the description carries the return burden and does: 'Returns holdings, total and anything that could not be priced.' Chain coverage, default token set, cost model, and the read-only rationale are all present, leaving no material gap for correct invocation.

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 semantics: it names which tokens are included by default (native ETH, USDC and WETH on all chains, common Base tokens on Base) and restates the up-to-20 extra-token cap. The chain parameter's meaning is left to the schema's enum, which is already sufficient.

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 metric ('USD value of a wallet') with the supported chains enumerated inline, and explicitly bounds the scope with 'Not a full token inventory,' which separates it from inventory-style siblings like wallet_audit or token_report. An agent can tell what it produces and what it does not.

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 context: 'Use to check what a wallet is worth before trading, lending or paying.' It also implies a negative case via 'Not a full token inventory,' but it never names an alternative tool (e.g. wallet_audit for full holdings) or states when to prefer a different pricing tool, so routing is clear but not fully closed.

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