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

Annotations already declare the read-only, idempotent, non-destructive profile, so the description's real contribution is semantic: the metrics are derived from execution/post-fill prices rather than stated probabilities, it carries no championship rank, and null sections mean 'unavailable or insufficient observations' with a `minimums` field to consult. That is meaningful context an agent would otherwise guess wrong about.

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?

Four sentences, front-loaded with what the record contains, then disambiguation, then null-handling — each sentence carries distinct information. Slight density cost from jargon stacking in sentence one, but nothing is redundant.

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 not be spelled out, and the description still usefully flags the `minimums` key and null-section semantics. For a single-parameter read tool with full annotations, this covers what an agent needs; only the missing sibling pointer keeps it from full marks.

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 100% and the single `address` parameter is fully documented in the schema, so the description correctly does not restate it. It adds no meaning beyond the schema about the address (e.g., whether non-participating wallets return empty sections), which is the baseline 3 for a fully covered schema.

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 enumerates the concrete contents (Brier/log transforms, price-bin frequencies, streak/best-call fields) and states their basis (selected execution/post-fill prices), which tells an agent exactly what resource this returns. It stops short of an explicit verb ('retrieve the legacy scoring record for a wallet') and never names the sibling tool it contrasts with, only the concept 'fixed-lock Arena record'.

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?

Usage is implied through exclusion: this is 'not the trader's stated probabilities or explicit forecast accuracy' and 'separate from the fixed-lock Arena record.' An agent can infer to use it for legacy price-based diagnostics rather than forecast accuracy, but no alternative tool is named and no positive trigger ('use when you need historical calibration of execution prices') is given.

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