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

Annotations declare openWorldHint and destructiveHint, but the description adds substantial beyond-annotation context: writes are drafts until published in Steamworks, snapshots are saved before every call, empty fields never clear Steam's, store_assets never replaces existing images, community tags are never removed, and store_tags goes live immediately. These side effects are precisely what an agent needs before a destructive-capable call.

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 dry-run-then-write workflow before the dense section catalogue, so the important guidance is not buried. It is long, but the length is largely justified by ten sections and eight parameters; the section list is information-dense rather than padded.

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 complex 8-parameter, 10-section mutation tool, the description covers the workflow, per-section semantics, parameter gates, drafted-vs-live distinction, and snapshot behavior. An output schema exists, so return values need not be described. Nothing an agent needs 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?

Schema description coverage is 0%, so the description must carry the full burden, and it does: all eight parameters are explained (path, section, app, dry_run, user_confirmed, remove_extra, upload_icons, goes_live_now), including gating conditions like 'only when the user explicitly asks for it' for remove_extra.

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 ('Make Steam match the approved values of one section') and then enumerates the exact section names it operates on with per-section behavior. An agent can distinguish this from siblings like set_field, scan_project, or mark_applied 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?

Explicitly prescribes the workflow: 'Always call with dry_run=true first and show the user the changes; write (dry_run=false, user_confirmed=true) only after they agreed.' It further names the store_tags exception with its own gate (goes_live_now=true). When-to-use and when-not conditions are fully spelled out.

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 readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: that section paths like 'apps.main.cloud' approve everything beneath them (scope expansion) and that approval must be user-sanctioned. It omits what 'approved' actually changes downstream.

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 purpose, followed by the pattern semantics and the safety caveat. The examples earn their space, though the pattern and section sentences could be tightened.

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. For a non-destructive mutation, the description covers purpose, scope behavior, and the user-consent prerequisite. It leaves the effect of approval and its relation to sibling tools implicit.

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 parameter meaning. It explains pattern syntax for the path argument ('achievements.*.name', section paths) but never clarifies the 'fields' array or maps the examples to a specific parameter, leaving half the contract unexplained.

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: 'Mark values as approved by the user.' This is clearer than the bare name and conveys the approval semantics. It does not explicitly differentiate itself from nearby siblings like set_field or mark_applied, 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?

