En los últimos años, muchas webs se han puesto a añadir IA. Lo primero fueron los asistentes conversacionales, casi siempre para soporte (¿os acordáis del típico «¡Hola! Pregúntame lo que quieras»?). Cuando los modelos de lenguaje (los LLM) mejoraron, muchas webs empezaron a convertir en conversación funciones que antes eran solo interfaz. Kiwi.com, el buscador de vuelos, es un buen ejemplo: tiene un botón de «AI Mode» al lado de la búsqueda normal. Lo activas y, en vez de rellenar origen, destino y fechas, describes el viaje y hablas con el asistente de Kiwi hasta que encuentra vuelos.
Si lo miras con objetividad, la idea es muy buena. Muchas veces entras en estas webs sin saber muy bien qué quieres, y contarlo con tus palabras es más cómodo que rellenar fechas y campos que luego tienes que ir cambiando para ver otros resultados.
El problema es que cada vez que quieres hacer algo así tienes que repetir lo mismo. A la IA de cada web le tienes que dar todo el contexto desde cero, y se te va el tiempo escribiendo. El asistente de Kiwi no sabe que me gusta volar a primera o a última hora para aprovechar el día, ni si tengo una carrera, ni cuándo ni dónde es. Al final, estos asistentes son una segunda interfaz para lo que antes eran botones y clics.
Mientras tanto, la IA que uso cada día ha mejorado muchísimo. Conoce mis proyectos, sabe qué hago cada día y lo que me gusta, y la tengo conectada a mi calendario y a mi código. Cada vez que una web me ofrece su propia IA, pienso lo mismo: ¿por qué no puedo conectar mi asistente, que ya sabe lo que quiero?
Agentes que usan el navegador por ti
Las empresas de IA vieron el mismo problema y lo atacaron por otro lado: si la web no deja entrar a tu IA, que tu IA use la web como lo harías tú. Anthropic ha lanzado Computer Use y Claude in Chrome, y OpenAI tiene su propia extensión de Chrome y su versión de Computer Use. Con ellas, el agente maneja tu ordenador y tu navegador desde su app de escritorio o desde la terminal.
También hay pruebas de otras empresas y de desarrolladores independientes, como agent-browser, de Vercel. Es una herramienta de línea de comandos pensada para agentes de programación. Abre una página, lee el árbol de accesibilidad y le da a cada botón o campo una referencia corta, como @e1, que el agente puede pulsar o rellenar después.
Estas herramientas funcionan, y me gustan. Pero úsalas un tiempo y enseguida verás dónde se quedan cortas. Me recuerda a pedir comida en un país donde no sé leer la carta. El agente lee la página, adivina cuál es el campo de búsqueda, pulsa, espera y vuelve a leer la página para ver si ha pasado algo. A veces pulsa tres veces el banner de cookies y se rinde. Todo eso lo hace más lento y gasta tokens, que es justo lo que pagas cuando usas un LLM.
El agente hace lo que puede con una interfaz pensada para personas. La web sabe qué se puede hacer en ella, como buscar vuelos o registrar un entrenamiento, pero lo esconde detrás de píxeles, y al agente no le queda otra que adivinar.
De ahí nace WebMCP.
Qué es WebMCP
WebMCP es una propuesta de estándar web. Con ella, una página le dice a un agente de IA qué acciones ofrece y qué función ejecuta cada una. La propuesta sale del Web Machine Learning Community Group del W3C, donde trabajan en ella, entre otros, gente de Google y Microsoft.
Todavía es un borrador, pero ya puedes probarlo en Chrome 149 o posterior. Entra en chrome://flags/#enable-webmcp-testing, ponlo en «Enabled» y reinicia el navegador. Para ver qué herramientas registra una página y llamarlas a mano, instala la extensión Model Context Tool Inspector. Si quieres que funcione para tus usuarios sin que toquen ningún flag, tienes que apuntarte al origin trial de Chrome y servir el token desde tu dominio.
El nombre viene de MCP, el Model Context Protocol, que es lo que usan casi todas las apps de IA para conectarse a herramientas. Un servidor MCP publica una lista de herramientas, cada una con un nombre, una descripción y un esquema de entrada, y el modelo decide cuándo llamarlas. WebMCP se queda con esas ideas, pero las saca del servidor aparte y las mete en la propia página, en la pestaña que ya tienes abierta.
Cómo funciona
WebMCP tiene dos APIs. La API imperativa es JavaScript: el propio código de la página registra cada herramienta en document.modelContext, y queda casi igual que una herramienta MCP.
document.modelContext.registerTool({
name: "add-todo",
description: "Add a new item to the user's active todo list",
inputSchema: {
type: "object",
properties: {
text: { type: "string", description: "The text of the todo item" },
},
required: ["text"],
},
async execute({ text }) {
await addTodo(text);
return {
content: [{ type: "text", text: `Added "${text}" to the list.` }],
};
},
});La función execute es parte de la API de WebMCP. Se ejecuta en el navegador, con tu sesión y tus permisos. Así la web les da a los agentes la misma API, sin necesidad de añadir otra.
La API declarativa es HTML puro, y es la que más me gusta. Añades unos cuantos atributos a un formulario de toda la vida:
<form toolname="search-cars" tooldescription="Perform a car make/model search">
<input name="make" toolparamdescription="The vehicle's make (e.g., BMW, Ford)" required>
<input name="model" toolparamdescription="The vehicle's model (e.g., 330i, F-150)" required>
<button type="submit">Search</button>
</form>El navegador convierte un formulario en una herramienta. Por defecto, el agente lo rellena y eres tú quien pulsa «Enviar». Con toolautosubmit, el agente también puede enviarlo. En tu código, el evento submit te dice si lo ha enviado un agente (agentInvoked), y con respondWith() le devuelves un resultado estructurado en vez de pintar una página nueva. En el fondo, un formulario ya dice qué acción hace y qué datos necesita, y con estos atributos el agente también lo puede leer.
A partir de ahí, el proceso es corto. El agente, ya sea el del navegador o una extensión, le pide a la página sus herramientas, lee los nombres y las descripciones y llama a una con sus argumentos. No necesita capturas de pantalla ni adivinar qué div esconde un botón.
Algunos agentes ya lo usan. En la app de escritorio de ChatGPT, el navegador integrado lo soporta con el nombre de «site tools». Y agent-browser, la herramienta de Vercel que comentaba antes, lo soporta desde la versión 0.36. Cuando abre una página, le dice al agente qué herramientas tiene, y el agente las puede llamar con agent-browser webmcp invoke en vez de ir pulsando botones.
Por qué creo que es el siguiente paso
Volvamos a los AI modes y a los agentes de navegador. Con un AI mode usas la IA de cada web, que no sabe nada de ti. Con un agente de navegador usas tu IA, pero tiene que ir adivinando la estructura de la página. Con WebMCP tienes las dos cosas: tu propia IA y una web que le explica qué puede hacer. A Kiwi se le da bien encontrar vuelos, pero su asistente no conoce mi calendario de carreras, y el mío lo tiene conectado.
También es más fiable: con capturas, el agente tiene que adivinar en cada paso, mientras que una llamada a una herramienta o cumple el esquema o devuelve un error claro.
Además, el control lo tienes tú. Puedes usar tu propio modelo, a través de un agente que vive en tu navegador, como una extensión al estilo de Claude in Chrome, mientras sigues viendo la interfaz de la app de siempre. La especificación presenta WebMCP como una forma de que los agentes trabajen junto a una persona en el navegador, y deja fuera a los agentes que van por libre, sin navegador. El agente trabaja en la página que estás mirando: ves cómo se rellena el formulario y decides tú si pulsas el botón. No quiero un agente reservándome cosas en un backend que no veo. Quiero que haga el trabajo pesado mientras miro, y que la última palabra sea mía.
WebMCP en Peak Health
Para probarlo en algo de verdad, lo he añadido a Peak Health, mi app de entrenamiento.
Peak Health ya tenía un servidor MCP. Pegas la dirección en Claude o ChatGPT, inicias sesión y ya puedes pedirle a tu agente cosas como «mira mi último bloque y planifica el siguiente». Lee tus rutinas y tus entrenamientos y prepara el plan contigo sin abrir la app.
En la web, esas herramientas no me servían tal cual. get_routine(routineId), por ejemplo, pide el id de la rutina porque el agente que la usa no ve nada. Si tienes la rutina abierta en pantalla, el agente ya tiene el mismo contexto que tú, así que las herramientas de la web ya saben cuál es el ID y qué datos hay en pantalla.
Cada página registra solo las suyas. En el panel, por ejemplo, read_next_session lee cuál es tu próxima sesión. En el calendario, plan_rest_day marca un día de descanso. En el catálogo de ejercicios, show_exercises escribe la búsqueda y pone los filtros en la propia página, así que veo la misma lista que el agente. Y el editor de rutinas tiene herramientas para añadir, mover o quitar ejercicios y series sin tocar el ratón.
Quitar las herramientas al salir de una página cuesta muy poco código. Al registrar cada herramienta le pasas una señal, y cuando abortas esa señal WebMCP la quita:
export function registerPageTools(context: ModelContext, tools: readonly PageTool[]) {
const leaving = new AbortController();
for (const tool of tools) {
context.registerTool(tool, { signal: leaving.signal });
}
// Al desmontar la página se quitan todas sus herramientas.
return () => leaving.abort();
}Con el panel abierto, le pregunto al agente del navegador qué me toca entrenar hoy. Llama a una herramienta y lee la respuesta que la página ya tiene. No necesita capturas ni hacer scroll.
Con las herramientas que cambian datos fui con más cuidado. Cada una hace exactamente lo mismo que su botón: plan_rest_day usa el mismo código que «Descansar este día». Si el servidor lo rechaza, al agente le llega el mismo mensaje que me saldría a mí junto al botón, y el calendario no cambia. Además, antes de ejecutar nada el navegador me pide permiso, así que no se toca nada hasta que acepto.
En el editor, las herramientas no responden hasta que el cambio se ve en la página, así que lo que me cuenta el agente coincide con lo que tengo en pantalla. Y ninguna guarda nada. Tocan el editor abierto como si hiciera yo los clics, y la rutina no se guarda hasta que pulso «Guardar rutina».
Lo que más tiempo me ha llevado han sido las descripciones de las herramientas, más que el propio código. El agente no ve la pantalla, solo lee lo que le escribo, así que si una descripción no deja claro qué lee esa herramienta y qué necesita, el agente se equivoca.
Si le preguntas qué toca entrenar hoy y la página aún está cargando, la herramienta contesta algo como «todavía no tengo tu plan» en vez de devolver nada. Con una respuesta vacía, el agente se pone a adivinar qué ha pasado.
Luego está el texto que escribes tú. En el nombre de una rutina o en una nota puede haber cualquier cosa, así que cuando una herramienta lo devuelve, va marcado como texto del usuario. Así el agente sabe que eso no son órdenes.
Probarlo, de momento, es cosa de hacerlo a mano. Automatizar los tests todavía no es sencillo, así que toca abrir Chrome con chrome://flags/#enable-webmcp-testing activado e ir llamando a cada herramienta para ver qué hace.
Lo que falta por resolver
Al ser un borrador, todavía le queda camino. De momento solo funciona en navegadores basados en Chromium. Firefox y Safari participan en la discusión, pero no se han comprometido a nada.
Además, hoy WebMCP tiene sentido sobre todo en el ordenador. Los agentes que llaman a estas herramientas viven en extensiones del navegador o en apps de escritorio, y Chrome para Android no admite extensiones. Para usarlo en la web del móvil, tendría que ser el asistente del propio móvil (Gemini, en Android) el que supiera leer las herramientas de la página que tienes abierta.
La seguridad es el otro gran tema. La especificación le dedica una sección bastante larga, y no es para menos. El agente se cree lo que dice la descripción de una herramienta, así que una página le puede mentir. Y el texto que devuelve una herramienta puede colarle instrucciones al agente, lo que se conoce como inyección de prompts.
Los agentes de navegador ya se toparon con este problema. En agosto de 2025, cuando Anthropic empezó a probar Claude in Chrome, sus propias pruebas mostraron que estos ataques seguían funcionando el 11,2 % de las veces con las defensas activadas, y Anthropic decidió que era demasiado para abrirlo a todo el mundo. WebMCP no lo va a arreglar por sí solo, pero cuando una web declara sus herramientas, el agente tiene menos cosas que malinterpretar que cuando va adivinando.
Aun así, tengo muchas ganas de ver cómo evoluciona. Hasta ahora, meter IA en una web era construir tu propio asistente o tu AI mode, o dejar que el agente de otro se peleara con tus páginas. Para mí, el siguiente paso es poder usar mi propia IA en las webs que ya uso, sin que cada una tenga que montar su propio asistente, y WebMCP va justo en esa dirección.
