Skip to main content
Glama
icue

Steam Review and Forum MCP

by icue
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

get_steam_review

Retrieve Steam reviews for a specific app with filters for language, review type, and date, plus cursor pagination, automatic multi-page collection, and optional review metadata.

Instructions

Retrieves Steam reviews for a specific app. Supports manual cursor pagination and automatic multi-page collection. Off-topic review activity is included by default. The response always includes a cleaned reviews text array, and can optionally include review_details with timestamps and playtime metadata when include_review_metadata is true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appidYesSteam application ID
cursorNoCursor for paging. Pass "*" for the first page, then pass the returned next cursor for the next request.*
filterNorecent: sorted by creation time, updated: sorted by last updated time, all: sorted by helpfulness. Note that Steam's "all" filter does not naturally terminate when paging.all
languageNoLanguage filter (e.g. english, french, schinese). Default is all languages.all
day_rangeNoRange from now to n days ago to look for helpful reviews. Only applicable for the "all" filter.
fetch_allNoWhen true, automatically follow cursors until all matching reviews are collected. If filter="all", the server automatically switches to filter="recent" because Steam's "all" filter does not terminate when paging.
max_reviewsNoOptional cap when fetch_all is true. Useful to avoid pulling very large review sets into the model context.
review_typeNoall: all reviews, positive: only positive reviews, negative: only negative reviewsall
num_per_pageNoNumber of reviews per page. Steam allows up to 100.
purchase_typeNoall: all reviews, non_steam_purchase: users who did not pay on Steam, steam: paid on Steamall
include_review_metadataNoWhen true, return review_details in addition to the cleaned review text. review_details includes per-review metadata such as timestamp_created, timestamp_updated, timestamp_dev_responded, and author playtime fields like playtime_at_review and last_played.
filter_offtopic_activityNoOff-topic review activity is included by default. This parameter is set to 0 unless explicitly overridden in future versions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.5

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden, and it does disclose useful traits: off-topic reviews are included by default, the response always contains a cleaned reviews text array, and review_details is opt-in. However, it omits error behavior, rate limits, and the pagination-termination caveat that actually matters for correctness, so it is only partially complete.

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?

Four sentences, front-loaded with the core purpose, with no filler. Slight redundancy with the schema's parameter descriptions, but the structure is efficient and easy to scan.

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

Completeness3/5

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

For a 12-parameter tool with no output schema and no annotations, the description partly compensates by sketching the return shape (cleaned text array plus optional review_details). It still leaves the cursor/next-cursor return contract and multi-page termination behavior underspecified relative to the tool's complexity.

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 all 12 parameters including cursor, filter, fetch_all, and include_review_metadata. The description restates a few of these (metadata opt-in, off-topic default) but adds no syntax or format detail beyond the schema, matching the baseline.

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 and resource ("Retrieves Steam reviews for a specific app"), so the agent knows exactly what it fetches. It does not distinguish itself from related siblings like query_steam_review_corpus or create_steam_review_corpus, which could plausibly serve similar review-oriented needs.

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

Usage Guidelines2/5

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

The description never says when to use this raw fetcher versus the corpus-building or query siblings, and offers no exclusions or prerequisites. The mention of manual vs automatic collection hints at modes but not at tool selection, so the agent must infer context on its own.

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

Deploy Server

Other Tools