WebMCP en 2026: la API con la que los agentes usan tu SaaS

WebMCP es una API del navegador con la que una página registra sus propias herramientas, cada una descrita en JSON Schema, para que un agente de IA dentro del navegador pueda llamarlas directamente en lugar de leer la pantalla y adivinar para qué sirve cada botón.

Hoy es un Draft Community Group Report del W3C Web Machine Learning Community Group, editado por ingenieros de Google y Microsoft, y funciona como origin trial en Chrome desde la versión 149. No es un estándar del W3C ni está en la vía de estandarización. Quienes deberían leer el borrador ahora son los equipos que publican checkouts, paneles, buscadores y pantallas de reserva: esas son las tareas que un agente intentará completar en nombre del usuario.

La versión de treinta segundos

Un agente de navegador maneja hoy tu producto como lo haría una persona, solo que peor. Lee el árbol de accesibilidad o una captura, deduce la intención por las etiquetas, hace clic, espera, vuelve a leer. Cada vuelta cuesta tokens. Cada vuelta se atasca con un modal, con una lista que carga tarde o con tres botones que en la misma página dicen Continuar.

WebMCP da la vuelta al flujo. La página declara lo que sabe hacer. El agente llama a la función declarada. El manejador se ejecuta en el contexto JavaScript de la propia página, con la sesión que el usuario ya tiene abierta. Ninguna segunda API, ninguna autenticación aparte, ningún trabajo de servidor.

Por qué sale caro dejar que un agente adivine el DOM

El coste se mide. Un artículo de 2025 publicado en arXiv con ese mismo nombre, webMCP, un prototipo de cliente distinto del borrador de Google y Microsoft, ejecutó 1.890 llamadas reales a API en flujos de compra, autenticación y gestión de contenidos. Meter en la página los metadatos estructurados de la interacción redujo un 67,6% la carga de procesamiento y mantuvo un 97,9% de tareas completadas, con un coste por interacción entre un 34% y un 63% menor (Perera, arXiv:2508.09171).

Son cifras de un prototipo, no de la implementación de Chrome, así que léelas como dirección y no como promesa. La dirección no está en discusión: una llamada a función tipada cuesta menos que una captura más una cadena de deducciones.

Cómo funciona la API

La interfaz expone tres métodos y un evento: registerTool, getTools, executeTool y el manejador ontoolchange. Una herramienta es un nombre, una descripción, un esquema de entrada y una función asíncrona.

await document.modelContext.registerTool({
  name: "add-todo",
  description: "Add an item to the user's active todo list",
  inputSchema: {
    type: "object",
    properties: { text: { type: "string", description: "The todo item text" } },
    required: ["text"]
  },
  async execute({ text }) {
    await addTodoItemToCollection(text);
    return { content: [{ type: "text", text: "Added todo: " + text }] };
  }
});

Chrome documenta dos caminos. El imperativo es el código de arriba: herramientas definidas en JavaScript para navegación, relleno de formularios y cambios de estado. El declarativo permite anotar un formulario HTML normal para que el navegador lo exponga como herramienta sin escribir nada más. Las DevTools de Chrome traen un panel experimental que lista las herramientas registradas en la página, las invoca a mano y valida el JSON Schema (Chrome for Developers).

En qué punto está la especificación en septiembre de 2026

• Estado. Draft Community Group Report del W3C Web Machine Learning Community Group. No es un estándar ni está en la vía de estandarización.
• Chrome. Origin trial desde la versión 149, anunciado en mayo de 2026.
• La API se movió. El getter pasó de navigator.modelContext a document.modelContext. Chrome 150 marcó como obsoleto el nombre en navigator y lo dejó como alias, así que el código antiguo sigue funcionando y el cambio se cuela sin que nadie lo note.
• Un método desapareció. provideContext() salió del borrador en marzo de 2026. Cualquier guía que aún lo muestre está desactualizada.
• Edge. Microsoft coedita la especificación, pero WebMCP no figura como publicado en las notas públicas de la plataforma Edge. Las afirmaciones de terceros sobre soporte nativo en Edge siguen sin confirmar.
• Firefox y Safari. Participan en el community group. Ninguno se ha comprometido con una fecha.

Es un blanco en movimiento. Todo lo que se desarrolle sobre esta base en 2026 es un experimento con una factura de mantenimiento detrás.

