Skip to main content
Glama
BuyWhere

BuyWhere Catalog MCP Server

Official

BuyWhere MCP Server — Product Search & Price Comparison for AI Agents

AI agents use BuyWhere to search products, compare prices, and discover deals across Singapore and US merchants in real time.

Install in 30 Seconds

export BUYWHERE_API_KEY=bw_live_xxxx
npx -y @buywhere/mcp-server

Use with Claude Desktop, Cursor, VS Code Copilot, Cline, Windsurf, OpenCode, Codex, Continue.dev, and any MCP-compatible client.

npm version npm downloads npm weekly downloads License: MIT Node version TypeScript GitHub stars Smithery MCP Registry Hashnode Blog


Related MCP server: Godalo

AI Agents: Use This Package To

  • Search products across Singapore, US, Malaysia, Thailand, and Vietnam markets by keyword, category, or price range

  • Compare products across Lazada, Shopee, Amazon, and local retailers in a single query

  • Find deals and track real-time pricing with multi-currency support

  • Build shopping agents that recommend, compare, and link to products programmatically

  • Discover product catalogs with structured taxonomy for supported markets


Product search API for AI agents via Model Context Protocol. Built for AI agent commerce, not store management.

Official MCP Registry listing: io.github.BuyWhere/buywhere-mcp

Works with Claude Desktop, Cursor, VS Code Copilot, Cline, Windsurf, OpenCode, Codex, Continue.dev, and any MCP-compatible client. Also supports Agent-to-Agent (A2A) protocol.


Demo

BuyWhere MCP in Claude Desktop

44-second demo: product search, deal discovery, price comparison, and multi-region support.

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_products → side-by-side with best-value pick]

Quick Start

Get a key in 3 seconds — no signup, no email:

# 1. Register (one call, returns api_key instantly)
curl -X POST https://api.buywhere.ai/v1/auth/register \
  -H "Content-Type: application/json" \
  -d '{"agent_name":"your-agent"}'
# → {"api_key":"bw_...","tier":"unverified","rate_limit":{"rpm":20,"daily":1000}}

# 2. Use the key
export BUYWHERE_API_KEY=bw_...
npx -y @buywhere/mcp-server

Legacy email signup (60s, manual approval) → buywhere.ai/api-keys

Tutorials

From the Blog

Read the BuyWhere Engineering Blog for deep dives on MCP architecture, agent commerce, and the ecosystem.

Also follow the BuyWhere Hashnode blog mirror for the same engineering content on Hashnode.

Tools

Tool

Description

search_products

Search catalog by keyword, category, price, country

get_product

Full product details by ID (prices, specs, images)

compare_products

Side-by-side comparison of 2–10 products

find_best_price

Cheapest deliverable listing for a product across merchants

get_deals

Products with significant price drops

list_categories

Available product category taxonomy

find_similar

Similar products by vector similarity

ingest_products

Submit product URLs for catalog ingestion (agents/merchants)

search_products_v2

v2 search; requires deliver_to (ISO country)

get_product_v2

v2 product details by ID

compare_products_v2

v2 comparison; optional deliver_to

get_deals_v2

v2 deals; requires deliver_to

find_best_price_v2

v2 best price; requires deliver_to

Remote MCP: POST https://api.buywhere.ai/mcp (JSON-RPC 2.0, protocolVersion 2024-11-05, 13 tools). Glama listing: https://glama.ai/mcp/servers/BuyWhere/buywhere-mcp

MCP Client Configuration

Framework quickstarts:

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "buywhere": {
      "command": "npx",
      "args": ["-y", "@buywhere/mcp-server"],
      "env": { "BUYWHERE_API_KEY": "bw_live_xxxx" }
    }
  }
}

Cursor / VS Code / Cline

Add to your MCP settings file:

{
  "mcpServers": {
    "buywhere": {
      "command": "npx",
      "args": ["-y", "@buywhere/mcp-server"],
      "env": { "BUYWHERE_API_KEY": "bw_live_xxxx" }
    }
  }
}

Windsurf

Add to ~/.windsurf/mcp.json:

{
  "mcpServers": {
    "buywhere": {
      "command": "npx",
      "args": ["-y", "@buywhere/mcp-server"],
      "env": { "BUYWHERE_API_KEY": "bw_live_xxxx" }
    }
  }
}

