WebMCP: qué permite hacer, compatibilidad y futuro de la web con agentes

Imagina que tienes abierto un catálogo de formación y le pides a un asistente que encuentre cursos de arquitectura de software, con plazas disponibles y compatibles con tu horario. El agente puede recorrer los filtros y leer los resultados. También podría pedirle a la propia aplicación que aplique esos criterios y le devuelva las opciones, mientras tú ves cómo cambia la página.

La segunda posibilidad explica el interés de WebMCP: una aplicación web puede describir operaciones que un agente descubre e invoca, utilizando el código y el estado de esa página. El sitio conserva su interfaz, pero ofrece otra forma de acceder a sus funciones. Una petición en lenguaje natural podría acabar en una búsqueda, un formulario preparado o una propuesta de cambio que el usuario revisa allí mismo.

Esto abre una cuestión de producto: qué parte de usar una aplicación consiste en tomar decisiones y qué parte consiste en encontrar los controles para expresarlas. WebMCP puede facilitar la segunda. El criterio del usuario, los permisos y las reglas sobre lo que puede ocurrir siguen necesitando un diseño explícito.

Para valorar su alcance conviene separar las capacidades que se pueden probar hoy, la compatibilidad real y las posibilidades de evolución. A 15 de octubre de 2026 hay implementaciones experimentales y propuestas abiertas; todavía no existe una base para dar por hecho que cualquier navegador o asistente vaya a comportarse igual.

Qué es WebMCP y qué cambia en una aplicación web

WebMCP es una propuesta del Web Machine Learning Community Group para que una página exponga funciones como herramientas destinadas a agentes. El documento publicado sigue siendo un Draft Community Group Report: no es un estándar W3C ni está en su vía de estandarización. Eso permite estudiar una dirección técnica concreta, aunque todavía no acredita estabilidad o adopción general. Borrador de WebMCP.

Un agente que opera una web suele interpretar capturas, el DOM o la estructura de accesibilidad para decidir dónde pulsar y qué escribir. Si el sitio ofrece una herramienta como prepare_announcement, el agente puede solicitar directamente la preparación de un aviso con determinados argumentos. El navegador media la invocación y el código de la página realiza la operación.

La diferencia útil está en el contrato. El agente deja de necesitar una secuencia de clics para esa operación; recibe una descripción de lo que puede pedir y de los datos necesarios. El sitio sigue teniendo que aplicar sus reglas y reflejar el resultado en pantalla. El diseño contempla consumidores integrados en navegadores, extensiones y agentes proporcionados por las propias aplicaciones. Funcionamiento descrito por el proyecto.

El usuario y el agente pueden acceder a la misma operación. Compartir la lógica ayuda a conservar el significado del cambio; la aplicación mantiene sus controles y actualiza la interfaz.

Ver a tamaño originalCerrar

WebMCP tampoco incorpora un modelo por sí solo. Hace falta un consumidor que descubra las herramientas y, si se quiere interacción en lenguaje natural, un agente que interprete el encargo. Una llamada puede resolverse en memoria o consultar un servidor. El tiempo total seguirá dependiendo de esos servicios y de la revisión que necesite el usuario.

Qué permitiría hacer y dónde aportaría valor

Su aportación más inmediata aparece en aplicaciones donde el usuario ya tiene una sesión y un objeto de trabajo abierto: un expediente, un diseño, un pedido o un curso. La herramienta puede actuar sobre ese contexto sin obligar al agente a reconstruirlo a partir de cada pantalla.

En el catálogo de formación del ejemplo, una herramienta podría consultar disponibilidad y aplicar filtros combinados. La aplicación mostraría los cursos que cumplen los criterios y explicaría las incompatibilidades. La persona decidiría qué curso encaja con lo que necesita. Para que funcione, el sitio tiene que ofrecer una operación que entienda fechas, horarios y disponibilidad; registrar el nombre de una función no crea esa lógica.

En un formulario largo, el agente podría trasladar los datos de una conversación a los campos adecuados y dejar pendientes los que no conoce. El usuario revisaría la solicitud antes de enviarla. La documentación de Chrome contempla recorridos de búsqueda, compras y cumplimentación de formularios; son ejemplos de diseño, no resultados universales de rendimiento. Casos de uso de WebMCP.

Las posibilidades pueden ordenarse por lo que recibe el usuario:

