Skip to main content
Glama

steam_reviews

Read-only

Returns a page of user reviews for an app with cursor pagination and an aggregate query_summary (score, positive/negative totals). Aggregate totals populate only on the first page (cursor=*). Pass the returned cursor back to page. Credential-free public Steam storefront JSON. appid: Numeric Steam app id. day_range: Look-back window in days (filter=all only, max 365). Use steam_reviews_histogram to get the review up/down histogram for a Steam app.

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": {
      "appid": "<appid>"
    },
    "name": "steam_reviews"
  }
}

Input Schema

NameRequiredDescriptionDefault
appidYesNumeric Steam app id
cursorNoPagination cursor from the previous page
filterNoSort order. Documented values: recent, updated, all.
languageNoSteam language name or 'all'
day_rangeNoLook-back window in days (filter=all only, max 365)
review_typeNoReview sentiment filter. Documented values: all, positive, negative.
num_per_pageNoReviews per page (max 100)
purchase_typeNoPurchase source filter. Documented values: all, steam, non_steam_purchase.

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / appid / description
      Added value: +"Numeric Steam app id"
    • addedInput schema / properties / cursor / description
      Added value: +"Pagination cursor from the previous page"
    • addedInput schema / properties / day_range / description
      Added value: +"Look-back window in days (filter=all only, max 365)"
    • addedInput schema / properties / filter / description
      Added value: +"Sort order. Documented values: recent, updated, all."
    • addedInput schema / properties / language / description
      Added value: +"Steam language name or 'all'"
    • addedInput schema / properties / num_per_page / description
      Added value: +"Reviews per page (max 100)"
    • addedInput schema / properties / purchase_type / description
      Added value: +"Purchase source filter. Documented values: all, steam, non_steam_purchase."
    • addedInput schema / properties / review_type / description
      Added value: +"Review sentiment filter. Documented values: all, positive, negative."
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so this is a low bar. The description goes beyond them with real behavioral detail: aggregate totals only populate on the first page (cursor=*), cursor must be threaded for paging, and the source is credential-free public storefront JSON.

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?

Front-loads the return shape, then the pagination caveat, then source/auth context, then per-parameter notes, and closes with the sibling alternative. Most sentences earn their place, though the appid/day_range lines duplicate the schema and could be trimmed.

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?

With an output schema present, return-value detail is unnecessary, and the description still flags the key gotcha that aggregates appear only on cursor=*. Pagination, credential-free access, and the histogram alternative are all covered; little an agent needs 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 description coverage is 100%, so the schema already documents every parameter including appid syntax and day_range's filter=all/max-365 constraint. The description largely repeats these (appid numeric, day_range window), adding no significant meaning beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource ('Returns a page of user reviews for an app') plus the distinctive capabilities (cursor pagination, query_summary aggregate). It explicitly names the sibling steam_reviews_histogram and how this tool differs, so an agent can disambiguate 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.

Usage Guidelines4/5

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

Gives clear routing guidance to steam_reviews_histogram for histograms and explains the pagination workflow ('Pass the returned cursor back to page'). It stops short of explicit when-not conditions for the main paginated fetch, but the alternative and the paging mechanics are both stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.