Skip to main content
Glama

Compare Prices Across Russian Marketplaces

compare_prices
Read-onlyIdempotent

Find the cheapest price for any product across Russian marketplaces in one query. Returns ranked offers and source status to spot incomplete comparisons.

Instructions

Price one product across every configured Russian marketplace at once.

Queries each marketplace concurrently and returns a single list ranked by price, plus a per-source report of what answered and what did not. This is the tool for "where is X cheapest" — running the per-marketplace search tools one at a time gives the same data far more slowly and without the ranking.

Two things to read carefully in the output:

  • cheapest is chosen on everyday prices. Yandex Market's subscriber price appears as price_with_subscription_rub and is deliberately excluded from ranking, since it requires a paid Yandex Plus subscription.

  • source_outcomes shows which marketplaces answered. A blocked or timed-out source means the comparison is partial, not that the product is absent there — complete tells you which case you are in.

Titles are matched loosely: marketplaces name things differently, so scan the results rather than assuming every row is the identical model.

Return Format

CompareResponse: {query, sources_queried, sources_ok, complete, total_offers, cheapest, price_spread_rub, offers, source_outcomes, warnings, server_version}. offers is ranked by everyday price_rub — cheapest first, offers without a rouble price after the ranked ones. warnings carries validation/completeness warnings.

Error Format

On validation failure, raises ToolError with a JSON message describing the error code and whether it is retryable. Individual source failures do NOT raise — they are reported in source_outcomes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesWhat to price, in Russian — e.g. 'стиральная машина узкая' or 'iphone 15 128'.
sourcesNoRestrict to specific marketplaces (wildberries, yandex_market, ozon). Omit to query all.
in_stock_onlyNoRank only offers whose marketplace explicitly reports them in stock.
per_source_limitNoHow many offers to take from each marketplace.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNo
offersNo
cheapestNo
completeNo
warningsNo
sources_okNo
total_offersNo
server_versionNo
source_outcomesNo
sources_queriedNo
price_spread_rubNo
cheapest_comparableNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.1.0
    • addedInput schema / properties / in_stock_only
      Added value: +{
      +  "default": false,
      +  "description": "Rank only offers whose marketplace explicitly reports them in stock.",
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / cheapest_comparable
      Added value: +{}
  2. First observedv1.5.1

TDQS

A4.7/5.0
Behavior5/5

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

The annotations already provide readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral detail beyond those: cheapest is based on everyday prices and deliberately excludes the subscription-only price, source_outcomes indicates partial vs complete results, titles are matched loosely, and validation errors raise while individual source failures are reported non-fatally.

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 organized into clearly labeled sections with the primary purpose and key behavioral caveats front-loaded. Each paragraph earns its place, and the Return/Error format sections are compact and informative without being bloated.

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 the output schema exists, the description need not re-enumerate every field, yet it still explains the most important output semantics: ranking by price_rub, how `cheapest` is computed, the `source_outcomes` meaning, and error/raise behavior. The tool is complex enough that this guidance matters, and it is fully and clearly supplied.

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%, so the schema already documents all four parameters with descriptions, defaults, and constraints. The description adds contextual flavor—such as querying in Russian and how subscription prices affect ranking—but does not materially define the parameters beyond what the schema already provides, so the baseline of 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 states a specific verb ('price'), a resource ('one product'), and a scope ('across every configured Russian marketplace') in a single sentence. It also distinguishes itself from the per-marketplace search tools by noting they give the same data more slowly and without ranking.

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 explicitly positions this as 'the tool for "where is X cheapest"' and contrasts it with running per-marketplace search tools one at a time, which deliver the same data more slowly and without ranking. This gives an agent clear selection criteria relative to the sibling search tools.

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