WebMCP, MCP a nivel de servicio o uso simple en el navegador: dónde encajan las herramientas de agente.

A primera vista, WebMCP parece razonable. El usuario ya está conectado, un agente funciona dentro del navegador y el sitio puede indicar qué acciones existen, de modo que el agente no necesita adivinar qué campos y botones están disponibles. La dificultad radica en dónde se ubica esa interfaz. Cuando se invierte esfuerzo en hacer que una aplicación sea utilizable por agentes, ¿deben exponerse las capacidades a través de la página o a través de los servicios subyacentes? ¿Y qué aporta una interfaz de herramientas a nivel de página a las herramientas generales del navegador?

Esas dos preguntas definen la evaluación que sigue.

Qué es WebMCP

Con WebMCP, un sitio registra herramientas estructuradas que un agente compatible puede llamar a través del navegador. Cada herramienta indica qué función realiza, qué entradas acepta y qué código la ejecuta. El registro se realiza en JavaScript o a través de formularios HTML anotados. Chrome documenta esta idea como un estándar propuesto cuya prueba inicial comienza con Chrome 149, y la API podría cambiar.

Imagínese una página de búsqueda de vuelos. Sin WebMCP, un agente lee la página, localiza el campo de destino, establece las fechas y hace clic en Buscar. Con WebMCP, el sitio podría publicar una herramienta llamada search_flights que reciba el destino y las fechas. El agente solo debe ingresar los argumentos, y la aplicación realiza la búsqueda.

Se deben mantener tres rutas distintas: MCP a nivel de servicio, WebMCP y uso general en el navegador. Nada obliga a elegir una en particular, y un mismo agente puede llamar a una herramienta de servicio para un producto, a una herramienta de página para otro y controlar directamente el navegador para un tercero.

La preocupación arquitectónica

La primera reacción es que WebMCP lleva las cuestiones relacionadas con los servicios a la capa de presentación. Buscar inventario, cambiar una reserva o realizar un pedido en una aplicación empresarial típica termina en un servicio backend, y el navegador ya llama a un endpoint que realiza esa tarea. Entonces, ¿por qué definir un contrato orientado al agente dentro de la página en lugar de junto a ese servicio?

Una alternativa natural parte del contrato de servicio existente, como una especificación OpenAPI o una definición gRPC, y construye la interfaz MCP sobre él. La ventaja radica en la propiedad: el equipo responsable de la operación empresarial puede versionar, probar y gestionar el contrato dirigido a los agentes, y tanto los agentes interactivos como los trabajos por lotes y los flujos de trabajo programados pueden utilizarlo.

Envolver un endpoint interno en una herramienta de página tampoco hace que el contrato sea menos comprometedor. Los agentes reciben una operación con entradas y un comportamiento esperados, y los flujos de trabajo fallan si ese comportamiento cambia. Dondequiera que se exponga la herramienta, el equipo debe decidir qué compatibilidad y soporte promete, y colocar la interfaz en la capa web por sí sola no reduce esas responsabilidades.

Al analizarlo más de cerca, algunas de esas suposiciones iniciales se debilitan.

• El navegador almacena estado real. Un editor puede contener un borrador sin guardar, una selección en tiempo real u operaciones locales que no tienen equivalente útil en el servidor, y considerar al cliente como una carcasa vacía ignora todo eso.
• No es necesario duplicar la lógica. Una herramienta puede invocar la misma función del cliente que un botón y, a través de ella, el mismo endpoint backend. La verdadera preocupación es el contrato adicional de la herramienta con su propio ciclo de vida, y la forma en que las reglas de negocio podrían acumularse alrededor de ella con el tiempo.

Los flujos multi-pantalla son el caso más complicado. Seleccionar varios vuelos, asignar pasajeros y validar una reserva antes de enviarla puede resultar mucho más económico si se reutiliza la orquestación existente del cliente. Una secuencia escrita exclusivamente para el agente plantea la pregunta de cuáles partes corresponden a la presentación y cuáles a las reglas de negocio. La elegibilidad y la autorización deben formar parte del servicio, y cuando la herramienta de página y la herramienta de servicio difieren, alguien debe asumir la responsabilidad por esa discrepancia y establecer un conjunto compartido de verificaciones contractuales.

La ruta del servicio es más difícil de lo que parece. Generar automáticamente herramientas a partir de cientos de puntos de extremo API no produce una interfaz útil para el agente. Las descripciones necesitan un lenguaje orientado al agente, las respuestas deben tener límites de tamaño, ciertas operaciones deben combinarse, y alguien debe decidir qué se expondrá.

También es importante la madurez del sistema. Se espera cierto grado de experimentación, pero una interfaz basada en una API del navegador en constante cambio añade otra fuente de trabajo de mantenimiento.

Por lo tanto, la postura más refinada es que una operación empresarial duradera debe ser gestionada de cerca por el servicio que la implementa, y existe una razón específica para incluir su contrato en la página.

