Steamworks Release Assistant

save_review_study

Save game review labels by appid: praised themes, criticized points, and a one-sentence insight. Stores labels and shares them, not review text, for store-text briefs.

Instructions

Save your labels for the games study_reviews returned: per game appid, praised (1-4 themes, most important first), criticized (0-4) and insight (one sentence in your own words; one that repeats 4+ consecutive words of a review is rejected). Keeps labels and shares, never review text; the store-text briefs use it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>",
      "notes": "<notes>"
    },
    "name": "save_review_study"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes
`notes`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Oct 3, 2026

TDQS

A3.7/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.