debuff

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

Annotations declare readOnlyHint=false and destructiveHint=false, so safety is partly covered; the description adds real value beyond that by disclosing the return content (raw/gzip/brotli per file) and a behavioral constraint ('leaks' must be empty). It does not describe side effects on disk or runtime cost, but for an annotated tool this is above the bar.

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 with the core action and output front-loaded and zero filler. It is close to optimal, though the reference to a 'leaks' field is slightly opaque without surrounding context about the report object.

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 no output schema, the description usefully describes the return payload (size report fields plus the 'leaks' check), which is the key missing piece. It omits what a build mutates on disk, but the essentials for correct invocation are present for a single-optional-param 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?

With one wholly documented parameter (schema coverage 100%), the schema already explains 'root' fully. The description adds no syntax or format detail beyond it, so the baseline 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 verb ('build for production') and clarifies the primary output (a per-file size report). This clearly separates it from the sibling maintenance tools such as run_tests, fuzz, and the game_* tools. An agent can identify its role without opening the schema.

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 phrase 'for production' implies the context in which to use it, but there is no explicit when-to-use/when-not guidance and no named alternative (e.g., vs. run_tests or a dev build). The agent has to infer that this is the release-build step.

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?

Adds substantial context beyond the annotations: execution is headless, findings carry a kind/file:line/hint plus a replayable `repro` scenario file, and seeds are deterministic. With destructiveHint=false already declaring safety, the remaining gap is disk/state side effects (repro files written?) and resource cost of runs, which go unstated.

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, front-loaded with what the tool does before the finding format and the follow-up workflow. No filler; each sentence (behavior, return shape, workflow/determinism) 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?

With no output schema and five optional parameters, the description carries the return-value burden well: it names the finding fields and the repro artifact, and closes the loop with the verification workflow. An agent has everything needed to invoke and act on results.

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%, so the schema already documents keys, root, runs, seed, and seconds. The description's seed statement ('The same seed gives the same inputs') restates the schema's own 'reuse it to repeat a run exactly' without adding new syntax or constraints. Baseline 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 verb and resource ('Play the game headlessly with random but plausible input') plus the goal (find runtime errors, stuck states, loops). It is clearly distinguished from the sibling run_scenarios, which is positioned as the reproduction step rather than the discovery step.

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?

Provides an explicit downstream workflow: pass the generated `repro` file to run_scenarios to reproduce, then run it again after fixing to verify. This routes the agent to the right sibling. It stops short of saying when not to fuzz (e.g., versus run_tests) or any cost/limits, so it is not a full 5.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating call, so the bar is lower. The description adds the useful fact that output is a PNG image of the *current* frame, but says nothing about how the image is returned (inline/base64 vs. file path), timing/latency, or whether it captures a live or last-rendered frame.

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 short, front-loaded sentence with no filler; the essential noun (PNG image) and scope (current frame) come first. It is a fragment rather than a full sentence, 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 no output schema, the description usefully declares the return type (PNG image), which is the key contract detail for a capture tool. However, the delivery mechanism of that image and any precondition for a valid capture are left unstated, so it is adequate but not fully complete.

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, so there is nothing for the description to disambiguate; the 4 baseline applies. No misleading parameter claims are made.

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 concrete action (screenshot) and an exact artifact (PNG image of the current frame), which is enough for an agent to distinguish it from state/step/replay siblings. It does not explicitly contrast itself with the nearest sibling (game_frames), so it stops 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?

There is no guidance on when to call this versus game_frames, game_state, or game_step, and no stated preconditions (e.g. game must be running or paused, frame must be rendered). Only an implicit sense of usage is conveyed.

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 only declare readOnlyHint=true, so the description carries most of the behavioral burden and does so: it discloses the consequence of a loop error (game halts), the recovery procedure via game_pause, and an escalation policy for debuff-bug errors. It adds genuine context beyond the annotation.

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?

