Signed OHLCV snapshot from our own market-data store (PAID $0.01)

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

The description adds genuinely useful behavioral context beyond annotations: paid consumption (0.01 USD), settlement asset/network (x402/base/usdc on eip155:8453), and the remote POST route. However, it never explains the non-obvious annotation profile (readOnlyHint=false and idempotentHint=false for what reads like a snapshot read), nor auth requirements, rate limits, or whether repeats are billed twice — which matters given non-idempotency plus a per-call charge.

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?

Very short and front-loaded, and the payment/route line earns its place. But the first sentence is a verbatim restatement of the title, so roughly half the text is duplication rather than added 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?

An output schema exists, so return values need no explanation, and the payment/route detail is covered. What is missing is the substance an agent needs to actually call it: parameter meanings for six undocumented fields, time-window semantics, and the effect of non-idempotency under per-call billing.

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?

Six parameters (as_of, limit, from_ts, to_ts, instrument, granularity) have 0% schema description coverage, and the description supplies no meaning, format, units, defaults, or timezone semantics for any of them. For a 6-param tool with untyped schema fields, this is a complete gap the description was required to compensate for.

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 artifact (signed OHLCV snapshot from a first-party market-data store) plus price, which tells an agent what it gets and at what cost. It does not distinguish itself from plausible siblings like v1_market_history, v1_data_signed_snapshot, or v1_market_regime, so an agent cannot route confidently between them from this 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?

There is no when-to-use guidance, no exclusions, and no named alternative among the many market-data siblings. The only selection signal offered is the price and the transport route, which speaks to execution, not applicability.

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