What Is the Protocol-Ready Web? A Guide to MCP, A2A, WebMCP, ACP, AP2 and UCP

What is the protocol-ready web?

The protocol-ready web is a single digital property that can serve every AI agent arriving at your site, each over its own protocol, with the same accuracy. Responsive design was the idea that one site adapts to every screen; instead of separate desktop, tablet and phone sites, one structure with a fluid layout. It began as a choice in the 2010s and became an obligation. The same shift is happening again on a new axis: what arrives at your site is no longer different screens but different agents. ChatGPT uses ACP for shopping, Google's agents use A2A and UCP, assistants like Claude use MCP, browser agents use WebMCP, payment agents use AP2.

Responsive design had three building blocks: the fluid grid, media queries and scalable images. The protocol-ready web has three as well, and the logic is strikingly similar.

The structured data layer (the fluid grid's counterpart). In responsive design, layout was tied to percentages rather than pixels. On the protocol-ready web, content is tied to machine-readable data rather than page design: product, price, stock, opening hours and services defined in Schema.org / JSON-LD. If that layer is solid, whichever protocol arrives receives the same correct information. If it is weak, even the most advanced protocol carries the wrong price.

Capability definitions (the media query's counterpart). A media query said "if the screen is narrower than 768 pixels, use this layout". A capability definition says "if you are an agent, you may call these tools": the tool definitions on an MCP server, the Agent Card in A2A, the navigator.modelContext registrations in WebMCP, the product feed and checkout endpoints in ACP and UCP.

One source, many surfaces (the scalable image's counterpart). Your product database, stock system or API feeds every protocol the same data. If the price in your feed, on your site, in your MCP tool's response and in ChatGPT is the same, you are protocol-ready. If not, agents flag you as an unreliable source.

The philosophy of responsive design was "a consistent experience on every device". The philosophy of the protocol-ready web is a consistent truth for every agent.

Six protocols: who, what for, which layer?

Responsive design required knowing the breakpoints. Protocol readiness requires knowing the protocols: which solves what, who stands behind it, which one matters for you. Six protocols sit on four layers.

The tool layer: MCP (Model Context Protocol)

The standard Anthropic open-sourced in November 2024 and handed to the Agentic AI Foundation under the Linux Foundation in December 2025. It lets a model talk to external tools, data sources and prompt templates in a standard way (JSON-RPC). What it means for you: set up an MCP server and Claude, and a growing number of assistants, can call your functions such as "check stock", "create appointment" or "calculate quote" directly as tools. It is called the USB-C of the web for agents for a reason; it is the most widely adopted layer.

The agent-to-agent layer: A2A (Agent2Agent)

Announced by Google in April 2025 and handed to the Linux Foundation in June 2025. Where MCP lets an agent talk to a tool, A2A lets two agents talk to each other. Agents introduce themselves through an Agent Card at /.well-known/agent.json: what I can do, how to reach me, which authentication I require. For you: a customer's shopping agent and your sales agent can find each other and exchange tasks.

The browser layer: WebMCP

Developed jointly by Google and Microsoft, accepted by the W3C Web Machine Learning Community Group in September 2025 and shipped experimentally in Chrome 146 in February 2026. It is MCP's in-browser counterpart: the site registers its functions ("add to basket", "filter", "book") as tools for the browser agent through navigator.modelContext. Instead of taking a screenshot and hunting for a button, the agent calls the tool directly. It is the strongest candidate for the cheapest way to add an agent interface to an existing site without running a separate server.

The commerce layer: ACP and UCP

ACP (Agentic Commerce Protocol): the open standard OpenAI and Stripe announced in September 2025 to enable purchases directly inside ChatGPT. It includes a product feed specification, a checkout API and a shared payment token. The first wave of embedded checkout was withdrawn in 2026; today ACP matters primarily as a discovery and product feed standard.

UCP (Universal Commerce Protocol): the open standard Google announced at NRF in January 2026, developed with retailers such as Shopify, Etsy, Wayfair, Target and Walmart. It aims to bring the whole agentic shopping flow, from discovery to payment, under one roof and is designed to work alongside A2A, MCP and AP2. It is the ground on which your products can be found and bought by agents in the Google ecosystem (AI Mode, Gemini).

The payment layer: AP2 (Agent Payments Protocol)

Announced by Google in September 2025 with more than 60 partners (Mastercard, PayPal, American Express, Adyen, Coinbase). Its question: when an agent pays on a user's behalf, how do you prove who authorised what? AP2's answer is the mandate: the user cryptographically signs their intent (intent mandate) and their basket (cart mandate), the agent pays with those documents, and the merchant and bank can audit them. If you plan to accept agent payments, a liability chain defined by protocol protects you too.

The protocol map

Two more layers sit beneath this table, and neither is a protocol; both are prerequisites: Schema.org structured data (so the agent understands you) and llms.txt / AGENTS.md (so the agent takes you as context). Without them, none of the protocols above works properly.

How do you build a protocol-ready development process?

The golden rule of responsive development was mobile-first: build the core for the most constrained device, then expand as the screen grows. The counterpart in protocol-ready development is agent-first: build the core for the most constrained reader, the agent that has no visual perception and reads only data and definitions, then add the visual layer for people. In practice the order is this:

1. Unify the data layer. Product, price, stock, service and location information must come from a single source. The site, the feed, the API and the schema must all read that source; none of them may be a hand-updated copy. Responsive design's "one URL, one content" becomes "one source, one truth".
2. Open access. Allow GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot and Google-Extended in robots.txt and the firewall. Move content out from behind JavaScript and render it on the server. No protocol can talk to a site it cannot reach.
3. Match schema and visible HTML. Organization, Product, Offer, LocalBusiness and FAQPage schemas must carry exactly the information the visible text carries. Most AI crawlers read both; a contradiction is a loss of trust.
4. Write the context files. A short, hand-written, verified llms.txt. Bloated files lower agent success; 40 good lines are worth more than 1,000 generated ones.
5. Choose the first protocol layer. It is not the same for everyone. A product feed (ACP/UCP-compliant) and AP2 readiness for a cross-border retailer; an MCP server for SaaS; a booking tool via WebMCP for a service business; an A2A Agent Card for an enterprise running multi-agent operations.
6. Set up authorisation and guardrails. Treat every tool definition with zero trust: what may the agent read, what may it change, where is human approval required? For transactions involving money, contracts or personal data, the approval step is part of your design, not of the protocol.
7. Measure and rescan. Separate agent traffic in server logs, run agent task simulations, measure your agent-readiness score regularly. In responsive design you tested at every breakpoint; here you test on every protocol.

The protocol-world counterpart of the @media (max-width: 768px) line is a few lines of tool registration in WebMCP: introducing the site's "add to basket" function to the agent with a name, a description and parameters. Small amount of code, large effect. We covered the button-scale detail in our CTA article.

How do protocols affect AI visibility and agentic commerce?

Responsive design became a precondition of visibility with Google's mobile-first indexing. Protocol readiness is becoming a precondition of AI visibility and agentic commerce too, through two different mechanisms.

The visibility side. AI engines choose sources when they generate answers. Sites with clear structured data, open access and a proper context file are easier to understand and cited more often. The Princeton-led GEO research showed that the right content structure can lift AI visibility by 30 to 40 per cent. The protocol layer adds to that: the agent not only cites you, it sees that it can transact with you, and a source it can transact with moves up the recommendation.

The commerce side. Industry projections agree that agentic commerce grows into a trillion-dollar global channel by the end of this decade; in our own client surveys the first question from cross-border brands is now "why am I not showing up in ChatGPT". The infrastructure of that commerce is being built with protocols such as ACP, UCP and AP2. A retailer without a protocol-compliant product feed is simply not on the shelf in this channel; at best the agent describes it as "information", never as "purchasable". We measure that side separately on our Agentic Commerce Readiness page.

But there is an important difference from responsive design, and it should be said plainly: responsive paid off on every site, in every market, immediately. Protocol readiness does not.

• Agentic commerce is today primarily a discovery channel; the first wave of embedded checkout was withdrawn and is being reshaped.
• Market asymmetry is real: ChatGPT Ads does not yet target every market, and the commerce protocols pay off mainly in cross-border markets for now.
• Protocols change quarterly. This article reflects the state of September 2026; six months later the table may look different.
• Part of AI traffic cannot be measured with any setup. Your numbers are a floor.

These limits are not a reason to skip the investment; they are a reason to sequence it correctly. The data, access and schema layers pay off in every market immediately; the protocol layer should be entered gradually according to your target market and product type.

Mistakes to avoid in protocol readiness

Responsive design had its classic mistakes: designing for desktop and retrofitting mobile, over-complicating media queries, not optimising images. Protocol readiness is developing its own classics.

• Starting with the protocol. The most common mistake. Setting up an MCP server on a site with broken schema and blocked bots is like adding an AR experience to a site with no mobile version. The chain rule: access, readability, data, visibility, protocol, transaction, measurement. Investment that skips the order is wasted.
• Feed and site out of sync. The price is 100 in the ACP or UCP feed and 120 on the site. The agent notices; it either flags you as unreliable or tells the user the wrong price. A hand-updated feed drifts sooner or later; it must be fed automatically from one source.
• Entering every protocol at once. A team preparing for all six protocols at the same time sets none of them up properly. Build the shared data layer, then start with one protocol chosen for your target agent.
• Leaving authorisation for later. Defining a tool and postponing "what may the agent do" is like leaving the admin panel without a password. Zero trust must be the first step of the setup.
• Fabricating data. Invented GTINs in the feed, fake AggregateRating in the schema, out-of-stock items shown as available. Misleading for people, an account risk for agents; on commerce protocols it can mean being dropped from the channel permanently.
• Investing without measuring. A team without a baseline cannot prove its success. Record the agent-readiness score, agent log traffic and AI citation rate from the start.
• Carrying dark patterns into the protocol. Fake urgency and coercive flows annoyed people on the web; on the protocol layer they stop the agent and come back to the user as "this site is not trustworthy".

Which protocol for which agent?

In responsive design, strategy changed with the screen. In protocol readiness, strategy changes with which agent brings you customers.

The cross-border retailer. Priority: the commerce layer. An ACP- and UCP-compliant product feed, correct GTINs and stock, AP2 readiness. For a retailer selling only domestically with no export goal, this layer pays off little today; access, schema and measurement are the smarter focus.

SaaS and API businesses. Priority: the tool layer, an MCP server. Letting assistants such as Claude and Cursor and coding agents call your product directly is a new distribution channel.

Service businesses (clinics, restaurants, hotels, consultancies). Priority: the browser layer and local data. A LocalBusiness schema, current opening hours, a booking or appointment tool via WebMCP. This is how you show up when a user tells their glasses "find somewhere open nearby and book a table"; we walked through that scenario in our wearables article.

Enterprises running multi-agent operations. Priority: the agent-to-agent layer. Introduce your own service agent to customer agents with an A2A Agent Card. Prerequisite: CX data aligned with ERP and CRM.

Common to everyone. Access open, schema correct, llms.txt short and honest, measurement in place. These four are the viewport meta tag of the protocol era; without them the rest does not work.

Responsive design promised to remove the differences between devices. Protocol readiness promises something different: not to remove the differences between agents, but to tell every agent the same truth in its own language.

Which standard wins?

The conclusion of the responsive article was clear: a site that is not responsive loses its competitive edge. In the protocol world it would not be honest to say with the same certainty that "the standard of the future is protocol X". MCP has settled on the tool layer; A2A, UCP and AP2 are institutionalising through the Linux Foundation and the major payment networks; WebMCP is experimental in the browser; ACP's checkout leg is being reshaped. There will be no single winning protocol; the layers will work together.

What stands firm in that uncertainty is the ground beneath the protocols: single-source correct data, open access, schema that matches visible HTML, a short and honest context file, zero-trust authorisation, continuous measurement. A business that builds this ground adapts within weeks whichever protocol wins. One that does not starts from zero with every new protocol.

We used to say responsive design had to be the foundation from the first line. The advice for protocol readiness is the same, with one difference: make the truth the protocol will read, not the protocol itself, the foundation from the first line. Find out how ready your site is with a free agent-readiness scan in 60 seconds, and plan which protocol layer to start with on our Agent Experience service page.