stake-analyzer

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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: data originates from Telegram channels, entries carry value/requirement/post time, and codes are highly perishable ('expire within minutes'), which tells the agent results go stale fast. It stops short of saying how staleness or missing codes are represented.

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 tight sentences, front-loaded with what the tool returns and followed by the freshness caveat. Every clause carries information; nothing is redundant with the title or annotations.

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, return-value structure need not be explained, and the description covers source, recency, and volatility. The only gap is the undocumented limit parameter and any note on ordering or empty-result behavior.

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?

There is one optional parameter (limit, default 10, max 30) with 0% schema description coverage, and the description never mentions it. The parameter is simple enough that the schema type/default/bounds largely suffice, but the description adds no meaning about what the limit counts or how results are ordered.

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 resource (newest bonus drop codes) with explicit provenance (Stake's official Telegram channels for Stake and Stake.us) and the fields returned (value, requirement, post time). No sibling tool covers bonus codes, so it is instantly distinguishable from the odds/game/verification tools.

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 only implied: 'newest' and 'Codes expire within minutes' signal that this should be called for real-time code retrieval and re-called often, but the description never states when to prefer it or what to do instead. No explicit exclusions or alternatives are given, though the sibling set makes alternatives obvious.

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

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

Annotations already declare readOnly, idempotent and closed-world, so safety is covered; the description adds real value by disclosing that it returns the newest round plus prior rounds and that results differ by game type (multipliers vs. animals). The warning that stake.com and stake.us operate independent chains is a genuine failure-prevention detail beyond the enum list.

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?

One dense sentence that front-loads the resource and packs the game-dependent output and chain separation without any filler.

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 both parameters being enums with defaults, the description covers what is needed to choose values correctly. The only omissions are the depth of 'rounds before it' and any rate or recency caveats, which are minor for a read-only lookup.

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 0%, so the description must compensate, and it does: it clarifies that the game choice determines whether output is a multiplier or animals, and that the site choice selects between two independent chains. It does not state how many prior rounds are returned, which is the one remaining semantic gap.

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 resource: the newest round on a Stake Crash/Slide/Zoo hash chain plus the rounds preceding it, including each round's multiplier or animals. This clearly separates it from siblings like stake_verify_bets or stake_crash_odds, though it never names an alternative 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?

There is no guidance on when to use this versus stake_verify_bets, stake_crash_droughts or stake_crash_odds; the only contextual sentence ('stake.com and stake.us run separate chains') is a data note, not a usage rule. The agent must infer the call context entirely.

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

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.

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

Annotations already declare readOnlyHint, idempotentHint, and closed-world behavior, so the safety profile is covered. The description adds meaningful behavioral context by naming the exact statistics returned, including average rounds between hits and the instant 1.00x chance, which go beyond the annotations.

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?

The description is a single dense sentence that front-loads the core purpose and enumerates the outputs without filler. It is efficient, though the long list of metrics makes it slightly harder to scan than a short bulleted structure would.

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 the description need not explain return values in full. It still names the returned metrics, covers the required target and optional rounds semantics, and works alongside annotations that confirm safe read-only calculation. Minor gaps remain around sibling differentiation but nothing essential for correct invocation is missing.

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 67%, and the description compensates well by clarifying that target is a cash-out multiplier and that rounds relates to the chance of at least one hit within N rounds. It also indicates the two game types, Crash and Slide. The enum parameter 'game' still lacks a description in the schema, but the description covers it adequately.

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 clearly states the computed outcomes: hit probability for a cash-out target, return, average rounds between hits, hit chance within N rounds, and instant 1.00x chance. It is specific enough to distinguish this from general payout tools, but it does not explicitly differentiate itself from close siblings like stake_crash_droughts or stake_payout_odds.

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 by the listed calculations: use this when you need Crash/Slide target odds, return, or hit timing. However, there is no explicit statement of when to use this versus sibling tools such as stake_crash_droughts or stake_payout_odds, nor any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious domain behavior: the first guess carries the house edge, subsequent guesses pay fair odds, and skips deal a new card without multiplying the payout. It does not discuss invalid-path handling or edge cases.

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 dense sentences with no filler, front-loading what is computed before the payout mechanics. Every clause carries information an agent needs.

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 only two top-level parameters, an output schema covering return values, and annotations covering the read-only/idempotent profile, the description supplies everything else needed to invoke it correctly — the path structure and the payout rules. Minor gaps around malformed paths are acceptable at this complexity.

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 50% and the description compensates by mapping the structure semantically: 'the start card, then each guess and the card that came' ties directly to start and the steps[].guess/next pair. It also explains evaluation ordering and the special meaning of skip, which the schema does not convey. It does not disambiguate the enum values (higher vs higherEqual, equal), leaving that gap.

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 a specific resource ('Payout and odds of a HiLo path') and clarifies the inputs are the start card plus each guess and resulting card. That is far more specific than the siblings that cover other games (crash odds, slot lookup, chain latest), though it never explicitly contrasts itself with stake_payout_odds.

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 only implied: an agent can infer this is for evaluating a completed HiLo sequence, but there is no statement of when to choose it over stake_payout_odds or other odds tools, and no prerequisites or exclusions are given. The domain rules about house edge and skips are behavioral, not routing guidance.

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

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

Annotations already establish that the tool is read-only, closed-world, and idempotent. The description adds useful behavioral context by disclosing that results are computed from payout tables and that output differs depending on whether `game` is supplied.

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 tight sentences: the first states what is returned and how it is computed, and the second explains the optional parameter's effect. There is no wasted language.

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 one-parameter read-only lookup with an output schema, the description is largely complete. The only meaningful gap is that it does not clarify how this differs from other odds/payout-oriented sibling tools.

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 0%, so the description must carry the parameter semantics. It does so by explaining the effect of omitting versus providing `game`, though it does not elaborate on the enum values themselves beyond the schema listing them.

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 a specific set of metrics (return to player, house edge, top payout) for a specific scope (Stake Originals) and explains that values come from each game's payout table. It is clear what the tool does, but it does not explicitly distinguish itself from similar siblings such as stake_payout_odds.

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 explains the two usage modes: omitting `game` produces a summary, and supplying `game` produces detailed settings. However, it does not say when to choose this tool over related tools like stake_payout_odds or stake_crash_odds.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuine content context — that each listed game comes with its seed checker, simulator and verifier links — which tells the agent what it will receive and why it is useful before other calls.

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 short sentences with zero filler. The content statement comes first and the actionable routing hint ('call this first') is placed last where it is most likely to be acted on.

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?

A no-parameter, read-only listing tool with an output schema and full annotation coverage needs little else; the description covers what is returned and when to reach for it. Nothing an agent needs in order to call it correctly is missing.

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?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The description correctly implies a no-argument, enumerate-everything call.

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 verb and resource ('List ... every Stake Original') and even enumerates the payload each entry carries (seed checker, simulator, verifier links), which no sibling does. An agent can immediately tell this apart from the analysis-oriented siblings like stake_crash_odds or stake_verify_bets.

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?

'Call this first when unsure of a game id' gives a clear triggering condition and positions the tool as the entry point for the set. It does not name explicit when-not conditions or alternatives, but none of the siblings actually substitute for enumeration.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds useful return-category context (RTP, win chance, top payout), but it does not disclose calculation assumptions, permissions, or other behavioral constraints beyond what the annotations and output schema already provide.

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?

The description is compact, front-loaded with the core result, and uses examples rather than redundant explanation. The first sentence is dense but every clause earns its place.

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?

The tool is complex: 29 game enum values and a nested options object with many game-specific fields. The description samples only a few configurations, so an agent must rely heavily on the schema and output schema for the rest. It is adequate but not fully complete for calling across all supported games.

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 reported as 0%, so the description must carry parameter meaning. It does this for a few cases (Mines with mines/gems, Keno risk/picks, Plinko rows/risk, Dice over 50), but it leaves most of the many game-specific options undocumented, so compensation is only partial.

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 a specific resource and scope: multipliers and exact result chances for one Stake Original at one setting, with examples such as Mines, Keno, Plinko, and Dice. It clearly says what the tool returns (RTP, win chance, top payout), though it does not explicitly distinguish itself from sibling odds tools like stake_crash_odds.

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 examples imply how to call the tool for a few games, but there is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternatives such as stake_crash_odds or stake_house_edge. Usage is therefore inferred rather than directed.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds that this is a pure probability calculation, but says nothing about cost — nonces accepts up to 250,000,000, and an agent has no warning that large runs may be expensive or how results are returned.

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?

One dense sentence that front-loads the primary probability and appends the nonces extension. No filler, though the clause structure is compressed enough that the two distinct outputs could be separated more cleanly.

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 described, and the annotations cover safety. What remains missing is the mapping from game to required options and any note on the cost of large nonce runs — material for a tool with 4 top-level params and a 25-property nested object.

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 50%, and the description explains none of it beyond 'a setting' and 'a run of N nonces'. The nested options object is game-dependent (mines gems/bombCount, plinko rows/risk, dice target/isRollOver, etc.) and the description gives no rule for which options apply to which game — the single largest usability gap.

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 computation: the probability a Stake Original pays at or above a multiplier at a given setting, plus the chance at least one such payout falls inside a run of N nonces. The 'run of N nonces / Seed Hunter' framing distinguishes it from a plain payout-odds tool, though it never names the sibling stake_payout_odds it most resembles.

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?

There is no explicit when-to-use guidance, no exclusions, and no mention of the near-neighbour stakes_payout_odds or stake_crash_odds. The phrase 'the maths behind the Seed Hunter' gestures at a context but leaves the agent to infer the selection rule.

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

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

Annotations already declare read-only, idempotent, closed-world behavior, so the description only needs to add value beyond that. It does: it discloses that odds/multiplier figures are only returned 'where the site has computed that mode's table', warning the agent that results can be partially populated, and notes results span each mode.

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?

A single dense sentence that front-loads the action and the match criteria, then the return contents. No filler, though the trailing clause about conditional odds tables is slightly convoluted.

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 no explanation. However, for a lookup tool with many semantically adjacent siblings, the description leaves unresolved how it differs from list/ranking tools and whether multiple matches are returned as a list.

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%, so both parameters are already documented as substring match on slot or publisher name and an optional mode name. The description restates the name/publisher matching without adding syntax, case rules, or precedence, and says nothing about the optional 'mode' filter beyond 'each mode's published RTP'.

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 verb and resource ('Finds Stake Engine slots on Stake by name or publisher') and describes the returned payload (mode RTP, max multiplier, odds). It does not distinguish itself from siblings like stake_list_games or stake_slot_rankings, which plausibly overlap in scope.

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?

No when-to-use or when-not-to-use guidance, and no alternatives named despite a crowded sibling set (stake_list_games, stake_slot_rankings, stake_payout_odds) that an agent could easily confuse with this lookup. The only implied usage signal is 'by name or publisher'.

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

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

Annotations already cover readOnly/idempotent/openWorld=false, so the safety profile is settled. The description adds value beyond that by naming the data source (Stake Engine Insights) and the shape of each entry (publisher, average bet). It omits only secondary behaviors like caching or tie-breaking.

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?

A single dense sentence with no filler; the ranking basis and returned fields are front-loaded, and nothing is repeated from the schema.

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-value detail is not needed. However, with zero schema description coverage, the absence of any mention of limit behavior, default ordering metric, and how ties or 'all' range behave leaves gaps for a 3-parameter ranking tool.

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 parameters. It covers 'range' and 'category' (turnover vs. bets), but 'limit' is only hinted at by the word 'top' – the maximum of 25 and default of 10 are left entirely to the schema, and the default metric (bets) is not stated.

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?

Names a specific resource (Stake Engine slots) and states the ranking dimension explicitly: 'most played... by turnover or bet count over a range.' It also discloses the returned fields (publisher, average bet), which distinguishes it from stake_slot_lookup and stake_list_games without naming them.

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 by 'most played... over a range' – the agent can infer this is for leaderboard/discovery queries – but there is no explicit when-to-use or when-not, and no guidance on choosing between stake_slot_lookup (details on a known slot) versus this ranking tool.

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

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

Annotations already declare readOnly/idempotent/closed-world, so the description's added value is the mechanics: deterministic replay of the provably fair algorithm, a per-bet result and multiplier, and the SHA-256 hash returned for comparison against the pre-reveal hash Stake published. The prerequisite that only revealed seeds work is meaningful behavioral context. It stops short of describing error behavior for mismatched seeds or invalid option combinations.

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?

Three sentences with no waste: purpose and cap first, then the verification hash return, then the seed-reveal prerequisite. Front-loaded and each sentence adds distinct information.

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-shape explanation is optional, yet the description still calls out the SHA-256 comparison value, which is the crux of verification. The only gap is guidance on constructing the game-dependent `options` payload for the 29 supported games.

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 67%, so most parameters are already documented, and the description only reinforces serverSeed/clientSeed/nonce and the 200-nonce cap on count. The large game-specific `options` object — where wrong settings silently change the replay — gets no explanation in the description beyond what the schema's own summary says.

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?

Names a specific verb and resource: replays Stake Originals bets from a revealed server seed, client seed and nonce using Stake's provably fair algorithm, and reports results and multipliers. This is clearly distinct from the sibling set (stake_seed_hunt_odds, stake_hilo_path, stake_crash_odds), which estimate odds or paths rather than verifying actual bet outcomes.

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 precondition for use: it needs the unhashed server seed, which Stake only reveals after the seed pair is rotated. It also states the throughput limit of 200 nonces per call. It does not explicitly name when to prefer a sibling tool, but the verification framing makes the boundary reasonably obvious.

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

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

Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds genuine behavioral value by disclosing the three computed outputs (wager remaining, cheapest-game cost, sports bet equivalent), telling the agent what kind of answer to expect. It stops short of describing assumptions behind 'cheapest games' or the cost model.

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?

A single dense sentence with no filler; every clause contributes a distinct output. It is slightly awkward to parse because the input modes and outputs are crammed together, but nothing is wasted.

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 and full annotation coverage, the description only needs to convey the computation model, which it does. The remaining ambiguity — whether level is needed alongside totalWager and what currency/units the cost uses — is minor but not resolved in the text.

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%, so the baseline is 3. The description goes beyond the schema by clarifying the two mutually exclusive input modes: either level plus progress percentage, or a total wagered figure ('instead of level and progress'), which is semantically important given zero required parameters.

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 a specific computed resource — wager remaining to the next Stake VIP level — plus the derived outputs (cost on cheapest games, sports bet equivalent). No sibling tool covers VIP progress, so disambiguation is implicit rather than stated. It lacks an explicit verb ('calculates'), reading as a noun phrase, which keeps it just short of a 5.

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 only implied: an agent can infer this is the tool for VIP-level questions, but the description never says when to prefer it or what to do when no level data is known. No alternative sibling is named or excluded, though the sibling list offers no obvious overlap.

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