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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds substantive behavioral context beyond that: results are computed over 'the newest rounds checked' (a sampling window, not full history) and that stake.com and stake.us maintain separate chains, so data is not interchangeable between sites.

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, no filler, with the metric definition front-loaded ahead of the site caveat. The first sentence is dense and slightly convoluted ('the longest run without each'), which keeps it from a 5.

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?

With an output schema present and annotations covering safety, the description only needs to convey scope and semantics, which it does: the metric set, the recency/sampling caveat, and the per-site chain separation. Remaining gaps (exact window size, refresh cadence) are minor for a read-only statistics query.

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 carry the meaning. It does address both parameters at a domain level: it frames the 'game' choice as Crash vs Slide chain, and explains that the 'site' parameter selects between stake.com and stake.us chains that are kept separate. The mapping is implicit rather than explicit to the enum values, so it falls just short of full compensation.

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 names the specific metrics returned (rounds since the last 2x/10x/100x and the longest run without each) over a named data source (Stake Crash or Slide chain), which is clearly distinct from siblings like stake_crash_odds or stake_chain_latest. It is not a tautology of the name, though it doesn't explicitly point to the sibling tools it is not.

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: this is the drought/streak statistics query, and the note that stake.com and stake.us run separate chains warns the agent to pick the right site. However, there is no explicit when-to-use guidance or comparison against alternatives such as stake_crash_odds or stake_chain_latest.

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