Front-loaded with what the resource is, then the field enumeration, then the two action rules; every sentence earns its place and there is no filler. It is dense but each clause conveys either output shape or required agent behavior.

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 no output schema, the description must explain return values and it does by enumerating the error record fields. Combined with the stop/resume semantics and the debuff-bug escalation rule, an agent has everything needed to call it and act on the result.

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, so per the rubric the baseline is 4. The description adds no parameter meaning because none exists, and it does not claim any filtering or scoping inputs.

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 exact resource (runtime errors since game start) and enumerates its shape with the error kind taxonomy (your-code, debuff-usage, debuff-bug, outside), location, hint, loop phase/tick, and repeat count. This is clearly distinguishable from siblings like game_state, game_profile, and game_notes without opening any schema.

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 concrete situational guidance: a loop error stops the game, so fix it and resume with game_pause false; for debuff-bug, escalate to the human with reportUrl instead of working around it. It stops short of explicitly contrasting with alternative diagnostic siblings, but the when-to-act guidance is strong.

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 only supply readOnlyHint=true, so the description carries most of the burden and does so well: it defines ordering (oldest first), the meaning of each timing field, that steps>1 indicates catch-up, and that longTaskMs is browser-reported main-thread stall. The headless-mode caveat is a genuinely non-obvious behavioral trait. It stops short of covering pagination/limits or cost.

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 tightly packed sentences with zero filler: the return shape and field semantics lead, then the usage hint and the headless caveat close. 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?

There is no output schema, so the description must explain return values, and it names and interprets every reported field, plus the headless-mode semantic caveat. For a read-only diagnostic tool with one well-documented parameter, nothing material 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 single 'count' parameter has 100% schema description coverage ('Default 60'), so the schema already documents it. The description never mentions count, its default, or the 240 cap, adding no meaning beyond the schema. Baseline 3 applies when 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 makes clear this returns recent per-frame timing data ('Recent frames, oldest first') and enumerates exactly which fields come back, so an agent knows the resource and granularity. It does not explicitly contrast itself with close siblings like game_profile or game_state, but the frame-level scope is distinct enough to route correctly.

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?

'Use it to explain stutter' gives a concrete when-to-use context that an agent can act on. It adds a meaningful when-not caveat ('in headless mode times reflect stepping, not real play'), though it names no explicit alternative tool for profiling vs. frame inspection.

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 declare readOnlyHint=false and destructiveHint=false, so the mutation profile is partly covered by structured data. The description adds the genuinely useful buffering trait — input is queued and only takes effect on the next game_step — but says nothing about preconditions (must the game be running or paused?), invalid-code handling, or whether inputs can be cancelled.

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 short sentences, zero filler, and the highest-value information (the action→parameter mapping) is front-loaded. Nothing needs to be cut.

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 four-parameter mutation tool with no output schema, the description covers mode dispatch, argument formats, and timing semantics. Remaining gaps — preconditions such as required game state and error behavior — are modest rather than critical.

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 only 25%, so the description carries real weight here: it maps the action enum to the parameters each mode consumes (press/release → code; tap/pointer_down/pointer_move → x, y), supplies KeyboardEvent.code examples, and clarifies that x/y are 'logical' coordinates. It leaves pointer_up unexplained and gives no coordinate-space details (origin, units).

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+resource ('Keyboard or pointer input') and immediately decomposes it into the two input modes (key/press vs pointer), which distinguishes it from siblings like game_state or game_step. It does not, however, explicitly contrast itself with the other game_* control 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?

The closing sentence 'Input takes effect on the next game_step' implies the intended workflow (send input, then advance with game_step), which is useful sequencing guidance. There is no explicit when-not-to-use guidance or named alternative, so usage remains implied rather than stated.

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?

readOnlyHint=true already covers the safety profile, so the description only needs to add traits. It discloses that results are scoped to live mode and that each note bundles surrounding context (tick, inspect() state, leading frames), which hints at a richer return than a flat list. It says nothing about ordering, limits, or what happens when the session was not live – gaps left entirely unfilled.

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 compact sentence with the resource stated first and the payload contents listed after. Every clause adds information; nothing is padded or repeated from the title.

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 no output schema, the description must carry the return-value burden, and it does: it names the human's words, the tick, the inspect() state at that moment, and the preceding frames. The live-mode constraint is stated. What is missing is ordering/pagination behavior and whether prior game capture is a precondition.

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, so the schema carries no semantics to supplement; the baseline for a parameterless tool is 4. The description correctly introduces no parameter discussion, avoiding noise.

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 identifies a specific resource – moments the human flagged in the overlay – and enumerates the payload (their words, the tick, the inspect() state, preceding frames). It is distinctive enough that an agent won't confuse it with game_state or game_frames, though it never states an explicit verb and never names a sibling to differentiate against.

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 parenthetical '(live mode)' implies the operating condition under which the tool applies, which is genuine usage context. However, there is no explicit when-to-use guidance, no when-not-to-use, and no routing to alternatives such as game_frames or game_capture for the same underlying data.

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?

