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

With no annotations, the description carries the full transparency burden. It discloses auth/payment methods, per-call cost, the read-style nature of the tool, the report sections, and the behavior that unavailable sections are labeled 'unavailable'. It does not mention freshness, rate limits, or output formatting, but the output schema presumably covers return structure.

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 description is information-dense and has no filler, but its first sentence is consumed by network and payment details, delaying the actual high-level purpose. The payment options for fiat are also fairly lengthy for an agent that is selecting and invoking a tool. It could be more front-loaded with 'Produces a one-chain aggregate market brief.'

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?

Given its simple one-parameter schema and existing output schema, the description is largely complete: it defines scope, expected content, credential/payment requirements, and failure naming. It does not discuss freshness or alternatives, but these are less critical for this tool. An agent can decide whether this tool is worth invoking from the provided text.

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%, so the description must add meaning to the only parameter, 'chain'. It does add context by saying the tool covers one chain and that Bitcoin specifically includes mempool data. The enum already enumerates the valid chains, and the single parameter is self-evident, so the description does not need to explain each value.

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 communicates that this tool returns a single-chain comprehensive read covering market state, momentum, price walls, large transfers, bot activity, open interest, stablecoin flows, and Bitcoin mempool. It does not use a simple verb like 'generates' or 'summarizes', but the intent is clear. It separates itself from specialized siblings by emphasizing one chain and multiple dimensions in one answer.

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 phrase 'One chain, the whole read in one answer' provides clear usage context: use this tool when you want a broad, consolidated view of a single chain. It does not explicitly name alternatives or say when not to use it, but it implies a distinction from focused siblings like whale_flows, open_interest, stablecoin_flows, or market_state.

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