WebMCP: What Google Calls “Optional” Rarely Stays Optional for Long.

Every time Google introduces an "optional" standard, I think of Mark Twain:

"History doesn't repeat itself, but it often rhymes."

In May 2026, at Google I/O, Google introduced WebMCP as a key component of the agentic web: an open, voluntary standard that "improves your users' experience." If you have worked in digital marketing for more than ten years, that language will sound familiar. It is also, word for word, the same language Google used for HTTPS in 2014, responsive design in 2012, and Core Web Vitals in 2020.

None of those recommendations remained optional.

In short: Google never forces a change overnight. It publishes a recommendation, provides free measurement tools, allows a grace period, and then turns the recommendation into a condition for being visible in its search engine. WebMCP is currently in phase one of that cycle, and anyone leading marketing in 2026 should read the calendar through the lens of 2014 because, as the saying goes, those who forget the past are bound to repeat its mistakes.

What is WebMCP? The short answer

WebMCP is a proposed web standard, promoted by Google and Microsoft within the W3C, that allows a webpage to expose structured "tools"—JavaScript functions and annotated forms—that AI agents can invoke directly instead of blindly interpreting the DOM through scraping.

The practical difference is that today, an agent trying to make a booking on your website "looks" at the page and guesses where to click, which involves high costs and inconsistent results. With WebMCP, your website tells the agent exactly what it can do and how to do it. Fewer errors, fewer tokens, more agent-driven conversions, lower system load, and greater efficiency and profitability for agents.

As of July 2026: an origin trial has been available since Chrome 149, Gemini in Chrome is the first consumer, and Expedia, Booking.com, Shopify, Credit Karma, and Target are already experimenting with it. All completely "optional," of course.

Google's pattern: four times optional stopped being optional

Quality content → Panda

In January 2011, Google warned on its blog that it would take action against content farms. It was an editorial recommendation: "create useful content." On February 23, 2011, Panda arrived and removed 12% of search results from view. eHow and Suite101 went from empires to footnotes within weeks. The same cycle was repeated in 2022 with the Helpful Content Update: a recommendation from the Quality Rater Guidelines became an algorithmic filter.

HTTPS → "Not secure"

At Google I/O in June 2014, Google launched its "HTTPS Everywhere" campaign: encryption was presented as a best practice. By August 2014, it was already a ranking signal, although a "lightweight" one. In July 2018, Chrome 68 began marking every HTTP site as "Not secure" in the address bar. Optional lasted four years, and in the end, it was not simply an SEO issue: your website looked broken in front of customers. The browser itself began displaying warnings and blocking access to sites that did not meet what had initially been an optional requirement.

Mobile-friendly → mobile-only

Google had recommended responsive design since 2012. In February 2015, it set a date: "Starting April 21, mobile-friendliness will become a ranking signal." Mobilegeddon arrived, marking the first time Google announced the exact day of an update. But the cycle did not end there: in November 2016, it introduced mobile-first indexing as "an experiment"; in 2019, it became the default; and in October 2023, Google completed the transition to mobile-only indexing: if your website does not work on mobile, it does not exist for Google. Eleven years from "recommendation" to absolute requirement.

Are you starting to see the pattern?

Speed → Core Web Vitals

Speed became a desktop ranking signal in 2010, affecting fewer than 1% of queries: a largely symbolic gesture. For years, Google provided PageSpeed Insights and Lighthouse for free "to help you." In 2018, the Speed Update brought speed signals to mobile. Then, in May 2020, Google introduced Core Web Vitals with an unprecedented promise: six months' notice before activation. In June 2021, the Page Experience Update made them a ranking signal. Metric published, free tool released, grace period granted, ranking factor activated, mass hysteria triggered. The full playbook, executed patiently.

I could also mention AMP—optional in 2015, a de facto toll for appearing in Top Stories in 2016, and largely irrelevant by 2021—or schema.org structured data. The pattern remains the same: nobody forces you; you simply disappear.

Where we are now with WebMCP

If we overlay the historical timeline onto WebMCP, the picture is clear:

1. Recommendation phase—we are here: an open standard, a narrative focused on "user experience," and high-profile early adopters acting as showcases. This is HTTPS in June 2014.
2. Measurement phase: an agent-readiness validation tool will arrive, equivalent to the mobile-friendly test or Lighthouse, where the possibility of testing is already being discussed. When Google gives you a free measurement tool, it is not generosity: it intends to score you with it.
3. Visible advantage phase: websites using WebMCP will convert better in Gemini in Chrome and agentic search experiences. Case studies from Expedia or Shopify will do the commercial work Google does not need to do itself. Everyone will want to tell a story such as: "We improved conversion for this transaction, in this way, and through this channel."
4. Toll phase: websites without exposed tools will become to agents what websites without a mobile version were in 2015: invisible. No announced penalty will be necessary.

Do I have proof this will happen? No. I have four precedents over fifteen years and none pointing in the opposite direction. In my field, we call that a pattern worth planning around.

What WebMCP looks like in practice: two examples

The theory behind the pattern is useful, but a CMO makes better decisions when they can see the real cost. WebMCP provides two APIs, and the choice is not technical but commercial: the imperative API—JavaScript—for transactional actions such as searching or adding products to a cart, and the declarative API—HTML attributes—for forms, where the implementation cost is almost zero.

Example 1: a Shopify ecommerce store

An agent trying to purchase something from your store today "looks" at the page and guesses: it locates the search box, interprets the product grid, and finds the purchase button. Every step is an opportunity for error. With the imperative API, your store declares its two highest-value actions as tools, using the AJAX endpoints Shopify already exposes (/search/suggest.json and /cart/add.js):

