What the question actually requires#
A retail and category brief looks like one question but resolves into four, each owned by a different party. Assortment — which SKUs are listed in which stores — is owned by the retailer. Price, both shelf and promotional, is observable in the aisle but licensed in bulk. Category performance — share, velocity, distribution — is a measurement product sold by a handful of firms. Product attributes — pack size, claims, nutrition — are partly public and partly your own master data.
That decomposition matters because MCP coverage is not evenly thin across the four. Assortment has nothing at all in the catalogue. Price has one server, in one country, with two tools. Category performance has nothing beyond your own first-party commerce and behaviour records. Product attributes have a real reference source. An evaluator who treats "retail research" as one capability will conclude the whole use case is unsupported; an evaluator who splits it will find there is a narrow but real build available.
The catalogue behind this page was generated on 19 September 2026 from a corpus of 33,512 records. Forty-eight servers were assessed as candidates and 33 published. The category split is lopsided: 14 in collaboration and productivity, 5 in data platforms and analytics, 5 in commerce and retail, 5 in market and consumer intelligence, and 4 in food safety and compliance. Two of our categories — ERP and supply chain, and CRM and marketing — have no published server at all. Commerce and retail holds about a third as many servers as the collaboration bucket, and four of its five members are two payments services, a web host and a site builder; the fifth is a food-photography service.
Read that split honestly and the shape of the problem is visible before any individual server is opened. The MCP ecosystem has grown fastest where the buyer is a developer. Retail data is bought by a category manager, and on this evidence category managers have not been the audience.
What exists today#
One server in the catalogue returns live retail prices. offerhopper.ai publishes a hosted endpoint at mcp.offerhopper.ai covering German supermarkets and drugstores, and it is open: our unauthenticated probe on 19 September 2026 sent POST initialize with no credentials and received HTTP 200. That is unusual — only 5 of the 33 published servers answered an unauthenticated initialize, and 4 of those returned a tool list.
The tool list is the important part, and it is not what a category team would hope for. The two tools observed were plan_optimal_shopping_route and swap_route_item. That is the surface of a consumer shopping assistant: plan a basket across several stores, substitute an item. We observed no tool for listing prices across a category, no assortment query, no historical series. An agent can ask it what a basket costs this week in a German chain. It cannot ask it how a category's price architecture has moved.
Six of offerhopper.ai's eighteen claims are documented. No repository is declared, so there is nothing to read about how it is maintained. No installable package is declared, so it cannot be run inside your own network. Our probe found no OAuth discovery document at either well-known location and could not retrieve authorisation-server metadata — both resolve to not documented, and since the endpoint answers without credentials there was nothing to present in any case.
For category performance, the only measurement readable through MCP is your own. Stripe's registry description names tools for customers, products and payments; PayPal's names access to PayPal services and operations; Amplitude's names search, access and insight over your Amplitude data. Stripe and Amplitude both require authentication, both had OAuth and dynamic client registration observed at their well-known endpoints, and both document ten of eighteen claims. Amplitude's observed scopes are mcp:read and mcp:write, which is a real separation; it also declares a second endpoint on an EU hostname alongside the default, though the data-residency claim itself remains undocumented. Stripe's scope separation is not documented either way.
For product attributes, fmcg.network is the one directly relevant source. Its publisher describes USDA FoodData Central nutrient lookup, FDA recall watch and EU FMCG labelling. Eight of eighteen claims are documented and no repository is declared. It is a reference layer: once you have a SKU list from somewhere else, it can tell you things about those products. It cannot tell you which of them are on shelf.
The absence is the finding#
Syndicated retail measurement publishes nothing. Nielsen, NielsenIQ, Circana, SPINS and Numerator have no published server in this catalogue, and we track them explicitly as absent rather than as something we assessed and declined.
Retail media publishes nothing. Amazon Ads, Criteo and The Trade Desk are absent by the same standard. So the two halves of a modern category conversation — what the category did, and what your media spend did to it — are both unreadable through MCP today.
Two adjacent absences compound it. No foodservice POS platform is present: Toast, Olo, NCR Aloha, Punchh and Paytronix are all missing, so a total-market view that includes on-premise cannot be assembled. And no supply-chain planning system is present — Blue Yonder, Kinaxis, o9 Solutions, Manhattan Associates, Coupa, Anaplan and E2open are absent — so a finding about assortment cannot be traced through to a forecast or inventory consequence in the same agent session.
The practical consequence is worth stating plainly, because it is the thing most likely to be misunderstood by whoever commissioned the pilot. An agent connected to every relevant server in this catalogue still cannot answer "what happened to our category last quarter". It can answer "what happened to our own DTC sales", "what does this basket cost in a German store this week", and "what are the nutritional attributes of these products". Those are useful questions. They are not the question.
This is not a criticism of the publishers. These firms sell measurement under contract, and entitlement rules of that kind do not map obviously onto an open protocol surface. We cannot say from the catalogue why any given vendor has not published, only that none has. Plan on the assumption that the gap is still there at your next budget cycle, and check the date on this build rather than assuming it has closed.
What adoption costs an IT team#
The single most consequential number on this page for a security reviewer: across all 33 published servers, every one of the four governance claims we track resolves to undocumented. Audit logging, access control, data residency, retention — 132 claim slots, 132 of them not documented in public material. That is a statement about what we could cite, not about what the publishers operate; undocumented never means absent. It does mean you cannot cite it from the server's own documentation, so every shortlisted publisher needs a direct request before a questionnaire can be closed. Budget that as calendar time ahead of the pilot.
Scope separation is the second thing to check, and it splits three ways across the catalogue: 8 servers show a read/write separation, 8 explicitly offer none, and 17 leave it undocumented. Among the servers on this page, Amplitude, Airtable and Supabase fall in the first group — our probe observed thirteen scopes on Supabase, including database:read, analytics:read and organizations:read, and seven on Airtable, including data.records:read and schema.bases:read. Zapier falls in the second: its observed scopes are openid, profile and email, with no read-only variant. Where separation is absent, a token issued to a read-only research agent still carries whatever the connected account can do, and containment has to be built outside the token — a dedicated service account, a sandboxed workspace, a proxy in front of the endpoint.
Deployment shape changes the review materially. Only 6 of the 33 servers declare an installable package, and 4 declare no remote endpoint at all. Microsoft Fabric and Power BI Modeling are in both groups: Fabric ships as npm:@microsoft/fabric-mcp and nuget:Microsoft.Fabric.Mcp, Power BI Modeling as npm:@microsoft/powerbi-modeling-mcp, and neither publishes a hosted endpoint. That is a different risk profile rather than a better one. Warehouse credentials never leave your estate, but you own patching, isolation and the runtime. Power BI Modeling is also the least documented server in the catalogue at five of eighteen claims, and sits at version 0.5.0-beta.13.
Maintenance signals are readable where a repository is declared, and they vary more than you would expect from vendors of similar size. Stripe and Supabase both showed a repository push on the day of our build, as did Microsoft Fabric. Zapier's was 51 days earlier. Two servers we do not recommend for this use case — Vercel and Microsoft Sentinel Data Exploration — last saw a push 248 days before the build, which resolves to unmaintained on our records. Several relevant servers — offerhopper.ai, Amplitude, Airtable, fmcg.network — declare no repository at all, so this signal simply is not available for them.
An open endpoint is cheap to connect and awkward to govern. offerhopper.ai needs no credential, which removes a secrets-management task and removes an access-control surface in the same motion. There is nothing to revoke, no per-user identity in the request, and nothing on the server side that your own audit trail can reconcile against. For a price spot-check that is proportionate. For anything that feeds a decision document, log the query and the response on your side, because nothing in the published record says the server will do it for you.
A build that survives review#
The honest architecture for the next twelve months puts MCP over your own copy of the data, not over the source. Syndicated measurement continues to arrive by contract on whatever cadence you already pay for. It lands in a store you control — Microsoft Fabric if your estate is already on Fabric, Power BI Modeling where the category measures are already defined, Supabase where you want a hosted database whose read-only scopes are documented, Airtable where the category team's tracker already sits and nobody wants to move it. The agent reads that copy. None of those four servers contain a single retail fact until you put it there, and saying so early prevents a lot of disappointment later.
Layer first-party measurement on top through Stripe, PayPal and Amplitude, and label it precisely in every output. "Our DTC velocity" and "category velocity" are different claims, and an agent writing fluent prose will blur them unless the system prompt forbids it. This is a real failure mode, not a hypothetical one: the model has no way to know that the numbers it can reach describe a sliver of the market.
Use offerhopper.ai for what it is — a German price check with two route-planning tools and no credential. It will answer a specific question about a specific basket in a specific market. Do not build a price-tracking capability on it, and do not present its output as competitive pricing intelligence outside Germany.
Where a retail system you already license exposes an API but no MCP server, Zapier is the bridging path its publisher advertises, at 9,000+ apps and 40,000+ actions. The trade is containment rather than capability: with no read-only scope offered, restrict at the connected account and treat the bridge as write-capable in your threat model even when the agent only reads.
Finally, put a date on the gap and revisit it rather than re-litigating it. Our claims carry a verification timestamp — this build is 19 September 2026 — and the absences above are checkable against that date. If a syndicated measurement vendor publishes a server, the shape of this recommendation changes completely. Until one does, the constraint is not which server to choose. It is that for the central question, there is nothing to choose between.