SuperMCP

The problem

Israeli law requires every large grocery chain to publish its full price list. The data is public and it is free. It is also unusable: raw XML dumps on ten different portals, each with its own quirks, no shared product identity across chains, and no way to ask it a question. Consumer price-comparison sites read it for humans. Nothing reads it for software.

So every developer who wants an agent to answer "where is this basket cheapest" re-scrapes and re-normalises the same feeds, badly, and most simply skip the use case.

What I built

SuperMCP ingests those feeds into one canonical Postgres catalog and puts two interfaces on top: a REST API and a remote MCP server, so an AI assistant can call it directly. On my machine the catalog currently holds ten chains, 898 branches, 122,575 canonical products, 249,106 chain listings, 6.7 million prices and 1.07 million promotions.

The main call is optimize_basket. You hand it a shopping list in free Hebrew text and a location, and it returns a plan: the best single store, the cheapest complete store, the nearest one, and a multi-store split, with a line breakdown for each.

The bug that shaped the product

The first version ranked stores by what they charged. That is wrong, and the way it is wrong is invisible.

A store only prices the items it stocks. Rank on that total and the store missing the most expensive thing in your basket looks cheapest. A real Herzliya basket recommended a shop at 92.86 shekels over one at 171.42, purely because it did not carry a 71.60 tuna line.

Every plan now also carries a comparableTotal: the same basket priced at every store, using each store's own price where it has one and the median market price where it does not. Imputed lines are counted and reported, and ranking charges a surcharge when a store leaves lines unpriced, because finishing the list somewhere else is a second trip. Lines also carry a normalised price per 100g, 100ml or piece, so a small pack cannot win on shelf price alone.

Conditional prices

The feeds carry about 54,000 active coupon promotions and only around 250 of them are marked as loyalty-card prices. Everything else was being applied silently. One real case priced a 5.90 shekel cottage cheese at 1 shekel under a clipped-coupon promotion, which wins any cheapest-store comparison and then surprises the shopper at the till.

Club-only and coupon-only lines are now flagged on every plan and can be switched off entirely. On a real Herzliya basket, turning them off changes both the winning store and the price.

Built for a model, not a browser

The response is sized for an agent's context window. The default detail level keeps the full line breakdown for one plan, drops per-line diagnostics, and caps that plan at 25 lines while still reporting the true count. Measured: 12 items is about 12KB, 30 items about 26KB, 50 items about 32KB.

Search is lexical and semantic together. Vocabulary and attribute rules live in Postgres rather than in code, so the engine never branches on a specific Hebrew word; product embeddings are computed offline through a dirty queue and query embeddings are cached after the first miss.

Distances are labelled rather than faked. Each store reports whether its distance was measured from a geocoded branch address or stood in from a city centroid. Excluding the imprecise ones removed about 45 per cent of the catalog, including entire discount chains, so they are ranked with an uncertainty margin instead.

Open source

Apache-2.0, self-hostable end to end. The repository contains no path into any hosted environment: production hostnames and secrets live in the hosting environment only. The data documentation is deliberately blunt about the one thing that is not settled, which is whether a normalised API over mandated public data can be commercially redistributed.