ru-marketplace-mcp

Verify Compared Offer

compare_verify_offer

Read-onlyIdempotent

Verify a compared offer against its native marketplace card to confirm live price, stock, seller, and product identifiers before relying on the comparison.

Instructions

Verify one compared offer through its marketplace card tool.

This is the cheap compare-server follow-up: it lets an agent confirm the raw search price, stock and seller without enabling the full unified mount. The returned card is source-native and therefore keeps fields the comparison intentionally normalises away.

Return Format

JSON object: {source, product_id_or_url, card}. card is the native source response, preserving price, availability, seller, and source-specific fields when the marketplace exposes them. identity_verification, when requested, carries the observed typed identifiers and a match verdict; absent manufacturer evidence yields unknown, never a title-derived exact match. For Yandex, pass the search row's variant_id as expected_variant_id: a different or missing card SKU is rejected before computing a price delta. Without it, only the current default card price is checked.

Error Format

Raises BadRequestError when the source is unknown, not installed, or the identifier cannot be validated; native card errors are returned as tool errors with their source-specific taxonomy.

Input Schema

TableJSON Schema

Name	Required	Description
`source`	Yes	Marketplace source name from compare_prices, e.g. wildberries or ozon.
`expected_identity`	No	Optional manufacturer identifiers and variant attributes to verify against the card.
`product_id_or_url`	Yes	product_id or direct product URL from the compared offer
`expected_price_rub`	No	Price returned by compare_prices; used to report a live card delta.
`expected_variant_id`	No	Yandex variant_id from the search row; rejects a different card SKU.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.3.0Sep 13, 2026

addedInput schema / properties / expected_identity

Added value: +{
+  "anyOf": [
+    {
+      "description": "Product-family/variant evidence, independent of a seller offer.",
+      "properties": {
+        "brand": {
+          "default": "",
+          "type": "string"
+        },
+        "gtin": {
+          "default": "",
+          "type": "string"
+        },
+        "model": {
+          "default": "",
+          "type": "string"
+        },
+        "mpn": {
+          "default": "",
+          "type": "string"
+        },
+        "native_product_id": {
+          "default": "",
+          "type": "string"
+        },
+        "source": {
+          "default": "",
+          "type": "string"
+        },
+        "variant_attributes": {
+          "additionalProperties": {
+            "type": "string"
+          },
+          "type": "object"
+        }
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional manufacturer identifiers and variant attributes to verify against the card."
+}

addedInput schema / properties / expected_variant_id

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 100,
+      "minLength": 1,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Yandex variant_id from the search row; rejects a different card SKU."
+}

Addedv2.1.0Sep 9, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent/openWorld annotations: it documents the returned card shape, the deliberate retention of source-native fields the comparison normalises away, the identity-verification verdict semantics ('unknown, never a title-derived exact match'), the Yandex SKU-rejection behavior, and an explicit error taxonomy (BadRequestError vs native card errors).

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?

Front-loaded one-line purpose, then clearly headed Return Format and Error Format sections; sentences are dense but each carries functional content. Slightly verbose given an output schema already exists, so some return-format prose is partially redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, invocation context, return shape, error behavior, and the awkward Yandex edge case, which is complete for a 5-parameter read tool with an output schema. The duplication of return-format detail that the output schema already supplies is the only slack.

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 baseline is 3, but the description adds real cross-field behavior the schema cannot express: expected_variant_id causes a pre-delta SKU rejection for Yandex, expected_identity drives a match verdict, and falling back to default card price occurs when variant id is omitted.

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 (verify) and resource (one compared offer) via a named mechanism (its marketplace card tool), and positions it against sibling tooling by calling it 'the cheap compare-server follow-up' versus the 'full unified mount'. An agent can distinguish it from compare_prices and the individual *_card tools without opening any schema.

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?

Gives clear context for when this tool applies: after a comparison, to confirm raw search price, stock and seller cheaply. It implies the alternative (the full unified mount) but never states explicit when-not/exclusion conditions, and the Yandex-specific guidance is scoped to one parameter rather than the tool's overall usage boundary.

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