Reutilización de sesiones versus acceso delegado

La ventaja de la autenticación proviene del funcionamiento dentro de un navegador con sesión iniciada, y tanto WebMCP como el uso habitual del navegador la comparten. La comparación aquí pone esa comodidad frente al acceso delegado a servicios. Qué herramientas específicas de WebMCP aportan además de la interacción habitual con el navegador es un tema distinto, que se tratará más adelante.

Cuando un agente hace clic en un control en un sitio con sesión iniciada, la aplicación envía su solicitud bajo la sesión existente, y una herramienta WebMCP invocada directamente puede utilizar la misma sesión. Ninguno de los dos necesita un permiso delegado separado entre el host del agente y el servicio.

La ventaja aumenta al aplicarse a diferentes aplicaciones. Un flujo de trabajo que involucre cinco servicios podría requerir cinco permisos, cinco ciclos de vida de tokens y cinco conjuntos de requisitos de integración, además del proceso de registro del cliente que depende de cada servicio. Si el usuario ya está conectado a los cinco sitios, reutilizar esas sesiones evita gran parte de esa configuración.

Llamar a esta autenticación gratuita sería exagerar. Una sesión en tiempo real tiene su propio ciclo de vida de seguridad, y el hecho de estar conectado no implica consentimiento para todo lo que un agente podría intentar. Aun así, el ahorro en trabajo de integración es real. La inyección de comandos y las acciones no deseadas no se resuelven simplemente eligiendo una capa, ya que ambos escenarios requieren medidas de protección como confirmaciones para operaciones significativas, con diferentes niveles de exposición y aplicación, por lo que cada diseño debe evaluar esos riesgos por separado.

Cómo CIMD reduce la brecha

El acceso a nivel de servicio también está mejorando. Los Documentos de Metadatos de ID de Cliente (CIMD) resuelven uno de los problemas que genera OAuth: cómo un cliente completamente nuevo se identifica ante un servidor de autorización que nunca lo ha conocido. El cliente utiliza una URL HTTPS como su identificador, y dicha URL proporciona un documento de metadatos que enumera elementos como las URI de redirección permitidas. Un servidor auxiliar lo obtiene y lo verifica, lo que elimina la necesidad de registrar cada par de cliente y servidor con antelación. La especificación de autorización MCP de noviembre de 2025 recomienda el uso de CIMD y lo prioriza sobre el registro dinámico de clientes cuando no existen detalles de clientes preregistrados.

En el caso de los cinco servicios, el soporte de CIMD en los cinco servidores de autorización elimina las registraciones previas. Los requisitos de autorización y los ciclos de vida de los tokens por servicio se mantienen, aunque las concesiones o sesiones existentes pueden reducir las solicitudes, por lo que no es necesario realizar cinco inicios de sesión nuevos. Las decisiones de autorización en sí no se ven afectadas por CIMD.

Contexto, ciclo de vida y descubrimiento

Un documento no guardado demuestra el valor del estado del navegador local. Una herramienta que edita el párrafo seleccionado de un borrador inacabado funciona con un estado que el servicio aún no ha visto, lo cual es una razón más específica para exponer una herramienta de página en lugar de reenviar una operación de backend.

El problema es que el estado local vincula las herramientas a la página. Después de que un usuario abandona la página o la cierra, un agente podría necesitar volver a abrir la aplicación y reconstruir primero el contexto. La sesión de inicio de sesión puede seguir activa incluso después de cerrar la página; lo que desaparece es el estado no guardado o las herramientas que estaban allí.

El descubrimiento es un asunto distinto: ¿cómo sabe un agente qué ofrece un sitio? Las limitaciones documentadas de Chrome indican que es necesario visitar el sitio antes de poder conocer sus herramientas WebMCP. Se puede consultar directamente un endpoint MCP conocido sin necesidad de una interfaz humana, pero localizar uno a partir de una dirección web simple representa un desafío adicional. Además, los metadatos de OAuth solo permiten encontrar el servidor de autorización de un recurso protegido ya conocido, sin ofrecer un listado universal de las capacidades MCP.

SEP-2127, titulado MCP Server Cards, propone una forma estándar de publicar metadatos estructurados de servidores a través de HTTP para que los clientes puedan descubrir las interfaces de servicio antes de establecer una conexión MCP y sin necesidad de operar una página dirigida a usuarios. Esa es una dirección prometedora. En el momento de redactar este texto, la solicitud de integración sigue abierta, por lo que se trata de una propuesta para cubrir esa carencia y no de una solución ya adoptada que pueda aplicarse en todas partes.

