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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: NQ has a weekend halt and a 21:00 UTC daily break, past windows are SEALED and therefore cacheable, and the same data is served keyless over HTTP. The note that this is the tape the conformance check replays is a genuinely non-obvious behavioral guarantee.

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?

Scope and the use/don't-use rule are front-loaded, and the sentence about sealed windows is high-value. The HTTP mirror paragraph with OpenAPI link and User-Agent instruction is arguably adjacent to invoking this MCP tool and costs some density, though it does earn its place as an auth-free fallback.

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?

Covers the tricky parts an agent needs — market break schedule, immutability/caching, and authoritative-source guarantee — for a 4-param required-everything read tool. The one gap is that with no output schema, the description never says what a bar actually contains (OHLCV fields, ordering, gaps at breaks).

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% with enums for market and tf, so baseline is 3. The description adds real value on top: it stresses the window must be in the past, and it clarifies the format split (MCP takes ISO-8601 while the HTTP mirror takes unix SECONDS), which is precisely the kind of mistake an agent would otherwise make.

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?

Opening sentence states a specific verb and resource — 'Read real candles from the Taifoon tape for one market' — and the 'never to predict' clause implicitly separates it from forecast-style siblings like forecast or plan_claim. It never names an actual sibling, so an agent still has to infer which of the ~48 tools is the alternative read path.

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 a clear intended use ('ground an answer in what the market actually did in a past window') plus an explicit exclusion ('never to predict'), which is exactly the routing signal an agent needs. It does not say what to do when the window is in the future or which sibling serves live/current data instead.

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