Steam MCP Server

Overview Schema Source Related Servers Discussions Admin

Get review trend over time

get_review_histogram

Read-only

Retrieve a game's review trends by appid, showing long-term history and recent daily breakdowns with positive/negative counts and percentages to assess if reviews are improving or if updates hurt reception.

Instructions

Get how a game's reviews trend over time by appid: a long-term history (rollup_type reports each entry's granularity, e.g. 'week' or 'month', chosen server-side by Steam; capped at the most recent 24 entries) and the recent per-day breakdown (capped at the most recent 30 days), each with positive/negative counts and positive %. Good for 'are reviews improving / did an update hurt reception'. An unknown appid comes back as empty history/recent arrays rather than an error — Steam answers success for any id — so an empty result means either no such appid or a game nobody has reviewed yet; confirm the appid with get_game if that distinction matters. For a current summary and example review text instead of a trend, use get_game_reviews. Get the appid from search_games. No API key required.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`appid`	Yes	Steam application id (appid). Get it from search_games.

Output Schema

TableJSON Schema

Name	Required	Description
`recent`	Yes
`history`	Yes
`rollup_type`	Yes	Granularity of each `history` entry's date bucket, e.g. 'week' or 'month' — chosen server-side by Steam and passed through as a free-form string (not validated or enumerated here), so don't assume a fixed set of possible values.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.14.0Sep 27, 2026
- removedOutput schema / properties / history / items / properties / date / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / history / items / properties / date / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / history / items / properties / positive_pct / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / history / items / properties / positive_pct / type
```
Added value: +[
+  "number",
+  "null"
+]
```
- removedOutput schema / properties / recent / items / properties / date / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / recent / items / properties / date / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / recent / items / properties / positive_pct / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / recent / items / properties / positive_pct / type
```
Added value: +[
+  "number",
+  "null"
+]
```
- removedOutput schema / properties / rollup_type / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / rollup_type / type
```
Added value: +[
+  "string",
+  "null"
+]
```
Changed1 schema field changedv0.12.1Jul 30, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
Addedv0.10.4Jul 26, 2026
Removedv0.9.0Jul 18, 2026
Addedv0.8.0Jul 17, 2026
Removedv0.8.0Jul 17, 2026
First observedv0.1.0Jun 29, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses key behaviors: server-side rollup granularity, caps of 24 long-term entries and 30 recent days, empty arrays for unknown appids instead of errors, Steam's success-for-any-id behavior, and no API key requirement.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: core behavior first, then caps, then empty-result semantics, then sibling routing, then appid sourcing, then auth. It is front-loaded with the most important operational detail before caveats.

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

Completeness5/5

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

The description covers what the tool returns, how results are capped, the rollup_type semantics, the empty-array ambiguity, how to disambiguate with get_game, and which sibling to use for non-trend data. With an output schema also present, nothing needed for correct invocation is missing.

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 coverage is 100% and the schema already documents the appid parameter and tells the agent to get it from search_games. The description adds the empty-result caveat for unknown appids, but that is more behavioral than parameter-level meaning, so the baseline of 3 is appropriate.

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

Purpose5/5

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

The description states a specific verb and resource: 'Get how a game's reviews trend over time by appid'. It also distinguishes itself from the sibling get_game_reviews, which returns a current summary and example review text instead of a trend.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly gives use cases ('Good for are reviews improving / did an update hurt reception') and names the alternative get_game_reviews when trend data is not what is needed. It also instructs the agent to get appid from search_games and to confirm unknown appids with get_game.

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