WebMCP: el estándar web para que agentes usen tu sitio sin scrapear

Imaginá un agente de IA queriendo reservar una mesa en la web de un restaurante. Hoy funciona como un pasante muy paciente y un poco confundido: carga la página, lee el HTML crudo, intenta adivinar cuál de los cuarenta <div> es el date picker, supone que el botón verde probablemente dice "confirmar", hace clic, espera y vuelve a leer toda la pantalla a ver si algo cambió. Movés ese botón la semana que viene y el agente se rompe. Renombrás una clase de CSS y se rompe. Le metés un cookie banner arriba y termina cliqueando cualquier otra cosa.

Eso es, literalmente, lo que hace la mayoría de los "agentes usando sitios web" hoy: scraping de pantalla y esperanza. Es la versión automatizada de operar una computadora describiendo capturas por teléfono.

WebMCP propone algo mucho más sano. En lugar de que el agente adivine qué puede hacer tu sitio mirándolo, tu sitio declara qué puede hacer, como un set de herramientas limpias y estructuradas que el agente puede llamar directamente. "Acá está la herramienta book_table. Toma una fecha, una hora y un tamaño de grupo. Llamala." Nada de leer píxeles. Nada de adivinar. Y lo mejor: ya corre en Chrome detrás de un trial, y agregar tu primera herramienta lleva unos diez minutos.

El cambio de fondo: de scrapear a declarar

Toda la idea cabe en una comparación. Misma tarea, dos mundos.

Hoy: el agente scrapea

1. Lee el DOM entero
2. Adivina qué elemento es el campo de fecha
3. Simula tecleo y clics
4. Vuelve a leer la página para verificar
5. Se rompe cuando cambia el layout

WebMCP: el sitio declara

1. La página registra una herramienta book_table
2. El agente lee el schema de la herramienta
3. El agente la llama con argumentos estructurados
4. La herramienta corre tu JS real y devuelve un resultado
5. Sobrevive a rediseños: la herramienta es el contrato

La columna de la izquierda es frágil porque el agente está haciendo ingeniería inversa de tu UI en cada corrida. La columna de la derecha es estable porque le diste una interfaz real. El layout puede cambiar libremente debajo de una herramienta cuyo nombre y schema se mantienen igual.

Si leíste el post sobre MCP, el puente entre la IA y tus datos, esto te va a sonar familiar, y tiene que sonar así. MCP le dio a la IA una forma estándar de llamar herramientas en un servidor. WebMCP trae esa misma idea al navegador: la propia página web se vuelve un lugar que ofrece herramientas, corriendo en la pestaña que ya tenés abierta, con la sesión en la que ya estás logueado. La versión 2.0 del protocolo, que simplifica el handshake y elimina sesiones, ya está plantando esta misma lógica de "menos estado, más contrato" en el lado servidor; WebMCP es la cara cliente de esa misma idea.

Qué es concretamente

WebMCP es un estándar web propuesto, desarrollado en conjunto por Google (Chrome) y Microsoft (Edge) dentro del W3C Web Machine Learning Community Group. Le da a una página web un pequeño API de JavaScript para registrar herramientas que un agente de IA puede descubrir y llamar. Google lo describe sin rodeos en la documentación de Chrome: una forma de "construir y exponer herramientas estructuradas para agentes de IA", donde el sitio anota sus propias features para que los agentes "sepan exactamente cómo interactuar" con ellas. Para ser precisos sobre su madurez, es un draft del Community Group, no un estándar W3C terminado ni siquiera en el track formal, y eso es exactamente por qué ahora es el momento de aprenderlo y darle forma.

Tres cosas lo hacen encajar en su lugar:

• Discovery. Una forma estándar de que la página diga "ofrezco estas herramientas", como checkout o filter_results, para que un agente las liste.
• Schemas. Cada herramienta declara sus entradas y salidas como JSON Schema, así que el agente sabe exactamente qué pasar y hay mucho menos lugar para que alucine o mallea.
• State. Una comprensión compartida de qué hay en la página en este momento, para que el agente sepa sobre qué puede actuar realmente.

Dónde está parado hoy

WebMCP es real y se puede correr, pero es temprano. Está disponible como Chrome origin trial desde Chrome 149, y lo podés prender localmente con la flag chrome://flags/#enable-webmcp-testing. La propuesta vive en github.com/webmachinelearning/webmcp, Angular ya tiene soporte experimental, y Chrome tiene sitios de demo (un pizzería, búsqueda de viajes, reserva de restaurantes). Las propias palabras de Google: "está bajo discusión activa y sujeto a cambios". Así que este es un momento de "probá y dale forma", no de "llevalo a producción", y por eso vale aprenderlo ahora.

Cómo fluye una llamada de verdad

Acá va el loop entero, página al agente y de vuelta. No pasa nada exótico: la página registra herramientas, el agente las lista, elige una, la llama con argumentos estructurados, y tu propio JavaScript hace el trabajo dentro de la página.