readOnlyHint=true already establishes the safety profile, so the description only needs to add context. 'Every tunable param group' usefully signals an unfiltered, complete listing with no arguments, but it says nothing about ordering, cost, or staleness relative to game_state. Adequate but thin given annotations do most of the work.

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 front-loaded fragment of roughly fifteen words with no filler, and the enumeration of returned fields is tightly packed. It is telegraphic rather than broken, but the missing verb makes it slightly less self-contained than a full sentence would be.

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 no output schema, the description must carry the return-shape burden, and it does list the schema fields (type, default, min, max, units, description) plus current values. However it omits any mention of how these values relate to the rest of the game_* family (e.g., that current values are the same ones game_set_param mutates), leaving a gap for an agent navigating twenty 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?

The tool takes zero parameters, so the baseline of 4 applies. The description appropriately spends no words on parameter syntax and instead describes what the call yields.

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 resource precisely ('every tunable param group') and enumerates the returned content shape, so an agent can tell this is a read-only enumeration of parameters rather than the mutator game_set_param. It is clear but never explicitly contrasts itself with its sibling setter, so it stops 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?

There is no when-to-use or when-not-to-use guidance; the description is purely a content description. An agent must infer on its own that this is the discovery step before game_set_param, and no exclusion (e.g., 'use game_state for live values') is stated.

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 only declare readOnlyHint=false and destructiveHint=false; the description adds real behavioral context beyond that: headless games are implicitly paused, and game_step pauses first (an ordering side effect). It does not state whether the call is idempotent or what the response looks like, but the safety profile is already covered by 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?

Two short sentences, zero filler, with the primary behavior front-loaded and the two caveats relegated to parenthetical and trailing clauses. Nothing wastes an agent's context.

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 one-boolean control tool with no output schema, the description covers the meaningful edge cases (headless no-op, game_step ordering). It leaves open whether the boolean sets absolute state versus toggling, which is the one gap an agent might care about.

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 single boolean. 'Pause or resume' together with the parameter name 'paused' makes the true/false mapping inferable, though the description never states it outright (e.g. paused=true pauses).

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 pair and resource: 'Pause or resume a live game'. It also differentiates from the sibling game_step by noting 'game_step also pauses first', so an agent can distinguish the two without opening either schema.

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 applicability boundary — 'headless games are always paused' tells the agent this call is a no-op there — and warns about ordering interaction with game_step. It stops short of an explicit 'use this instead of X when Y' rule, so it is clear context rather than full 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 declare readOnlyHint=true, and the description adds meaningful behavioral context: the live-mode vs headless caveat, the enumeration of cause categories (script, gc, upload, compile, layout, throttled, hidden, unknown) with confidence and hints. It doesn't contradict the annotation. Minor gap: no mention of measurement overhead or duration for what is presumably a longer-running profiling pass.

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?

Front-loaded with the core answer (why the game stutters) followed by the payload shape, then the routing rule. Dense but each sentence carries information; the 'debuff's update and render' span sentence is the only mildly cryptic bit.

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 no output schema, the description carries the full burden of describing return values, and it does so: percentiles, hitches per minute, per-hitch cause/confidence/script/function/hint, plus span timing. Combined with the live-mode caveat, an agent has enough to interpret results correctly.

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, so the baseline is 4. The schema is empty and there is nothing for the description to clarify about inputs.

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 the concrete artifact it produces (frame-time p50/p95/p99, hitches per minute, worst hitches with causes and confidence) and explicitly contrasts itself with the game_frames sibling. An agent can tell exactly what this tool returns without reading anything else.

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?

