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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds substantial behavioral context beyond them: exact price, network, contract address, the required X-PAYMENT header, the EIP-3009 signing scheme, and precisely what an unpaid call returns (a payment_required payload with amount/asset/network/payTo). The 402 -> sign -> retry loop and SDK option are spelled out, which is exactly the kind of side-effect and auth disclosure 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-loaded with the resource, then VALUE/PRICE/HOW TO PAY in labeled blocks — an agent can stop after the first line if it just needs to know what this is. The payment block is dense but each element (amount, chain, scheme, address, header name, retry semantics) is load-bearing, so little is wasted.

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

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

For a tool with six undocumented parameters and no output schema, the description should explain how to bound the query (as_of vs from_ts/to_ts), what granularity values are accepted, and what the returned OHLCV payload contains. It covers the payment path exhaustively but leaves the call-shaping information an agent actually needs in order to invoke it correctly unaddressed.

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

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

Schema description coverage is 0% across six parameters, so the description carries the full burden and largely fails it: as_of, from_ts, to_ts, limit and granularity are never explained, and no formats are given (timestamp unit, granularity tokens, instrument identifiers). Only 'bounded and timestamped' loosely hints at the from/to range, which is far short of compensating for the total schema gap.

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 format: 'Signed OHLCV snapshot from our own market-data store', plus a point-in-time framing ('the now you stamp a decision with'). That implicitly separates it from market_history / market_history_bulk, but it never names those siblings, so the differentiation is inferred rather than stated.

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

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

The VALUE line gives a usable context ('point-in-time market snapshot for an instrument ... the now you stamp a decision with'), which implies using this for current-state reads rather than backfills. However, no explicit when-not and no named alternative (market_history, market_history_bulk, market_calendar are all plausible confusions) are mentioned, leaving the routing decision to inference.

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