qm_data_crypto

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

No annotations are provided, so the description carries the full burden and does so well: it discloses cost ($0.01 USDC on Base via x402), that the live 402 challenge is authoritative, the two-phase payment protocol, that the tool never signs/holds funds/touches private keys, and that resale is permitted. This is exactly the behavioral context an agent needs before invoking a paid 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 purpose followed by the payment mechanics; every sentence carries information. The resale-permission sentence is arguably tangential but relevant to agent decision-making, and the whole is a bit long for a single-price fetch.

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 explaining that 'the data comes back in the tool result' and detailing the payment handshake. The absence of an explicit return-field description is a minor gap for a three-parameter paid tool with no annotations.

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 goes beyond the schema by explaining the temporal role of 'payment' — omit it first to receive requirements, then re-call with the base64 x402 payload — which clarifies the otherwise opaque two-phase contract.

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 ('Live crypto spot price') with concrete use cases (pricing goods, portfolio math, trading-bot inputs) and the data source (Coinbase spot). It is clearly distinguishable from fiat-oriented siblings like qm_data_fx and the other qm_data_* fetchers.

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 and a full procedural recipe: call without 'payment' to get requirements, pay externally, re-call with the payload. It does not explicitly name which sibling to use instead (e.g. qm_data_fx for fiat), so it stops short of full when-not guidance.

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