States the selection rule directly: 'Prefer this over game_frames to explain stutter,' and adds a prerequisite constraint ('measure in live mode, since headless stepping doesn't reflect real play'). Both the alternative and the when-not condition are explicit.

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 declare readOnlyHint=false and destructiveHint=false, and the description adds useful context beyond them: the capture scope (keys, pointer, param changes), the output directory, and that a `warnings` field flags anything a replay cannot reproduce (e.g. slow motion). It stops short of describing return format or file naming specifics.

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, front-loaded with what gets captured and where it is saved, followed by workflow guidance. Efficient and free of filler, though slightly dense.

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 no output schema, the description usefully explains the returned file and the `warnings` field, and directs the agent to run_scenarios for the next step. Covers what an agent needs to invoke and use the tool, missing only minor details like file naming.

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?

Only one parameter with 100% schema description coverage, so the schema already documents `toTick` and its default. The description restates the default ('default: now') without adding syntax or boundary semantics beyond what the schema provides, so the 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 action (capture everything played since load and save it as a replayable scenario) and a concrete output location (.debuff/replays/). The name 'game_replay' is slightly ambiguous (could imply playback), but the description resolves this by clarifying it saves a scenario, and it implicitly distinguishes itself from run_scenarios, which executes 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?

Gives a clear when-to-use workflow: 'Use a note's tick to reproduce what the human saw when they flagged it, then run_scenarios with the returned file.' This names the alternative (run_scenarios) and the hand-off, though it does not state explicit exclusions or when NOT to use it.

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 only flag readOnlyHint=false / destructiveHint=false, so the description carries the real burden and does: it discloses the page reload, the input replay to the target tick, the paused end state, and the ~1 second latency. It also reassures that state is restored exactly, which is consistent with destructiveHint=false.

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?

Front-loads the critical constraint ('Live mode only') and then packs mechanism, guidance, and latency into three tight sentences with no filler. Every sentence 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?

For a single-param tool with no output schema, the description covers the preconditions, side effects, latency, resulting state, and next steps. Nothing an agent needs to invoke 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?

Schema coverage is 100% and already documents tick, so the baseline is 3; the description adds meaning by tying the value to a note's tick and bounding it to the 'known session'. It doesn't add format/syntax detail beyond that, so it sits just above baseline.

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+resource (rewind the live game to a tick) plus the mechanism (reload, replay inputs, stay paused). Distinguishes itself from siblings like game_step, game_replay and game_capture by naming the live-only scope and the exact resulting state.

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?

Explicitly scopes usage ('Live mode only'), gives a concrete trigger ('use a note's tick to look at the moment the human flagged'), and routes to follow-up tools ('then use game_state or game_capture'). The when-not (non-live modes) is stated rather than implied.

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 only declare readOnlyHint=false and destructiveHint=false. The description adds real value beyond that: values are validated against the param's type and range, and changes are ephemeral (last until game_start or reload). It does not say what happens on invalid input (error vs rejection) or whether the change is immediately observable.

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 short sentences, front-loaded with the action, then validation, then lifetime. No filler; every sentence carries 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?

For a zero-coverage, three-required-param mutation with no output schema, the description covers validation and duration but leaves the key/group addressing model and error behavior unexplained. Adequate but with clear gaps an agent needs to call it correctly.

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% for three required parameters. The description explains the semantics of 'value' (validated against the param's type and range), but gives no meaning for 'group' vs 'key' — they are not defined anywhere, so an agent must guess the addressing scheme.

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 + resource ('Set a tunable param live'), which is clear and distinct from the sibling read-oriented tool game_params. It does not explicitly name that sibling or otherwise differentiate, but the purpose is unambiguous.

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 'live' and 'tunable param' — i.e., use it during a running game to change parameters. However, there is no explicit statement of when to use this versus game_params (read) or how it interacts with game_start/reload beyond a lifecycle note.

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 signal a non-read-only, non-destructive mutation, but the description adds meaningful context beyond them: it discloses the paused on-start condition and the side effect 'Replaces any running session.' That replacement caveat is exactly the kind of behavioral trait the annotations do not capture.

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?

Front-loaded with the core purpose, then modes, then return values, then the replacement caveat. Dense but every clause carries information; slightly long single-sentence block for the auto case, but no 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 no output schema, the description usefully names the return contents (mode, state, count of flagged notes) and warns about replacing a running session. Covers the essentials for a session-launching tool; missing only explicit prerequisites/auth needs.

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%, so the baseline is 3; the description goes further by explaining the semantic of the 'auto' default (attach to live if available, else headless), which clarifies mode selection beyond the schema's terse enum descriptions. It does not elaborate on page or root, which are minor.

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 action (connect/start the game) and elaborates the three modes, making it distinguishable from siblings like game_stop, game_pause and game_state. It is clear but does not explicitly name which sibling to prefer when an agent merely wants to check status.

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 'auto (default)' behavior gives implied guidance on the common path (attach to live browser game, else start headless paused). However, it never states when to choose live vs headless explicitly, nor when NOT to call this versus game_pause or game_stop. Usage is implied rather than prescribed.

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?

readOnlyHint=true already tells the agent this is a safe read, lowering the bar. The description adds useful content detail by enumerating the payload (scene, tick, time, renderer, frame stats, inspect data), but says nothing about cost, snapshot freshness, or how it relates to the sibling frame/profile tools.

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 compact sentence-fragment with no filler; every item named is meaningful payload. It loses a point only because the fragment lacks a leading verb that would frame the whole list.

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 no output schema, the description carries the burden of describing return content, and its enumeration partially does that. However, with seven or more closely related game_* inspection siblings and no routing hints, an agent lacks enough context to know when this is the right call versus game_frames or game_profile.

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, so per the rubric the baseline is 4. There is no parameter behavior the description needs to compensate for.

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 is a bare noun list ('Current scene, tick, time, renderer, frame stats...') with no verb or framing sentence, so the purpose is only implied rather than stated. It does let an agent infer this is a read of live game state rather than a capture or profile, but it never explicitly distinguishes itself from overlapping siblings like game_frames or game_profile.

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 when-to-use guidance, no prerequisites, and no mention of alternatives among the many game_* siblings (game_frames, game_profile, game_capture, game_notes). The agent must guess which sibling returns which slice of state.

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 declare readOnlyHint=false and destructiveHint=false, so the agent already knows this mutates state without being destructive. The description usefully adds that it returns the new state and that steps run at a fixed 60/sec by default, but it omits whether the call blocks, what happens at the 36000 step ceiling, or any error behavior.

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 sentence, front-loaded with the action, no filler. The default rate and return value are packed in without wasting words.

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 one-parameter mutation with full schema coverage and annotations covering the safety profile, the description is nearly sufficient, and it even discloses the return of new state despite no output schema. It stops short of explaining blocking behavior or failure modes, which is a minor residual gap.

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 single parameter is documented, so the baseline would be 3. The description adds real meaning beyond the schema by stating the fixed rate (60 steps per second by default), which tells the agent how to translate a desired duration into a step count.

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: advancing the simulation by fixed steps, with the default rate named. It is distinguishable from game_pause/game_stop, but it never explicitly contrasts itself with nearby siblings like game_frames or game_start, so the differentiation is inferred rather than stated.

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 call this versus game_frames, game_start, or game_pause, nor any precondition such as requiring the game to be running. The default step rate hints at typical use but does not route the agent between alternatives.

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 declare readOnlyHint=false and destructiveHint=false, so the mutation profile is already covered. The description adds genuinely useful state information: in headless mode it tears down the browser and dev server (processes are killed), and in live mode it hands control back to the human and disconnects. The only gap is how the mode is determined.

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 mode-labelled clauses, no filler, front-loaded with the discriminating mode names. Every word carries 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?

For a zero-parameter, no-output-schema tool with annotations covering the safety profile, the description supplies the key missing piece: what actually happens to the environment in each mode. It could be slightly more complete by explaining what 'disconnect' ends or whether the session state is discarded.

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, so there is no parameter meaning to convey and the schema is trivially complete. Baseline 4 applies for a no-argument tool.

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 concrete effects of stopping: closing the browser and dev server in headless mode, resuming the human's game and disconnecting in live mode. It never uses the word 'stop' or explicitly contrasts with sibling tools like game_pause, but the mode-specific outcomes make the operation unambiguous.

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?

By naming the two operating modes (headless vs. live) and what each yields, it implies when the tool is appropriate and what state the session ends in. It does not say when to prefer this over game_pause or game_rewind, nor whether the caller must first be in a running session, so routing guidance is only implicit.

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?

The readOnlyHint annotation already establishes that this is a safe, non-mutating call, so the description need not restate safety. It adds useful behavioral content by naming the categories of data returned (dependencies, plugins and their contributions, assets, build size), which is real information given there is no output schema. However, it says nothing about cost, whether a build must exist first, or how stale/incremental the summary is.

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?

It is a single compact sentence fragment with no filler or repetition, and the most important token ('Summary of the project') is front-loaded. It loses a point only for being a fragment that reads as a return-value label rather than a complete instructional statement.

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 one-parameter, read-only tool with full schema coverage, the main remaining gap is the absence of an output schema, and the description does compensate by listing the categories returned. What is missing is any guidance on placement in a workflow relative to build, list_assets, or run_tests. Adequate but not complete.

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 a single optional parameter ('root') with 100% schema description coverage, so the schema already fully documents it, including the default behavior. The description adds no syntax, path, or resolution detail beyond that. Baseline 3 is appropriate when the schema carries the parameter burden.

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 is a noun phrase ('Summary of the project: dependencies, plugins and their contributions, assets, last build size') rather than a verb+resource statement, so it echoes the title 'Inspect project' more than it defines an action. It does enumerate the contents returned, which helps an agent see it is an aggregate overview, but it never says 'returns a summary' explicitly. Sibling differentiation is partial: list_assets overlaps with the 'assets' element, and nothing explains that this tool rolls them up rather than listing 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?

There is no when-to-use, when-not-to-use, or alternative routing. An agent cannot tell from the description whether to call inspect_project or list_assets first, nor whether this is a cheap orientation call before build/run_tests. Usage is only weakly implied by the word 'Summary'.

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, so safety is covered. The description adds useful output-shape context (generated files, warnings, possibly unused ids) and hints at non-trivial pipeline work via 'Run the asset pipeline', but says nothing about cost, caching, or whether the pipeline can fail.

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, front-loaded on the action and followed by the payload contents. Slightly list-heavy 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?

No output schema exists, so the description carries the return-value burden and does so by enumerating the fields returned. With readOnly covered by annotations and the sole parameter documented in schema, only usage guidance 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?

Only one optional parameter ('root') with 100% schema description coverage, so the schema fully documents it. The description adds nothing about the parameter, which is the expected baseline when the schema is complete.

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 action ('Run the asset pipeline') and enumerates exactly what is produced: asset id, type, size, importer, generated files, warnings, unused ids. That is concrete and identifiable, though it never explicitly contrasts itself with the many sibling 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. An agent must infer from context that this is the enumeration tool for project assets.

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 declare readOnlyHint=false and destructiveHint=false, so the safety profile is already carried; the description usefully adds what the run produces (per-step results, runtime errors, captures, final state). It does not disclose the write side effect implied by accepting captures as baselines, leaving a behavioral gap.

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, and the primary action plus default scope are front-loaded ahead of the return-value summary. 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?

For a no-required-param tool with no output schema, naming the returned artifacts is helpful, but the definition omits sibling routing (run_tests, fuzz) and the consequences of the update/baseline path. Adequate but with clear gaps.

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%, so all three parameters are already documented in the schema. The description only echoes the files default ('or the given files') and adds nothing about root or update semantics.

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?

Specific verb+resource: runs scenarios/*.json files in a headless browser, with scope made explicit ('or the given files'). It doesn't differentiate itself from likely siblings such as run_tests or fuzz, so the agent must infer which 'run' tool applies.

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 guidance or conditions for choosing this over run_tests/fuzz/game_replay. The description only defines file scope ('scenarios/*.json', default all), which is not the same as telling the agent when this tool is the right one.

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 state this is not read-only and not destructive. The description adds useful behavioral context beyond that: no browser, fast millisecond execution, and detailed failure output including source line and game state.

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 short sentences, front-loaded with the core action and environment. Every sentence contributes to scope, output expectations, or usage timing.

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?

No output schema exists, but the description explains failure diagnostics sufficiently for a test runner. It does not describe success output, but the purpose and invocation context are otherwise complete.

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 three parameters are already fully described in the schema. The description adds no additional parameter syntax or filtering details, so the baseline of 3 is appropriate.

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: run logic tests in tests/**/*.test.ts. It also scopes the environment to Node with no browser and distinguishes this from broader game or scenario 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?

Gives clear when-to-use guidance: after every change, and advises writing a test for each new mechanic. It does not explicitly compare against alternatives like run_scenarios or fuzz, but the context is clear.

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