La unidad de trabajo que se ofrece determina cuánto puede simplificarse el recorrido. Ofrecer cada detalle interno del sitio como una herramienta puede dejar al agente casi la misma carga de coordinación que tenía con los clics. Una operación como «preparar la solicitud» tiene más sentido para el usuario que veinte funciones sobre controles, siempre que su alcance sea claro y deje un resultado revisable.

El beneficio potencial procede de reducir la incertidumbre sobre cómo manejar la interfaz y de poder agrupar pasos coherentes. La exactitud de los datos, la interpretación del objetivo y el tiempo necesario para aceptarlo son problemas adicionales. Una operación invocable puede simplificar el acceso sin resolver la tarea completa.

Compatibilidad: navegador, versión de la API y agente

La compatibilidad tiene varias capas. La web debe implementar las herramientas; el navegador debe ofrecer la API correspondiente y tenerla habilitada; el agente debe saber descubrirla y utilizarla. Por último, la sesión tiene que permitir la operación solicitada. Una aplicación que cumple solo una de esas condiciones puede seguir siendo inutilizable para ese recorrido.

Que el navegador exponga la API es una condición del recorrido. También importan la web, el consumidor de las herramientas y la autorización de la operación.

Ver a tamaño originalCerrar

El estado contrastado a 15 de octubre de 2026 es el siguiente:

Las referencias son el estado de implementación del proyecto, el anuncio de Chrome, la prueba de origen de Edge, el seguimiento de Brave y las posiciones de Mozilla y WebKit.

Una prueba de origen permite a sitios participantes ensayar una función durante un periodo y con condiciones determinadas. La activación local mediante una opción experimental sirve para desarrollo. Son mecanismos diferentes de una función disponible de serie. Tampoco el ensayo de escritorio acredita su comportamiento en Android, iOS o todas las variantes de un navegador.

En el ensayo local, Chrome 155.0.8059.40 no expuso la API con su configuración de inicio predeterminada. Al arrancarlo con --enable-experimental-web-platform-features, permitió descubrir e invocar una herramienta con un objeto de argumentos. En Chromium 151.0.7922.34, el descubrimiento funcionó con esa opción, pero la misma invocación se rechazó. El Edge instalado era 144.0.3719.104, anterior al programa documentado desde la versión 150: solo expuso el antiguo navigator.modelContext con activación experimental. Ese resultado no permite juzgar el Edge actual.

En WebKit 26.5 de Playwright no se encontró la API. Se trata de una compilación de pruebas, no de una validación de Safari comercial. Firefox no se ejecutó porque su binario no estaba instalado. La muestra ilustra por qué conviene registrar versión y configuración, en lugar de resumir la compatibilidad con un «sí» para toda una familia. Para repetir un ensayo local, Chrome documenta la opción específica chrome://flags/#enable-webmcp-testing; el laboratorio descargable registra la opción más amplia que utilizó.

Las dos formas de ofrecer herramientas no tienen el mismo estado

La API imperativa permite definir herramientas en JavaScript mediante document.modelContext. La vía declarativa añade atributos a formularios HTML para que el navegador describa sus campos como parámetros. La primera está en el borrador principal; la segunda sigue desarrollándose en un documento separado, aunque Chrome permita experimentar con ambas. Propuesta declarativa.

En la variante de formularios probada, el navegador rellenó los campos y esperó al envío manual cuando faltaba toolautosubmit. Con ese atributo, pudo completar la operación sin pulsar el botón. Es una diferencia de producto relevante: facilitar que se prepare una solicitud y permitir que se envíe directamente requieren decisiones distintas. API declarativa de Chrome.

El asistente también tiene que ser compatible

Que un asistente navegue o acepte conexiones MCP no demuestra que consuma WebMCP. Debe existir una integración que lea las herramientas de la página, las incorpore a su contexto y devuelva sus resultados. La documentación de Chrome ofrece extensiones para inspeccionar y probar herramientas y aclara que son distintas de Gemini en Chrome. Herramientas de prueba y limitaciones.

Hay integraciones que ya concretan esa diferencia. OpenAI documenta Site tools para ChatGPT Work y Codex en el navegador integrado de ChatGPT Desktop: descubre herramientas JavaScript de la página principal, pero no las declarativas ni las registradas en iframes. La disponibilidad depende del despliegue, la aplicación y el modelo; la guía indica GPT-5.6 Sol o GPT-6 Sol. En Enterprise requiere habilitación administrativa y en espacios Edu no está disponible. Son límites especialmente relevantes para una plataforma educativa. Documentación oficial de OpenAI sobre Site tools.

