Skip to main content
Glama
Pangolin-spg

Pangolinfo Amazon Data MCP

by Pangolin-spg
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_amazon_reviews

Fetch Amazon buyer reviews by ASIN to mine pain points, analyze competitors, or extract VOC insights. Filter by star, sort, and media type for targeted review research.

Instructions

[Amazon review batch scrape] Page-fetch real buyer reviews for an ASIN. Filterable by star / sort / media type. Use when: user says "look at X's negative reviews" / "mine pain points" / "analyse competitor reviews" / "do VOC" / "find user complaints for Listing copy"; or pre-launch critical-review scan; or finding improvement points for listing optimization. Don't use: when the few reviews already in the PDP would suffice (get_amazon_product carries 5-10 reviews + aiReviewsSummary — enough for a quick read); for keyword search (use search_amazon). Returns: data.json[0].data = { totalReviews (total review count; empty when unavailable), results[{ reviewId, date, country, star, title, content, author, authorId, authorLink, imgs[], videos, purchased, vineVoice, helpful, attributes }] } — ~10 reviews per page. Pair with: ↑ asin typically from search_amazon / get_amazon_product / list_bestsellers; ↓ review text can be fed directly to an LLM for pain-point clustering and keyword extraction. Cost: 10 points per page (expensive). Start with pageCount=1 to confirm data, scale to 3-5 only when needed. Prefer filterByStar='critical' — highest signal density. Tips: filterByStar = all_stars / five_star ... one_star / positive / critical; sortBy = recent (default) | helpful; mediaType = all_contents (default) | media_reviews_only (with photos/videos, higher credibility).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asinYesAmazon ASIN (10 letters/digits, case-insensitive — auto-uppercased). Example: 'B0B4NLGCH5'.
siteNoAmazon review marketplace: 10 supported sites including Japan (amz_jp). Defaults to amz_us.amz_us
sortByNoSort order: 'recent' (newest first — track current sentiment) or 'helpful' (most-upvoted first — highest impact reviews).recent
zipcodeNoZIP code that must match the site country (amz_us → US zip, amz_jp → JP zip, ...). Optional; backend picks a random one from the per-country pool when omitted. Cross-country zips (e.g. amz_us + JP zip) are rejected by the backend. Examples: 10001 (NY) / 90001 (LA) / 100-0001 (Tokyo).
mediaTypeNoReview type: 'all_contents' for all, 'media_reviews_only' for reviews with photos/videos only (higher credibility).all_contents
pageCountNoNumber of review pages to fetch (~10 reviews per page). **Costs 10 points per page** — control accordingly. Defaults to 1.
clientSourceNo调用来源标记。仅由 Pangolinfo Skill 传 skill；普通 MCP 调用省略即可。
filterByStarNoFilter by star rating. For VOC pain-point mining, pass 'critical' (1-3 star reviews) to surface defects; for positive-aspect extraction, pass 'positive'.all_stars

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.6/5.0
Behavior5/5

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

No annotations exist, so the description carries the full behavioral burden and largely does: it discloses the cost model (10 points per page), the pagination granularity (~10 reviews/page), a scaling strategy (pageCount=1 first, then 3-5), backend zip-country validation with rejection, and an empty totalReviews when unavailable. That is material operational context an agent needs before calling.

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 purpose and organized into labeled sections (Use when / Don't use / Returns / Pair with / Cost / Tips), so it scans fast despite being long. There is some duplication with the schema (cost and mediaType semantics appear in both), which costs it a point.

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

Completeness5/5

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

For an 8-parameter tool with no output schema and no annotations, it supplies everything needed: required input provenance (ASIN from search_amazon/get_amazon_product/list_bestsellers), a full return-shape sketch, cost control guidance, and a downstream pairing note. Nothing essential to correct invocation is missing.

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 baseline is 3. The description mostly restates schema content (star enum values, sort options, mediaType credibility, per-page cost) rather than adding syntax or defaults beyond it; the one genuinely additive note is the recommendation to prefer filterByStar='critical' for signal density.

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 concrete verb+resource ("Page-fetch real buyer reviews for an ASIN") plus the filter surface (star/sort/media type). It also names the siblings it is NOT (get_amazon_product, search_amazon), so an agent can route without opening a schema.

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

Usage Guidelines5/5

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

Explicit "Use when:" block with concrete user utterances ("look at X's negative reviews", "do VOC") and an explicit "Don't use:" block that names the alternative tool and the condition that selects it (PDP's built-in 5-10 reviews suffice). This is exactly the when/when-not/alternative structure.

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