Get a hosted Edge Stats report

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

With no annotations provided, the description carries the full disclosure burden and does so well: it states results are precomputed, framed as historical conditional frequencies rather than predictions, and enumerates the statistical guards (Wilson 95% CI, minimum-sample guards, stability split, per-year counts, disclaimer). It leaves failure modes unaddressed, but for a read-only report tool the honesty-envelope detail is unusually transparent.

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?

Tightly front-loaded with the core message ('One precomputed session-statistics result') and every clause earns its place — the honesty-envelope list and the 'not predictions' caveat are all informative. It reads as a dense run-on em-dash chain, so scannability suffers slightly, but there is no wasted verbiage.

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 simple two-parameter read tool with no output schema, the description compensates by spelling out the full return envelope: estimate, N, Wilson interval, minimum-sample guards, stability split, per-year counts, value distribution, and disclaimer. The only notable omission is error behavior for invalid preset/symbol values, which the schema examples partially mitigate.

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%, and both parameter descriptions already include examples ('gap-fill', 'BTCUSDT') plus cross-references to edge_presets and edge_symbols. The tool description repeats that sourcing relationship but adds nothing materially new beyond what the input schema states, so the high-coverage baseline of 3 applies.

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 deliverable — 'One precomputed session-statistics result: P(outcome | conditions) for a preset on a hosted symbol' — and details the return contents. The epistemic qualifier 'Historical conditional frequencies, not predictions' further pins down what the tool does. References to edge_presets/edge_symbols distinguish it from the sibling listing tools that supply its inputs.

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 closing sentence, 'Preset ids come from edge_presets; symbols from edge_symbols,' implies the correct calling workflow and routes the agent to the data-source siblings. The 'Historical conditional frequencies, not predictions' phrase acts as a when-not-to-use caution. No explicit comparison to an alternative report tool is given, but the guidance is clear enough.

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