Por tanto, un formulario que el laboratorio de Chrome descubre puede quedar fuera del alcance de ese consumidor. El catálogo del proyecto también registra la integración experimental de Brave con Leo. Ninguna de estas referencias equivale a haber probado aquí esos asistentes ni permite extender su compatibilidad a toda la API.

Para un producto, la comprobación útil consiste en completar la tarea con el navegador, el canal, la cuenta y el asistente que utilizará su público. Comprobar que existe document.modelContext es un primer paso. Conviene mantener una experiencia manual completa para quienes no dispongan de ese recorrido.

Cómo encaja con MCP, las API y la automatización del navegador

WebMCP puede convivir con una API de servidor y con MCP. La diferencia principal está en el lugar desde el que se ofrece la capacidad y en el contexto que necesita el trabajo. Registrar una herramienta en una página no publica automáticamente un servicio MCP compatible con cualquier cliente. Relación entre WebMCP y MCP.

Una plataforma puede reutilizar las reglas de negocio detrás de varias de estas entradas. Por ejemplo, el cambio de fecha de una actividad debe obedecer las mismas restricciones tanto si se solicita desde un botón como desde una herramienta. La integración concreta cambia; el permiso para alterar la actividad y el significado de la fecha deben conservarse.

La elección tampoco tiene que ser exclusiva. Un asistente podría usar una herramienta para preparar un cambio y recurrir después a la interfaz para que el usuario lo revise. Un proceso nocturno de sincronización, en cambio, encaja mejor en una operación de servidor que pueda ejecutarse, recuperarse y auditarse sin depender de un documento abierto. El artículo sobre MCP y Moodle desarrolla esa segunda arquitectura.

Qué podría cambiar en un campus o una plataforma educativa

En un campus, el estado de trabajo importa: qué curso está abierto, qué actividad se edita, qué grupo se consulta y qué versión está viendo el docente. Una interacción en lenguaje natural resulta más útil cuando puede apoyarse en ese contexto y dejar su resultado dentro del lugar donde la persona ya está trabajando.

Un recorrido posible sería pedir: «Prepara un aviso para este grupo con los recursos que necesita antes de la próxima sesión». La plataforma tendría que ofrecer consultas autorizadas sobre calendario y materiales, y una operación que compusiera la propuesta. El docente vería el curso, el grupo, los enlaces y el texto antes de decidir el envío. WebMCP facilitaría el acceso del agente a esas operaciones; la aplicación construiría el recorrido y conservaría sus reglas.

La propuesta debería quedar vinculada al curso y al grupo para los que se preparó. Si entre la preparación y la confirmación cambia el contexto de la página, alguien modifica los recursos o la sesión pierde permisos, la aplicación debe volver a comprobar el destino y la vigencia de la propuesta antes de enviarla. Tomar sin más «el curso abierto ahora» puede aplicar una propuesta correcta en un lugar equivocado. La revisión necesita mostrar el contenido y el alcance de la acción, y el servidor debe rechazar una confirmación que ya no sea válida. Este es un requisito del diseño propuesto; el laboratorio no prueba su implementación en un servidor.

La misma idea podría aplicarse a preparar una reorganización de recursos o una propuesta de fechas. La ventaja potencial consiste en traducir una intención a cambios concretos sin obligar al usuario a describir cada control de la interfaz. Para que la propuesta sea útil, la plataforma tiene que detectar conflictos y mostrar qué va a cambiar. Si guarda los cambios antes de ofrecer una revisión, la persona tendrá que corregir una interpretación equivocada cuando ya haya producido su efecto.

La preparación y la ejecución necesitan alcances distintos. Consultar la estructura de un curso no concede acceso a las entregas de sus participantes; preparar un mensaje tampoco autoriza enviarlo a cualquier grupo. Si la operación utiliza Moodle, el servidor debe validar parámetros, contexto y permisos, como exige su API externa.

El artículo plantea estos ejemplos como un diseño posible; no se han comprobado en una instalación Moodle. El laboratorio que lo acompaña preparó una vista previa con datos sintéticos. Su alcance permite estudiar el mecanismo, sin acreditar una mejora del aprendizaje, de la adopción o del tiempo de trabajo en un campus real.

