marketplace-mcp
A read-only MCP server for searching and comparing products across Ozon and Yandex Market — no login, cart interaction, or order placement.
Search across marketplaces (
marketplaces_search): Query one or more marketplaces simultaneously, with configurable result limits and loading strategy.Search Ozon only (
ozon_search): Run a product search exclusively on Ozon.Search Yandex Market only (
yandex_market_search): Run a product search exclusively on Yandex Market.Compare products (
marketplaces_compare): Search both marketplaces simultaneously and receive results grouped by similar products for easy price and availability comparison.Get product details (
marketplaces_product_details): Retrieve detailed information from a specific product page by URL.Retrieve saved artifacts (
marketplaces_get_artifact): Access previously saved search or comparison results by artifact ID.
All results return normalized fields: title, price, old price, currency, rating, review count, availability, delivery notes, source URL, image URL, and scrape timestamp. Warnings such as CAPTCHA_OR_BLOCKED are included when data is partial or unavailable.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@marketplace-mcpsearch for Nike shoes on Ozon and Yandex Market"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Marketplace MCP
Read in Russian: readme_rus.md
Marketplace MCP is a read-only MCP server for product search, review sampling, and price comparison across Ozon, Wildberries, Yandex Market, and Avito. It also searches public Ozon Travel flight and hotel offers for explicit travel dates.
It is built for agents that need marketplace data without logging in, touching carts, or automating checkout. The server returns normalized product data, comparison groups, warnings, and source URLs. When a marketplace blocks scraping or shows anti-bot behavior, the tool reports that instead of trying to bypass it.
Tools
marketplaces_searchsearches one or more marketplaces.ozon_searchsearches Ozon only.wildberries_searchsearches Wildberries only.yandex_market_searchsearches Yandex Market only.avito_searchsearches Avito as an explicit used-market path.marketplaces_comparesearches retail marketplaces and groups similar products; Avito is opt-in withinclude_avito=true.marketplaces_product_detailsreads a product page by URL.marketplaces_product_reviewsreturns a compact review sample for supported marketplaces.marketplaces_get_artifactreads a saved result artifact.ozon_travel_flights_searchsearches Ozon Travel flights by route, dates, passengers, cabin class, direct-flight preference, and sort order.ozon_travel_hotels_searchsearches Ozon Travel hotels by destination, stay dates, guests, rooms, rating, stars, and maximum total stay price.ozon_travel_hotel_detailsreads room rates for one Ozon Travel hotel URL and the requested stay dates.
Returned product fields include marketplace, title, URL, image URL, price, old price, currency, rating, review count, availability, delivery notes, seller evidence, used-item condition and location, scraped timestamp, and warnings when data is partial.
Flight offers keep segments, airlines, stops, duration, baggage evidence, and
the displayed total price. Hotel results deliberately keep nightly_price and
total_price separate. A search-card “from” price is never silently presented
as the exact total for the requested stay; use hotel details/rates when an exact
dated total is required.
Flight prices stay unknown when the page lacks the requested journey legs. Arrival dates use displayed day offsets; ambiguous overnight dates stay unknown. Hotel prices are withheld when the displayed year conflicts with the request or individual tariff prices cannot be separated. Meals, cancellation and payment terms belong to each tariff, including different tariffs with the same price.
Related MCP server: hermes-marketplace-tools
Package tours and access diagnostics
ozon_travel_tours_searchdiscovers Ozon package-tour hotel candidates.ozon_travel_tour_detailsreads dated room, meal-plan, operator and package-price evidence for a candidate from the same browser search.ozon_tours_access_statusreads cached access state by default;inspect_tab=trueinspects the retained page without navigating, and explicit probes respect shared cooldown.package_tours_searchis a separate 1001tur source, never an Ozon quote.avito_access_statusreports shared Avito access/cooldown state.avito_game_searchdistinguishes physical cartridges, Game-Key Cards and excluded digital/account listings.
Ozon package search and details share the same access cooldown. Browser failures,
busy requests and visible challenges return structured diagnostics with a source
URL. Completing verification manually in the retained tab can be checked with
ozon_tours_access_status(inspect_tab=true) before continuing.
The verified Ozon package scope is Saint Petersburg (LED) to UAE, one room,
exact departure date, 1–6 adults and up to three children aged 0–16. Age 0 means
an infant under one year. Request 2–21 nights with at most five stay lengths
per call, for example 5–9 and 10–12.
Search-card prices can belong to breakfast even when all-inclusive filters are
selected. Package search therefore returns total_price=null; use details to
read each room/meal/operator row. A package rate marked as including flights
still has flight_selection_pending=true: specific flights, baggage, transfer,
return-flight date and final booking total remain unconfirmed. stay_end_date
is the hotel checkout date, not proof of the return-flight date.
Ozon package tools require Camofox at MARKETPLACES_CAMOFOX_URL. Use a working
display (the supported CAMOFOX_INTERACTIVE=desktop mode was verified) and keep
tab/session inactivity timeouts long enough for a search and details workflow
(30 minutes was tested). Browser deployment must preserve a replacement session
when an older context finishes closing. A navigation timeout retains the tab;
visible CAPTCHA/block pages are reported for manual inspection rather than retried
with rotating profiles or addresses. No login, booking or payment is automated.
Safety model
Marketplace MCP is deliberately read-only.
By default it does not:
log in to a marketplace;
use cookies or account sessions;
add items to cart;
place orders;
reserve products;
submit payments;
bypass CAPTCHA or anti-bot systems.
Prices are scraped snapshots. Always open the product URL before making a purchase decision. Travel availability and prices are also snapshots and must be rechecked before booking. The server never reserves or books a flight or hotel.
Marketplace MCP uses Hive Web as the default page loader (MARKETPLACES_WEB_BACKEND=hive_web).
legacy mode keeps the previous Playwright/httpx loading stack.
auto tries Hive Web first and falls back to legacy only if Hive Web is unavailable.
MARKETPLACES_WEB_BACKEND:hive_web(default),auto,legacyMARKETPLACES_HIVE_WEB_MAX_TOKENS: maximum tokens for Hive Web text snapshot (default12000)MARKETPLACES_CAMOFOX_URL: optional Camofox base URL for anonymous ephemeral read-only fallback sessions.MARKETPLACES_AVITO_REGION_SLUG: Avito region path (defaultall).MARKETPLACES_AVITO_STATE_PATH: shared Avito rate-limit state file (default~/.cache/marketplaces-mcp/avito-access-state.json).MARKETPLACES_AVITO_MIN_INTERVAL_SECONDS: minimum interval between Avito live requests (default10).MARKETPLACES_AVITO_BLOCK_COOLDOWN_SECONDS: cooldown after an explicit Avito IP block (default21600, six hours).
When rendered pages are unavailable, public search-index discovery may return
canonical product links. Such results always have no verified price and include
INDEX_DISCOVERY_ONLY and PRICE_UNVERIFIED; an index snippet is never treated
as current marketplace data. Avito is excluded from default retail search and
comparison because each used listing is a unique physical item.
Runtime settings can also live in ~/.config/marketplaces-mcp/config.json or in the path from MARKETPLACES_CONFIG:
{
"web_backend": "hive_web",
"hive_web_max_tokens": 12000,
"browser_channel": "chrome",
"browser_headless": true,
"browser_locale": "ru-RU",
"browser_timezone": "Europe/Moscow",
"browser_args": ["--disable-blink-features=AutomationControlled"],
"browser_default_user_agent": true,
"proxies": {
"ozon": "http://user:password@proxy.example:19081",
"yandex_market": null
}
}For local development, scripts/camofox-bridge.py exposes the small Camofox-compatible read-only API used by the adapters (POST /tabs, GET /tabs/{tabId}/snapshot, DELETE /sessions/{userId}) on top of Hive Web/Playwright:
uv run python scripts/camofox-bridge.py --host 127.0.0.1 --port 8765 --headfulThen set "camofox_url": "http://127.0.0.1:8765" in the runtime config.
Per-marketplace proxy values are only applied to that marketplace. When a proxy is configured for a marketplace, the adapter skips Hive Web for that marketplace and uses the proxied Playwright/httpx path. Use an HTTP proxy with authentication for browser-heavy marketplaces because Chromium/Playwright does not support authenticated SOCKS5 proxies. Environment variables override file values: MARKETPLACES_PROXY_OZON_URL, MARKETPLACES_OZON_PROXY_URL, OZON_PROXY_URL, MARKETPLACES_PROXY_YANDEX_MARKET_URL, MARKETPLACES_YANDEX_MARKET_PROXY_URL, YANDEX_MARKET_PROXY_URL.
Ozon is rendered with JavaScript enabled. When an Ozon proxy is configured, the Ozon adapter keeps Playwright headful even if browser_headless is true, because Ozon is stricter in headless mode. Disabling JavaScript is not a useful fallback: Ozon returns an anti-bot challenge asking the browser to enable JavaScript, and the adapter reports it as CAPTCHA_OR_BLOCKED.
Ozon Travel uses the Ozon proxy setting by default. Search-index fallback can
discover canonical flight or hotel links, but it returns no invented price and
adds INDEX_DISCOVERY_ONLY, PRICE_UNVERIFIED, and, for hotels,
DATE_AVAILABILITY_UNVERIFIED.
Requirements
Python 3.11+
Hermes or another MCP client
Install
git clone https://github.com/YegorMy/marketplace-mcp.git
cd marketplace-mcp
uv syncRun tests:
uv run pytest -qRun the MCP smoke test:
uv run python scripts/test-mcp-client.pyRun a live search smoke test:
uv run python scripts/smoke-search.py --query "бумага a4" --limit 2Run one explicit Avito canary without touching retail marketplaces:
uv run python scripts/live_canary.py --avito-only --avito-query "кроватка Stokke"Run explicit read-only Ozon Travel canaries:
uv run python scripts/smoke-travel.py flights MOW LED 2030-05-10
uv run python scripts/smoke-travel.py hotels "Сочи" 2030-05-10 2030-05-12Live search depends on current marketplace behavior. Ozon, Ozon Travel, and
Yandex Market may rate-limit, block, or change page markup. In that case the
smoke test should return warnings such as CAPTCHA_OR_BLOCKED instead of
crashing or fabricating current prices.
Hermes setup
The installer writes a marketplaces MCP server entry into ~/.hermes/config.yaml and tests the connection:
bash scripts/install-hermes-mcp.shYou can override the MCP server name:
SERVER_NAME=marketplaces bash scripts/install-hermes-mcp.shManual Hermes config:
mcp_servers:
marketplaces:
command: /absolute/path/to/uv
args: ["run", "--project", "/absolute/path/to/marketplace-mcp", "marketplaces-mcp"]
connect_timeout: 60
enabled: trueAfter changing MCP config, reload MCP in the client or start a new session.
Other MCP clients
Any MCP client that supports stdio can run the same command:
uv run --project /absolute/path/to/marketplace-mcp marketplaces-mcpClaude Code:
claude mcp add -s user marketplaces -- uv run --project /absolute/path/to/marketplace-mcp marketplaces-mcpCodex CLI:
codex mcp add marketplaces -- uv run --project /absolute/path/to/marketplace-mcp marketplaces-mcpOpenCode uses the same stdio command in its MCP config:
{
"mcp": {
"marketplaces": {
"command": "uv",
"args": ["run", "--project", "/absolute/path/to/marketplace-mcp", "marketplaces-mcp"]
}
}
}Development
uv sync
uv run pytest -q
uv run python scripts/test-mcp-client.py
uv run python scripts/smoke-search.py --query "бумага a4" --limit 2The adapters live under src/marketplaces_mcp/adapters/. Tests use fixtures where possible so the core behavior does not depend on live marketplace pages.
License
MIT
Available Tools
6 toolsmarketplaces_compareD
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| strategy | No | auto | |
| limit_per_marketplace | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
marketplaces_get_artifactD
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | content.json | |
| artifact_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
marketplaces_product_detailsD
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| strategy | No | auto |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
marketplaces_searchD
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| strategy | No | auto | |
| marketplaces | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ozon_searchD
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| strategy | No | auto |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
yandex_market_searchD
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| strategy | No | auto |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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
v0.1.0- First observed
marketplaces_compare - First observed
marketplaces_get_artifact - First observed
marketplaces_product_details - First observed
marketplaces_search - First observed
ozon_search - First observed
yandex_market_search
TDQS
Scored across 6 tools
Tools like marketplaces_search, ozon_search, and yandex_market_search overlap in purpose, making it unclear when to use which. marketplaces_compare and marketplaces_product_details also have unclear boundaries.
Naming is inconsistent: some tools use 'marketplaces_' prefix while others use specific marketplace names (ozon_, yandex_market_). Verb usage varies (compare, get, details, search) without a clear pattern.
With 6 tools, the count is appropriate for a focused marketplace server. It covers search, comparison, and details without being excessive.
The tool set covers search and product details but lacks obvious lifecycle operations like add, update, or delete products. The 'get_artifact' tool is ambiguous and doesn't clearly fit.
Maintenance
Related MCP Connectors
Federated commerce search across independent WooCommerce merchants. Keyless, read-only MCP server.
Google Shopping products, prices, sellers, and deals as structured data via a hosted MCP server.
MCP server for real-time product search by barcode (EAN, UPC, GTIN) or keyword on ean-search.org
MCP server for Russian books search, details, and recommendation candidates.
Related MCP Servers
- AlicenseCqualityCmaintenanceA Model Context Protocol server enabling product searches across e-commerce platforms, price history tracking, and product specification-based searches using natural language prompts.219MIT
- FlicenseBqualityCmaintenanceProvides MCP tools for searching and comparing products on Wildberries (and Ozon planned), including product search, detailed card retrieval, and review fetching, normalized for LLM consumption.32-
- AlicenseAqualityBmaintenanceRead-only MCP server for searching Yahoo! Shopping products through the Yahoo! Shopping Item Search API v3. It supports keyword and JAN-code search with price, stock, condition, shipping, sorting, category, brand, seller, image-size, and pagination filters.11MIT
- AlicenseAqualityCmaintenanceEnables querying and comparing prices, availability, ratings, reviews, and seller details from major Russian and Chinese marketplaces (Wildberries, Ozon, Yandex Market, and others) without requiring API keys, via a unified MCP interface.424MIT