Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

steam_reviews

Fetch paginated Steam app user reviews with cursor-based paging, sentiment and language filters, and an aggregate score summary of positive and negative totals.

Instructions

List reviews for a Steam app. 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.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.17.5
    • addedInput schema / properties / filter / enum
      Added value: +[
+  "recent",
+  "updated",
+  "all"
+]
    • addedInput schema / properties / purchase_type / enum
      Added value: +[
+  "all",
+  "steam",
+  "non_steam_purchase"
+]
    • addedInput schema / properties / review_type / enum
      Added value: +[
+  "all",
+  "positive",
+  "negative"
+]
  2. Addedv1.5.0

TDQS

A3.8/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden, and it does well: it discloses the return shape (a page of reviews plus a query_summary with score and positive/negative totals) and the non-obvious rule that aggregates only populate on the first page (cursor=*). It stops short of stating auth requirements or rate limits, but for a read-only list endpoint this is solid disclosure.

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?

Three tight sentences, front-loaded with the core purpose, then return shape, then the paging rule. No filler; every sentence carries actionable information.

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?

For an 8-parameter, no-output-schema tool, the description covers the essential non-schema facts: pagination mechanics and the query_summary return structure. It does not enumerate or clarify the filter parameters (day_range's filter=all coupling, etc.), but the schema handles those, so the gap is minor.

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%, so the eight parameters are already documented, making 3 the baseline. The description adds one genuinely useful detail not in the schema: the initial cursor value is '*' for the first page, whereas the schema only says 'Pagination cursor from the previous page.' That is a marginal, not a major, addition.

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+resource: 'List reviews for a Steam app.' An agent immediately knows what the tool returns. However, it offers no differentiation from siblings like steam_reviews_histogram or steam_community_recommendations, which could plausibly compete for the same intent.

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?

The pagination guidance ('Pass the returned cursor back to page') and the cursor=* first-page note give implied usage context, but there is no explicit when-to-use vs. when-not-to-use guidance or mention of an alternative tool. A caller must infer that this is the tool for raw review retrieval.

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