Si el campus integra una actividad o un asistente mediante un iframe de otro origen, hay además una condición de arquitectura. La política tools regula si ese marco puede registrar herramientas; compartirlas entre orígenes requiere también configurar su exposición y descubrimiento. El laboratorio comprobó esas restricciones de forma aislada. Un consumidor que no descubre herramientas en iframes, como Site tools, seguirá teniendo ese límite aunque el navegador permita registrarlas. La ubicación de la integración forma parte de la compatibilidad.

Para un primer piloto elegiría la preparación de un aviso que pueda inspeccionarse y corregirse antes del envío. Ampliaría el alcance a operaciones con efectos después de comprobar cómo se resuelven los cambios de contexto y las interpretaciones equivocadas. El marco de plataformas preparadas para agentes permite valorar esa preparación más allá del mecanismo de conexión.

Qué problemas seguirían existiendo aunque la conexión funcionase

El agente sigue interpretando nombres y descripciones. Una herramienta llamada «finalizar» puede significar guardar un borrador o producir una operación irreversible. Un esquema tipado ayuda a describir los argumentos, pero no fija por sí solo la intención de la persona ni la correspondencia entre lo anunciado y lo ejecutado.

Las pruebas realizadas para este análisis permitieron observar fallos que una integración tiene que contemplar. Esta selección relaciona el resultado del laboratorio con la decisión de aplicación que exige:

El tercer resultado tiene una consecuencia fácil de pasar por alto. Si el usuario ve una cancelación y vuelve a intentarlo, la primera operación puede seguir trabajando. Para un envío real, el servidor tendría que reconocer una repetición de la misma solicitud y devolver su estado sin publicar otro aviso. Esa propiedad, la idempotencia, requiere una decisión de aplicación; no se ensayó con persistencia en este laboratorio. La cancelación tampoco equivale a deshacer un cambio ya aplicado.

Las anotaciones ayudan al agente a interpretar el riesgo. El consentimiento, la autorización y la recuperación deben concretarse en el recorrido de producto y en sus operaciones. El consumidor puede añadir sus propios controles; una invocación directa no reproduce las políticas de un asistente integrado. Guía de seguridad de herramientas.

También puede haber instrucciones maliciosas en una descripción o en los datos devueltos. Un agente que conecta información de varios orígenes necesita distinguir esa información de las instrucciones del usuario y limitar dónde puede actuar o enviar datos. La existencia de una sesión válida no resuelve ese problema. Seguridad para agentes.

El laboratorio conserva 27 comprobaciones nativas en Chrome, junto con el ensayo de compatibilidad por versiones. Sirven para contrastar el mecanismo y sus límites. No evaluaron un modelo eligiendo herramientas ni midieron una mejora porcentual frente a manejar la interfaz. El código y los resultados se pueden descargar para repetirlos con la configuración registrada.

Qué futuro se está discutiendo

La propuesta apunta a una web que pueda ofrecer operaciones comprensibles para distintos consumidores, además de mostrar información y controles a las personas. Su evolución dependerá de acuerdos sobre contratos, consentimiento e interoperabilidad. En el repositorio hay líneas concretas de trabajo que ayudan a entender esa dirección; no constituyen un calendario de lanzamientos.

Una de ellas es describir mejor lo que devuelve una herramienta. Un contrato de salida podría distinguir una propuesta pendiente, una operación completada y un error con información suficiente para recuperarse. Ayudaría a que los clientes no tuviesen que interpretar formatos propios de cada sitio. La discusión sobre outputSchema sigue abierta. Que exista la propuesta no permite atribuir esa garantía a la API ensayada.

Otra línea busca una interacción más continua. El envío progresivo de argumentos permitiría explorar cómo mostrar una composición mientras el modelo la produce, en lugar de esperar a disponer de todos los datos. Tiene interés para editores y tareas largas, pero obliga a distinguir lo provisional de lo que ya se ha aplicado. La respuesta de herramientas que navegan a otro documento plantea una continuidad distinta: cómo seguir el resultado cuando la página de origen desaparece.

