WebMCP: lo que Google llama “opcional” nunca lo es durante mucho tiempo.

Cada vez que Google presenta un estándar "opcional", me acuerdo de Mark Twain:

"La historia no se repite, pero rima."

En mayo de 2026, en el I/O, Google presentó WebMCP como protagonista de la web agéntica: un estándar abierto, voluntario, que "mejora la experiencia de tus usuarios". Si llevas más de diez años en marketing digital, ese lenguaje te suena. También es, palabra por palabra, el mismo que usó con HTTPS en 2014, con el diseño responsive en 2012 y con Core Web Vitals en 2020.

Ninguna de esas recomendaciones siguió siendo opcional.

Resumiendo: Google nunca obliga de golpe. Publica una recomendación, regala herramientas de medición, da un periodo de gracia y después convierte la recomendación en la condición para existir en su buscador. WebMCP está hoy en la fase 1 de ese ciclo, y quien dirija marketing en 2026 debería leer el calendario con las gafas de 2014 por eso de que, quien no tiene memoria, repetirá los errores del pasado.

Qué es WebMCP (la respuesta corta)

WebMCP es una propuesta de estándar web, impulsada por Google y Microsoft en el W3C, para que una página exponga "herramientas" estructuradas (funciones JavaScript y formularios anotados) que los agentes de IA puedan invocar directamente en lugar de interpretar el DOM a ciegas haciendo scraping.

La diferencia práctica es que si hoy un agente que quiere reservar en tu web "mira" la página y adivina dónde hacer clic, con coste alto y resultados inconsistentes. Con WebMCP, tu web le dice exactamente qué puede hacer y cómo. Menos error, menos tokens, más conversión agéntica, menos carga de sistemas, más eficacia y rentabilidad para sus agentes.

El estado a julio de 2026: origin trial desde Chrome 149, Gemini in Chrome como primer consumidor y Expedia, Booking.com, Shopify, Credit Karma y Target ya experimentando. Todo "opcional", claro.

El patrón de Google: 4 veces que lo opcional dejó de serlo

Contenido de calidad → Panda

En enero de 2011, Google avisó en su blog de que actuaría contra las content farms. Era una recomendación editorial: "haz contenido útil". El 23 de febrero de 2011 llegó Panda y borró del mapa al 12% de los resultados de búsqueda. eHow y Suite101 pasaron de imperios a notas al pie en semanas. El mismo ciclo se repitió en 2022 con el Helpful Content Update: la recomendación de las Quality Rater Guidelines se convirtió en filtro algorítmico.

HTTPS → "sitio no seguro"

En el I/O de junio de 2014, Google lanzó la campaña "HTTPS Everywhere": cifrar era una buena práctica. En agosto de 2014 ya era señal de ranking, aunque "ligera". En julio de 2018, Chrome 68 empezó a marcar todo sitio HTTP como "No seguro" en la barra de direcciones. Lo opcional duró cuatro años y al final no era un tema de SEO: era que tu web parecía rota delante del cliente, el propio navegador empezó a mostrar señales y bloquear el acceso a sites que no cumplieran con ese criterio, inicialmente opcional.

Mobile-friendly → mobile-only

Google recomendaba responsive desde 2012. En febrero de 2015 puso fecha: "el 21 de abril, la compatibilidad móvil será señal de ranking". Llegó Mobilegeddon y, con él, la primera vez que Google avisaba con un día exacto. Pero el ciclo no terminó ahí: en noviembre de 2016 anunció el mobile-first indexing como "un experimento", en 2019 lo hizo default y en octubre de 2023 completó la indexación mobile-only: si tu web no funciona en móvil, para Google no existe. Once años de "recomendación" a requisito absoluto.

¿Empezáis a ver el patrón?

Velocidad → Core Web Vitals

La velocidad fue señal de ranking en desktop desde 2010, afectando a menos del 1% de las consultas: puro gesto simbólico. Durante años, Google regaló PageSpeed Insights y Lighthouse "para ayudarte". En 2018, el Speed Update la llevó a móvil. Y, en mayo de 2020, presentó las métricas Core Web Vitals con una promesa inédita: seis meses de aviso antes de activarlas. En junio de 2021, el Page Experience Update las convirtió en señal de ranking. Métrica publicada, herramienta gratuita, periodo de gracia, factor de ranking, histeria masiva. El manual completo, ejecutado sin prisa.

