amazon-scraper-api
amazon-scraper-api-mcp
用于 Amazon Scraper API 的 MCP (模型上下文协议) 服务器。 可接入 Claude Desktop、Cursor、Claude Code、Continue 或任何兼容 MCP 的 AI 客户端。它为您的模型提供实时的亚马逊产品数据,作为一流的工具调用。
它能解锁什么
“帮我找到 amazon.com 上评分最高且价格低于 150 美元的无线耳机,然后检查它们在 amazon.de 上是否更便宜”
这只需要一个提示词。如果没有 MCP,您的 AI 无法抓取亚马逊页面(亚马逊会阻止 LLM 浏览),并且在价格和库存方面完全没有时效性。有了这个 MCP 服务器,它可以直接调用 amazon_search 和 amazon_product,并从 Amazon Scraper API 返回结构化数据。
Related MCP server: Amazon Price Tracker MCP
公开的工具
工具 | 功能 | 典型用途 |
| 通过 ASIN 或 URL 获取单个产品 | “获取 B09HN3Q81F 的价格和评分” |
| 带排序/过滤功能的关键词搜索 | “50 美元以下的十大铸铁煎锅” |
| 将最多 1000 个 ASIN 加入队列进行异步抓取 | “抓取我目录中的所有 500 个产品,完成后通过 webhook 通知我” |
| 查询批处理进度 | “xyz 批次完成了多少?” |
每个工具都返回结构化的 JSON:标题、价格、评分、评论数、库存状态、购买框、变体、图片、要点、分类、规格表。
基准测试(实时生产环境,2026-04)
指标 | 数值 |
中位延迟(产品,美国) | ~2.6 秒 |
P95 延迟 | ~6 秒 |
价格 / 1,000 次请求 | $0.50 固定 |
市场支持 | 20+ |
Claude Desktop 设置
编辑 ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) 或 %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"amazon-scraper": {
"command": "npx",
"args": ["-y", "amazon-scraper-api-mcp"],
"env": {
"ASA_API_KEY": "asa_live_..."
}
}
}
}重启 Claude Desktop。工具将出现在聊天编辑器的 MCP 图标下。
Cursor 设置
设置 → MCP → 添加服务器:
命令:
npx -y amazon-scraper-api-mcp环境变量:
ASA_API_KEY=asa_live_...
Claude Code 设置
claude mcp add amazon-scraper -- npx -y amazon-scraper-api-mcp
# then set ASA_API_KEY in the environment Claude Code runs in对话示例 (Claude Desktop)
您: AirPods Pro 第三代在 amazon.com 上的当前价格是多少?
Claude: [使用 ASIN B09HN3Q81F 调用
amazon_product]AirPods Pro 第三代目前在 amazon.com 上的价格为 $199.00,原价为 $249.00(优惠 20%)。它拥有 4.7 星评分(来自 58,214 条评论),目前有货,由 Amazon.com 发货并销售,支持 Prime 服务。
您: 将其与德国亚马逊的列表进行比较。
Claude: [使用
query=B09HN3Q81F, domain=de调用amazon_product]在 amazon.de 上,同一产品的价格为 229.00 欧元。按今天的汇率计算约为 245 美元,比美国价格高出约 23%。德国列表由亚马逊发货,并符合 Prime 配送条件。
为什么选择这个而不是通用的“浏览网页” MCP
尝试加载 amazon.com 的通用浏览器工具通常会被阻止(机器人检查)或提供移动端精简页面。此服务器通过 Amazon Scraper API 路由每个调用,该 API:
通过升级代理层检测并重试机器人/CAPTCHA 页面
返回结构化 JSON(类型化字段),而不是 HTML 乱码
支持 20 多个市场,并使用国家匹配的住宅 IP
处理批量(数百到数千个 ASIN)并支持 webhook 交付
内置速率限制退避机制
错误处理
错误会作为带有 code 字段和提示的工具错误呈现给模型。模型随后决定是重试还是放弃子任务。您无需自己编写错误处理逻辑。
常见代码:INVALID_API_KEY, INSUFFICIENT_CREDITS, RATE_LIMITED, target_unreachable, amazon-robot-or-human, extraction_failed, SERVICE_OVERLOADED。完整列表:amazonscraperapi.com/docs/errors。
获取 API 密钥
app.amazonscraperapi.com。注册即送 1,000 次免费请求,无需信用卡。 足以测试此 MCP 公开的每个工具,外加几十次高效对话。
链接
Node SDK: amazon-scraper-api-sdk · Python SDK: amazonscraperapi-sdk · Go SDK: github.com/ChocoData-com/amazon-scraper-api-sdk-go · CLI: amazon-scraper-api-cli
许可证
MIT
Available Tools
4 toolsamazon_batch_createA
Queue up to 1000 ASINs or search queries for async processing. Returns a batch id - poll with amazon_batch_status or receive a webhook callback.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | Yes | ||
| items | Yes | ||
| webhook_url | No | Optional HTTPS callback URL |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions async processing and result retrieval methods, but lacks details on side effects, auth, rate limits, or error handling. The description is insufficient for a tool with no structured behavioral hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and includes key details (limit, result method). No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given missing annotations and output schema, the description covers main function and result retrieval. However, it lacks details on error handling, item validation, and batch id format. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33%, only webhook_url has a description. The description adds context for items ('ASINs or search queries') but does not explain endpoint values or items structure beyond the schema. It partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queues up to 1000 ASINs or search queries for async processing and returns a batch id. It distinguishes from siblings like amazon_batch_status (poll), amazon_product, and amazon_search (single lookups).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for multiple items ('up to 1000 ASINs or search queries') and mentions polling or webhook, but does not explicitly state when to avoid this tool (e.g., for single queries) or contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
amazon_batch_statusB
Poll an async batch job for progress + results.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It indicates a read-only polling operation, but does not mention safety, rate limits, or whether it blocks or returns immediately. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no fluff, front-loaded with the action verb 'Poll'. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple polling tool, but lacks context on return values (no output schema) and lifecycle (e.g., relationship to batch creation). More detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'id' has no description in the schema (0% coverage) and the description does not explain what it represents (e.g., the job ID from amazon_batch_create). The description fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Poll' and resource 'async batch job', and specifies that it returns 'progress + results'. This clearly distinguishes it from sibling tools like amazon_batch_create (creation) and unrelated searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as indicating that it should be called after creating a batch job with amazon_batch_create, or any prerequisites or polling behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
amazon_productB
Fetch structured data for a single Amazon product by ASIN. Returns ~55 fields including title, price, variations, reviews, category ladder, images.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 10-character Amazon ASIN, e.g. "B09HN3Q81F" | |
| domain | No | Amazon marketplace TLD | com |
| language | No | Content language xx_YY (e.g. en_US, de_DE). Not all combos supported per marketplace. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description leaves burden on text. States return fields but omits idempotency, rate limits, authentication needs, or any side effects. For a fetch tool, read-only behavior is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is efficient and front-loaded with action 'Fetch structured data'. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters and no output schema, description mentions ~55 fields and examples. Lacks error handling, response format, or data shape beyond field list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters, description adds no extra meaning beyond 'by ASIN'. Baseline 3 applies due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Fetch', resource 'structured data for a single Amazon product', and identifier 'by ASIN'. Lists sample fields, distinguishing from sibling batch and search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly for single product lookup by ASIN, but no explicit comparison with sibling tools (amazon_search, amazon_batch_*). Lacks when-not-to-use or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
amazon_searchA
Run an Amazon keyword search. Returns ranked product listings with organic/sponsored positions, prices, ratings, and image URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search keywords | |
| domain | No | com | |
| sort_by | No | best_match | |
| start_page | No | ||
| pages | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It mentions output includes organic/sponsored positions, prices, ratings, and image URLs, but does not address pagination behavior, result count per page, rate limits, or authentication needs. Adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear verb and a returns clause. No wasted words; front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with multiple parameters (sorting, pagination, domain) and no output schema, the description lacks details on result structure, items per page, and sorting behavior. It does not connect to sibling tools or mention prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only query has a description). The description does not explain parameters like domain, sort_by, start_page, or pages, leaving their semantics unclear. It adds minimal value beyond the schema defaults and enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs an Amazon keyword search and lists the returned data: ranked product listings with organic/sponsored positions, prices, ratings, and image URLs. It distinguishes from siblings like amazon_product (single product) and batch tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching Amazon, but does not explicitly state when to use this tool versus siblings like amazon_product for detail retrieval or batch tools for bulk operations. No guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v0.1.5- First observed
amazon_batch_create - First observed
amazon_batch_status - First observed
amazon_product - First observed
amazon_search
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: batch creation, batch status polling, single product fetch, and keyword search. No overlap between tools.
All tools use snake_case and start with 'amazon_'. Three follow verb_noun pattern ('batch_create', 'batch_status', 'search'), while 'amazon_product' is a noun implying fetch. Minor inconsistency but overall predictable.
Four tools cover the essential scraping operations: search, single product details, and async batch processing. The count is well-scoped for the server's purpose.
Covers search, single product, and batch processing. Missing dedicated review or category tools, but the product tool includes reviews. Minor gaps but core workflows are complete.
Maintenance
Related MCP Connectors
Amazon product API & MCP server: search, prices, reviews, sellers, deals, and ASIN lookup by Canopy.
Live Amazon product, review, search, deal, offer/stock and seller data across 23 marketplaces.
One MCP server for 180+ live web-data APIs returning clean JSON from sites that block scrapers.
Get recommended by Amazon's AI. Hosted MCP server for Amazon listing compliance & generation.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceThis MCP server scrapes Amazon product details and reviews, manages a local JSON database, and visualizes intelligence data through a rich dashboard.-
- FlicenseAqualityDmaintenanceMCP server for tracking Amazon product prices via camelcamelcamel.com, using headless Chromium to bypass Cloudflare protection.3-
- FlicenseBqualityDmaintenanceProvides tools to access real-time Amazon data, including product details, reviews, offers, influencer profiles, and deals, through a FastMCP-based server.18-
- AlicenseAqualityBmaintenanceRemote MCP server with 19 e-commerce and IP-compliance data tools — Amazon product/review/search/niche/bestseller data, AI SERP & keyword trends, local Maps POI, WIPO trademark search, and PACER patent litigation. No scraping code or proxies needed; one API key unlocks all tools.211MIT