1. La página registra herramientas. Tu JS declara book_table, search, etc.
2. El agente descubre. Lista las herramientas de la página con sus schemas.
3. El agente llama con args. JSON estructurado que matchea el schema.
4. La página corre execute(). Tu JS real, en la página logueada.
5. El agente recibe el resultado. Una respuesta estructurada, visible, en la pestaña.

La función execute de la herramienta corre dentro de tu página real, usando tu JavaScript existente, el estado, y la sesión propia del usuario. Pasa de forma visible en la pestaña, no en un navegador headless invisible, así que el usuario puede mirar y confiar.

Ese detalle de "corre en la página en la que ya estás logueado" es grande. El agente no es un bot separado logueándose con credenciales robadas en algún lado. Está llamando a una función en tu pestaña abierta y autenticada, usando la sesión que ya tenés. El sitio mantiene control sobre qué expone, y el usuario puede ver cómo pasa.

Mirá una llamada pasando

Concretamente, cuando le pedís a un agente embebido en el navegador que haga algo en un sitio con WebMCP, se ve así: tu pedido, el agente eligiendo la herramienta declarada, la herramienta corriendo, el resultado.

Vos: "reservame una mesa para 4 hoy a las 20" Agente: "encontré la herramienta book_table en esta página" Agente: "llamando a book_table con { date: \"hoy\", time: \"20:00\", party: 4 }" Página: "Reservado. Mesa para 4 a las 20:00, confirmación #A17."

No hay adivinación de DOM en ningún lado. El agente llamó a una función con nombre, con argumentos tipados, y la página hizo el resto con su propio código. Esa es la diferencia entre un agente operando tu sitio y un agente operando una foto de tu sitio.

El código es genuinamente chico

Esta es la parte que hace que la gente quiera probarlo. Registrar una herramienta es una llamada. Usando la API imperativa actual de los docs de Chrome, un sitio de to-do agregando una herramienta "agregar item" se ve esencialmente así:

await document.modelContext.registerTool({
  name: 'add_todo',
  description: 'Add an item to the to-do list',
  inputSchema: {
    type: 'object',
    properties: {
      text: { type: 'string', description: 'The item text' }
    },
    required: ['text']
  },
  execute: async ({ text }) => {
    const li = document.createElement('li');
    li.textContent = text;
    document.querySelector('#todos').appendChild(li);
    return { ok: true, count: document.querySelectorAll('li').length };
  }
});

Una sola llamada a registerTool, un schema declarativo, y la lógica de la herramienta es el mismo JavaScript que ya tenés. No hay SDK pesado, no hay backend nuevo, no hay infra que mantener. El navegador hostea todo.

Por qué importa aunque no trabajes en agentic

Hay un ángulo que el primer comentarista del hilo de Hacker News clavó mejor que nadie: WebMCP es tecnología de accesibilidad espectacular disfrazada de cosa de IA. Si podés engañar a un montón de empresas para que hagan sus sistemas de booking accesibles por API con la excusa de "habilitar agentes", terminás mejorando la vida de personas que usan screenreaders, asistentes de voz, o cualquier interfaz no-visual. Es la misma idea, vista desde otro lado: en lugar de obligar al usuario a pelear con tu UI, exponés la operación como un contrato.

Y hay un segundo ángulo más filoso: el navegador se vuelve un entorno de ejecución sandboxed para código de agentes. En vez de que los skills te pidan descargar binarios arbitrarios a tu máquina, podrían apuntar a un dominio que viene con ese binario pre-cargado en WebAssembly y deja al agente ejecutarlo dentro del sandbox del browser. Chrome 149 ya está plantando esa bandera.

Lo que cambia para vos como developer

Si hoy mantenés un sitio con UI más o menos interactiva, WebMCP te da una pregunta directa: ¿qué herramientas de tu sitio expondrías si los agentes fueran un cliente más? Para la mayoría, la respuesta es corta pero útil: login, búsqueda, carrito, checkout, reserva, formulario de contacto. Cada una de esas es un registerTool con un schema.

El umbral es ridículamente bajo. Una tarde agregando registerTool a las tres operaciones más comunes de tu sitio te pone adelante del 95% de la web, y te posiciona para cuando la propuesta madure, los navegadores lo soporten sin flag, y Codex, ChatGPT, Claude y los demás agentes empiecen a buscar herramientas declaradas antes de caer al scraping como fallback.

Estado real, no hype

Para cerrar: WebMCP es un draft de Community Group, no un estándar W3C terminado. La API puede cambiar, los nombres de los métodos pueden cambiar, y hay partes del spec que todavía están bajo discusión. Pero ya hay origin trial en Chrome 149, soporte experimental en Angular, demo sites de Google, y Codex y ChatGPT desktop ya lo soportan en su browser integrado según reportes de la comunidad. Eso es señal suficiente como para prestarle atención, probarlo con la flag activada, y darle feedback al grupo antes de que la API se congele.

No es el "momento de meterlo en producción". Es el momento de aprenderlo y darle forma, y por eso escribo esto ahora: en seis meses va a ser tarde para opinar sobre el diseño de algo que los vendors van a terminar decidiendo solos si la comunidad no se mete temprano.