Blog · Agents and commerce

MCP servers for brands: a practical look

Published 21 September 2026 · Updated 12 October 2026 · 8 min read

MCP servers for brands: a practical look
Photograph: Tom Jackson / unsplash

The short answer: An MCP server is a small HTTP endpoint that lets an assistant call your systems directly for prices, stock, policies or availability, instead of inferring them from a page it crawled last week. For most brands it is worth building only after the crawl path works, because it reaches people who have already connected you. Where it pays is accuracy: the answer is sourced from your fields, dated by you, and logged by you.

The protocol moved a lot in 2026. An architecture scoped against the 2025 revisions will be wrong in places that matter operationally, so it is worth reading the current changelog before you scope the work.

What changed, in one paragraph

The Model Context Protocol revision dated 2026-07-28 removed protocol-level sessions and the initialize handshake entirely. Every request now carries its own protocol version and client capabilities in _meta, and servers must implement a server/discover call that advertises supported versions, capabilities and identity. Streamable HTTP lost its GET stream. Roots, Sampling and Logging were all marked deprecated under a new feature lifecycle policy, which holds a deprecated feature in the specification for at least twelve months, or at least ninety days under its expedited removal exception, before it becomes eligible for removal. If your vendor is quoting an architecture built on session identifiers, they are describing last year.

For a brand, the headline consequence is pleasant. A stateless server is cheap to run behind a normal load balancer, and the thing an assistant reads first is now one plain POST you can test with curl.

Your tool descriptions are the copy that gets you called

A host application lists your tools to the model as small records: name, title, description, input schema, output schema. The model picks from that list the way a reader picks from a search result. Nothing else about your brand is in the room at that moment.

We think this is the part teams underfund, and we cannot prove it. We have not found an engine that publishes how a model chooses between two tools, and we have not run a controlled test of our own. The argument is structural rather than measured. The description of check_availability is what a model has to go on when it decides whether to call you, and it is not written to charm anyone. Treat those strings as published content, with an owner and a review cycle. The companion piece on your API and MCP server as a visibility surface goes further into how that record is assembled.

One detail from the current spec is easy to miss and expensive to get wrong. Results from tools/list now carry required ttlMs and cacheScope fields, a freshness hint that tells clients how long they may cache your tool list and whether shared intermediaries may cache it too. Set ttlMs generously and your corrected description, your renamed tool, your new currency field will sit invisible in client caches long after you shipped it. Set cacheScope to public on a listing that varies by authenticated customer and you have asked an intermediary to serve one tenant's view to another.

The same revision says servers should return tools from tools/list in a deterministic order, and gives the reason in the changelog: client side caching, and better hit rates on the model's prompt cache. The consequence of ignoring it follows from that rationale rather than from anything we have benchmarked. A server that returns tools in whatever order the database felt like gives the prompt cache a different prefix each time, and nobody sees an error when it happens.

The failure mode to check first: headers

Since 2026-07-28, every POST to the MCP endpoint must carry Mcp-Method, and calls that name a thing must carry Mcp-Name holding the tool name or resource URI. These mirror fields out of the JSON body into HTTP headers so that load balancers and gateways can route without parsing the body.

Servers must then validate that the headers match the body, and must reject a mismatch with HTTP 400 and JSON-RPC error -32020. Read that twice if you run a CDN or an API gateway with a header allowlist. Any intermediary that strips Mcp-Name, rewrites it, or normalises its casing in a lossy way will turn every tool call into a 400 from your own infrastructure. A tool name with a non-ASCII character has to travel base64 encoded in a sentinel format, which is another thing a well meaning header sanitiser can mangle.

The upside of the same change is the best measurement gift this protocol has produced. Your access log now tells you which tool was called, by name, per request, with no body parsing and no sampling. You can count real usage of get_price against get_return_policy from nginx alone. That is a more direct signal than the crawl side gives you, where a request rarely tells you what was wanted, and it belongs in the same analysis as agent traffic is not bot traffic, since both describe machines acting for a named human rather than indexing in bulk.