Podría añadir AMP (opcional en 2015, peaje de facto para salir en Top Stories en 2016, irrelevante en 2021) o los datos estructurados de schema.org. El patrón no cambia: nadie te obliga, simplemente desapareces.

Dónde estamos ahora con WebMCP

Si superponemos el calendario histórico sobre WebMCP, la lectura es clara:

1. Fase de recomendación (estamos aquí): estándar abierto, discurso de "experiencia de usuario", early adopters de referencia haciendo de escaparate. Es el HTTPS de junio de 2014.
2. Fase de medición: llegará una herramienta de validación de agent-readiness, el equivalente al test de mobile-friendly o a Lighthouse donde ya está informada la posibilidad de revisar. Cuando Google te regala un medidor, no es generosidad: es que va a puntuar con él.
3. Fase de ventaja visible: los sitios con WebMCP convertirán mejor en Gemini in Chrome y en las experiencias agénticas de búsqueda. Los case studies de Expedia o Shopify harán el trabajo comercial que Google no necesita hacer. Todos querremos contar una historia de "hemos mejorado la conversión de este transaccional de esta forma y en este canal".
4. Fase de peaje: las webs sin herramientas expuestas serán para los agentes lo que una web sin versión móvil fue en 2015: invisibles. No habrá penalización anunciada, no hará falta.

¿Tengo pruebas de que esto pasará? No. Tengo 4 precedentes en quince años y ninguno en contra. En mi trabajo, a eso lo llamamos un patrón con el que planificar.

Cómo se ve WebMCP en la práctica: dos ejemplos

La teoría del patrón está bien, pero un/a CMO decide mejor viendo el coste real. WebMCP tiene dos APIs y la elección no es técnica, es de negocio: la imperativa (JavaScript) para acciones transaccionales como buscar o añadir al carrito y la declarativa (atributos HTML) para formularios, donde el coste de implementación es casi cero.

Ejemplo 1: un ecommerce en Shopify

Un agente que hoy quiere comprar en tu tienda "mira" la página y adivina: localiza el buscador, interpreta el grid de productos, encuentra el botón de compra. Cada paso es una oportunidad de error. Con la API imperativa, tu tienda declara sus dos acciones de valor como herramientas, apoyándose en los endpoints AJAX que Shopify ya expone (/search/suggest.json y /cart/add.js):

// En el theme.liquid o como snippet: la tienda declara sus herramientas.

// Herramienta 1: buscar producto (solo lectura).
await document.modelContext.registerTool({
  name: 'buscar_producto',
  description: 'Busca productos en el catálogo por texto libre. Devuelve nombre, precio, disponibilidad y variantes (talla, color).',
  inputSchema: {
    type: 'object',
    properties: {
      consulta: { type: 'string', description: 'Texto de búsqueda, ej. "zapatillas running mujer"' }
    },
    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 } // Señala al agente que esta acción no modifica nada.
});

// Herramienta 2: añadir al carrito (acción sensible).
await document.modelContext.registerTool({
  name: 'anadir_al_carrito',
  description: 'Añade una variante de producto al carrito. No completa la compra: el checkout siempre lo confirma el usuario.',
  inputSchema: {
    type: 'object',
    properties: {
      variantId: { type: 'number', description: 'ID de la variante (producto + talla/color)' },
      cantidad: { type: 'number', description: 'Unidades, por defecto 1' }
    },
    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 `Añadido al carrito. Total actual: ${cart.items?.length ?? 1} artículos.`;
  },
  annotations: { readOnlyHint: false }
});

Hay 3 decisiones de negocio escondidas en estas 40 líneas que no debería tomar solo el implementador:

• Qué expones y qué no. Aquí el agente puede buscar y añadir al carrito, pero el checkout queda en manos del usuario. Dónde pones esa frontera es una decisión de riesgo y de margen, no de código.
• Qué devuelves. El agente decide con lo que le das: si buscar_producto no devuelve disponibilidad, el agente recomendará productos agotados. El diseño del output es el nuevo merchandising.
• La descripción es tu nuevo copy. description es lo que "lee" el agente para decidir si usa tu herramienta o la de tu competidor. Escribirla bien es trabajo de marketing, no de sistemas.