Gives clear context for use ('after showing them') and an explicit when-not constraint ('Never approve without the user's agreement'). It does not name alternative tools for adjacent cases, 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?

The readOnlyHint=true annotation is echoed by "(read-only)", and the description adds genuine value beyond it: every finding carries a file, a line and a fix, and secrets are never surfaced. This tells the agent what the output will contain behaviorally, though it does not discuss permissions or failure modes.

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 action and scope, then a dense but informative enumeration of check categories. Every clause adds concrete scope; the parenthetical lists are long but each item earns its place by telling the agent what is inspected.

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 multi-category linting tool with an output schema present, the description covers scope, all parameters, and behavioral guarantees (file/line/fix, no secret leakage). Return values needn't be explained since an output schema exists, so nothing essential 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 description coverage is 0%, so the description must compensate, and it does: path is the game folder with steamworks.yaml, source_dir is the engine project when different from path, and rules restricts to specific rule/group ids with a pointer to get_spec_info("code_rules"). All three parameters are explained, though formats/syntax for rules remain slightly loose.

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 (check) and resource (the game's own code, engine settings, SteamPipe scripts) scoped to Steamworks rules, then enumerates the check categories. An agent can distinguish this from scan_project, validate, or steamworks_inspect from the description alone.

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?

Scope implies when it applies, and it points to get_spec_info("code_rules") for listing rule ids, which is a useful routing hint. However, it never says when NOT to use it or how it differs from siblings like validate or scan_project, leaving that to inference.

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 openWorldHint=true, so the agent knows this is a safe external read. The description adds the 15-appid cap and the default dataset, which is useful context, but it says nothing about cost, latency, or partial-result behavior beyond that.

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 comparison scope in the first sentence, then the default, then a compact Args block. Every line earns its place, though the inline Args formatting is slightly verbose.

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. For a read-only comparison tool, the description covers scope, default behavior, mutual parameter meaning, and the 15-item limit, leaving little an agent needs unstated.

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 carries the full burden and it does: path is 'the game's folder to compare with its market study', and appids is 'games to compare instead', capped at 15, with store_lookup noted as the id source. This meaningfully compensates for the undocumented schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (compare) and resource (games) and enumerates the exact dimensions compared (price, reviews, positive share, players right now, release, modes, Steam features). It partially distinguishes itself from siblings by tying the default to study_market and store_lookup, though it doesn't explicitly name what 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?

Explains the default behavior (market study games plus this game once live) and how to override it with appids, pointing to store_lookup for discovering ids. Clear context for when each parameter applies, though it stops short of explicit when-not-to-use guidance or exclusions.

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 openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior: outputs are 'rules of thumb with every assumption listed, never a forecast', and the output shape changes conditionally depending on whether wishlists 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?

Front-loaded with the core purpose and appropriately sized, with the Args block cleanly separated. The opening sentence is somewhat run-on and could be split for faster scanning, but no sentence 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?

An output schema exists so return values need no description coverage, and annotations cover the read-only/open-world profile. Purpose, all three params, and the heuristic caveat are present; only explicit sibling routing 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?

With 0% schema description coverage, the description carries the full burden and does document all three parameters in the Args block. It explains path as the game folder's market study and price, appids as substitute games, and wishlists as release-day wishlists the user may know from Steamworks.

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 verb and resource: estimating copies sold from review counts, and a first-week range when wishlists are supplied. It is distinguishable from siblings like study_reviews or compare_games, though the dense opening sentence takes effort to parse.

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 implies usage via 'close games' and the defaulting rule ('Default games: the market study's'), and clarifies the accuracy expectation ('never a forecast'). However, it never states when to prefer this tool over siblings such as compare_games or price_brief, leaving routing to inference.

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=false with destructiveHint=false, and the description goes further: it discloses the output directory layout, the file inventory, the CHECKLIST.md content (per-item target page/field), and explicitly bounds side effects ('nothing is uploaded or published'). It does not say whether existing export files are overwritten, which is the remaining 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?

One dense sentence carries the artifact list and the second sentence bounds behavior. It is front-loaded with the action and destination, though the first sentence is long and slightly overloaded with parenthetical file types.

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 explained; the description instead covers what is written, where, and the guarantee that nothing is uploaded. For a 2-parameter write tool this is nearly complete, with only the overwrite/idempotency question left open.

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 load. It partially covers 'gate' by embedding it in the path template gate_<gate>, but the required 'path' parameter is never explained, and it is unclear whether the stated output directory is fixed or derived from path.

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 gives a concrete verb and artifact: writes named localization JSON, images/icons, SteamPipe scripts, achievement icons and CSV to .steam-mcp/exports/gate_<gate>/. That level of enumeration makes it clearly distinct from siblings like generate, apply, and import_from_steamworks.

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?

'Write everything needed to finish a gate by hand' signals the context (manual completion of a gate), and 'Nothing is uploaded or published' implicitly separates it from apply/import_from_steamworks which push to Steamworks. No sibling is named explicitly and no exclusion is stated, so this falls short of a 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds meaningful behavior beyond that: data is cached locally on this machine, only derived measurements are returned, and raw texts remain in the local cache for the anti-copy check. This helps the agent understand what it will and won't receive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action and resource, followed by the scope of returned data. No filler, though the return-value summary slightly overlaps with the output 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 values need not be detailed, and annotations cover the safety profile. However, the tool still lacks usage context and any explanation of the 'tags' and 'refresh' parameters, leaving gaps for a 3-parameter tool with 0% schema coverage.

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% across three parameters. The description alludes to caching (relevant to 'refresh') but never explains 'refresh' semantics, and it says nothing about the 'tags' filter or 'appid'. With zero schema coverage, the description fails to compensate for the parameter documentation 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 states a specific verb and resource ('Fetch a successful Steam game's public data') and scopes the output ('return derived measurements only: description structure and length, media counts, categories, achievement count/style/distribution'). It does not explicitly distinguish itself from siblings like store_lookup or compare_games, but the 'derived measurements only' framing makes the purpose recognizable.

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 and no named alternatives. The agent must infer that this tool is for gathering reference/benchmark data for a successful game, but nothing states the conditions under which it should be chosen over store_lookup, study_market, or compare_games.

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; the description goes well beyond that by enumerating the item status taxonomy (fail / review / todo / unknown), the execution modes (API, BROWSER, ARTIFACT, MANUAL), that next_steps indicates ordering, and that include_info controls non-blocking background notes. This is substantive behavioral disclosure of what the report contains, though it doesn't touch cost or pagination.

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 opening sentence front-loads the purpose, followed by a compact gate legend and a clearly delineated Args block. Nearly every sentence carries information, with only minor redundancy between the prose and the Args section.

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 explanation is optional, yet the description still characterizes the payload (statuses, fields, execution mode, Steamworks location, next_steps). Combined with the gate definitions and full parameter coverage, an agent has enough to call and interpret the tool correctly; only sibling disambiguation 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 description coverage is 0%, so the description must compensate, and it does: path is defined as the folder holding steamworks.yaml, gate is bounded to 0-3 with a stated default of all, and include_info is explained as adding background notes that never block. All three parameters gain meaning beyond the bare schema types.

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 verb+resource: reporting what is still missing before each release gate and how each item gets done. A reader immediately understands the tool surfaces blocking gaps, distinct from mutating siblings like apply or set_field. It does not explicitly differentiate itself from the 'status' or 'validate' siblings, keeping it at a 4.

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 gate model (0=prerequisites, 1=store page review, 2=build review, 3=release) gives useful context for scoping the call, and 'default all' clarifies behavior. However, there is no explicit statement of when to reach for gap_report versus status, validate, or scan_project, so selection guidance is only 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 substantial behavioral context beyond them: text sections return a brief the agent must write from (the server never invents marketing text), deterministic sections mutate steamworks.yaml but 'never over approved values', and 'requirements' output is 'always to review'. This tells the agent exactly what gets written and what the safety boundaries are.

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 one-line purpose is front-loaded, and the body is split cleanly into text sections (agent-authored) versus deterministic sections (written directly), each as a tight bullet. Dense but every clause earns its place; minor verbosity in the parenthetical strategy 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?

An output schema exists so return values needn't be explained, and annotations cover the safety profile. The description supplies the missing workflow semantics and mutation boundaries, making it largely complete; the only real gap is the unexplained 'path' parameter, which an agent still has to infer.

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 carries the full burden. It documents the 'section' values thoroughly (store_short, store_long, achievements, cloud, builds, requirements, code) and explains 'stage' for store_long ('outline' then 'text'), but the required 'path' parameter is never explained anywhere. It compensates well for two of three parameters but leaves the third undocumented.

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 gives a concrete verb+resource ('Produce drafts for a part of the release') and enumerates the section types it handles, which distinguishes it from write-oriented siblings like save_draft, set_field and apply. The generic tool name 'generate' is rescued by the description, but sibling differentiation is only implicit 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?

It gives explicit per-section workflow: store_short means one variant per listed strategy saved via save_draft; store_long requires staging 'outline' before 'text'; deterministic sections write straight to steamworks.yaml. This is strong routing guidance, but there is no explicit 'when not to use this' statement or named alternative tool for the deterministic path.

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 safe read-only profile, so the description only needs to add context. It does add value by disclosing the breadth of retrievable content (schemas, gates, capabilities, rules, patterns) and that some kinds are parameterized (gate:<0-3>, style_guide:<id>, reference:<appid>), but says nothing about response shape or size.

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?

Purpose is front-loaded in the first line, followed by a compact list of kinds. The list is dense and slightly run-on but every entry earns its place by defining a valid parameter value.

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 parameter enumeration is thorough. The definition is complete for a lookup tool, with only minor gaps around usage relative to overlapping siblings.

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 0% schema coverage on the single 'kind' parameter, the description fully compensates by enumerating every valid value and explaining what each returns, including templated forms. This is exactly the semantic detail the bare string schema lacks.

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 the tool as reference-data retrieval and frames it as the tool equivalent of the server's resources for tool-only clients, which is a clear and specific purpose. It distinguishes itself from action-oriented siblings like scan_project or generate, though it uses no explicit verb.

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 implies when to use it ('for clients that only use tools') and reveals the coverage of each kind, but offers no explicit when-to-use vs. alternatives guidance relative to siblings such as steamworks_inspect or study_market, which also surface reference-style 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?

Goes well beyond the annotations: it discloses that it never writes to Steamworks, never overwrites existing file values, and that differences surface as conflicts for the user. This explains the otherwise confusing readOnlyHint=false + destructiveHint=false combination and clarifies concurrency/safety behavior the annotations cannot express.

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?

Dense and front-loaded: the qualifying condition, then the action, then the safety guarantees, then the workflow, then prerequisites. No sentence is filler and the sequencing mirrors how an agent should reason about calling it.

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 mutation tool with an output schema (return values need no explanation here) and non-obvious side effects, the description covers scope, safety, workflow ordering, and prerequisites. Nothing an agent needs 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?

Schema description coverage is 0%, so the description must carry the load. It clarifies dry_run semantics and enumerates the section values (matching the enum), which is strong compensation, but the 'app' enum (main/demo/playtest) and 'path' remain unaddressed.

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+scope: read Steam data and fill EMPTY fields of steamworks.yaml, enumerating exactly which sections (store texts, achievements, cloud, installation, leaderboards, checklists) it covers. The 'already exists in Steamworks' qualifier immediately distinguishes it from tools like init_project or steamworks_inspect.

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 the entry condition ('a game that already exists in Steamworks'), the ordered workflow ('Dry run first; save with dry_run=false after the user agreed'), and the environmental prerequisite (publisher key for leaderboards, BROWSER mode for the rest). An agent knows when and how to invoke it without inference.

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=false, destructiveHint=false, and openWorldHint=false. Beyond that the description adds genuinely useful behavioral context: existing files are kept and never overwritten, the server never edits the project's own .gitignore (it only suggests lines), and scanning can be suppressed via `scan`.

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 behavioral summary is front-loaded in the first sentence, with parameters and return values in a clean structured block. Slightly verbose, but each line 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?

The tool has an output schema, so return values need not be explained, yet the description still summarizes them (created/existing files, .gitignore lines, scan report). Combined with full parameter coverage and mutation context, it is essentially 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 0%, so the description must carry the burden, and it does: all five params (path, name, appid, scan, source_dir) are given meaning beyond their JSON types, e.g. path is 'usually the game project's root' and source_dir applies 'when it is not `path` itself.'

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 opens with a specific verb+resource: 'Start tracking a game: create steamworks.yaml and .steam-mcp/ in `path`.' It is clearly distinguishable from a bare scanner like scan_project because it states it creates tracking files and then scans. It stops short of naming a sibling or a decision boundary, so it is clear but not sibling-differentiating.

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 rather than stated: this is obviously the first step of a workflow, and 'scan the game project unless `scan` is false' describes internal sequencing. There is no explicit when-to-use/when-not or pointer to an alternative tool, so it lands at minimum-viable.

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 say it is a non-read-only, non-destructive, non-open-world operation. The description adds the key behavioral fact that output is written to .steam-mcp/exports/code/<target>/ and 'never into the game', plus the scope of generated features — real information 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 lead sentence front-loads the deliverable and its constraints, then an Args block documents each parameter without repetition. The lead sentence is dense but every clause (output location, 'never into the game', name sourcing) 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 an output schema present, return values need no explanation, and all four parameters plus the steamworks.yaml prerequisite and output destination are covered. Minor gaps remain: no mention of behavior when steamworks.yaml is absent or how this relates to `apply`/`check_code` in the workflow.

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 carries the full load and does: path is the game folder with steamworks.yaml, features lists the exact enum values and the 'default all', target enumerates the supported engines with a concrete mapping (godot = GodotSteam 4) and a default-derivation rule, and source_dir is explained as needed only when it differs from path.

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 concrete deliverable — Steamworks SDK integration code for the game's engine — and enumerates the covered concerns (init/lifecycle, achievements, stats, leaderboards, cloud). It is clearly distinct from siblings like `check_code`, `apply` or `generate`, though it never explicitly contrasts itself with 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 context is clear: it emits code keyed to the app id and names in steamworks.yaml, and the target defaults to whatever engine/wrapper the project already uses. There is no explicit when-not-to-use guidance or pointer to a sibling for overlapping tasks (e.g. applying the code).

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 flag openWorldHint=true, readOnlyHint=false, and destructiveHint=false; the description usefully explains the non-read-only aspect by disclosing that each check is persisted to .steam-mcp/market/launch.jsonl and compares against the previous run. It does not mention auth needs or rate limits, but the persistence side-effect is well covered.

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 "After release" condition, keeps the payload list compact, and uses the parenthetical only for essential persistence detail. Two sentences with little waste.

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 explanation is unnecessary, and the description supplies the post-release context, metric set, and persistence behavior. The only real gap is the unexplained "path" parameter.

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 required parameter, "path", at 0% schema description coverage, and the description never explains what it expects (project path? file path? Steam app id?). Unlike the zero-parameter baseline, this description leaves the sole parameter entirely undocumented.

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 (post-release metrics: review score/count, current players, price) and an implicit verb, tracking against the last check. It is clear what the tool does but does not explicitly differentiate itself from siblings like study_reviews or price_brief.

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?

"After release" gives a clear temporal context for when to invoke it, and "Call it again any day to see the trend" tells the agent to reuse it for trend tracking. It stops short of naming alternatives or exclusions (e.g., versus study_reviews).

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?

With readOnlyHint=true already declaring the safety profile, the description still adds meaningful behavior: stale entries carry the previous translation to update, results are enriched with context and glossary terms from localization/glossary.yaml, and the operation is part of a repeat loop. These are non-obvious traits 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?

Three tight sentences, front-loaded with what the tool returns and immediately followed by the action to take. Every sentence contributes; only the parenthetical glossary path is slightly incidental.

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-field explanation is not required, and the description covers the translate-then-set loop and stale handling well. However, for a 3-parameter tool with 0% schema description coverage, the unexplained `path` and `limit` parameters leave a real 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 description coverage is 0%, so the description must carry parameter meaning. It clarifies that `language` is a Steam API code, but says nothing about `path` or `limit` (default 30), leaving two of three parameters undocumented in both schema and description.

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 it returns the source-language texts that need translating into the target `language`, with context, length limits, and glossary terms. That is a specific resource plus scope, and it is distinguishable from siblings like localization_status and localization_set. It lacks an explicit verb ('list/returns') but the intent 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?

It gives a clear workflow: translate the returned items, then call localization_set, and repeat until nothing is pending. The next-tool alternative is named explicitly. It does not state when-not-to-use it (e.g., versus localization_status), which keeps it short of a 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?

Annotations already declare non-readonly, non-destructive, closed-world execution, and the description layers on genuinely new behavior: three concrete rejection conditions (BBCode mismatch, >300-char short description, Valve store-text violations) and the draft/approval lifecycle. That is substantial disclosure beyond the annotation surface, though it does not address permissions or idempotency.

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 action, then validation rules, then the approval caveat — no filler. The parenthetical syntax is dense but each sentence carries 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 values needn't be explained, and the description covers the mutation's semantics, failure modes, and the required follow-up approval step. The main remaining gap is the undocumented 'path'/'source' parameters.

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 four parameters, so the description carries the full burden. It clarifies the shape of 'translations' ({key: text}) but says nothing about 'path', 'language', or the 'source' enum (generated vs user), leaving over half the parameters undocumented anywhere.

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 ('Save translations') and even sketches the payload shape ('{key: text}'), which cleanly separates it from read-side siblings like localization_status and localization_pending. It stops short of explicitly naming an alternative, so it falls just below the top score.

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?

Implies clear context: writes go in as drafts that only become live after the user approves via approve_fields, which tells the agent where this tool sits in the workflow. It does not state when to prefer this over set_field or state any preconditions, so not a 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?

Annotations declare destructiveHint=false and openWorldHint=false, so safety is largely covered structurally. The description adds genuine domain semantics beyond them: it defines 'stale' as the source changing after translation and notes such items are marked needs_review, and it explains that `next` names the recommended language. That is real behavioral value on top of 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 scope ('Per target language') is front-loaded and the parenthetical definition of stale is dense but earns its place. Two short sentences carry the whole payload with little waste, though the parenthetical is slightly overstuffed.

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 re-explained, and the description helpfully glosses the `next` field. However, for a tool with one undocumented required parameter and no routing guidance relative to localization siblings, the definition is only minimally 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 0% and the single `path` parameter has no description in either the schema or the description text. With one required parameter and no explanation of what path refers to (project root, locale directory, etc.), the description fails to compensate for the coverage 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 states a specific resource and scope: per target language counts of player-facing texts that are translated, missing, or stale. An agent can tell it is a localization reporting tool. It does not, however, differentiate itself from siblings like localization_pending or localization_set, which an agent might otherwise consider.

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 description explains what is reported but never says when to call this tool, what preconditions apply (e.g. a project must be initialized/scanned), or how it relates to localization_pending and localization_set. Usage is only implied by the tool name.

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 this is a non-read-only, non-destructive, non-open-world write. The description adds meaningful context beyond that: it is a stateful confirmation gated on user approval and unchanged values, and it must not be invoked autonomously. It does not describe side effects on dependent artifacts, but the key behavioral constraint is well covered.

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 compact sentences, front-loaded with the core meaning and the operational constraint. Dense but every clause carries information; 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?

An output schema exists so return values need no explanation, and annotations cover the safety profile. However, for a 3-parameter mutation tool with 0% schema coverage, the description leaves parameter usage undocumented, which is a real gap for correct invocation.

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% across three parameters (path, fields, notes), so the description carries the full burden. It hints that 'fields' correspond to approved values and references 'checklist.<rule id>', but never explains what path, fields, or notes actually accept or how they map.

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 action (marking something 'applied' in Steamworks) and pins down what the object is: a manual step keyed as 'checklist.<rule id>' from gap_report, or user-approved values. It is clear enough to separate from siblings like apply or approve_fields, though the phrasing is somewhat indirect.

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 an explicit when-not: 'Never call this on your own: only when the user says it is done.' It also states the precondition that only approved, unchanged values qualify, and points to gap_report as the source of the item.

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 non-readonly, non-destructive, non-openWorld, but the description adds genuinely useful behavior beyond that: it crops around assets.key_art_focus, never stretches, reports upscaling, never generates artwork, and writes output plus a preview page to .steam-mcp/exports/images/. It stops short of stating overwrite behavior or whether existing files are replaced.

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 action and dense with useful specifics; every clause conveys something concrete. Slightly long but no filler or repetition, so it stays efficient.

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 values need not be described, and the description still tells the agent where files land and that a preview page is produced. The main gap is the unexplained 'only' and 'path' parameters, otherwise this is adequate for the task.

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 carries the full burden and largely fails. It explains the achievement_icons behavior (256x256 JPG with greyscale locked versions), but 'only' and the required 'path' parameter are never clarified, leaving two of three params undocumented in both schema and prose.

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 ('make every store, library and icon image... plus achievement icons') and names the exact input assets (assets.key_art, assets.logo, assets.overrides) plus the output location. It even distinguishes itself from generative siblings by stating 'never generates artwork'.

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 context is implied (produce Steam-ready images for the user to upload) and the input sourcing is clear, but it never routes the agent explicitly against siblings like generate, export_package, or apply. No when-to-use-vs-alternative or prerequisite guidance is given.

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 say it is not read-only and not destructive; the description goes further by naming the output location (.steam-mcp/exports/), confirming it writes a file, and honestly flagging that the first-screen mark is an estimate because Steam's cut-off height is undocumented. That uncertainty disclosure is valuable context not available in structured fields.

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?

Compact and front-loaded: the action and destination come first, followed by the caveat. No wasted sentences, though the parenthetical caveat slightly crowds the single sentence.

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 purpose/output path are covered. However, for a 4-parameter tool with zero schema description coverage, the description leaves parameter meaning largely unexplained, so it is only minimally 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 coverage is 0% for 4 parameters, so the description must carry the load. It only indirectly gestures at about_draft/short_draft ('the given drafts') and fold_px ('estimated end of the first screen'), without naming any parameter or explaining units, defaults, or what 'path' refers to.

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: 'Write an HTML preview of the store text' plus the output directory. It is clearly distinct from read-only inspection tools, though it does not explicitly name which sibling (e.g. export_package or validate) it replaces.

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 description offers the choice of 'current values, or the given drafts' but gives no guidance on when to run this versus sibling tools like validate, export_package, or apply. There are no prerequisites or exclusions 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 already declare readOnlyHint=true and openWorldHint=true, so 'Nothing is saved' largely restates the read-only hint. The description adds a little (defaults sourced from the market study, the user retains pricing control), but no auth, rate-limit, or data-source caveats beyond that.

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 front-loaded opening sentence is heavily nested with parentheticals and clauses, making it hard to parse on first read. The Args block is clean and well-structured, but the prose could be tightened.

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 explained, and all parameters are documented despite 0% schema coverage. For a read-only pricing comparison this is nearly complete; only the routing vs sibling tools 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 0%, so the description must carry the burden, and it does: path ('The game's folder'), appids ('Games to compare with instead of the market study's'), and countries (two-letter store codes with the full default list). All three parameters gain meaning the bare schema lacks, though 'the game's folder' remains slightly vague.

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 computation: close games' US full prices (median and middle half) plus per-country charge-per-US-dollar applied to this game's base price. That is a concrete verb+resource an agent can identify. It doesn't explicitly differentiate itself from siblings like compare_games or study_market, keeping it just below the top band.

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 useful defaults ('Default games: the market study's', default country codes) and a decision note ('the user decides the price'), but never states when to choose this tool over compare_games, estimate_sales, or study_market. Usage is implied rather than spelled out.

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 readOnly=false, destructive=false, openWorld=false. The description goes well beyond that: it discloses rejection rules (Valve store rules, 8+ consecutive words copied from a reference game), rubric scoring, and the shape of the response (rubric findings plus questions). This is exactly the behavioral context annotations cannot carry.

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 action and the non-mutation constraint, then validation behavior, then the strategy values, then the handoff. The strategy enumeration and trailing ellipsis make it slightly run-on, but 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?

An output schema exists, so return values need not be explained, yet the description still summarizes them (rubric findings plus questions). The validation rules and the set_field handoff make the workflow complete; the only real gap is the undocumented meaning of path/field/value.

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% across 5 parameters, so the description must compensate. It enumerates accepted strategy values (fantasy, mechanic, situation_humor, market_common, market_contrast, outline, text, revision) which is genuinely useful, but path, field, value, and notes remain undocumented in both schema and description.

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 ('Store a text YOU wrote as a draft') and immediately scopes it against the sibling that applies drafts ('it does not change steamworks.yaml', 'The user picks a draft with set_field(...)'). An agent can distinguish save_draft from set_field 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?

Names the follow-up alternative (set_field with from_draft=<id>) and the condition that selects it, and clarifies that this tool only stages text rather than applying it. It stops short of stating explicit exclusions (e.g. when to use set_field directly instead of drafting), but the workflow context is clear.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds genuinely useful behavior beyond that: it discloses what is persisted (labels, notes, numbers, never page text) and a concrete validation rule (a note repeating 4+ consecutive words of the page is rejected). It does not say whether re-saving overwrites an existing study.

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 action is front-loaded and every clause carries information (field list, vocabulary rule, word-repeat constraint, persistence note). The single dense paragraph is a touch long and could be split, but there is little wasted text.

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 values need not be described, and annotations cover the safety profile. The description supplies workflow position, the notes structure, and validation behavior, making it complete enough to call correctly; only the meaning of 'path' and re-save semantics are absent.

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 param burden. It does this well for notes, enumerating the required fields (appid, short_opening, short_moves, about_shape, about_sections, tone, technique) and the vocabulary constraint, though 'path' is left unexplained. Substantially compensates for the coverage 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 states a specific verb (Save) and resource (labels for the pages study_market returned), and names both the producing sibling (study_market) and the consuming sibling (generate), so an agent can place it in the workflow. It does not explicitly contrast with the near-twin sibling save_review_study, leaving that distinction to inference from the 'market' vs 'reviews' wording.

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 context is clear: this is called on the output of study_market and generate builds on it afterward, giving a clear before/after position. There are no explicit exclusions or prerequisites stated (e.g., what happens if a study already exists), so it stops short of a full when/when-not treatment.

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 establish this is a write (readOnlyHint=false) that is non-destructive (destructiveHint=false), so the safety profile is covered. The description adds genuinely useful context beyond that: it stores labels and shares but 'never review text', and it discloses a validation rule (insight repeating 4+ consecutive review words is rejected).

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?

Dense and front-loaded: the core action and the label structure come first, followed by storage and validation caveats. Every clause carries information (theme counts, ordering, insight rule, storage scope), with little waste.

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. For a two-param write tool the description covers what is stored, the validation rule, and downstream use; the only real gap is the unexplained 'path' parameter.

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 the two parameters. The description partially compensates by describing the shape of the 'notes' entries (per appid: praised 1-4 themes, criticized 0-4, insight one sentence), but the required 'path' parameter is never explained, so coverage remains incomplete.

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 (save) and resource (labels for the games study_reviews returned), and it is clearly the write counterpart to the sibling study_reviews. The 'save your labels' framing plus the enumerated label structure makes the intent unambiguous, though it does not name a sibling it must be distinguished from.

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 rather than stated: the agent infers it is called after study_reviews returns games, and 'the store-text briefs use it' hints at downstream consumption. There is no explicit when-to-use/when-not or a named alternative, leaving routing to inference.

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?

Goes well beyond the annotations by disclosing that findings become drafts tagged source "scan" with file/line evidence and confidence, that approved values are never overwritten and surface as conflicts, that raw observations land in .steam-mcp/scan/, and that it is read-only toward the game project. This also reconciles the readOnlyHint=false annotation (it does write steamworks.yaml) with the read-only posture toward the engine project.

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 core action and outcome, then adds the conflict rule and read-only scope before a compact Args block. Every sentence carries distinct, decision-relevant information with no redundancy.

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 explained, and the description still covers the side effects (drafts, conflicts, observation storage) an agent needs before invoking. Nothing material is missing for a two-parameter scan-and-merge 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 load — and it does, defining path as the folder holding steamworks.yaml and source_dir as the engine project folder when it differs from path. The subtle relationship between the two is spelled out, though no format/example detail is added.

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 (scan the game project) and its exact output behavior (merge findings into steamworks.yaml as drafts). The tool's distinct role — auto-discovering and drafting, versus a sibling like import_from_steamworks which pulls from Steam — is clear without opening a 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 description explains the merge/conflict semantics well but never states when to choose this over alternatives such as import_from_steamworks or init_project. Usage is implied by the behavior rather than stated as an explicit when/when-not 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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the bar is lower. The description adds one genuine disclosure beyond the annotations - '(no secrets)' - signalling the response is safe to surface, but says nothing about auth requirements, caching, or freshness.

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 sentence fragment with no filler; the most decision-relevant content (what is returned) comes first and the caveat is parenthetical.

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, the description needn't enumerate return fields, and it correctly stays short for a zero-parameter read tool. Only minor gaps remain around when to prefer it over related info 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 there is nothing for the description to disambiguate; baseline 4 applies. Schema description coverage is 100% and the empty argument object is self-explanatory.

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 fragment names the concrete resource contents returned: server version, workspace root, and enabled optional features. An agent can tell this is a server/environment introspection call, distinct from project-oriented siblings like status or get_spec_info, though the phrasing lacks an explicit verb and never names those siblings.

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 statement of when to call this versus alternatives, nor any prerequisite or context. The mention of 'which optional features are enabled' hints at capability discovery, but the agent must infer that usage on its own.

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 destructiveHint=true and openWorldHint=true, so the description isn't the sole source of the risk profile. It nonetheless adds valuable context: publisher-key auth, Web API nature, the dry-run safety workflow, and the guarantee that the default branch is never touched. It stops short of stating exactly what happens to players currently on the branch.

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 tight sentences with the action and scope front-loaded, the safety workflow second, and the boundary condition last. 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?

An output schema exists, so return values need not be described, and the critical safety/mutation workflow is covered. The remaining gap is the unexplained path/app/description parameters against 7 params at 0% schema coverage, which leaves a little ambiguity for a destructive operation.

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 parameter meaning, and it does clarify branch, dry_run (must precede the live call), and user_confirmed (explicit agreement) implicitly. However, path, app, and description are never explained, leaving several parameters undocumented in both places.

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 (set live) and resource (an uploaded build) scoped to a beta branch, and explicitly excludes the default branch. An agent can immediately tell this apart from generic build or status siblings.

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 explicit ordering (dry run first), a precondition (only after the user explicitly agreed), and an alternative workflow for the excluded case (do it in Steamworks Settings > SteamPipe > Builds). Nothing is left to inference about when to invoke 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 already declare readOnlyHint=false and destructiveHint=true, and the description adds real behavioral context on top: generated store text violating Valve's rules is rejected, and setting a value to null removes it (a destructive side effect made explicit). It stops short of stating permissions or reversibility.

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 core action and then layers the source/draft semantics and path examples; nearly every clause earns its place. It is dense but not padded, though the path-example sentence is somewhat lengthy.

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 annotations cover the safety profile. For a 7-param mutation tool the description is largely complete, with the only real omission being the `notes` parameter.

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 0% schema description coverage the description must carry the load, and it does for most parameters: field, value, values, source, and from_draft are all explained with examples. However, the `notes` parameter is entirely undocumented and `path` (the required param) is only implied by 'into steamworks.yaml', leaving a 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 verb (write) and resource (value into steamworks.yaml) with two explicit modes (single field+value vs. bulk values). It also names the draft workflow, letting an agent distinguish it from siblings like save_draft and approve_fields 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?

Gives clear conditional guidance for the source parameter (user=approved, generated=draft-for-review) and for from_draft. It does not, however, explicitly state when to prefer set_field over siblings such as save_draft, approve_fields, or apply, so alternatives are implied rather than enumerated.

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 non-read-only, non-destructive, non-open-world; the description adds real behavioral context beyond that, notably that with MCP elicitation support the answers are saved immediately as a side effect, plus the type-coercion of free-text answers. This surfaces a side effect the annotations alone would hide.

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?

Mostly efficient and front-loaded, with the interview-flow explanation preceding the Args block. It is somewhat dense and has a mid-sentence line break, but each clause carries useful information rather than repetition.

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 documentation is unnecessary, yet the description still describes the returned question shape (`confirm` flag) and the answer format. Combined with the alternative-routing notes, an agent has enough to call and chain this tool 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 coverage is 0%, so the description carries the full burden and does compensate: it defines `path` (folder holding steamworks.yaml), `gate` (0-3), `max_questions` (1-5, default 3), and `use_form`. It adds range constraints and purpose beyond the bare schema types, though it could be slightly more explicit about defaults.

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 explains that this returns the next batch of interview questions with suggested answers, and that `confirm: true` marks a value already found (e.g. by the scan) needing only confirmation. It distinguishes itself from siblings by routing store-text questions to `generate` and answer-saving to `set_field`. The opening fragment 'Next questions for the user' lacks a strong verb, but the purpose is recoverable.

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 states the workflow (ask in chat, then persist via set_field) and names explicit alternatives/exclusions: store texts go to `generate`, and `use_form=false` disables the form path. It does not cover when to begin an interview versus other flows, but the routing guidance is clear.

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 annotation already declares this is a read-only operation, so the safety burden is low. The description adds useful behavioral context by explaining what the tool reports in each mode, including statuses, translations, and a recommended next action.

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 brief and front-loaded with the most important routing information. Every sentence contributes to understanding the two modes and the path argument.

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 one optional parameter, a read-only annotation, and an output schema, the description supplies everything an agent needs to decide when and how to call the tool. It does not need to explain return values because an output schema already exists.

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 parameter meaning. It does so precisely: `path` is defined as the game folder containing steamworks.yaml, relative to the workspace root, and the omitted-path behavior is fully described.

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 tool's two modes: without `path` it lists games in the workspace, with `path` it reports release progress, values, store text/translations, and the next action. This goes beyond restating the name, but it does not explicitly distinguish itself from sibling tools such as `compare_games` or `launch_watch`.

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 opening 'Start here' gives clear entry-point guidance, and the path/no-path distinction tells the agent exactly when to use each mode. However, it does not name alternative tools or describe when not to use this 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered and the bar is lower. The description reinforces 'read-only' and adds that snapshots are 'local' and that pending reflects the unpublished Publish-tab changes, which is useful context, but it doesn't state auth requirements or rate/scope limits beyond the mode split.

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 purpose is front-loaded in the first sentence and each value's gloss earns its place. The formatting is cramped with awkward line breaks inside quoted strings, but there is little wasted text.

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 needn't be described, and the enum-value glosses cover much of the 'what' surface. But with 0% schema description coverage, the missing 'app'/'path' semantics and the undocumented depots/store_tags values leave the definition short of fully self-sufficient.

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 param burden, and it does explain roughly ten of the fourteen 'what' values with helpful parentheticals (e.g. store_assets = image slots filled, checklist linked to gap_report rule). However, it omits 'depots' and 'store_tags' entirely and never explains the 'app' (main/demo/playtest) or required 'path' parameters, leaving the coverage incomplete.

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 (read-only look/inspect) and resource (Steam state) with scope 'what Steam has now'. It is clear what the tool does, though it does not directly contrast itself with siblings like status or gap_report, which is referenced only in passing.

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 implicitly guides usage by splitting the 'what' values into two operating modes (publisher key vs BROWSER mode), which tells the agent which values are available under which auth. However, it never names an alternative tool or states when NOT to use this 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the data is public, cached for a few hours (relevant for freshness/staleness), and 'nothing is saved in the project' (a non-obvious side-effect guarantee). That is real added value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and resource, followed by the field enumeration and the caching/persistence caveat. Every clause carries information, though the long comma list of return fields is dense and could be trimmed since an output schema already exists.

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 annotations covering the safety profile and an output schema covering return values, the description only needs to add input semantics and behavior, and it does both. Accepted query formats and the caching/no-persistence behavior are stated; only the precise link/ID format is left implicit.

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% for the single 'query' parameter, so the description must carry the semantics. It does so by naming the three accepted input forms ('by name, app id or store link'), which the schema does not express. It stops short of giving format examples (e.g., a store-link shape), so it compensates well but not completely.

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 ('Look a game up on the Steam store') and then enumerates the returned data (price, review score, players right now, release date, genres, etc.), which makes the tool's scope unambiguous. It does not, however, name or distinguish itself from any sibling (e.g., preview_store, compare_games, study_market), so it falls 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?

The description implies when the tool is useful by listing the data it returns and noting the accepted input forms ('by name, app id or store link'), but it gives no explicit when-to-use/when-not guidance and never routes the agent to an alternative tool. Usage is inferable 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?

Adds real behavioral context beyond the annotations: only app ids are persisted, the texts stay in a local cache, and drafts are checked against them. This clarifies the side effects of a non-read-only tool (readOnlyHint=false, openWorldHint=true) and is consistent with both hints.

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 purpose, then the storage semantics, then a clearly labelled Args block. Slightly dense, but every sentence carries information and nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be described, and the description covers purpose, parameters, side effects and the follow-up call. It is complete for the call itself, though it never situates the study against sibling research 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 description coverage is 0%, so the description must compensate, and it does: it explains that path is the folder holding steamworks.yaml, tags are Steam tag names used instead of store.tags (most specific first), and games has a 3-15 range with default 10. Only the tags ordering constraint goes slightly beyond, but overall the params are well documented.

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 ('Start a market study') plus the exact selection criteria (most specific tags, Popular New Releases/Top Sellers, last 3 years) and what it returns (short descriptions and About texts). An agent can distinguish it from study_reviews, compare_games and store_lookup 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?

Gives clear context ('before writing the store text') and an explicit follow-up step ('Then call save_market_study'), plus a parameter alternative ('instead of store.tags'). It stops short of naming or excluding specific sibling tools, so it is strong but not a full when/when-not map.

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 openWorldHint=true; the description adds genuinely non-derivable context: only app ids are saved, review texts stay in the local cache, and no reviewer information is fetched. It does not cover failure behavior or whether this must follow study_market, so it stops short of full disclosure.

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?

Purpose, workflow, and persistence caveat are front-loaded before the Args block, and the Args block maps cleanly to the three parameters. It is somewhat verbose, but every sentence carries operational information, so little 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?

An output schema exists, so return values need not be described; the description still indicates that themes are returned and how to use them. Persistence semantics and parameter constraints are covered. Minor gaps remain around prerequisites (e.g. whether a market study must exist first).

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 carries the whole burden and does so: path is the game's folder, appids overrides the market study's default, and per_kind defines reviews per game and kind with the 3-25 range and default 10. The 3-25 constraint is not expressed anywhere in the schema, adding real value.

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 ('Start a review study') plus the exact scope of what is fetched (most helpful positive and negative English reviews) and the workflow it kicks off. It is clearly distinguishable from siblings: save_review_study is the follow-up step and study_market is the source it defaults to.

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 names the default target (the market study's close games), the override condition and parameter ('appids: Games to study instead of the market study's'), and a concrete trigger ('this game after launch'). It also dictates the required next action ('then call save_review_study'), leaving no routing ambiguity.

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 reinforces this with 'without changing it'. It adds genuinely useful behavior beyond the annotation: the two-phase judge-then-resubmit flow with llm_judgements, and that deterministic and judged results are reported separately.

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 lead sentence is front-loaded and every subsequent clause (sections, workflow, fix path) earns its place. The inline 'section:' formatting and leading whitespace are slightly rough, but the content is dense and purposeful rather than padded.

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, and the description covers the section taxonomy, the interactive judgement loop, and the fix path. For a three-parameter tool the only real omission is documentation of the 'path' argument.

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 0% schema description coverage the description must carry the load, and it does well for two of three params: it enumerates the section values and spells out the llm_judgements object shape ({rule_id, field, outcome, note}) with the pass|warn|fail outcome domain. The required 'path' parameter is left entirely unexplained, a minor remaining 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 gives a specific verb+resource: it reviews/validates the contents of steamworks.yaml (and translations) without modifying it. The 'without changing it' clause usefully distinguishes it from save_draft, though it doesn't explicitly contrast with other diagnostic siblings like gap_report or scan_project.

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 clearly states the use case (review before changing) and enumerates the section choices ('store', 'achievements', 'localization', 'all'), then describes the two-phase workflow for store text. It also points to save_draft(strategy='revision') for fixes, giving a clear alternative, but stops short of explicit when-not-to-use guidance.

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