Checks you can run this afternoon

Four of them, in the order we run them. We have not measured which one fails most often, so read the order as ours rather than as a ranking.

Discovery. POST a server/discover call at your endpoint and read what comes back. The current revision requires servers to implement it and to advertise supported protocol versions, capabilities and identity. Clients may call it before any other request, or use it as a backward compatibility probe on stdio. If yours does not answer, you are out of spec, and a client that does probe has nothing to select a version from.

Header round trip. Send a tools/call through your production edge, not from your laptop. Confirm Mcp-Method and Mcp-Name arrive at the origin unchanged. This is where WAF rules and header allowlists show up.

Cache hints. Fetch tools/list and look at ttlMs and cacheScope on the result. Ask yourself how long you are willing to wait for a wording fix to reach users, and whether anything in that list varies per customer.

Origin. The spec requires servers to validate the Origin header and return 403 on an invalid one, to stop DNS rebinding. Confirm yours does, and that a local development server binds to 127.0.0.1 rather than every interface.

If you would rather see what this looks like written up as a finding with evidence attached, the sample audit report shows the shape.

Where it fits against the rest of the work

An MCP server does not make you discoverable. It makes you accurate to people who already chose you, or whose host application ships your connector by default. The gap matters when budget is at stake. We cannot give you the split. Of the engines we have checked, none publishes how often an answer about a brand comes from a tool call rather than from retrieval, and a brand can only see its own side of it. Our working assumption, from audit work on retrieval of ordinary pages, is that the crawl path still carries most of it. That path is the subject of what is answer engine optimisation.

Build the server when one of three things is true. Your facts change faster than a crawl cycle, so prices or stock go stale on the page. Your answers are customer specific, so no public page could carry them. Or an assistant is already getting something about you wrong and you want a source of truth it can call.

For retail the calculation runs alongside the catalogue question, because an agent that can call you for stock still needs a feed it can browse before it knows to ask. The split is laid out in agentic commerce: what an agent needs from your catalogue.

Honest limits

We cannot tell you what share of assistant conversations currently reach a brand through a tool call rather than retrieval. We have not found an engine that publishes it, and server side logs only see the brands that already built a server. Our own view is skewed toward teams who came to us after shipping something, so nothing here is a sample of the market.

The claims about the protocol in this post are read off the specification, not off a fleet of production servers. We have not benchmarked prompt cache behaviour, and we have no count of which of the four checks fails most often, so the ordering above is a habit rather than a finding. Where we say a thing breaks, we mean the specification requires a rejection that your edge can trigger, not that we have watched it break at scale.

Durability is the other unknown. The protocol has had five revisions since November 2024, and the most recent one removed the handshake every earlier implementation was built on. Anything you build now carries maintenance. Budget for a rewrite rather than a launch.

FAQ

Do we need an MCP server to show up in ChatGPT or Claude answers? No. A server adds a second, higher fidelity path for users who connect you or whose host ships your connector. It reaches nobody who has not. We have not found a published split between the two paths, so treat the crawl path as the one you cannot skip.

Is this just our REST API with extra steps? It is your API with a discovery format, a description layer written for a model rather than a developer, and a transport the host already speaks. If your API is solid, the work is mostly the descriptions and the edge configuration.

What should we check first in production? Header handling at the CDN or gateway, then cache hints set without thinking. We offer that order as the one we use, not as a measured failure rate. Both fail quietly: one as a 400 your dashboards may class as client error, the other as a fix that never reaches anyone.

How do we measure whether it is used? Count Mcp-Name values in your access logs by tool and by day. Compare that against your crawl side numbers before you decide where the next engineering week goes.

Sources

All six pages above were opened and checked against the sentences that cite them on 12 October 2026.

Related reading

Agentic commerce: what an agent needs from your catalogueAgent traffic is not bot trafficYour API and MCP server as a visibility surfaceWhat is answer engine optimisationProduct feeds for AI shopping surfacesAgent payments, and the trust signals in the way