WebMCP vs. MCP: ¿cuál es la diferencia?

MCP es un protocolo para ejecutar un servidor que expone tus herramientas a agentes de IA desde cualquier lugar. WebMCP es un estándar web propuesto que permite a una página web declarar qué puede hacer un agente en ella mientras el usuario la tiene abierta.

Si ya has creado un servidor MCP, el nombre «WebMCP» sugiere que se trata del mismo protocolo, solo que trasladado al navegador. No es así. Esta diferencia determina dónde reside el código orientado a agentes, bajo qué identidad se ejecuta y si ya puedes depender de él.

Este artículo compara ambos en cuanto a entorno de ejecución, identidad, ciclo de vida y descubrimiento. Después, asocia cada uno a un tipo de producto y ofrece una evaluación directa del estado actual de WebMCP.

¿Cuál es la diferencia entre WebMCP y MCP en una sola frase?

MCP es un servidor que ejecutas para que un agente pueda invocar tus herramientas. WebMCP es tu página declarando qué puede hacer un agente en la página en la que ya se encuentra. El Model Context Protocol es un estándar abierto para conectar aplicaciones de IA con datos, herramientas y flujos de trabajo externos, y le da igual si el agente se ejecuta en un navegador. La guía de Chrome sobre cuándo usar WebMCP y MCP define WebMCP como un estándar de navegador propuesto compuesto por dos API. Esas API solo llegan al agente integrado en el navegador, y es el navegador el que transmite los mensajes entre ese agente y tu sitio. Para conocer el contexto de los navegadores que incorporan su propio agente, consulta nuestra introducción a los navegadores agénticos. Chrome describe WebMCP como «inspirado en MCP». Es una API del navegador modelada a partir de MCP, no MCP reescrito en JavaScript.

¿Quién ejecuta qué en MCP y WebMCP?

Un servidor MCP es un proceso independiente, con su propio despliegue, su propia autenticación y su propio tiempo de actividad. WebMCP no añade ningún proceso nuevo: se ejecuta dentro de la pestaña abierta.

Con MCP, ejecutas un servicio al que pueden conectarse en cualquier momento agentes de clientes de escritorio, móviles, en la nube o web. Ese alcance tiene un coste. Tú alojas el servidor, gestionas sus versiones, lo monitorizas y decides cómo autenticar a cada cliente que lo invoca. La guía para desarrolladores sobre el ecosistema MCP explica cómo encajan los clientes, los servidores y el protocolo.

Con WebMCP, las definiciones de las herramientas se distribuyen como parte de tu frontend. No hay nada adicional que desplegar, pero las herramientas están ligadas a la pestaña. Cada herramienta WebMCP desaparece junto con la pestaña que la registró. Si el usuario navega a otra página o cierra la pestaña, el agente pierde el acceso a esa herramienta.

Identidad: el agente actúa como el usuario que ha iniciado sesión

Como las herramientas WebMCP se ejecutan dentro de la página que el usuario ya tiene abierta, un agente que las utiliza trabaja dentro de la sesión, las cookies y los permisos existentes de ese usuario. No dispone de una credencial independiente para tu sitio. Chrome señala que WebMCP puede utilizar los datos de la sesión activa, las cookies y el DOM de la página, elementos que no existen fuera de una pestaña abierta. De ello se deduce que las solicitudes de red de una herramienta se envían con la sesión que ya tenga la página.

Un servidor MCP se enfrenta a un problema distinto. Al ser un servicio independiente, tiene que determinar por sí mismo quién lo invoca y qué puede hacer. Normalmente, eso implica emitir y verificar algún tipo de credencial para el agente o para el usuario al que representa. WebMCP se ahorra ese paso porque nunca sale de la sesión del usuario. No tienes que aprovisionar claves de API, configurar cuentas de servicio ni construir una capa de autorización independiente para el agente.

La identidad basada en sesión de WebMCP tiene un coste. Desde el punto de vista de la página, una llamada a una herramienta WebMCP es una acción realizada por el usuario que ha iniciado sesión. A menos que diseñes expresamente una forma de distinguirlas, tu código no puede diferenciar una llamada de un agente de un clic. De ahí se derivan tres prácticas:

• Limita el alcance de cada herramienta a algo que el usuario ya podría hacer desde la interfaz.
• Exige confirmación para las acciones sensibles. La descripción general de WebMCP indica que una herramienta que realiza una acción sensible, como una compra, puede mostrar al usuario un diálogo de confirmación antes de continuar.
• Apóyate en los controles de la plataforma. WebMCP solo se ejecuta en documentos con aislamiento de origen y está controlado por la Permissions Policy tools. El valor predeterminado de la política es self, por lo que a un iframe de origen cruzado hay que concederle acceso de forma explícita.

<iframe src="https://widget.example.com/" allow="tools"></iframe>

Si el iframe no tiene este atributo, el valor predeterminado self bloquea el registro de herramientas en ese frame de origen cruzado. La documentación de Chrome también indica que las API de WebMCP se desactivan en cualquier documento que habilite document.domain, por ejemplo, mediante la cabecera Origin-Agent-Cluster: ?0.

Comparativa directa entre WebMCP y MCP

La división fundamental entre MCP y WebMCP es la persistencia y el alcance, por un lado, frente al contexto de la página y la sesión del usuario, por otro.

Las cinco primeras filas se basan en la comparativa de WebMCP y MCP de Chrome.

¿Cuándo conviene usar MCP o WebMCP?

Usa MCP para el trabajo que se realiza en un servidor sin interfaz y WebMCP para el trabajo que se realiza en una página con un usuario presente.

