Skip to main content
Glama
SZhukovWork

ozon-mcp

by SZhukovWork
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ozon-mcp

English · Русский

A server for buyers: it reads the public storefront as an anonymous visitor, no Ozon account or token needed. For the seller side (orders, stock, the official Seller API) you need a different tool.

An MCP server that gives LLM agents live, honestly-labelled data from Ozon: search with real pagination, sorting and a price window; product cards with every price labelled, delivery dates for your region, seller legal details, variants and other sellers' offers; reviews with the SKU's own rating separated from the rating Ozon shares across a whole product line.

Why another Ozon server

Ozon scrapers tend to return numbers that look right and mean something else. This one is built around the traps found while checking its output against the site:

Pitfall

What this server does

Ozon's anti-bot (Variti) blocks plain HTTP clients, even with the browser's cookies (403/307)

Keeps one Chromium page on ozon.ru and calls the storefront API from inside it; renews the session when Ozon revokes it

One "price" without saying which

Every price is named: price_with_ozon_card_rub (paying with an Ozon Bank card), price_without_ozon_card_rub, price_before_discount_rub (crossed out). Search tiles show only the Ozon Card price, and the field says so

The rating on a card is the rating of a whole variant line — for a Fiskars axe, 24 different models share "4.9 • 3 536 reviews"

Shows the card rating with its scope next to the SKU's own rating, computed from its own reviews (e.g. 4.94 from 389 reviews); flags shared ratings in search results

"Brand" read from the tile's first label — which is often "Бренд проверен" or "24 ₽ / шт"