La extensión a service workers, código que el navegador puede ejecutar en segundo plano para atender determinadas tareas de una web, llevaría la idea más lejos. El documento complementario estudia que un sitio pueda ofrecer herramientas sin mantener su página abierta, con mecanismos de descubrimiento y posibles intervenciones del usuario cuando hicieran falta. Ese recorrido ampliaría las oportunidades de automatización y también cambiaría la relación entre visibilidad y control. Antes de confiarle una acción habría que resolver qué se autorizó, durante cuánto tiempo, cómo se revoca y cómo se informa de lo ocurrido. Es una propuesta para trabajo en segundo plano, ajena a lo demostrado por el laboratorio.

El futuro de producto dependerá de quién conserve el control

Si esta dirección se consolida, un usuario podría expresar objetivos y alternar entre conversación y manipulación directa de la aplicación. El agente prepararía parte del recorrido; la interfaz mostraría el estado y permitiría corregirlo. En ese escenario, el diseño de producto tendría que definir con más cuidado qué constituye una operación completa y qué parte puede delegarse.

Para los equipos de desarrollo, una posible consecuencia sería dar tanta importancia al contrato de esas operaciones como a los componentes visuales. Una función reutilizada por la interfaz y por agentes puede reducir divergencias. También puede crear otra superficie que mantener si cada vía acaba implementando sus propias reglas. Esta es una consecuencia de arquitectura que cabe anticipar, no una mejora de mantenimiento ya medida.

La discusión con WebKit señala una dificultad más profunda. Su oposición cuestiona la conveniencia de una capa específica para agentes frente a mejorar la semántica compartida de HTML y accesibilidad. También advierte del riesgo de tratar de forma distinta a quien utiliza un agente y a quien no. Posición y argumentos de WebKit.

Esa objeción influye en cómo adoptaría la tecnología. La interfaz accesible debe seguir permitiendo completar las mismas operaciones; el usuario debe poder reconocer y corregir los cambios. Si la mejor forma de utilizar un servicio exige un agente concreto o esconde sus efectos en una conversación, el producto pierde parte del control compartido que hacía atractiva la propuesta.

Mi lectura es que WebMCP merece atención porque intenta normalizar una relación que ya empieza a ser necesaria: cómo puede una aplicación ofrecer sus capacidades a quien actúa por cuenta del usuario. Su adopción general, su forma definitiva y su capacidad para mejorar tareas concretas siguen abiertas. El indicador relevante será que más personas puedan completar mejor su trabajo con el mismo control sobre lo que ocurre.

Qué haría hoy en un producto que quiere prepararse

Antes de invertir en la conexión, comprobaría qué hace costosa la tarea actual. Si el docente prepara el mismo aviso cada semana, una plantilla con el grupo y los enlaces correctos puede resolver gran parte del trabajo. WebMCP merece un piloto cuando la petición varía y obliga a combinar contexto y operaciones que un agente compatible puede utilizar. Si el problema está en datos incompletos o permisos mal resueltos, esas carencias seguirán condicionando el resultado.

En el ejemplo del campus, acotaría el piloto a preparar el aviso con datos sintéticos o de prueba, sin enviarlo. Compararía esa tarea con la vía habitual hasta que el docente considerase aceptable el borrador. Además del tiempo, registraría correcciones de contenido, errores al elegir curso y grupo y enlaces que hubiera tenido que sustituir. Si preparar el texto resulta más rápido pero verificarlo añade más trabajo del que se ahorra, la tarea completa no ha mejorado.

Las incidencias servirían para decidir dónde intervenir. Un destino equivocado exige revisar cómo se conserva el contexto; una buena propuesta que no ahorra trabajo puede justificar mejorar la interfaz o la plantilla. Pasar al envío requeriría otro ensayo sobre autorización, cambios de estado, repetición de solicitudes y recuperación. El responsable del producto decidiría si el resultado compensa mantener la integración con la evidencia del equipo técnico y de quienes realizan la tarea.

Mantendría la operación compartida y la vía manual para que la mejora conserve utilidad si cambia la API. Si el público depende de un consumidor que no admite la integración necesaria, aplazaría esa conexión. Si el piloto mejora la tarea y sus errores se pueden detectar y recuperar, habría una razón para ampliarlo. El estado experimental aconseja una inversión acotada y reversible, cuya continuidad dependa de esos resultados.

Si estás valorando qué podría delegar un agente en tu aplicación o campus, puedes plantearme en términos generales la tarea y las decisiones que debe conservar el usuario. El análisis útil empieza por ese recorrido: qué permitiría hacer, con qué compatibilidad y qué condiciones harían razonable llevarlo a producción.