WebMCP: la nueva API que prepara tu web para hablar directamente con agentes de IA

Hasta ahora, cuando un agente de inteligencia artificial quería hacer algo dentro de una web, tenía que comportarse casi como una persona: leer la interfaz, interpretar botones, localizar campos y simular clics. Funcionaba, pero cada paso abría una nueva posibilidad de error.

WebMCP propone cambiar esa relación. En lugar de obligar al agente a adivinar cómo utilizar una página, la propia web puede declarar qué acciones ofrece, qué datos necesita y qué resultado devuelve.

El tema acaba de ganar relevancia porque Microsoft anunció el 21 de septiembre de 2026 que su implementación de WebMCP en Edge ya está lista para pruebas. Tres días después, WebMCP apareció entre las pruebas de origen de Edge 154. Chrome, por su parte, permite probar la propuesta mediante una origin trial desde Chrome 149 y también ofrece una bandera para desarrollo local.

No estamos ante una API estable ni ante una función que deba desplegarse hoy sin cautela. WebMCP sigue en discusión y su forma puede cambiar. Pero sí estamos ante una señal bastante clara de hacia dónde se mueve la web: páginas diseñadas no solo para personas y buscadores, sino también para agentes capaces de actuar.

Qué es WebMCP

WebMCP es una propuesta de API web que permite exponer funciones de una página como herramientas estructuradas para agentes de IA que se ejecutan en el navegador.

La diferencia parece pequeña, pero cambia por completo el flujo. Un agente tradicional observa la interfaz y trata de deducir qué debe pulsar. Con WebMCP, la página puede registrar una herramienta llamada, por ejemplo, bookSlot, describir que sirve para reservar una consulta y definir mediante un esquema JSON que necesita fecha, hora, nombre y correo electrónico.

El navegador presenta esa herramienta al agente. El agente entrega argumentos estructurados y el código de la propia web ejecuta la acción. La interfaz visual sigue existiendo para el usuario, pero el agente deja de depender exclusivamente de ella.

En otras palabras: WebMCP convierte una intención humana en un contrato técnico explícito.

El problema que intenta resolver

Las interfaces web se diseñaron para ojos, manos y punteros. Los agentes de IA pueden utilizarlas mediante visión artificial, lectura del DOM y automatización, pero ese proceso es frágil.

Un cambio de texto, un botón movido, un selector ambiguo o un formulario complejo puede romper la secuencia. Y cuanto más larga es la tarea, más oportunidades existen para que el agente interprete algo mal.

WebMCP reduce esa ambigüedad porque la web explica directamente tres cosas:

• qué acciones están disponibles;
• qué parámetros acepta cada acción;
• qué código debe ejecutarse cuando el agente la invoca.

Google pone ejemplos como rellenar una solicitud, seleccionar una fecha compleja, consultar el estado de un pedido o ejecutar un diagnóstico dentro de una aplicación. Microsoft resume la idea de forma práctica: reutilizar el código frontend existente y exponerlo como herramientas estructuradas.

Dos formas de convertir una web en una web “agéntica”

La propuesta contempla dos caminos.

API imperativa: herramientas definidas con JavaScript

La API imperativa permite registrar una herramienta con document.modelContext.registerTool(). Cada herramienta incluye un nombre, una descripción, un esquema de entrada y una función execute.

await document.modelContext.registerTool({
  name: "buscar_producto",
  description: "Busca productos disponibles por nombre y presupuesto.",
  inputSchema: {
    type: "object",
    properties: {
      consulta: { type: "string" },
      presupuestoMaximo: { type: "number" }
    },
    required: ["consulta"]
  },
  annotations: {
    readOnlyHint: true
  },
  execute: async ({ consulta, presupuestoMaximo }) => {
    return buscarEnCatalogo({ consulta, presupuestoMaximo });
  }
});

Este enfoque encaja con aplicaciones donde la acción depende del estado, de llamadas a una API o de lógica propia. La documentación también describe mecanismos para descubrir herramientas, ejecutarlas y cancelar operaciones en curso.

API declarativa: formularios HTML como herramientas

La segunda vía permite convertir formularios HTML estándar en herramientas añadiendo anotaciones. Los campos del formulario se convierten en parámetros y el navegador genera una representación estructurada que el agente puede entender.

Es una idea especialmente interesante para reservas, solicitudes de contacto, búsquedas y otros flujos que ya viven dentro de un <form>. No elimina el formulario: le añade una capa de significado para agentes.

Chrome y Edge ya están moviendo ficha, pero sigue siendo experimental

Este es el dato importante que conviene separar del entusiasmo.

Chrome ofrece una prueba de origen de WebMCP desde la versión 149. Para desarrollo local, la documentación oficial indica que puede activarse mediante chrome://flags/#enable-webmcp-testing. Microsoft confirmó el 21 de septiembre de 2026 que su implementación para Edge está lista para pruebas, y las notas de Edge 154, publicado el 24 de septiembre, incluyen WebMCP en la lista de origin trials.

Eso demuestra interés real de dos navegadores basados en Chromium y del Web Machine Learning Community Group. No significa, sin embargo, que WebMCP forme parte hoy del conjunto estable y universal de APIs web.

La propia documentación de Chrome advierte que la propuesta está en discusión activa y puede cambiar. Tampoco existe todavía interoperabilidad garantizada con todos los navegadores. Para producción, la estrategia sensata es tratarla como una mejora progresiva: la web debe seguir funcionando perfectamente para personas y navegadores sin WebMCP.

Por qué importa para e-commerce, SaaS y webs de servicios

El valor no está en añadir “IA” a la portada. Está en reducir fricción en tareas concretas.

