Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

shop_app_shop_reviews

Fetch customer reviews for a Shop.app merchant by handle to analyze ratings and product feedback. Returns review details, total_count, and next_cursor for pagination up to 50 reviews.

Instructions

List Shop.app shop reviews. Lists customer reviews for a Shop.app merchant, by shop handle, up to limit (default 20, max 50). Each review has its rating, body, author, date, helpful count and the product reviewed. Also returns total_count and next_cursor. Unknown shops return not found.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum reviews, defaults to 20 and supports up to 50
handleYesShop handle

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries full behavioral burden and does meaningful work: it discloses pagination via next_cursor plus total_count, the default/max result size, and the error behavior for unknown shops. It omits auth requirements and rate limits, but the pagination and error semantics are the important traits for a list endpoint.

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?

Tight and front-loaded: purpose first, then parameters, then return fields, then error behavior. Four sentences with minimal waste, though the opening 'List Shop.app shop reviews' is slightly redundant with the following sentence.

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 exists, so the description usefully enumerates the returned review fields (rating, body, author, date, helpful count, product) and the envelope fields total_count and next_cursor. This is enough for a two-parameter list tool, though it could note ordering or filtering options.

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 both handle and limit are already documented in the schema, including the default 20 / max 50 detail the description repeats. The description adds no syntax or format meaning beyond what the schema provides, 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 ('List') and resource ('Shop.app shop reviews'), and scopes it to a merchant via the shop handle. This clearly distinguishes it from the sibling shop_app_product_reviews, which returns product-level reviews rather than merchant-level ones.

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 a merchant's reviews by handle) but gives no explicit when-to-use guidance, no exclusions, and does not name an alternative tool for product-level or filtered review queries. Usage is inferable but not directed.

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