Hay una demo que llevamos haciendo unas semanas en reuniones con clientes y que todavía no falla: abrimos Chrome, entramos en dribba.com, desplegamos Gemini y le pedimos "pídele a esta agencia un presupuesto orientativo para una app de reservas". El agente no abre el formulario de contacto. No hace scroll buscando un botón. Llama a una herramienta que nuestra web le expone, recibe la estimación y la presenta. Veinte segundos.

Eso es WebMCP. Y si te dedicas a producto digital, te conviene entender cómo funciona antes de que lo entienda tu competencia.

De MCP a WebMCP: un poco de contexto

En 2024, Anthropic publicó el Model Context Protocol (MCP), un estándar para que los modelos de IA se conecten a herramientas externas: bases de datos, APIs, sistemas de ficheros. MCP resolvió un problema real — cada integración entre un LLM y una herramienta era un desarrollo a medida — y se convirtió en el estándar de facto del ecosistema de agentes. Lo adoptaron OpenAI, Google y prácticamente todo el tooling de IA que importa.

WebMCP es la pregunta lógica siguiente: ¿y si las webs pudieran exponer herramientas igual que lo hace un servidor MCP?

La respuesta la presentaron Google y Microsoft como propuesta W3C (Web Model Context), y en el Google I/O de mayo de 2026 se materializó: Chrome 149 activó WebMCP como origin trial, con Gemini integrado en el navegador como primer agente capaz de descubrir y usar las herramientas que una página registra.

Cómo funciona, sin humo

La API es sorprendentemente pequeña. Tu página registra herramientas en JavaScript con document.modelContext.registerTool():

document.modelContext.registerTool({
  name: "book_table",
  description: "Reserva una mesa. Requiere fecha, hora y número de comensales.",
  inputSchema: {
    type: "object",
    properties: {
      date:   { type: "string", description: "Fecha en formato YYYY-MM-DD" },
      time:   { type: "string", description: "Hora, ej. 21:00" },
      people: { type: "number", description: "Número de comensales" },
    },
    required: ["date", "time", "people"],
  },
  async execute({ date, time, people }) {
    const res = await fetch("/api/bookings", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ date, time, people }),
    });
    const data = await res.json();
    return data.ok
      ? `Mesa reservada para ${people} personas el ${date} a las ${time}.`
      : `No hay disponibilidad: ${data.error}`;
  },
});

Tres cosas a destacar de este código:

1. El contrato es explícito. El inputSchema es JSON Schema estándar: el agente sabe exactamente qué parámetros existen, cuáles son obligatorios y qué formato tienen. Se acabó el "a ver si el agente adivina qué va en cada campo del formulario".

2. execute es tu código. La herramienta llama a la misma API que ya usa tu formulario de reservas. Misma validación, mismo rate limiting, mismos límites. El agente no tiene superpoderes: es un cliente más, con un contrato más claro.

3. La respuesta es texto para el agente, no UI. Devuelves el resultado en lenguaje natural y el agente decide cómo presentárselo a su usuario.

Un detalle de implementación que nos costó un rato descubrir: la API empezó en navigator.modelContext en Chrome 149 y se movió a document.modelContext en Chrome 150. Si implementas hoy, detecta las dos superficies.

Qué cambia respecto al scraping

Los agentes ya operan webs hoy — ChatGPT completa compras, los agentes de Gemini navegan por ti. Lo hacen interpretando la interfaz visualmente o a través del árbol de accesibilidad: simulan clicks, rellenan inputs, leen el DOM. Funciona... a veces. Es lento, frágil (un rediseño rompe todo) y peligroso (el agente puede pulsar donde no debe).

WebMCP invierte la relación. En lugar de que el agente deduzca qué puede hacerse en tu web, tu web declara qué puede hacerse en ella. Las consecuencias prácticas:

  • Fiabilidad: una llamada a función con schema validado vs. una simulación de clicks. No hay comparación.
  • Control: tú decides qué acciones existen, con qué límites y cuáles requieren confirmación humana explícita (enviar un formulario, pagar).
  • Coste: una llamada a herramienta consume una fracción de los tokens que quema un agente interpretando capturas de pantalla o DOMs de 2.000 nodos.
  • Atribución: sabes qué conversiones vienen de agentes, porque entran por una puerta etiquetada.

El estado real, sin inflarlo

Seamos honestos con el momento: WebMCP está en origin trial. Eso significa que para que funcione con visitantes reales, el sitio debe registrarse en el programa de Chrome y servir un token. El único agente consumidor hoy es Gemini in Chrome. La especificación puede cambiar — de hecho ya cambió de navigator a document entre versiones.

¿Por qué implementarlo ya, entonces? Por la misma razón por la que convenía tener web responsive en 2012: porque la ventana en la que ser de los primeros es ahora, el coste es bajo (las herramientas reutilizan tus APIs existentes) y el aprendizaje organizativo — qué acciones exponer, con qué límites, cómo medir tráfico agéntico — lleva meses, no días.

Y porque WebMCP es solo una capa de algo más grande: la web agéntica. Para que un agente llegue a usar tus herramientas, antes tiene que poder leerte (llms.txt, versiones markdown) y navegarte (árbol de accesibilidad limpio). Las tres capas se construyen juntas.

Lo que estamos viendo en Dribba

Implementamos WebMCP en dribba.com en junio de 2026 — cuatro herramientas: consultar servicios, pedir estimación de presupuesto, obtener enlace de reserva y dejar un lead. Todo reutilizando las APIs que ya teníamos detrás de los formularios, con el mismo rate limiting y la misma validación.

El aprendizaje más interesante no fue técnico sino de diseño: decidir qué NO exponer. Las acciones de escritura (enviar un lead) llevan instrucciones explícitas para que el agente pida confirmación al usuario antes de ejecutarlas, y entran etiquetadas para poder auditarlas. Un agente es un cliente más — y como a cualquier cliente nuevo, se le da acceso gradualmente.

Si quieres ver el detalle de implementación completo, lo contamos en el caso técnico de nuestra web. Y si quieres saber cómo quedaría tu web, una auditoría agéntica se hace en una semana.