En un e-commerce, un agente podría consultar productos, filtrar por restricciones reales y preparar un carrito usando contratos estructurados en lugar de navegar a ciegas. En un SaaS, podría crear un informe, cambiar una configuración o lanzar un diagnóstico. En una web de servicios, podría encontrar una cita disponible y rellenar una solicitud con los datos confirmados por el usuario.

La oportunidad es especialmente relevante en procesos con muchos pasos. Cuantas más pantallas, estados y validaciones existan, más valor tiene ofrecer una herramienta clara y acotada.

También aparece una nueva disciplina de optimización. Durante años hemos preparado webs para buscadores mediante SEO y para personas mediante UX. Ahora empieza a tomar forma una tercera capa: diseñar capacidades que un agente pueda descubrir y utilizar de forma segura.

Eso no sustituye al SEO ni a una buena interfaz. Los complementa.

La seguridad es el verdadero examen

Permitir que un agente ejecute acciones en una web abre riesgos evidentes. No es lo mismo consultar un catálogo que reservar un vuelo, borrar datos o transferir dinero.

La propuesta incluye anotaciones para describir el comportamiento de cada herramienta:

• readOnlyHint indica que una acción solo consulta información;
• consequentialHint señala acciones importantes o difíciles de revertir;
• untrustedContentHint marca resultados que contienen contenido externo o generado por usuarios.

Estas anotaciones ayudan al navegador y al agente a decidir cuándo exigir confirmación o tratar una respuesta con mayor cautela. Chrome también limita por defecto el acceso entre orígenes y utiliza una política de permisos llamada tools para los iframes.

Pero las anotaciones no son una barrera de seguridad por sí solas. La documentación oficial recuerda que los modelos siguen siendo vulnerables a la inyección indirecta de instrucciones. La autorización, la validación en servidor, los límites de permisos, la protección CSRF y la confirmación del usuario siguen siendo responsabilidad de la aplicación.

Una regla simple: un agente nunca debe recibir más capacidad de la que tendría el usuario autenticado, y una acción sensible nunca debería depender únicamente de que el modelo “entienda” la intención.

Qué debería hacer un desarrollador ahora

No hace falta reconstruir una web alrededor de una API experimental. Sí merece la pena empezar a pensar en términos de capacidades.

1. Identifica una tarea importante. Busca un flujo con valor real: reservar, consultar un pedido, filtrar un catálogo o ejecutar un diagnóstico.
2. Define entradas y salidas claras. Si no puedes describir la acción mediante un contrato pequeño y preciso, probablemente todavía sea demasiado amplia.
3. Empieza por lectura. Una herramienta sin efectos secundarios permite aprender con menos riesgo.
4. Reutiliza la lógica existente. La herramienta debería llamar a las mismas funciones y APIs que ya usa la interfaz, no crear un camino paralelo difícil de mantener.
5. Mantén siempre la alternativa humana. WebMCP debe ser una mejora progresiva, no un requisito para utilizar el sitio.
6. Prueba errores y abusos. Evalúa parámetros incompletos, permisos insuficientes, cancelaciones, contenido malicioso y confirmaciones.

La guía de seguridad de Chrome incluso recomienda mantener breves los contratos: hasta 500 caracteres para la descripción de una herramienta, 150 por parámetro, 30 para nombres y alrededor de 1.500 caracteres por salida individual. Son recomendaciones provisionales, pero revelan una idea importante: para que un agente actúe bien, menos ambigüedad vale más que más contexto.

¿Es WebMCP el nuevo SEO?

Todavía no. El SEO responde a cómo se descubre y se interpreta contenido. WebMCP responde a cómo un agente descubre y ejecuta acciones dentro de una página.

La comparación útil no es “SEO contra WebMCP”, sino contenido frente a capacidades. Una web puede necesitar ambos: información clara para ser encontrada y herramientas bien diseñadas para que un agente ayude al usuario a completar una tarea.

Si la web agéntica se consolida, la ventaja no la tendrán las páginas que registren cien herramientas. La tendrán las que expongan unas pocas acciones útiles, seguras y coherentes con su experiencia de usuario.

Conclusión: la web deja de ser solo una interfaz

WebMCP todavía es experimental, pero su dirección resulta difícil de ignorar. Chrome y Edge ya permiten probar una forma de interacción en la que las páginas explican sus capacidades al navegador y los agentes dejan de depender de una cadena de clics frágil.

Para los desarrolladores, el cambio no consiste únicamente en aprender otra API. Consiste en empezar a diseñar la web como una combinación de interfaz humana y contrato ejecutable.

La pregunta ya no será solo “¿puede una persona completar esta tarea?”. También será “¿puede un agente entenderla, ejecutarla con precisión y mantener al usuario en control?”.

Quien empiece a responder bien a esa pregunta estará mejor preparado para la siguiente etapa del desarrollo web.

Fuentes consultadas

• Microsoft Edge Blog — New in Edge for developers: Create better components and make your site agent-ready (21 de septiembre de 2026): https://blogs.windows.com/msedgedev/2026/09/21/new-in-edge-for-developers-create-better-components-and-make-your-site-agent-ready/
• Microsoft Learn — Microsoft Edge 154 web platform release notes (24 de septiembre de 2026): https://learn.microsoft.com/en-us/microsoft-edge/web-platform/release-notes/154
• Chrome for Developers — WebMCP: https://developer.chrome.com/docs/ai/webmcp
• Chrome for Developers — Imperative API: https://developer.chrome.com/docs/ai/webmcp/imperative-api
• Chrome for Developers — Declarative API: https://developer.chrome.com/docs/ai/webmcp/declarative-api
• Chrome for Developers — WebMCP tool security: https://developer.chrome.com/docs/ai/webmcp/secure-tools