Ejemplo 2: un formulario de captación (API declarativa)

Para leads, soporte o presupuestos no hace falta JavaScript: la API declarativa convierte el formulario que ya tienes en herramienta añadiendo tres atributos HTML. El coste marginal es tan bajo que el argumento de "ya lo haremos" pierde la excusa técnica:

<form toolname="solicitar_presupuesto"
      tooldescription="Solicita un presupuesto de proyecto. Recoge datos de contacto, tipo de proyecto y presupuesto estimado. Un consultor responde en 24h laborables."
      action="/contacto/enviar">

  <label for="nombre">Nombre y apellidos</label>
  <input type="text" name="nombre" id="nombre" required>

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

  <select name="tipo_proyecto" required
          toolparamdescription="Determina a qué equipo se enruta la solicitud.">
    <option value="analitica">Analítica digital y medición</option>
    <option value="cro">CRO y experimentación</option>
    <option value="data">Data e IA</option>
  </select>

  <label for="detalle">Cuéntanos tu proyecto</label>
  <textarea name="detalle" id="detalle"></textarea>

  <button type="submit">Enviar solicitud</button>
</form>

El navegador traduce esto a un JSON Schema que el agente entiende sin ambigüedad: el agente rellena los campos delante del usuario (el formulario permanece visible, con el indicador de foco :tool-form-active), y el envío final lo hace la persona, salvo que añadas toolautosubmit.

Y un detalle que a mí me parece el más relevante del estándar para los equipos de analítica: el evento de envío llega marcado con agentInvoked.

document.querySelector('form').addEventListener('submit', (e) => {
  if (e.agentInvoked) {
    // Lead generado por un agente: márcalo en tu dataLayer / CRM.
    dataLayer.push({ event: 'generate_lead', lead_source_type: 'ai_agent' });
  }
});

Es decir: el estándar ya trae de serie la pieza para segmentar tráfico humano vs. tráfico agéntico en tu medición. Si en 2015 la pregunta era "¿qué porcentaje de tu tráfico es móvil?", la de 2027 será "¿qué porcentaje de tus leads los genera un agente?". Quien empiece a medirlo ahora tendrá la línea base que los demás tendrán que improvisar.

Si quieres verlo funcionando antes de tocar tu web, Google publica demos completas en GitHub: la demo coffee-shop es el ejemplo más cercano a un ecommerce real (catálogo, carrito y pedido con herramientas expuestas), y en el mismo repositorio hay ejemplos de ambas APIs.

Nota: WebMCP está en origin trial (Chrome 149+) y la sintaxis puede cambiar; navigator.modelContext quedó deprecado en Chrome 150 a favor de document.modelContext. Los ejemplos usan la sintaxis vigente a julio de 2026.

Qué haría yo si dirigiese marketing digital en 2026

1. Inventaría tus transacciones críticas. Reserva, alta, presupuesto, compra: esas son las "herramientas" que un agente querrá invocar. Si no sabes cuáles son tus 5 acciones de más valor, ese es el primer trabajo, no el código.
2. Mete WebMCP en el roadmap técnico de 2027, no en el de "ya veremos". El origin trial de Chrome 149 permite experimentar hoy con coste bajo. Los que probaron responsive en 2013 vivieron Mobilegeddon como un trámite y los que esperaron, como una crisis.
3. Mide tu tráfico agéntico desde ya. Antes de optimizar para agentes necesitas saber cuántos te visitan, qué intentan hacer y dónde fallan. Sin esa línea base, cualquier decisión de 2027 será a ciegas.
4. No externalices el criterio. Igual que con los CDP o con la IA en CRO, la tecnología es lo de menos: el valor está en decidir qué expones, a qué agentes y con qué reglas de negocio. Eso no se delega en el implementador de turno.
5. Desconfía del "es opcional". Es la palabra con la que empiezan todos los requisitos de Google.

La web agéntica no va a preguntarte si estás preparado/a, igual que Mobilegeddon no preguntó en 2015. La buena noticia es que, esta vez, el patrón está escrito y el calendario, publicado. Lo opcional es la fase uno.