Ninguna de las partes tiene una ventaja clara en cuanto al descubrimiento de servicios, ya que las herramientas basadas en páginas requieren una visita al sitio, mientras que el descubrimiento de servicios desde una dirección arbitraria aún no cuenta con una convención universal. Tampoco ninguna de estas capas garantiza una buena gestión, ya que las herramientas WebMCP pueden estar bien probadas y mantenidas, mientras que las herramientas de servicio pueden estar mal diseñadas. La verdadera pregunta es quién asumirá la responsabilidad y qué flujos de trabajo debe soportar la interfaz.

Los agentes de navegador ya funcionan sin ella

Vale la pena verificar qué puede aprender un agente de navegador sin WebMCP. Se prefirieron acciones en elementos basadas en accesibilidad, siempre que estuvieran disponibles, mediante definiciones de herramientas de navegador en una sola sesión de escritorio del agente, utilizando capturas de pantalla como contexto visual o como solución de respaldo; además, la información de accesibilidad devuelta para una página de documentación resultó muy útil. Se trata de una observación específica de esa sesión y no de una afirmación sobre todas las versiones o configuraciones predeterminadas.

La integración proporcionó al agente una descripción estructurada de la interfaz renderizada, con cuadros de texto, botones, etiquetas, valores y estados, y había herramientas orientadas al DOM disponibles para tareas adecuadas. Una mayor parte del contenido de la página llegó en forma de texto estructurado, más de lo que podrían predecir las expectativas basadas en un alto uso de capturas de pantalla. En el caso de un formulario de búsqueda simple, el agente podría recibir algo similar a esto.

1 textbox “Destination”, value: “Tokyo”
2 button “Search flights”, enabled

A partir de eso, un agente puede identificar el campo de destino, hacer clic en el botón “Buscar vuelos” y verificar el estado actualizado. Las semánticas HTML y las etiquetas de accesibilidad ya transmiten gran parte del significado de una interfaz. La vista de la página que recibe un modelo depende de la integración y no del nombre del modelo; además, la documentación de uso de computadoras de OpenAI muestra integraciones en las que las capturas de pantalla se envían al modelo y las acciones se devuelven a través de herramientas proporcionadas por la aplicación.

En resumen, los agentes pueden operar un sitio sin WebMCP, lo que reduce lo que deben desarrollar los creadores del sitio. Sin embargo, eso no resuelve si WebMCP realmente vale la pena. Un árbol de accesibilidad enumera los controles, mientras que una herramienta bien diseñada puede describir toda una operación con sus entradas, reduciendo las interacciones y las conjeturas. Mientras que un agente del navegador funciona a través de una forma que consta de diez controles, la aplicación podría ofrecer una sola herramienta para esa tarea. Chrome presenta WebMCP como una mejora progresiva e incluye un inspector para probar las herramientas.

Para esta evaluación no se realizó una comparación controlada con y sin herramientas WebMCP, por lo que se trata de un juicio arquitectónico y no de un resultado de rendimiento. Un veredicto justo mediría la finalización de tareas, la cantidad de interacciones y el tiempo transcurrido en varios flujos de trabajo. Una demostración exitosa es un buen punto de partida, pero no responde a esa pregunta más amplia.

Lo que se puede desplegar también depende de las interfaces que controla un equipo. WebMCP necesita la cooperación del sitio, y la integración de servicios requiere una interfaz de servicio accesible y autorizada. Cuando una aplicación de terceros no ofrece ninguno de estos elementos, el uso habitual del navegador puede ser la única opción viable.

Donde deja esto a las cosas

Los puntos de partida que se derivan de todo esto son:

• Herramientas a nivel de servicio son adecuadas para operaciones empresariales duraderas, especialmente para flujos sin supervisión o de larga duración.
• WebMCP resulta útil cuando es importante el estado de la aplicación local o cuando reutilizar un flujo de trabajo de cliente autenticado ahorra una gran cantidad de trabajo de integración.
• Uso general del navegador abarca los casos en los que faltan herramientas especializadas, sobre todo las aplicaciones fuera del control del equipo.

Permanece la inquietud cuando WebMCP se convierte en el destino predeterminado para capacidades que ya tienen un límite de servicio claro. La comodidad de la sesión es un fuerte argumento a favor de su implementación, pero no debería determinar por sí sola la arquitectura a largo plazo.

Las pruebas que podrían cambiar esta perspectiva mostrarían, para una aplicación específica, que las herramientas definidas en la página superan claramente al uso habitual del navegador, con un costo total menor que el de crear y mantener una interfaz de servicio, donde dicho costo incluye la autorización, el mantenimiento, la gobernanza y los flujos de trabajo que dicha interfaz no puede abarcar.

WebMCP es más eficaz cuando coinciden tres factores: una sesión autenticada en tiempo real, un estado local valioso y flujos de trabajo del cliente que merecen ser reutilizados. El uso habitual del navegador también permite la reutilización de sesiones, por lo que la pregunta pendiente es qué herramientas específicas contribuyen a ello. Una herramienta de página que simplemente reenvía una operación a un servicio sigue necesitando una justificación para mantener el contrato orientado al agente en dicha página.