Fivebar Trading

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

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond them by explaining score mechanics (bundled buyer wallets counted once, wash-pattern removals, 'not scored yet' with progress, never a 0). It stops short of disclosing failure behavior for an unknown identifier or any latency/rate characteristics of the chain 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?

It is a single front-loaded sentence with no filler, leading with verb and resource before the payload details. The cost is density: three stacked parentheticals make it hard to skim, though each clause does carry real 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 must carry the return-value burden, and it names every returned field class (owner/agent wallet, Fivebar Score with buyer and seller semantics, x402 screen states, flags, clusters). An agent needs nothing else to decide whether the response answers its question.

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 carries an example, so the schema does the heavy lifting. The description adds value by enumerating that the query may be an ERC-8004 ID, a wallet address, or a name, which clarifies the union-type acceptance more broadly than the schema's one example.

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 (look up) and resource (AI agent on Robinhood Chain) plus the three accepted identifiers (ERC-8004 ID, wallet address, name). The returned artifact set (owner, agent wallet, Fivebar Score, x402 record, flags, clusters) makes it unmistakable next to siblings like wallet_holdings or x402_stats.

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 paying or trusting an agent" gives a clear triggering situation rather than leaving usage implicit. It does not, however, say when NOT to use it or how it relates to the overlapping sibling check_seller, so an agent must still infer the split between the two.

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 openWorldHint=true, so the safety profile is covered. The description adds real value beyond that by naming the data source (Fivebar's wash screen) and the specific signals returned – 24h payment pass status, buyers, volume, and conditional agent record – which tells the agent this is a reputational screen, not a balance lookup. Return shape and latency are not described.

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 sentence, zero filler, with the use-case trigger placed first and the returned signals following. Every clause carries information the 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?

No output schema exists, so the description must convey what comes back – and it does, listing the pass status, buyer/volume metrics, and agent record. What's missing is how to interpret an absent/failed screen result and the address format expected, which matters for a one-parameter decision 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 0% for the single required 'address' parameter. The description partially compensates by framing it as the seller's address to be screened, but it never states expected format (hex address vs ENS-style name), which chain, or whether it must be a seller that has already transacted.

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) and resource (an x402 seller's address on Robinhood Chain) and enumerates what is inspected: 24h payment pass status, buyers, volume, agent record. That scoping separates it from generic siblings like token_risk or wallet_holdings, though it does not explicitly say how it differs from agent_lookup despite overlapping on 'agent record'.

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?

The trigger is explicit and front-loaded: 'Before paying an x402 seller on Robinhood Chain.' That tells the agent exactly when to reach for it. It stops short of naming alternatives or stating when-not-to-use (e.g., for non-x402 addresses or plain token risk).

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds genuine behavioral context by disclosing the data source and the fallback path, which tells the agent prices may come from a DEX pool when the oracle is down. It stops short of saying whether freshness/staleness or precision is reported.

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

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

A single sentence that front-loads the answer (ETH price in USD) and folds the source and fallback into a parenthetical. Nothing is redundant and nothing needs re-reading.

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 parameterless read tool this covers the essentials: what is returned (USD price), from where, and what happens on fallback. The only gap is that with no output schema, the exact return shape (scalar vs object with source/timestamp) is left unstated, though the source ambiguity makes that slightly more relevant here.

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; baseline 4 applies. The description correctly implies a fixed, argument-free call.

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-like outcome (get ETH price) plus the unit (USD) and the chain/source (Robinhood Chain, Chainlink feed with WETH/USDG pool fallback). An agent can distinguish this from token_quote or stock_quote on the basis of the resource named.

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?

No statement of when to prefer this over siblings like token_quote, which plausibly also returns an ETH price, nor any exclusion or precondition. The agent must infer that this is the canonical spot-price call for ETH on Robinhood Chain.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by naming the returned data points (mark, oracle, funding, OI, volume, max leverage), but says nothing about behavior for an unknown/non-listed coin (error vs empty) or 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?

One dense sentence, front-loaded with what the tool returns for which key, and the field list is exactly the information an agent needs. 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 carries the return-shape burden and does so by enumerating fields. The remaining gap is edge-case behavior (unknown coin, stale quotes) and no pointer to the sibling listing tool.

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

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

Schema coverage is 0% — the single 'coin' parameter has no description or format constraint — so the description must compensate. It does so usefully with concrete examples (BTC, ETH, HYPE), disambiguating the bare symbol from a pair like 'BTC-PERP' or an asset index.

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+scope: a single Hyperliquid perpetual market looked up by coin, and enumerates the fields returned. The plural sibling perps_markets is implicitly contrasted by 'One ... market by coin', but it is never named, so the differentiation is inferential 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?

Usage is only implied: an agent can infer this is for single-market lookup versus the listing tool, but there is no explicit 'use this when' or 'use perps_markets instead when'. No prerequisites or exclusions are stated.

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

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

With readOnlyHint=true and openWorldHint=true already declaring a safe, live-data read, the description's main added value is the field inventory (mark price, funding yearly, max leverage), which substitutes for the absent output schema. It does not mention latency, refresh cadence, or whether markets with zero volume appear, so it is useful but not fully transparent.

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

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

A single tight sentence that front-loads the resource and then packs the returned metrics and the sort/filter controls. Every clause carries information; nothing is repeated from the title.

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

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

For a read-only listing tool with no output schema, the enumerated metric list is the essential missing piece and it is present, alongside sort and filter behavior. It stops short of stating result ordering tie-breaks or what an empty filter match returns, which are the remaining gaps.

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 defaults, enum values and the BTC-style coin example are already documented there. The description restates the sort dimensions and the coin filter without adding format details (e.g. whether query is case-sensitive or matches partial tickers), 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 resource (perpetual futures markets on Hyperliquid) and enumerates exactly what each entry contains: mark price, 24h change, funding hourly/yearly, open interest, volume, max leverage. It reads clearly as a market-wide listing rather than a single-asset quote, but it never names the closest sibling (perp_quote), so the distinction must be inferred from the plural/catalog framing.

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

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

Usage is implied by the mention of sorting and coin filtering, which tells the agent this is a screener/ranking call. However, there is no explicit when-to-use-this-vs-perp_quote guidance and no statement about scope (all Hyperliquid perps only, or other venues), leaving the agent to guess the boundary with the quote tool.

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?

With readOnlyHint and openWorldHint already declared, the description still adds real behavioral value: dividends and splits are baked in via a multiplier, the DEX price is only present "where a Uniswap pool exists," freshness is reported, and equity feeds follow US market hours 24/5 and hold the last price when markets are closed. It does not cover error behavior for an unknown symbol or how staleness is surfaced in the response.

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 the list of returned fields are front-loaded, and the second sentence adds a genuinely useful market-hours caveat. It is dense and nearly waste-free, though the colon-list is long enough that a reader must parse carefully to find the input forms.

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 well by enumerating the fields returned (feed price with multiplier, freshness, DEX price, sessions). What remains uncovered is the response shape and behavior on an unrecognized or non-equity symbol, which matter for a one-parameter public 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 single parameter already documents "Ticker like AAPL, or the token address," so the description's "by symbol (e.g. AAPL) or token address" largely restates the schema. Baseline 3 applies; no extra syntax, case sensitivity, or address-format guidance is added.

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 precise resource — the price of a Robinhood stock token on Robinhood Chain — and enumerates what the price payload contains (Chainlink feed price, freshness, DEX price, trading sessions), which clearly separates it from eth_price, perp_quote and token_quote. It is a noun phrase rather than an explicit verb (e.g. "get the price") and it never names an alternative tool, so sibling differentiation is implicit 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?

Usage is only implied: the reader infers this is the tool for equity tokens rather than ETH, perps, or arbitrary tokens, and learns it accepts either a ticker or a token address. There is no explicit "use this when…" statement and no routing guidance pointing to token_quote or perp_quote for non-equity assets.

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

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

Annotations already cover the read-only, open-world profile, but the description adds real substance: approximate catalogue size (~100), scope (Robinhood Chain only), and the exact shape of each record including the shares-per-token multiplier and Chainlink feed flag. It omits any statement about limit/pagination behaviour, which matters since ~100 items can exceed a caller's expectation.

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

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

Two sentences, zero filler: the scope and record shape come first, the filtering affordance second. The long field list earns its space because none of it is derivable from the schema or annotations.

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 only two optional params, no output schema, and light annotations, the description does the necessary heavy lifting by describing the returned record shape and dataset size. The remaining gap is behavioural detail around the undocumented 'limit' default of 200 versus a ~100-item catalogue.

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. The description's 'filter with query (symbol or name)' restates the schema's own example without adding format or matching rules, and the 'limit' parameter (default 200) is not addressed at all. 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 ('List') and a precisely bounded resource ('tokenized stocks Robinhood issues on Robinhood Chain'), and enumerates the returned fields so an agent knows exactly what it gets. It does not name a sibling such as stock_quote to contrast against, so differentiation from the price-oriented tools is only implicit.

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?

'Filter with query (symbol or name)' gives an in-tool usage hint, and the enumeration of returned fields implies catalog/discovery use. However, there is no explicit when-to-use-this-vs-alternatives guidance — nothing says to follow with stock_quote for pricing or token_quote for market data, which is the most likely confusion given the sibling set.

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

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

Goes well past the annotations (readOnlyHint/openWorldHint) with real behavioral facts: 0.5% fee is embedded in the swap, the service is non-custodial and never sees keys, sanctioned wallets are refused, EVM returns an exact-amount approval first when needed, and Solana returns one base64 versioned transaction the wallet pays for. That is exactly the context an agent needs before surfacing transactions to a user.

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

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

Front-loaded with the action and chains, then the return shape, then per-chain mechanics — a sensible order. The closing "xStocks are coming soon" is marketing that does not help invocation and is the one sentence not earning 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, and the description compensates fully by describing the return: a firm quote with amount out, minimum, and every fee, plus unsigned transactions in order. Combined with the per-chain transaction shapes and the fee/custody notes, an agent has everything needed to call it and explain 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%, including the default-chain note and the 'same forms as sell' reuse for buy, so the schema already does the heavy lifting. The description adds no parameter-level detail beyond it (no clarification of slippage behavior, amount precision, or address format), 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 — "Build a swap" — and adds the crucial scope "for your own wallet to sign and send," plus the exact artifact returned (firm quote + unsigned transactions in order). It never names swap_quote, so the boundary with that sibling is left to be inferred from "to sign and send" rather than stated outright.

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

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

Usage is implied by "for your own wallet to sign and send" and the per-chain breakdown, which tells an agent this is the self-custody execution path. There are no explicit when-not conditions and no named alternative (e.g. swap_quote for preview-only pricing), so the agent must infer the 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?

Consistent with readOnlyHint=true ('nothing is signed or sent'), and adds substantial behavior beyond annotations: per-fee breakdown (0.5% Fivebar, router fee, gas), slippage-adjusted minimum, USD valuation, token-tax flagging, and missing-balance/approval detection when taker is supplied. This is rich disclosure the structured fields do not 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?

Purpose is front-loaded in the first clause, with chain/DEX enumeration and fee details following. It is dense but every clause carries operational information; the long chain and DEX lists cost some readability, keeping it just under top marks.

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 describes what the agent gets back (amount out, minimum after slippage, USD value, itemized fees, tax and balance flags). For a read-only quote tool with 100% schema coverage, an agent has everything needed to call it and interpret results.

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: chain is auto-selected for Solana tokens, and passing taker triggers balance/approval checks rather than being a passive field. Amount whole-unit semantics and slippage default are already in the schema, so it doesn't rise to 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?

Opens with a specific verb+resource ('what swapping one token for another would give right now') and enumerates the chains, routing sources, and outputs. It clearly separates itself from swap_build (execution) and stock_quote (xStocks), so an agent can select it without opening any schema.

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

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

Explicitly states the when-not ('Quote only: nothing is signed or sent; to swap, use swap_build') and routes xStocks to stock_quote. It also implicitly scopes usage by chain and by passing taker for balance/approval checks, leaving nothing to inference.

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

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

The annotations only flag readOnlyHint and openWorldHint, so the description has to explain how pricing actually happens, and it does: thin pools (under $2,000 in range or missing) fall back to a $10 buy routed through 0x with a warning, and Solana mints are priced from a small USDC buy across DEXes. That fallback behavior, including the real trade and the warning, is exactly the kind of context the annotations 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?

The core purpose is front-loaded in one clean sentence, and the chain-dependent pricing behavior follows in a single dense parenthetical. It is information-heavy but every clause earns its place, with only slight compression cost to readability.

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 has to state the returns itself, and it does: price, market cap, and a fallback warning. For a 2-parameter read-only quote tool that is close to complete, with only minor gaps around output shape or units.

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 100% schema coverage, the baseline is a 3, and the description earns more by explaining the dual meaning of `address` (0x contract vs Solana mint) and what the default chain does. It adds real meaning beyond the schema text, though the enum values themselves add nothing new.

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 pair ('Price and market cap of any token by its contract address') and then pins down the address-type-to-chain mapping. That is enough for an agent to distinguish this from token_risk, eth_price, stock_quote or swap_quote 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?

It gives clear selection context: a 0x address defaults to Robinhood Chain, and you pass base, ethereum, arbitrum or solana to target those. It never says when *not* to use it, or when a sibling like token_risk or swap_quote is the better call, so it falls 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 only declare readOnlyHint and openWorldHint; the description adds substantial context beyond that — the per-chain checklist, the simulated $100 buy-then-sell through the router, the verdict scale (high/caution/low), and the 'not a guarantee' caveat. It stops short of saying whether the router test requires approvals, funds, or takes measurable time, and whether the verdict is deterministic per 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?

Opening sentence front-loads the question and the input, then the chain-specific checks are grouped logically and the return contract and caveat close it out. Dense but nearly every clause carries information; only the chain enumeration is mildly redundant with the enum.

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 only 2 parameters, no output schema, and minimal annotations, the description carries the burden well: it explains what is checked, what the output verdict looks like plus reasons, and the limits of the result. Nothing an agent needs to decide to call it, or to interpret the response, 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 parameters (address as 0x or Solana mint, chain enum with documented defaults) are already fully explained structurally. The description only restates the supported chains, adding no format or edge-case detail 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?

Names a specific verb-and-resource: a pre-purchase risk assessment of a token by contract address, broken out per chain family (Solana mint/freeze/Token-2022/holder concentration; EVM taxes/ownership; both get a $100 round-trip test). This clearly separates it from token_quote and swap_quote, which price rather than diagnose.

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?

The title 'before you buy' plus 'What could go wrong buying a token' establishes the use case and timing precisely. It does not name alternative siblings (e.g., when to prefer token_quote for pricing) or state exclusions, so it falls short of a full when/when-not/alternatives 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?

Annotations only cover read-only and open-world, so the description carries the real burden and does: spam-like airdrops are hidden and counted, unsellable tokens are listed apart, and stale prices are capped at 15 minutes and flagged via priceAsOf. It also discloses valuation sources per asset class, which the agent would otherwise have to guess.

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

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

Front-loaded with purpose and scope before the valuation detail, and every clause carries information (pricing sources, risk verdict, spam handling, staleness). It is dense and long-ish for a single paragraph but wastes nothing.

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

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

With no output schema, the description must describe the return shape, and it does: per-token USD values, a risk verdict on the largest positions, a separate list for unrouteable tokens, a hidden-spam count, and a priceAsOf marker. An agent can interpret the response without further doc.

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 the schema doesn't: chain defaults are derived from address format (0x vs Solana), and it clarifies that 'all' expands to four EVM chains rather than everything. That resolves the only real ambiguity in the enum.

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 and resource ('every token a wallet holds, with USD values'), plus the exact chain scope and the address type it accepts. It is clearly distinct from siblings like token_quote or token_risk, which cover one token rather than a wallet's whole portfolio.

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?

Explains the address/chain relationship explicitly ('all four EVM chains for a 0x address... or one chain with chain') so the agent knows how to constrain scope. It also routes the agent onward for deeper analysis ('run token_risk for the full check'), though it never states when not to use this tool.

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 annotations, the description discloses real behavioral context: data is screened before counting, updated every 3 hours, and the two exclusion buckets have distinct meanings (flaggedUsd = wash pattern evidence; tooFewBuyersUsd = insufficient sample, not washing). That distinction is exactly the kind of nuance an agent can't get from annotations. It stops short of describing pagination or the full response shape.

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 sentences, front-loaded with what is indexed and over what window, then the field semantics, then the refresh cadence. The middle sentence is long but each clause carries distinct meaning. Slight density cost, 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 has to carry return-value meaning, and it does define three key fields (flaggedUsd, tooFewBuyersUsd, topSellers) with interpretation guidance. It leaves the overall response structure (time-series shape, per-seller fields) unstated, which is the main remaining gap for an output-schema-less 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 tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. The description correctly implies no inputs are needed.

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: an index of x402 payments (USDG transferWithAuthorization) on Robinhood Chain covering the last 24 hours and recent days. It is clearly distinguishable from the quote/lookup siblings, though it never explicitly contrasts itself with check_seller, the closest sibling in subject matter.

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

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

Usage is implied rather than stated: an agent can infer this is the tool for aggregate payment-volume and wash-screening data, but there is no explicit 'use this when...' framing and no routing to check_seller for per-seller detail. The screening caveats help interpret results but don't guide tool selection.

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