// In theme.liquid or as a snippet: the store declares its tools.

// Tool 1: search for a product (read-only).
await document.modelContext.registerTool({
  name: 'buscar_producto',
  description: 'Searches the catalog for products using free text. Returns name, price, availability, and variants (size, color).',
  inputSchema: {
    type: 'object',
    properties: {
      consulta: { type: 'string', description: 'Search query, e.g. "women\'s running shoes"' }
    },
    required: ['consulta']
  },
  execute: async ({ consulta }) => {
    const res = await fetch(`/search/suggest.json?q=${encodeURIComponent(consulta)}&resources[type]=product`);
    const data = await res.json();
    return JSON.stringify(data.resources.results.products.map(p => ({
      titulo: p.title, precio: p.price, url: p.url, disponible: p.available
    })));
  },
  annotations: { readOnlyHint: true } // Tells the agent that this action does not modify anything.
});

// Tool 2: add to cart (sensitive action).
await document.modelContext.registerTool({
  name: 'anadir_al_carrito',
  description: 'Adds a product variant to the cart. It does not complete the purchase: checkout must always be confirmed by the user.',
  inputSchema: {
    type: 'object',
    properties: {
      variantId: { type: 'number', description: 'Variant ID (product + size/color)' },
      cantidad: { type: 'number', description: 'Number of units, 1 by default' }
    },
    required: ['variantId']
  },
  execute: async ({ variantId, cantidad = 1 }) => {
    const res = await fetch('/cart/add.js', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ items: [{ id: variantId, quantity: cantidad }] })
    });
    const cart = await res.json();
    return `Added to cart. Current total: ${cart.items?.length ?? 1} items.`;
  },
  annotations: { readOnlyHint: false }
});

There are three business decisions hidden in these 40 lines that should not be made by the implementer alone:

• What you expose and what you do not. Here, the agent can search and add items to the cart, but checkout remains in the user's hands. Where you draw that boundary is a decision about risk and margin, not code.
• What you return. The agent decides based on the information you provide. If buscar_producto does not return availability, the agent will recommend products that are out of stock. Output design is the new merchandising.
• The description is your new copy. description is what the agent "reads" to decide whether to use your tool or your competitor's. Writing it well is a marketing task, not a systems task.

Example 2: a lead-generation form using the declarative API

For leads, support requests, or quotations, JavaScript is not required: the declarative API turns your existing form into a tool by adding three HTML attributes. The marginal cost is so low that "we'll do it later" no longer has a technical excuse:

<form toolname="solicitar_presupuesto"
      tooldescription="Requests a project quote. Collects contact details, project type, and estimated budget. A consultant responds within 24 business hours."
      action="/contacto/enviar">

  <label for="nombre">Full name</label>
  <input type="text" name="nombre" id="nombre" required>

  <label for="email">Corporate email</label>
  <input type="email" name="email" id="email" required>

  <select name="tipo_proyecto" required
          toolparamdescription="Determines which team the request is routed to.">
    <option value="analitica">Digital analytics and measurement</option>
    <option value="cro">CRO and experimentation</option>
    <option value="data">Data and AI</option>
  </select>

  <label for="detalle">Tell us about your project</label>
  <textarea name="detalle" id="detalle"></textarea>

  <button type="submit">Submit request</button>
</form>

The browser translates this into a JSON Schema that the agent can interpret without ambiguity. The agent fills in the fields in front of the user—the form remains visible, with the :tool-form-active focus indicator—and the final submission is completed by the person unless toolautosubmit is added.

And one detail that I find particularly relevant for analytics teams: the submission event is automatically marked with agentInvoked.

document.querySelector('form').addEventListener('submit', (e) => {
  if (e.agentInvoked) {
    // Lead generated by an agent: tag it in your dataLayer / CRM.
    dataLayer.push({ event: 'generate_lead', lead_source_type: 'ai_agent' });
  }
});

In other words, the standard already includes the component required to segment human traffic from agentic traffic in your analytics. If the question in 2015 was, "What percentage of your traffic is mobile?", the question in 2027 will be: "What percentage of your leads are generated by an agent?" Those who start measuring it now will have the baseline everyone else will later need to improvise.

To see it working before changing your own website, Google provides complete demos on GitHub. The coffee-shop demo is the closest example to a real ecommerce experience—catalog, cart, and ordering through exposed tools—and the same repository contains examples of both APIs.

Note: WebMCP is currently in an origin trial in Chrome 149+, and the syntax may change. navigator.modelContext was deprecated in Chrome 150 in favor of document.modelContext. These examples use the syntax current as of July 2026.

What I would do if I were leading digital marketing in 2026

1. Identify your critical transactions. Booking, registration, quotation, purchase: these are the "tools" an agent will want to invoke. If you do not know your five highest-value actions, that is the first task—not writing code.
2. Put WebMCP on the 2027 technical roadmap, not on the "we'll see" list. The Chrome 149 origin trial allows experimentation today at low cost. Those who tested responsive design in 2013 experienced Mobilegeddon as a routine change; those who waited experienced it as a crisis.
3. Start measuring agentic traffic now. Before optimizing for agents, you need to know how many are visiting, what they are trying to do, and where they fail. Without that baseline, every decision made in 2027 will be a blind one.
4. Do not outsource the judgment. As with CDPs or AI in CRO, technology is the least important part. The value lies in deciding what you expose, to which agents, and under which business rules. That cannot be delegated to whoever happens to implement it.
5. Be suspicious of the phrase "it's optional." That is how every Google requirement begins.

The agentic web will not ask whether you are ready, just as Mobilegeddon did not ask in 2015. The good news is that this time, the pattern is already documented and the timeline has been published. Optional is only phase one.