MCP, WebMCP and the agentic web: a field guide

You are going to be sold MCP this year. It will appear in vendor decks, in conference sessions, and in emails from people who learned the acronym last week. It is worth twenty minutes to understand what it actually is, because the difference between the protocols determines what your store can and cannot do.

Here is the field guide, in plain language, with no assumption that you write software.

The problem all of this solves

An AI model on its own can only produce text. To do something useful about your business it needs two things: current information, and the ability to take actions.

There have historically been two ways to give it those. Let the model read your website, which is unreliable because websites are built for eyes and because reading gives you a snapshot rather than the truth right now. Or build a custom integration between one specific AI product and one specific system, which works well and costs a great deal, and has to be redone for the next AI product.

Every protocol below is an attempt at a third option: a standard way for a system to say here is my data and here are the things you can ask me to do.

MCP: the connection between an assistant and your systems

The Model Context Protocol is a standard for exposing data and tools to an AI assistant. Think of it as a menu your systems publish. Each item on the menu is a tool with a name, a description, defined inputs and defined outputs.

For a business the menu looks like search catalog, get product details, compare two products, check availability, look up current offers, estimate a trade, calculate a payment, capture a lead. When a shopper asks a question, the assistant picks the relevant tool, calls it, gets structured data back, and answers from that. Our own business server exposes 24 tools today.

Three properties matter to you.

It is live. The assistant is querying your actual feed at the moment of the question, not reciting what a crawler saw last week. Availability answers are correct.

It is structured. The assistant receives typed data rather than prose it has to interpret, which is the single biggest reduction in the chance of an invented answer.

It is reusable. Because MCP is a standard rather than a private integration, any assistant that speaks it can connect. You build the connection once instead of once per AI product.

MCP is the difference between an assistant that has read about your store and one that is connected to it.

ChatGPT apps: a named presence inside one assistant

OpenAI’s Apps SDK is how you get an actual app inside ChatGPT, with your name on it, that a user adds deliberately. It can render richer interface elements than plain chat and it is discoverable within that product.

MCP and a ChatGPT app are complements, not alternatives. The app is a storefront inside one very large assistant. MCP is the wiring that any assistant, including that one, can connect to. Sensibly built, both point at the same underlying data so they can never disagree about what is on your lot.

The strategic point is that an app is opt-in and named. Someone adds your business. That is a materially different relationship than being cited occasionally in a general answer.

WebMCP: agents that operate your website

The newest of the four, currently a Chrome origin trial, and the one most likely to be misexplained to you.

MCP connects an assistant to a server somewhere. WebMCP lets a web page itself declare tools to an agent running in the browser. The shopper is on your site, an agent is working on their behalf in that browser, and your page can offer it real capabilities: search this catalog, price this payment, start this lead.

Why this matters is context. The agent is not guessing what your site can do from the rendered HTML, and it is not clicking around a page it does not understand. It is calling functions you defined, on the page the shopper is actually looking at, with the shopper’s session and preferences intact.

It is early. Origin trial means Chrome is testing it with real sites before committing, and the specification is still moving. It is worth building for now precisely because it is early: this is the surface where being first is cheapest.

schema.org and llms.txt: the readable floor

The least exciting item on the list, and the one most businesses actually need first.

schema.org is a shared vocabulary for describing things on a web page so machines understand them. For a business that means LocalBusiness, Service, Product and Offer types, embedded as JSON-LD, telling a machine what this is, what it includes, what it costs, who provides it, and whether it is actually available.

llms.txt is a newer and simpler convention: a plain text file at a known location on your domain that tells an AI agent what this site is, what it offers, and where the authoritative information lives. The same spirit as robots.txt, aimed at a different reader.

Neither is live and neither lets an agent do anything. They are how the crawl-and-index path works, which still matters enormously, because answer engines and AI search read the open web and because a model with no live connection to you falls back to whatever it can read.

There is a related trap here. Cloudflare now gates AI crawlers by default. Perfect structured data does you no good if a default setting blocks the agents you want. Check that specifically.

How they fit together

The mental model that holds up: schema.org and llms.txt make you readable, MCP and ChatGPT apps make you answerable, WebMCP makes you operable, and the layer underneath all of them should be one authoritative model of your store rather than four independent copies.

That last part is the thing to insist on when a vendor pitches you. If the ChatGPT app has its own catalog copy and the website has another, they will disagree, and they will disagree in public, in front of a buyer. One source of truth, many surfaces, is the only shape that survives the next protocol.

What to ask a vendor

Five questions that separate the real from the rehearsed.

Is the data live at question time, or crawled on a schedule, and what is the freshness window.

Which surfaces are actually deployed today for a real customer, with a URL you can check.

Do all of the surfaces read from one source, and what happens when a unit sells.

Which tools can the agent call, specifically, and can it complete a lead into my CRM.

When the next surface appears, is that an adapter or a rebuild.

That last question is the whole game. Two years ago none of these protocols existed in the form they exist in now. The specific acronyms will keep changing. What should not change is the truth about your store, held in one place, ready to speak whichever protocol shows up next.