Brand only when the tile really shows one (otherwise from the card's structured data); unit prices become price_per_unit

No pagination; for the default sort Ozon pages hold only 8 items, so "limit 36" silently returns 8

Walks real result pages, reports next_page; never cuts a page

Following Ozon's "next page" past the end yields an endless shelf of unrelated products

Only Ozon's search-results widget counts as results

Ozon's price filter and price sort are approximate (a 1300–1450 ₽ window returns 1058–1545 ₽)

Items outside the requested window are kept and flagged outside_price_window

"Delivery today" that actually costs +1 937 ₽ extra

Regular and paid express delivery are separate fields, with the surcharge

Seller name truncated by the card layout ("Садовая техника и и...")

Full name, rating, order count, legal entity, ОГРН/ИНН and address

Every answer carries fetched_at and the region the prices and dates were computed for.

Related MCP server: ozon-customer-mcp

Tools

Tool

What it returns

search_products(query, page, sort, price_min, price_max, limit, auto_category)

Whole Ozon result pages from page until limit items; sort popular / price_asc / price_desc / rating / newest / discount; next_page; resolved_to (the category/brand Ozon narrowed the query to). Per item: SKU, name, brand when shown, Ozon Card price, crossed-out price, discount label, price per unit, rating & reviews as on the tile + rating_shared_with, delivery date (and paid express with surcharge), units left, sold by Ozon, 18+ flag, labels, URL

get_product(product, include_variants, include_other_sellers, include_description)

All three prices; sale banner and its end; Ozon's only price-history hint; availability; delivery options with dates, where it ships from, returns; seller with rating, orders and legal entity; card rating (scope, star split) + this SKU's own rating; every variant with its SKU and price; other sellers' offers of the same product; characteristics; description; package contents

get_reviews(product, page, limit, sort, scope, include_seller_replies)

30 per page; sort helpful (Ozon's default) / worst / best; scope=sku or the whole line; per review: date, stars, text, pros, cons, SKU and variant it is about, photo/video counts, helpful votes, outdated, comment count, seller reply (optional); line star split and the SKU's own rating

compare_products(products, with_delivery)

Up to 20 SKUs: prices, availability, card rating with the size of its variant line, seller, cheapest other-seller offer, delivery date

product accepts a SKU (1837133915) or a product URL.

Requirements

Python

≥ 3.10, with uv (or pip)

Browser

Chromium via Playwright, downloaded automatically on first run (≈300 MB download, ≈650 MB on disk in ~/.cache/ms-playwright, shared by all Playwright tools). Ozon's anti-bot lets no plain HTTP client through, so every request is made from inside a Chromium page (headless shell): the browser stays open while the server is in use and closes after 10 minutes idle. The first request of a session takes ≈15–35 s (browser start plus the anti-bot check; 34 s measured)

Docker

Not needed: Chromium runs as a child process of the server on the host

System libraries

Already present on desktop Linux, macOS and Windows. On a minimal Debian/Ubuntu server install them once (root): uvx --from playwright playwright install --with-deps chromium

Network

A Russian IP: VPN, foreign and many datacenter addresses are blocked. Switch the VPN off or set OZON_PROXY. Ozon can also stop letting an IP through for a while after many fresh browser sessions in a day (seen during development) — then wait rather than retry, and keep the cache directory: a saved session is what keeps the check passing

Memory

≈0.8 GB while the browser is open (measured)

Display

Not needed (OZON_HEADLESS=0 for debugging needs one)

Tested on

Linux (CachyOS; Playwright uses its Ubuntu build there). macOS and Windows are supported by Playwright but untested

Install

Claude Code:

claude mcp add ozon -- uvx --from git+https://github.com/SZhukovWork/ozon-mcp ozon-mcp

Any MCP client (claude_desktop_config.json, .mcp.json, …):

{
  "mcpServers": {
    "ozon": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/SZhukovWork/ozon-mcp", "ozon-mcp"]
    }
  }
}

From a checkout: uv venv && uv pip install -e . && .venv/bin/ozon-mcp.

The first request of a session opens the browser and passes the anti-bot check: expect 2–15 seconds (more on the very first run, when Chromium is downloaded). Later requests take about a second each. The browser closes after 10 idle minutes and reopens on demand.

Configuration (environment variables)

Variable

Default

Meaning

OZON_LOCATION

—

Delivery region. By default Ozon picks a city from your IP (reported in every answer). Set a city slug from Ozon's /geo/ pages (moskva, ekaterinburg, sankt-peterburg; the server picks the first pickup point Ozon lists there) or the URL of your pickup point, e.g. https://www.ozon.ru/geo/ekaterinburg/220380/ (open the point on the Ozon map and use "Поделиться"). The server selects it the way an anonymous visitor does; if that fails, answers say so in region.warning

OZON_PROXY

—

Proxy for the browser, e.g. http://user:pass@host:3128

OZON_MIN_INTERVAL

1.0

Seconds between requests to Ozon

OZON_IDLE_TIMEOUT

600

Close the browser after this many idle seconds

OZON_HEADLESS

1

0 shows the browser window (debugging)

OZON_CACHE_DIR

~/.cache/ozon-mcp

Where the browser session is kept (files are 0600)

What the numbers mean

  • price_with_ozon_card_rub — the green price on the site, "С банками": paying with an Ozon Bank card (Ozon also lists a few partner banks). price_without_ozon_card_rub — "С другими банками", any other card. price_before_discount_rub — the crossed-out price; the seller sets it, so large "discounts" against it are marketing. Search tiles carry only the Ozon Card price (price_rub for the few items that have a single price).

  • Region: prices and dates differ by region (checked: the same axe was 8 453 ₽ in Yekaterinburg and 8 494 ₽ in Moscow). A signed-in buyer may see other prices.

  • Ratings: rating.shown_on_card is what the site shows; its scope says whether it covers only this product or a variant line of N products. rating.this_sku is computed from the SKU's own reviews via Ozon's "this variant" filter; exact: false means only a lower bound was available. In search, rating_shared_with lists other results carrying the identical rating — that is a line rating.

  • Delivery: dates are the ones Ozon shows for the region, converted to ISO dates in the region's time zone (the original wording is kept in text). express_delivery / express_surcharge_rub is Ozon's paid fast option.

  • Stock: units_left only when Ozon itself shows a counter ("241 ед осталось"); Ozon's internal cart limits are not reported as stock.

  • Reviews: date is the date the site shows (the edit date for edited reviews). Ozon states that only buyers can review (review_policy); its per-review "Товар куплен на OZON" flag is almost never set, so a missing purchase_badge does not mean "not bought". outdated reviews no longer count toward the rating. Buyer names are not returned.

  • Price history: Ozon has none. When it shows "Стало дешевле", get_product returns its comparison of the current price (without Ozon Card) with last month's average — nothing more.

Limitations

  • Unofficial: uses the storefront's internal composer API, which Ozon can change at any time. Parsers are isolated in parse.py and covered by tests on recorded responses.

  • Needs a Russian IP; Ozon's anti-bot rejects VPN/foreign/datacenter addresses. Use OZON_PROXY if needed.

  • Ozon reports no total number of search results; the last page is only known when the next one comes back empty.

  • The search tile does not name the seller (only whether Ozon itself sells); use get_product / compare_products.

  • 18+ products (some knives, machetes) require a date-of-birth confirmation on the site; the server does not submit personal data on your behalf: search marks them adult_only, the card tools return an explicit error.

  • Sponsored placement: during testing Ozon did not label any search tile as advertising; sponsored is set only if a tile says so.

  • Read-only and anonymous (see Roadmap).

Roadmap

  • Later: optional account mode (off by default). Log in once in a visible browser window — phone number and SMS code never pass through the MCP client — to see your personal prices and exact delivery dates for your address.

  • Later: cart — add_to_cart / get_cart on top of the account mode.

  • Checkout, payment and changing the account's delivery address are deliberately out of scope.

Development

uv venv && uv pip install -e '.[dev]'
.venv/bin/pytest            # offline tests on recorded responses
.venv/bin/pytest -m live    # end-to-end over MCP stdio against live Ozon (Russian IP)

Layout: browser.py (Chromium in its own thread, anti-bot, location), client.py (request policy: re-challenge, rate limits, region), parse.py (pure functions over Ozon's JSON), server.py (tools).

Disclaimer & credits

Not affiliated with Ozon. Intended for personal price research; respect Ozon's terms of use and keep request rates low. The idea of calling Ozon's composer API from inside a browser page follows the MIT-licensed eduard256/ozon-mcp-server (Node.js); this is an independent implementation.

License: MIT.

Available Tools

4 tools
compare_productsA
Read-onlyIdempotent

Live side-by-side offers for up to 20 SKUs (one card request each).

Per SKU: name, brand, the three prices (Ozon Card / without / crossed-out), availability, the rating shown on the card with the size of its variant line (a line rating is not the SKU's own — use get_product for that), seller with rating, the cheapest other-seller offer Ozon advertises, and the delivery date under the cart button (express_delivery with its surcharge when Ozon also sells faster paid delivery). SKUs that fail are listed with the reason.

ParametersJSON Schema
NameRequiredDescriptionDefault
productsYesSKUs or product URLs to compare
with_deliveryNoAlso fetch the earliest delivery date Ozon shows under the cart button (one small request per SKU)

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Rich behavioral detail is added beyond the annotations: 'one card request each,' the delivery-date request cost under with_delivery, express_delivery surcharge semantics, and explicit handling of failed SKUs 'with the reason.' The 'Live' qualifier aligns with openWorldHint. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence front-loads scope and request cost, followed by a well-organized per-SKU field list. The description is longer than strictly necessary, but every clause carries useful semantics, and the explicit cross-reference to get_product earns its place. Slight verbosity keeps it from a top score.

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?

Given an output schema is present, the description still supplements it with field semantics, failure behavior, and the line-rating caveat. It covers the cost model (one card request each, one small request per SKU), which is important operational context. No critical gaps remain for a safe read-only tool with annotations already declaring readOnlyHint and idempotentHint.

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 description coverage is 100%, so baseline is 3. The description reinforces that products are SKUs and that with_delivery maps to the delivery date under the cart button, but it does not add new meaning beyond the schema or materially resolve ambiguity. It is serviceable but not elevated.

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?

States a specific verb and resource: 'Live side-by-side offers for up to 20 SKUs.' It clearly differentiates itself from get_product by noting that the rating shown is the card's line rating, not the SKU's own rating, and explicitly points to get_product for that. The function is unmistakably a multi-product comparison tool, distinct from search, detail, or review tools.

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?

The description gives a clear when-to-use and when-not-to-use signal: if you need the SKU's own rating, 'use get_product for that.' It also frames the tool's domain as comparing up to 20 SKUs side-by-side, which is a clear context for when it is the right choice over search or get_reviews.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_productA
Read-onlyIdempotent

Full, live product card for one SKU.

Prices: Ozon Card / without Ozon Card / crossed-out, plus the sale banner and Ozon's only price-history hint (current vs last month's average) when it shows "Стало дешевле". Availability, delivery options and dates for the region, where it ships from, return terms. Seller with rating, order count and legal entity (name, ОГРН/ИНН, address). Rating: the one Ozon shows (often the whole variant line's) next to this SKU's own rating computed from its own reviews. Variants with their prices, other sellers' offers of the same product, characteristics, description, package contents.

ParametersJSON Schema
NameRequiredDescriptionDefault
productYesOzon SKU (the number in the product URL, e.g. 1837133915) or a full ozon.ru product URL
include_variantsNoList every variant of the line (colour/size/weight) with its own SKU and Ozon Card price
include_descriptionNoFull characteristics, description and package contents (one more request)
include_other_sellersNoList other sellers' offers of the same product (Ozon's 'У других продавцов')

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context beyond those: the card is 'live', the displayed rating is often the variant line's while the SKU's own rating is computed from its own reviews, and the price-history hint is Ozon's only one. This is meaningful extra transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded in the first sentence, and the rest is a dense enumeration with no wasted sentences. The long run-on style could be improved with bullets, but every clause 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 complex tool with an output schema and rich annotations, the description covers the major output domains and the single-SKU scope well. It does not discuss error cases or data-freshness caveats, but those are not required for correct invocation.

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 description coverage is 100%, so the baseline is 3. The description maps output sections to the optional flags (variants, other sellers, characteristics/description/package contents), but it does not add significant parameter-level meaning beyond what the schema already provides.

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 opens with a specific verb and resource: 'Full, live product card for one SKU.' It then enumerates the card's contents (prices, availability, seller, rating, variants, other sellers, characteristics), which clearly distinguishes it from search_products, get_reviews, and compare_products.

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?

The 'for one SKU' phrasing implies this is the tool to use when a single product's full card is needed, but there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives. It does not explain when to prefer get_reviews or compare_products instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_reviewsA
Read-onlyIdempotent

Buyer reviews with date, stars, text, pros, cons and the variant bought.

Also returns the line rating with its star split and this SKU's own rating computed from its reviews, so it is clear what a headline number covers. Per review: sku/variant (which product of the line it is about), purchased_on_ozon, photo and video counts attached to that review, helpful votes, outdated (Ozon no longer counts it in the rating), number of comments and — optionally — the seller's reply. date is the date the site shows (the edit date for edited reviews). Ozon says only buyers can review (review_policy); purchase_badge appears only where Ozon still prints "Товар куплен на OZON".

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoOzon review page to start from (30 per page; continue with `next_page`)
sortNo'worst' puts the lowest ratings first — the fastest way to real drawbacks; 'helpful' is Ozon's default (new and useful)helpful
limitNoFetch whole pages until at least this many reviews
scopeNo'sku' = reviews of this exact SKU; 'line' = the whole variant line the card rating is based onsku
productYesOzon SKU (the number in the product URL, e.g. 1837133915) or a full ozon.ru product URL
include_seller_repliesNoLoad the shop's reply for reviews that have comments (one request each, up to 15)

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes far beyond the annotations. It explains semantic nuances: date is the edit date for edited reviews, purchase_badge appears only when Ozon still prints it, outdated reviews are not counted, the seller reply behavior, and the pagination behavior (fetch whole pages until limit, next_page). It also notes the review_policy indicating only buyers can review. This is rich behavioral context that annotations (readOnly, openWorld, idempotent, non-destructive) do not cover. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is fairly long but every sentence earns its place by explaining a specific facet of the tool's behavior or response structure. It is front-loaded with the core purpose and then details the output fields and nuances. There is no fluff or repetition. However, it could be tightened by using bullet points or sub-sections, but given the complexity, the current format is acceptable. It is concise relative to the information it conveys.

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 tool with 6 parameters and a rich output, the description is remarkably complete. It covers pagination, sorting, scope, edge cases (edited reviews, outdated, purchase_badge), and the optional seller replies. It also explains what the output includes (per-review fields, line rating, SKU rating). It does not mention rate limits or errors, but that is beyond typical scope and the output schema exists to define structure. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. But the description adds substantial meaning to parameters: it explains the effect of 'scope' (sku vs line), the meaning of 'outdated' in reviews, how 'limit' works (fetch whole pages), and the optional seller replies. It also clarifies that 'product' can be a SKU or URL. This goes beyond the schema's short descriptions and helps an agent choose correct parameter values.

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 what the tool does: 'Buyer reviews with date, stars, text, pros, cons and the variant bought.' It also explains the line rating and SKU rating, so an agent knows exactly what information is returned. The verb 'get' and resource 'reviews' are explicit and distinct from sibling tools (search_products, get_product, compare_products) which focus on product discovery, details, and comparison.

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 when to use it by specifying it returns reviews, and it details the scope (sku vs line) so an agent can select the right granularity. However, it does not explicitly state alternatives or exclusions. But given the sibling names, it's clear this is for reviews rather than product lookups. The guidance is solid but not fully explicit about when not to use it; a 4 is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_productsA
Read-onlyIdempotent

Search Ozon like the site does, with real pagination.

Walks Ozon's result pages from page until limit items are collected; pages are never cut, so next_page continues without gaps (Ozon itself may repeat an item across pages — repeats within one call are dropped). Ozon does not report a total count.

Per item: SKU, name, brand (only when the tile shows it — otherwise use get_product), price_with_ozon_card_rub (tiles show only the Ozon Card price; e-books and similar show a single price_rub), crossed-out price, Ozon's discount label, rating and review count as on the tile (usually the whole variant line's — see rating_shared_with), delivery date for the region (express_delivery = faster paid option with its surcharge_rub), units_left when Ozon shows a stock counter, sold_by_ozon, adult_only, marketing labels. resolved_to shows the category/brand filters Ozon applied to the query.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoOzon result page to start from (continue with `next_page`)
sortNoOrder of results, the site's optionspopular
limitNoFetch whole Ozon pages until at least this many items (pages hold 8–36)
queryYesSearch phrase, as typed on the site (Russian works best)
price_maxNoUpper bound, rubles (Ozon filters by the Ozon Card price)
price_minNoLower bound, rubles (Ozon filters by the Ozon Card price)
auto_categoryNoLet Ozon narrow the query to its predicted category/brand, as the site does; false searches every category

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this as read-only, idempotent, and non-destructive, and the description adds significant behavioral detail beyond that: pages are never cut, repeated items within a call are dropped, Ozon reports no total count, and many field-level caveats are disclosed (Ozon Card price only, e-books single price, rating_shared_with, conditional units_left, resolved_to filters).

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?

Although the description is long, it is densely informative with no filler. The first sentence establishes the core purpose, and the following sentences each earn their place by documenting pagination behavior, per-item field caveats, and the resolved_to detail.

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?

This is a complex scraping/search tool with many Ozon-specific quirks, and the description covers them thoroughly: page walking, repeat deduplication, missing total count, conditional fields, delivery date, price semantics, and category/brand filters. An output schema exists, so the description does not need to repeat return-value structure; the behavioral context is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning to the pagination parameters by explaining how page, limit, and next_page interact and that Ozon pages are never cut. The tile-level price and brand caveats also enrich what the returned data means, though the description does not add much beyond the schema for sort, query, or auto_category.

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 opens with 'Search Ozon like the site does, with real pagination,' which clearly identifies the verb, resource, and mode of operation. It distinguishes itself from the sibling tools (get_product, get_reviews, compare_products) by framing this as the site-style search and by explicitly routing missing brand data to 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?

The description gives concrete usage context: it searches Ozon result pages, accumulates until limit items, and continues via next_page without gaps. It also names an alternative explicitly ('otherwise use get_product'), but it does not provide a broader when-to-use vs. when-not-to-use comparison against get_reviews or compare_products.

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.

  1. 4 tool updatesv0.1.0
    • First observedcompare_products
    • First observedget_product
    • First observedget_reviews
    • First observedsearch_products
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: searching products, fetching a product card, fetching reviews, and comparing products. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: search_products, get_product, get_reviews, compare_products. The naming is predictable and uniform.

Tool Count5/5

With 4 tools covering search, product details, reviews, and comparison, the server is well-scoped for product research and price checking on Ozon. Each tool is necessary and the count is appropriate.

Completeness4/5

The server covers the core read-only workflows for product research: search, detail, reviews, and comparison. Minor gaps exist such as no category browsing or cart/ordering, but these are outside the likely intended scope of a research-focused MCP server.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • ozon-customer-mcp

    Raleose
    A
    license
    A
    quality
    B
    maintenance
    Enables Ozon marketplace customer-side operations including product search, detailed product cards, reviews, seller comparisons, and delivery city selection via MCP.
    4
    19
    MIT

  • ozon-mcp-ru

    ilyautov
    A
    license
    A
    quality
    A
    maintenance
    Ozon Seller API in your AI assistant: products, FBS and FBO orders, prices, stocks, finance and reviews. 441 methods live in a YAML catalog the server executes, the agent searches it in plain language and calls a method through three generic tools, and every method carries an access class so writes and irreversible calls ask for confirmation.
    25
    66 PyPI
    2
    MIT

  • marketplace-mcp

    stitcman
    A
    license
    Not graded
    quality
    B
    maintenance
    Lets AI agents read and query Wildberries, Ozon, and Yandex Market seller accounts through unified typed tools, with multi-account support, rate limiting, and encrypted credentials.
    57 npm
    MIT