OpenCode / Codex

Add to opencode.json:

{
  "mcpServers": {
    "buywhere": {
      "command": "npx",
      "args": ["-y", "@buywhere/mcp-server"],
      "env": { "BUYWHERE_API_KEY": "bw_live_xxxx" }
    }
  }
}

Continue.dev (VS Code / JetBrains)

Add to ~/.continue/config.json:

{
  "experimental": {
    "mcpServers": {
      "buywhere": {
        "command": "npx",
        "args": ["-y", "@buywhere/mcp-server"],
        "env": { "BUYWHERE_API_KEY": "bw_live_xxxx" }
      }
    }
  }
}

Mastra

Mastra is a TypeScript-first AI agent framework with native MCP support.

npm install @mastra/core @mastra/mcp
import { Mastra } from '@mastra/core';
import { MastraMCPClient } from '@mastra/mcp';

const buywhere = new MastraMCPClient({
  name: 'buywhere',
  server: {
    url: new URL('https://api.buywhere.ai/mcp'),
    requestInit: {
      headers: { 'Authorization': `Bearer ${process.env.BUYWHERE_API_KEY}` },
    },
  },
});

const agent = new Mastra({
  agents: {
    shoppingAgent: {
      instructions: 'You are a shopping assistant. Use BuyWhere to find and compare products.',
      tools: await buywhere.tools(),
    },
  },
});

const result = await agent.agents.shoppingAgent.generate(
  'Find me the best deal on a Sony WH-1000XM5 in Singapore'
);

Full guide: BuyWhere + Mastra Integration

LangChain

Use BuyWhere tools in LangChain agents via the MCP adapter:

from langchain_mcp_adapters.client import MultiServerMCPClient
from langgraph.prebuilt import create_react_agent
from langchain_anthropic import ChatAnthropic

async def main():
    async with MultiServerMCPClient({
        "buywhere": {
            "url": "https://api.buywhere.ai/mcp",
            "transport": "streamable_http",
            "headers": {"Authorization": f"Bearer {BUYWHERE_API_KEY}"},
        }
    }) as client:
        tools = await client.get_tools()
        agent = create_react_agent(ChatAnthropic(model="claude-sonnet-4-5"), tools)
        result = await agent.ainvoke({"messages": [("user", "Find the cheapest Sony headphones in Singapore")]})

LlamaIndex

Connect BuyWhere via LlamaIndex MCP client:

from llama_index.tools.mcp import BasicMCPClient, McpToolSpec
from llama_index.agent.openai import OpenAIAgent

async def main():
    mcp_client = BasicMCPClient(
        command_or_url="https://api.buywhere.ai/mcp",
        headers={"Authorization": f"Bearer {BUYWHERE_API_KEY}"},
    )
    mcp_tool_spec = McpToolSpec(client=mcp_client)
    tools = mcp_tool_spec.to_tool_list()
    agent = OpenAIAgent.from_tools(tools)
    response = await agent.achat("Compare prices for iPhone 16 Pro across Singapore and US")

CrewAI

Use BuyWhere in a CrewAI agent with MCP tool integration:

from crewai import Agent, Task, Crew
from crewai_tools import MCPServerAdapter

buywhere_server = MCPServerAdapter(
    server_params={
        "url": "https://api.buywhere.ai/mcp",
        "headers": {"Authorization": f"Bearer {BUYWHERE_API_KEY}"},
        "transport": "streamable-http",
    }
)

shopping_agent = Agent(
    role="Shopping Research Analyst",
    goal="Find the best deals across Singapore and US markets",
    tools=[buywhere_server],
)

task = Task(
    description="Find the best price for Sony WH-1000XM5 headphones across all available markets",
    agent=shopping_agent,
    expected_output="Product comparison with prices and merchant links",
)

crew = Crew(agents=[shopping_agent], tasks=[task])
result = crew.kickoff()

Configuration

Variable

Default

Description

BUYWHERE_API_KEY

(required)

API key (no signup: POST /v1/auth/register {"agent_name":"<name>"}) — returns instantly, no email verification

BUYWHERE_API_URL

https://api.buywhere.ai/mcp

Custom API base URL

Install

