WEM Price Compare

Check whether a price claim is true

verify_offer

Read-only

Check a price claim before repeating it. Given a product and a price someone has asserted at a named retailer, returns whether that price is live in WEM's verified catalogue and whether anything cheaper exists. Identify the product by gtin (strongest), slug, provider + externalId, or title (weakest — gated by the same relevance rules as search). Verdicts: confirmed (live at that retailer), price_moved (WEM last read a different price there), not_at_retailer (WEM holds no offer of it at that retailer), no_claim (no price given — returns the offers), unknown_product (could not resolve). unknown_product means the claim could NOT be checked; it never means the claim is false, and must not be reported as one. Every result carries lastConfirmedAt so the answer's freshness is visible. Use this before quoting any price you did not get from WEM.

Input Schema

TableJSON Schema

Name	Required	Description
`gtin`	No	Product barcode: EAN-13, UPC-A, EAN-8 or GTIN-14. Strongest identifier.
`slug`	No	WEM canonical slug, as in wem3.ai/pl/{slug}.
`price`	No	The price being claimed. Omit to ask only what the verified offers are.
`title`	No	Product title. Weakest identifier — used only when no id is available.
`currency`	No	ISO 4217 code for the claimed price. Default GBP.
`provider`	No	Retailer slug for the listing being checked, e.g. 'currys'.
`retailer`	No	Retailer the price was claimed at — slug or display name.
`externalId`	No	The retailer's own product id (ASIN, eBay item number). Use with provider.

Output Schema

TableJSON Schema

Name	Required	Description
`offers`	Yes
`source`	Yes
`product`	No
`receipt`	Yes	Unsigned citation handle for this answer. Serialises what was already returned. signed is always false.
`summary`	Yes	Written so quoting it verbatim is accurate. Prefer quoting it to paraphrasing the verdict code.
`verdict`	Yes
`betterBy`	No	Saving from taking `cheapest` over the claimed price. Never negative.
`cheapest`	No
`identity`	No	How the product was identified — a separate question from whether the price checks out. Never present a `strength` of "inferred" as a verified identity.
`disclosure`	Yes	Affiliate disclosure to relay once per answer. Outbound links are tracked at no extra cost to the buyer.
`resolvedBy`	No	Which identifier resolved the product.
`claimMatched`	No
`comparisonSet`	No	How wide the comparison behind `cheapest` was. `exhaustive` is always false: WEM does not see every retailer, so `cheapest` is the lowest offer WEM holds, never the lowest that exists. Relay it as such.
`lastConfirmedAt`	No	When WEM last read these offers — the freshness of this answer.
`toleranceApplied`	No

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, and the description adds substantial behavioral context on top: the exact verdict set, the crucial caveat that unknown_product must never be reported as false, and the presence of lastConfirmedAt for freshness. This goes well beyond the annotations and prevents dangerous misinterpretation.

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 long but every sentence earns its place: purpose, identifier strategy, verdict semantics, the critical unknown_product warning, freshness, and usage guidance. The most actionable instruction ('Check a price claim before repeating it') is front-loaded.

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 8 parameters, none required, and high ambiguity risk, the description covers the full invocation context: how to identify the product, what the verdicts mean, how to interpret the weakest identifier, and when to call it. The output schema handles return-value details, so nothing essential is missing.

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 description coverage is 100%, so the baseline is 3. The description adds genuine value by ranking identifier strength (gtin strongest, title weakest), explaining that omitting price returns offers, and clarifying the interplay of provider and externalId. These are semantic distinctions not present in the schema alone.

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 ('check'), a clear resource ('a price claim'), and the exact decision it produces (whether that price is live and whether anything cheaper exists). This distinguishes it sharply from siblings like find_lowest_price or get_product without needing to open their schemas.

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?

It explicitly says to use this tool before quoting any price not obtained from WEM, which gives a clear trigger for invocation. It also explains identifier precedence and the meaning of each verdict, though it does not explicitly name sibling alternatives or state when not to use it.

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

All WEM Price Compare tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation4/5

Each tool targets a distinct action: searching, semantic searching, retrieving categories or product details, comparing offers, comparing products, finding a single lowest price, and verifying a claim. The only mild ambiguity is between search_products and semantic_search, and between compare_offers and find_lowest_price, but the descriptions provide enough separation for an agent to choose correctly.

Naming Consistency4/5

Most tools follow a clear verb_noun pattern such as compare_offers, get_product, search_products, and verify_offer. The main deviation is semantic_search, which is adjective_noun rather than verb_noun, making it the one inconsistent name in an otherwise predictable set.

Tool Count5/5

Eight tools is a well-scoped size for a price-comparison server. Each tool covers a meaningful part of the workflow without redundancy or unnecessary breadth.

Completeness4/5

The toolset covers product discovery, category browsing, detailed product retrieval, multi-offer comparison, side-by-side product comparison, lowest-price recommendation, and price-claim verification. The main gap is the lack of a dedicated price-history tool, even though a 90-day price low is referenced in compare_offers, but this is not a blocking omission for the core comparison workflow.

Resources

Need Help?