• Servicio de backend, tareas en segundo plano o acceso a datos sin interfaz: MCP. WebMCP necesita una página abierta, y la descripción general de Chrome indica que está pensado principalmente para una persona que trabaja en un navegador local, no para ejecuciones headless. Empieza por cómo crear un servidor MCP.
• Aplicación web con un usuario que ha iniciado sesión: WebMCP. Úsalo para acciones en la página actual, como rellenar un formulario complejo o seleccionar fechas en un widget de reservas, en las que importan la sesión del usuario y el estado de la página.
• Ambos. Muchos productos necesitarán los dos. MCP se encarga de la lógica de negocio principal y de los datos, y WebMCP cubre las acciones dentro de la pestaña. Si ya tienes una API HTTP, exponer esa API a los LLM con MCP es la mitad natural del lado del servidor. Para el lado del navegador, consulta nuestro artículo complementario, Exponer las acciones de tu sitio a agentes de IA con WebMCP.

¿WebMCP sustituye a MCP?

No. Chrome afirma claramente que WebMCP ni amplía ni sustituye a MCP. Está diseñado para el navegador y prescinde de conceptos del lado del servidor, como los recursos. Además, depende de una página. Sus herramientas solo se pueden descubrir visitando el sitio y desaparecen cuando se cierra la pestaña. Muchas tareas de los agentes nunca pasan por una página web: tareas programadas, asistentes en el IDE, pipelines de datos y agentes que se ejecutan en la nube. Esas tareas siguen necesitando un servidor MCP.

¿Qué grado de madurez tiene WebMCP?

WebMCP es experimental. Está disponible mediante una prueba de origen de Chrome a partir de Chrome 149 y, en local, mediante el flag chrome://flags/#enable-webmcp-testing, y Chrome advierte de que la API todavía está en discusión y puede cambiar. Las pruebas de origen tienen una duración determinada, pueden incluir límites de uso y su objetivo es recopilar comentarios que den forma a la API definitiva. La especificación de WebMCP es un borrador de informe del W3C Web Machine Learning Community Group. No es un estándar del W3C ni forma parte del W3C Standards Track. La documentación de Chrome solo abarca la implementación de Chrome, así que no des por hecho que otros navegadores o hosts de agentes lo admiten hasta que su propia documentación lo confirme. Sigue WebMCP en Chrome Status para conocer los cambios en los hitos. Chrome también señala que WebMCP puede añadirse como mejora progresiva. Impleméntalo de esa forma, para que tu interfaz funcione igual tanto si un agente puede ver las herramientas como si no.

Cómo elegir entre ambos

MCP y WebMCP responden a preguntas distintas. MCP hace que tus capacidades sean accesibles desde cualquier agente en cualquier momento. WebMCP hace que la página en la que se encuentra un usuario sea utilizable por el agente de su navegador, bajo su propia sesión. Como siguiente paso, enumera las acciones que expone tu producto y clasifícalas: las operaciones headless van a un servidor MCP, y las acciones de página ligadas a la sesión se convierten en candidatas para WebMCP tras la prueba de origen. Mantén la capa de WebMCP lo más ligera posible, porque la API aún puede cambiar.

Preguntas frecuentes

¿Cómo activo WebMCP para los visitantes reales y no solo en mi propio navegador?

Registra tu origen en la consola de Chrome Origin Trials y genera un token de WebMCP. Sírvelo en todas las páginas que registren herramientas, ya sea en una metaetiqueta de origin trial o en una cabecera de respuesta HTTP Origin-Trial. Los tokens son por origen. Sin uno, los visitantes con Chrome estándar nunca verán tus herramientas, porque el flag de pruebas local solo afecta al navegador en el que lo activas. La prueba comenzó en Chrome 149 y en un principio estaba previsto que durara hasta Chrome 156. Google ha solicitado ampliarla hasta Chrome 162, así que comprueba la fecha de finalización de tu token en la consola de Origin Trials.

¿Cómo puedo probar las herramientas WebMCP sin crear un agente?

Usa Model Context Tool Inspector, una extensión de Chrome que aparece en la documentación de WebMCP de Chrome. Muestra las herramientas que ha registrado una página y te permite ejecutarlas tú mismo. También confirma que el navegador puede analizar tu JSON Schema y muestra el resultado o el error que devuelve cada herramienta. Tu página sigue necesitando tener WebMCP activado, ya sea mediante el flag de pruebas de WebMCP en chrome://flags o mediante un token de origin trial.

¿Puedo reutilizar las definiciones de mis herramientas MCP para WebMCP?

A menudo puedes reutilizar las definiciones de entrada, pero no los handlers. Tanto las herramientas MCP como las WebMCP describen sus entradas con JSON Schema, por lo que el nombre, la descripción y la estructura de los argumentos de una herramienta suelen poder trasladarse. El handler es diferente. Un handler de MCP se ejecuta en tu servidor con la autenticación que implementes. Un handler de WebMCP es código JavaScript que se ejecuta en la página, con la sesión del usuario y el estado activo del DOM.

¿Angular es compatible con WebMCP?

Sí, pero solo de forma experimental. La compatibilidad experimental de Angular permite registrar herramientas WebMCP que siguen el ciclo de vida de la inyección de dependencias de Angular, y puede convertir Signal Forms en herramientas sin que tengas que escribir JSON Schemas a mano. La documentación de Angular advierte de que la especificación de WebMCP cambia con frecuencia y de que estas API pueden cambiar incluso fuera de las versiones principales. Fija tu versión de Angular y prepárate para actualizar tu código.