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

With no annotations, the description carries the full behavioral burden and does notable work: it discloses payload scale (257 markets × ~50 fields), explains that omitting the parameter returns a compact subset rather than everything, and notes that unknown market values are echoed back with suggestions. It does not mention rate limits, freshness/latency, or the shape of the returned fields, which keeps it off a 5.

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?

Two sentences, front-loaded with the two-mode rule and immediately followed by the reason for the default (payload size). No filler, though the phrase 'the full ticker is 257 markets of ~50 fields, which no caller can use in one piece' is slightly verbose relative to the information it conveys.

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 single optional-parameter read tool with no output schema, the description covers both call modes, the default behavior, and the size constraint that motivates the default. It lacks any indication of what a returned market entry contains ('every field' is asserted but not illustrated) and says nothing about response latency or limits.

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 the schema description is unusually rich, already covering the quote-first keying convention, friendly-spelling resolution, the six-item cap, and the everstrike_pairs pointer. The prose adds only a light usage directive ('always pass this when the question is about specific markets'), so baseline 3 is appropriate given the schema does the heavy lifting.

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 states the resource (live prices across markets) and distinguishes two operating modes: full per-market ticker when `pairs` is supplied, compact summary of most active markets when omitted. It is specific enough to separate it from siblings like everstrike_ohlcv or everstrike_depth, though it never names those siblings explicitly.

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?

It gives a clear conditional rule – pass `pairs` for specific markets, omit it for a compact overview – and points to everstrike_pairs for canonical market names. It stops short of stating when to prefer everstrike_ohlcv, everstrike_depth, or everstrike_trades instead, so the routing is implied rather than exhaustive.

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