marketplace-mcp
This server provides read-only marketplace product search, comparison, product-detail lookup, and saved-artifact retrieval.
Search one or more marketplaces with
marketplaces_searchusing a query, result limit, strategy, and optional marketplace list.Search Ozon only with
ozon_search.Search Yandex Market only with
yandex_market_search.Compare retail marketplace results and group similar products with
marketplaces_compare.Read a product page by URL with
marketplaces_product_details.Retrieve a saved result artifact by ID with
marketplaces_get_artifact.Operate read-only only: no login, cart, ordering, payment, or CAPTCHA bypass.
Note: the README mentions additional Wildberries, Avito, reviews, travel, tours, and access-status tools, but those are not exposed in the provided schema.
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. Indexed flight links must match the requested airport/city codes exactly: a Pulkovo or all-Moscow route cannot satisfy an SVO request. Index links carry no verified fare or dated availability. A visible Ozon Travel block stops browser fallback; public-index discovery can still return a matching route link. 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.
Ozon package searches can use any departure city and destination country encoded
in a supported Ozon search link. Choose a route in Ozon's public tours form, copy
the resulting search URL and pass it as search_url to
ozon_travel_tours_search. In this mode, the link supplies the complete trip;
only limit may accompany it. The returned source_url can be passed to
ozon_travel_tour_details with the chosen hotel name.
Automatic name lookup currently knows only Saint Petersburg (LED) to UAE.
Other names return OZON_TOURS_ROUTE_LOOKUP_REQUIRED with a link to Ozon's form;
the server never substitutes that route or guesses provider IDs. Broader automatic
location lookup has not been implemented or verified. General route parsing and
context checks are covered offline; live Ozon access remains environment-dependent.
Both input modes quote one room, one 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. Copied links with incomplete, conflicting or unsupported trip filters are rejected rather than silently broadened. Supported meal filters are the existing all-inclusive options; omit the meal filter in Ozon's form to search all meal plans. Additional resort/hotel filters require separate support. Known campaign tracking parameters are discarded.
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
Install uv and the Hermes CLI first. The installers add or update only the selected MCP server entry and then run hermes mcp test.
macOS / Linux:
bash scripts/install-hermes-mcp.shWindows PowerShell 5.1 or PowerShell 7 (no WSL or Git Bash required):
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\install-hermes-mcp.ps1Use pwsh instead of powershell.exe for PowerShell 7. These options apply to this process only; the installer does not change the machine's execution policy.
You can override the server name, project directory, or uv executable:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\scripts\install-hermes-mcp.ps1 -ServerName marketplaces -ProjectDir 'C:\src\marketplace-mcp' -UvBin 'C:\Tools\uv.exe'SERVER_NAME=marketplaces bash scripts/install-hermes-mcp.shConfiguration uses $HERMES_HOME/config.yaml when HERMES_HOME is set. Otherwise it uses ~/.hermes/config.yaml on macOS/Linux and %LOCALAPPDATA%\hermes\config.yaml on native Windows, following the Hermes Windows guide. Run Hermes setup first if the config does not exist. For a custom Hermes profile, set HERMES_HOME to that profile's directory before running the installer.
Before changing the file, the installer saves config.yaml.bak. It preserves other settings and MCP servers. YAML comments and formatting may change; the backup retains the original file. Re-running with the same settings leaves the config and backup unchanged.
Manual Hermes config (macOS/Linux):
mcp_servers:
marketplaces:
command: /absolute/path/to/uv
args: ["run", "--project", "/absolute/path/to/marketplace-mcp", "marketplaces-mcp"]
connect_timeout: 60
enabled: trueManual Windows config: replace the example paths with your checkout and the output of (Get-Command uv).Source. Single quotes keep Windows backslashes literal in YAML.
mcp_servers:
marketplaces:
command: 'C:\Tools\uv.exe'
args: ['run', '--project', 'C:\src\marketplace-mcp', 'marketplaces-mcp']
connect_timeout: 60
enabled: trueAfter changing MCP config, run /reload-mcp in Hermes 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
Search products from independent stores. Read-only remote MCP; no sign-in. Buy on merchant sites.
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
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.2123 PyPI19MIT
- FlicenseBqualityDmaintenanceProvides 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-
- AlicenseAqualityDmaintenanceRead-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.425MIT