A
licenseC
qualityC
maintenanceA Model Context Protocol server enabling product searches across e-commerce platforms, price history tracking, and product specification-based searches using natural language prompts.
2
48 PyPI
19
MIT
BuyWhere Catalog MCP Server
Officialby BuyWhere
BuyWhere MCP 服务器
面向 AI 智能体的跨境产品目录。通过 模型上下文协议 (Model Context Protocol) 搜索并比较新加坡、东南亚和美国市场的产品。
适用于 Claude Desktop、Cursor、VS Code Copilot、Cline、OpenCode、Codex 以及任何兼容 MCP 的客户端。
演示
44 秒演示：产品搜索、优惠发现、价格比较以及多区域支持。
User: "Find me wireless earbuds under $50 available in Singapore"
Agent: [calls search_products → returns 5 matching products]
User: "Compare the top 3"
Agent: [calls compare_prices → side-by-side with best-value pick]Related MCP server: Agentic Product Protocol MCP Server
快速开始
export BUYWHERE_API_KEY=bw_live_xxxx
npx -y @buywhere/mcp-server获取您的免费 API 密钥 → buywhere.ai/api-keys
工具
工具 | 描述 |
| 按关键词、类别、价格、区域搜索目录 |
| 通过 ID 获取完整产品详情（价格、规格、图片） |
| 2–5 个产品的并排比较 |
| 获取单个产品在所有商家的当前价格 |
| 获取产品的点击追踪联盟链接 |
| 可用的产品类别分类法 |
使用场景
AI 智能体 — 实时搜索、比较和推荐新加坡、东南亚和美国市场的产品
开发者 — 无需 API 集成，即可为任何兼容 MCP 的应用添加跨境购物功能
价格比较 — 在一次查询中获取 Lazada、Shopee、Amazon 和本地零售商的多市场定价
快速设置
Claude Desktop
添加到 claude_desktop_config.json：
{
"mcpServers": {
"buywhere": {
"command": "npx",
"args": ["-y", "@buywhere/mcp-server"],
"env": { "BUYWHERE_API_KEY": "bw_live_xxxx" }
}
}
}Cursor / VS Code / Cline
配置相同 — 添加到您的 MCP 设置文件中：
{
"mcpServers": {
"buywhere": {
"command": "npx",
"args": ["-y", "@buywhere/mcp-server"],
"env": { "BUYWHERE_API_KEY": "bw_live_xxxx" }
}
}
}配置
变量 | 默认值 | 描述 |
| (必填) | 来自 buywhere.ai/api-keys 的 API 密钥 |
|
| 自定义 API 基础 URL |
安装
# Run directly (no install)
npx -y @buywhere/mcp-server
# Install globally
npm install -g @buywhere/mcp-server
buywhere-mcp开发
git clone https://github.com/BuyWhere/buywhere-mcp.git
cd buywhere-mcp
npm install
npm run build
npm start为什么选择 BuyWhere？
BuyWhere 是首个专为 AI 智能体构建的跨境产品目录 API。我们将新加坡、东南亚和美国市场的产品聚合到一个对智能体友好的单一接口中。
单一 API — 涵盖所有市场、所有零售商
智能体原生 — 从第一天起就为 MCP 构建
实时性 — 实时价格和库存状态
开发者优先 — 无需 SDK，只需添加服务器即可
A2A 协议
BuyWhere 还支持用于多智能体任务委派的 智能体到智能体 (A2A) 协议。请在 /.well-known/agent.json 查看我们的智能体卡片。
贡献
请参阅 CONTRIBUTING.md 了解如何报告问题、提交 PR 以及建议功能。
支持
如果您觉得本项目有用：
许可证
MIT
Available Tools
6 toolscompare_pricesA
Compare 2–5 products side-by-side. Returns structured differentiators, price range, pros/cons, and a best-value recommendation — purpose-built for AI agent decision-making.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| product_ids | Yes | Array of 2–5 BuyWhere product IDs to compare |
TDQS
A4.3/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. It discloses that the tool returns structured data including differentiators and a recommendation, indicating a read-only operation without side effects. No hidden behaviors are mentioned, but the description is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and outputs with no superfluous words. Front-loaded with key action and resource.
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 a simple tool with one parameter and no output schema, the description sufficiently covers what the tool does and what it returns. An agent can accurately decide to invoke it for multi-product comparisons.
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?
The input schema already provides a description for 'product_ids' (array of 2-5 strings). The description adds 'BuyWhere' specificity, but does not significantly enhance understanding beyond the schema. Schema coverage is 100%, so baseline 3 is appropriate.
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 clearly states the tool compares 2-5 products side-by-side and lists specific outputs (differentiators, price range, pros/cons, recommendation). It distinguishes itself from sibling tools like get_price and get_product which handle single products.
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?
The description implies use for multi-product comparison and mentions it is 'purpose-built for AI agent decision-making.' It does not explicitly state when not to use it or name alternatives, but the context from sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_affiliate_linkA
Get the click-tracked BuyWhere affiliate link for a product. Share this link with users — it logs the referral and redirects to the merchant page. Always use this instead of raw product URLs when sharing links.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | The BuyWhere product ID |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the link logs referrals and redirects, which is key behavioral info. With no annotations, this is nearly sufficient; could mention if any authentication is needed but acceptable for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no filler. Front-loads the core action and immediately provides usage guidance.
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?
Covers purpose, usage, and behavioral aspects adequately for a simple tool with one parameter and no output schema. Slightly lacking on return value details but sufficient.
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 already fully describes the only parameter (product_id) as 'The BuyWhere product ID'. Description does not add extra semantic detail beyond the schema.
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?
Clearly states the action ('get') and the specific resource ('click-tracked BuyWhere affiliate link'). Distinguishes from sibling tools like get_product or get_price by focusing on affiliate link generation.
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?
Explicitly advises to use this tool instead of raw product URLs when sharing links, and explains why (referral logging, redirect). Provides clear context for when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_catalogA
List available product categories in the BuyWhere catalog. Use this to discover what categories exist before searching or filtering.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| parent_slug | No | Parent category slug to list subcategories (optional — omit for top-level categories) |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lists categories but does not disclose any additional behavioral traits like pagination or rate limits. Adequate for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose. No redundant information, every word earns its place.
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?
For a simple list tool with full schema coverage, the description is fairly complete. Could mention return format, but not essential.
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 coverage is 100% with a well-described parameter. The description adds no extra meaning beyond the schema, meeting baseline for adequate parameter semantics.
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 uses specific verb 'List' and resource 'product categories', clearly distinguishing from sibling tools like search_products or get_product.
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?
Explicitly says 'Use this to discover what categories exist before searching or filtering', providing clear usage context. No need to exclude alternatives as no sibling overlaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_priceA
Get current prices for a product across all available merchants. Returns a ranked list of listings with price, shipping, merchant rating, and stock status. Use this to find the cheapest place to buy a specific product.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | The BuyWhere product ID |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions it returns a ranked list with price, shipping, merchant rating, stock status, but doesn't discuss freshness, pagination, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, every word adds value; no redundancy.
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?
Covers purpose, expected output structure, and usage context; missing details like response format completeness, but adequate for a simple tool without output schema.
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?
Only one parameter (product_id) with schema description identical to tool description; no additional meaning added beyond schema.
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?
Clearly states it retrieves current prices for a product across merchants, distinguishes from siblings like get_product and compare_prices.
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?
Explicitly says 'use this to find the cheapest place to buy a specific product,' providing clear usage context, though lacks explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_productB
Fetch full details for a single product by its BuyWhere product ID.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | The BuyWhere product ID (returned by search_products as product_id) |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Lacks details on what 'full details' includes, error behavior for invalid IDs, or any side effects. Vague behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Front-loaded with the core action and qualifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple single-param tool, but missing details about output content and error states. No output schema to supplement, so description should clarify what 'full details' means.
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 coverage is 100% with a clear property description. Tool description adds no extra context beyond the schema's property text, so it meets baseline without enhancement.
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?
Description clearly states the action (fetch), resource (full details for a single product), and uniqueness (by BuyWhere product ID). It distinguishes from sibling tools like search_products which return multiple results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives (e.g., get_price, get_catalog). No mention of prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_productsA
Search the BuyWhere product catalog using keywords or natural language. Returns matching products with title, price, availability, merchant, and URL.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keyword or natural-language query (e.g. 'wireless earbuds under $50', 'red dress size M') | |
| country | No | Country code to scope results (e.g. 'sg' for Singapore). Defaults to 'sg'. | |
| category | No | Category slug filter (e.g. 'electronics/smartphones', 'fashion/dresses') | |
| limit | No | Maximum number of results to return (1–50, default 10) |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies read-only search behavior but does not explicitly state side effects, authentication, or rate limits. Minimal transparency for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load purpose and output. No extraneous 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?
Covers purpose, parameters, and return fields adequately for a search tool. Lacks mention of pagination, error responses, or empty result handling, but these are minor gaps given low complexity.
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 covers 100% parameters with descriptions. Description adds no meaningful detail beyond the schema, such as query format examples or category slug usage.
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?
Clearly states verb 'Search' and resource 'BuyWhere product catalog'. Specifies output fields (title, price, availability, merchant, URL). Distinguishes from siblings like compare_prices and get_product by focusing on keyword search.
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?
Describes when to use (keyword search), but lacks explicit guidance on when not to use or alternatives. No mention of when to prefer compare_prices or get_product over this tool.
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.
6 tool updates
v1.0.0- First observed
compare_prices - First observed
get_affiliate_link - First observed
get_catalog - First observed
get_price - First observed
get_product - First observed
search_products
TDQS
A4/5.0
Scored across 6 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: compare_prices does side-by-side comparison, get_affiliate_link provides affiliate links, get_catalog lists categories, get_price shows merchant prices, get_product fetches details, search_products searches catalog. No overlapping functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., compare_prices, search_products). The naming is predictable and easy to understand.
Tool Count5/5
With 6 tools, the set is well-scoped for a price comparison and affiliate linking service. Each tool serves a necessary function without unnecessary bloat.
Completeness4/5
Core workflows are covered: search, get details, compare, get prices, affiliate links, and category discovery. Minor gaps like lack of explicit filtering or sorting in search are acceptable for the scope.
Maintenance
ActivityActive
ResponsivenessWithin a week
Related MCP Connectors
AI-agent product catalog: search, lookup & purchase routing over verified merchant data.
Cross-vendor B2B catalog for AI agents: search, compare, find equivalents, request a quote.
Agent-native product catalog: 300M+ products, 150,000+ stores, deliver_to ranking.
AI agent product discovery via open marketplace. Search, compare and discover advertiser products.
Related MCP Servers
- AlicenseAqualityDmaintenanceKlarna-style product discovery for AI shopping agents. Makes product catalogs machine-readable so AI agents can search, compare, and purchase products programmatically.6MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to search, compare, buy, and sell products across multiple e-commerce platforms through 13 marketplace tools.1MIT
- AlicenseNot gradedqualityDmaintenanceReal-time Shopee competitor price monitoring, powered by AI agents through the Model Context Protocol (MCP). Enables AI agents to track, analyze, and alert on price movements across Shopee Southeast Asia.1MIT