Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

playstation_concept_reviews

Fetch PlayStation Store reviews for a game concept, including review text, ratings, helpful counts, reviewer details, and aggregate star ratings. Supports pagination, sorting, and filtering.

Instructions

Get PlayStation concept reviews. Returns one page of written PlayStation Store reviews for a concept (game hub), each with its title, body, rating, helpful count, spoiler flag, the edition the reviewer owned, and reviewer identity (online id, PS Plus subscriber status, verified-purchase status, avatar). Also includes the concept's aggregate star rating (including its rating distribution). page/page_size page through the full review list (total_count reports the true upstream review count, has_next_page whether a later page has more), sort controls ordering, and rating optionally filters to one star value. Reviews are region-scoped: cc selects the store region whose reviews are returned (and the price currency); l accepts a language code or locale such as en or en-US, with the locale's primary language used for text.

Input Schema

NameRequiredDescriptionDefault
lNoLanguage code
ccNoStore country code (ISO)
idYesNumeric PlayStation concept id
pageNo1-based page number
sortNoSort order
ratingNoFilter to one star rating (1-5)
page_sizeNoReviews per page

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses return fields, pagination behavior (total_count and has_next_page), that cc affects both region and price currency, and that locale primary language drives review text. It omits auth/rate-limit context but for a read-only listing tool this is strong disclosure.

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-loaded with the purpose, then dense but informative clauses. It is a single lengthy block that could be broken up, but every sentence carries information and nothing is redundant.

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?

No output schema and no annotations, so the description must cover the return surface, and it does: it lists review fields, the aggregate rating with distribution, pagination counters, sorting, rating filter, and region/language scoping. Sufficient for an agent to call correctly, with only minor gaps (e.g., default paging values).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: cc selects the store region and price currency, l accepts a language code or a locale like en/en-US with the locale's primary language used for text, and page/page_size 'page through the full review list'. This is real semantics on top of the field list.

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+resource ('Get PlayStation concept reviews') and immediately clarifies that it returns written PlayStation Store reviews for a concept (game hub), enumerating the returned fields. An agent can distinguish this from sibling playstation_concept, which would give concept metadata rather than reviews.

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 description implies the use case (fetching reviews for a given concept) and explains that cc scopes reviews to a region, but it never states when to prefer this over siblings or any exclusions. Usage is inferable from context but not explicitly guided.

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