Qué cambia para el diseño de interfaces SaaS

El trabajo interesante aquí es de diseño, no solo de desarrollo.

La lista de herramientas es tu arquitectura de información, dicha en voz alta

Registrar herramientas obliga a nombrar lo que hace el producto con verbos que entiende un desconocido. Si un equipo no consigue enumerar ocho herramientas de su propio panel sin discutir, las funciones del producto nunca estuvieron claras. Escribir un servidor MCP produce el mismo efecto: poner nombres es un ejercicio de producto disfrazado de ejercicio de API.

Las descripciones de las herramientas son microcopy de interfaz

El modelo lee la descripción para decidir si llama a la herramienta. Es el trabajo que hace la etiqueta de un botón con una persona, ante un lector distinto. "Actualizar ajustes" le sirve tan poco a un agente como a un usuario. "Cambiar el correo de notificaciones de este espacio de trabajo" sí sirve.

Lecturas y escrituras piden trato distinto

Las recomendaciones de Chrome incluyen readOnlyHint para herramientas que no cambian nada y untrustedContentHint para las que devuelven datos de fuera de la página. Ordenar una tabla y cancelar una suscripción no se registran con la misma actitud.

La confirmación se muda a la frontera

Un agente que llama a una herramienta capaz de borrar registros, enviar mensajes o mover dinero necesita a una persona en el circuito. Esa confirmación es una pantalla, y alguien tiene que diseñarla. La interfaz no desaparece cuando llega el agente: se concentra en los puntos donde equivocarse cuesta caro.

La pantalla tiene que seguir funcionando

Cada herramienta que registra la página tiene su equivalente humano en esa misma página. Dos contratos que mantener sincronizados, dos caminos que probar. Es un coste real y es el argumento honesto para esperar. Sobre cómo lee una pantalla un usuario no humano escribimos aquí.

Cuándo conviene esperar

Cuatro situaciones en las que hoy la respuesta es no.

• Tu tráfico es humano. Si ninguna parte medible de las sesiones viene de un agente, estás pagando mantenimiento por una hipótesis.
• Tus flujos críticos son irreversibles. Pagos, borrados y mensajes salientes concentran el mayor riesgo de injection y la menor tolerancia a una llamada equivocada.
• No tienes forma de observar las llamadas. Sin registro de qué herramienta se ejecutó, con qué argumentos y con qué respuesta, no hay depuración ni auditoría posible.
• Tu equipo ya tiene un servidor MCP con esas mismas capacidades. Duplicar el contrato antes de que la API del navegador se asiente trae desajuste, no alcance.

Qué advierte Chrome sobre seguridad

Chrome publica una página dedicada a la seguridad de los agentes y los avisos son concretos (Agent security considerations for WebMCP). Una página maliciosa puede esconder instrucciones en los nombres de las herramientas, en las descripciones y en las salidas: es prompt injection indirecta con un canal de entrega nuevo. Las herramientas con demasiados parámetros se dejan convencer para filtrar datos del usuario. Y una herramienta puede declarar una cosa y hacer otra.

Las defensas no tienen ningún glamour: límites estrictos de caracteres en nombres y descripciones, hints que marcan las herramientas de solo lectura y el contenido no fiable, confirmación humana explícita antes de cualquier acción irreversible, y registro de cada llamada. Quien ya haya blindado un servidor MCP reconoce la forma del trabajo. La versión de servidor la contamos en blindar un servidor MCP para empresas.

WebMCP y MCP no son lo mismo

Los nombres se parecen, las arquitecturas no. Un servidor MCP vive en tu infraestructura, habla un transporte, lleva su propia autenticación y atiende a cualquier cliente que se conecte. WebMCP vive en la página, se ejecuta en el navegador y aprovecha la sesión que el usuario ya tiene. El primero expone el producto a cualquier agente, en cualquier sitio. El segundo expone la página que el usuario está mirando al agente que se la mira por encima del hombro.

La mayoría de equipos SaaS acabará con los dos, para trabajos distintos. Si la duda está en el lado servidor, se empieza por qué es MCP y por qué un SaaS necesita un servidor, y se sigue con la elección entre gestionado y self-hosted. La especificación en sí es lo bastante corta como para leerla en una tarde (borrador de WebMCP), y es la investigación más barata que un equipo de producto puede hacer este trimestre.