Skip to main content
Glama
Amazon Top Reviews Scraper MCP Server

Amazon Top Reviews Scraper MCP Server

Get Amazon top reviews

get_amazon_top_reviews
Read-onlyIdempotent

Fetch top reviews, ratings, star splits, and review rows for Amazon products by ASIN or URL across eight non-US marketplaces to analyze customer feedback.

Instructions

Read the top reviews Amazon shows logged out on a product page, for ASINs or product URLs on amazon.co.uk, .de, .fr, .it, .es, .ca, .co.jp, and .in: about 8 from the marketplace country and up to 5 from other countries, plus the rating, ratings count, and star split. One product row and one row per review. Costs 0.03 USD per product, 0.002 USD per ASIN not on that marketplace, plus a run start. No US marketplace, no paging, no sort.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_amazon_top_reviews"
  }
}

Input Schema

NameRequiredDescriptionDefault
productsNoASINs or Amazon product URLs. A URL sets its own marketplace; an ASIN uses Marketplace below. From Clay, put the column inside a one item list.
marketplaceNoMarketplace for ASINs given without a URL. amazon.co.uk (default), amazon.de, amazon.fr, amazon.it, amazon.es, amazon.ca, amazon.co.jp, or amazon.in. amazon.com is not supported: its logged out pages show no reviews.
max_charge_usdNoOptional. The run stops before a charge that would pass this amount. Summary rows are always returned.
include_reviewer_namesNono (default) or yes. Yes adds the public display name Amazon shows on each review.
include_other_countriesNoyes (default) or no. The page also shows about 3 to 5 top reviews from other countries, which can include the United States. No keeps only the marketplace's own country.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive, openWorld), the description discloses pricing (0.03 USD per product, 0.002 USD per unsupported ASIN, plus a run start), the exact volume returned (~8 local plus up to 5 foreign reviews), and the fact that data comes from logged-out public pages. These are material behaviors an agent needs before spending money.

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?

The description is dense and front-loaded, leading with what the tool does before costs and exclusions. Minor redundancy: it re-lists all eight marketplaces that the schema enum already enumerates, which costs a phrase without adding 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?

With no output schema, the description carries the return-value burden and does so reasonably ('one product row and one row per review', rating, count, star split). Remaining gaps, such as error or partial-failure behavior for invalid ASINs, are minor for a read-only scraping tool.

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 every parameter is already documented in the schema; the description adds only marginal detail such as the row-per-review output shape. It does not explain the max_charge cutoff semantics or the Clay one-item-list hint beyond what the schema already states.

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?

The description names a specific verb and resource (read top reviews on a product page), states the input forms accepted (ASINs or product URLs), enumerates the supported marketplaces, and describes the returned data (rating, ratings count, star split). An agent could not confuse this with any other operation.

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?

Explicit exclusions are given: 'No US marketplace, no paging, no sort,' and the marketplace enum is constrained to eight domains because logged-out US pages show no reviews. That is strong when-not guidance; the only shortfall is that no alternative is named, though there are no sibling tools to route to.

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