# Run directly (no install)
npx -y @buywhere/mcp-server

# Install globally
npm install -g @buywhere/mcp-server
buywhere-mcp

Use Cases

  • Shopping agents — build AI agents that search, compare, recommend products across markets

  • Price comparison — multi-market pricing in a single query across Lazada, Shopee, Amazon, local retailers

  • Deal discovery — find best-value products with real-time pricing and inventory

  • Ecommerce automation — integrate product search into any MCP-compatible app

  • Cross-border commerce — compare prices between Singapore, US, Malaysia, Thailand, and Vietnam markets

  • Agent-to-Agent commerce — delegate shopping tasks between agents via A2A protocol

Architecture

Developer's AI Agent (Claude, Cursor, etc.)
  │
  ├── MCP Protocol (stdio)
  │
  ├── @buywhere/mcp-server
  │     ├── search_products(q, category, min_price, max_price, country_code, deliver_to)
  │     ├── get_product(product_id)
  │     ├── compare_products(product_ids[])
  │     ├── find_best_price(product_name, country_code, deliver_to)
  │     ├── get_deals(country_code, deliver_to, category)
  │     ├── list_categories()
  │     ├── find_similar(product_id)
  │     └── ingest_products(urls[])
  │
  └── BuyWhere API (api.buywhere.ai)
        └── Product catalog across SG, US, MY, TH, and VN merchants

Development

git clone https://github.com/BuyWhere/buywhere-mcp.git
cd buywhere-mcp
npm install
npm run build
npm start

Why BuyWhere?

BuyWhere is a product search API for AI agents. We aggregate product data from Singapore, US, Malaysia, Thailand, and Vietnam merchants into a single, agent-friendly interface — no store management, no Shopify integration. Just search and compare products in real time.

  • One API — all markets, all retailers

  • Agent-native — built for MCP from day one

  • Real-time — live pricing and availability

  • Developer-first — no SDK needed, just add the server

Works Well With

These complementary MCP packages extend BuyWhere into powerful multi-tool workflows:

  • @modelcontextprotocol/server-filesystem — Save shopping results and product research to your local filesystem. Combine with BuyWhere to export deal lists, price comparisons, and product specs as structured files.

  • @supabase/mcp-server-supabase — Store favorite products, user preferences, and price alerts in Supabase. Persist shopping history across agent sessions.

  • n8n-mcp — Automate price monitoring workflows. Build no-code pipelines that watch BuyWhere prices and trigger notifications on price drops.

  • tavily-mcp — Research products before buying. Use Tavily to find reviews and comparisons, then use BuyWhere to get current prices and purchase links.

  • @playwright/mcp — E2E test your shopping agent interactions. Verify that product search, price comparison, and checkout flows work correctly in browser automation.

Protocols

Protocol

Support

MCP (Model Context Protocol)

Full support — 10 tools, stdio transport

A2A (Agent-to-Agent)

Multi-agent task delegation — Agent Card

Contributing

See CONTRIBUTING.md for how to report issues, submit PRs, and suggest features.

From the Blog

Learn more about MCP servers and the BuyWhere ecosystem:

Support

If you find this project useful:

  • Star the repo — it helps others discover BuyWhere

  • 🐛 Open an issue for bugs or feature requests

  • 💬 Start a discussion for questions or ideas

  • 📣 Share it with other developers who build AI agent tools

License

MIT

Available Tools

6 tools
compare_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
NameRequiredDescriptionDefault
product_idsYesArray 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_catalogA

List available product categories in the BuyWhere catalog. Use this to discover what categories exist before searching or filtering.

ParametersJSON Schema
NameRequiredDescriptionDefault
parent_slugNoParent 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
NameRequiredDescriptionDefault
product_idYesThe 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
NameRequiredDescriptionDefault
product_idYesThe 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
NameRequiredDescriptionDefault
queryYesKeyword or natural-language query (e.g. 'wireless earbuds under $50', 'red dress size M')
countryNoCountry code to scope results (e.g. 'sg' for Singapore). Defaults to 'sg'.
categoryNoCategory slug filter (e.g. 'electronics/smartphones', 'fashion/dresses')
limitNoMaximum 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.

TDQS

A4/5.0
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

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BuyWhere/buywhere-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server