Los agentes que operan sitios mediante la interfaz visual deben percibir la página, localizar controles e inferir qué acción producirá el resultado deseado. Ese camino es necesario cuando el sitio solo ofrece una interfaz humana. También es costoso: cada etapa puede involucrar una imagen, una representación extensa del DOM, un intento de clic y otra verificación.
WebMCP propone una capa adicional. El borrador publicado por el Web Machine Learning Community Group permite que las aplicaciones web registren herramientas JavaScript que los agentes pueden descubrir y ejecutar. En vez de interpretar un botón y su entorno, el agente recibe una capacidad con nombre, descripción, parámetros y resultado.
El cambio parece pequeño en la API y grande en la arquitectura. El sitio deja de ser solamente una superficie para automatización y comienza a declarar cómo quiere ser operado.
Los contratos superan la percepción en tareas estructuradas
Una interfaz visual lleva información útil para las personas: posición, jerarquía, color, texto y feedback. Para un agente que ya conoce la intención, parte de eso es ruido. Si la tarea consiste en añadir un producto al carrito, consultar un pedido o guardar una preferencia, una función bien definida puede representar la operación con mucho menos contexto.
Esa reducción no debe convertirse en una promesa universal de ahorro. El coste depende del modelo, del sitio, de la herramienta y de la tarea. La especificación define cómo exponer capacidades; no garantiza un porcentaje fijo de tokens para cualquier flujo.
El argumento sólido es estructural. Un esquema compacto suele exigir menos interpretación que una página completa. También resiste mejor los cambios cosméticos. Modificar clases CSS o mover un botón puede romper una automatización visual, mientras una herramienta con contrato estable sigue funcionando.
La interfaz humana continúa siendo necesaria
WebMCP atiende acciones que pueden describirse como operaciones. No reemplaza la observación visual cuando una decisión depende de composición, legibilidad, confianza o comparación subjetiva. Un agente puede usar una herramienta para enviar datos y todavía necesitar mirar la página para verificar cómo se presentó el resultado.
También existen tareas exploratorias en las que el usuario aún no sabe qué operación necesita. Navegar, leer y formar una intención son parte del trabajo. Exponer cientos de funciones para cubrir cualquier posibilidad recrearía en el catálogo de herramientas el exceso de contexto que la propuesta intenta reducir.
La división útil consiste en mantener la percepción para descubrir y verificar, usando capacidades explícitas para ejecutar operaciones conocidas.
El contrato se convierte en una superficie de seguridad
Una herramienta disponible para agentes necesita los mismos controles de cualquier API sensible. Autenticación, autorización, validación de entrada, confirmación de acciones irreversibles y límites de uso siguen siendo obligatorios. Que la llamada ocurra en el navegador no hace segura la operación.
La agencia introduce otro problema. Una persona puede autorizar a un agente a trabajar en un sitio, pero eso no significa que toda acción deba ocurrir sin revisión. Las operaciones de lectura tienen un riesgo distinto de compras, eliminaciones, mensajes o cambios de cuenta. El sitio debe exponer esa diferencia claramente y preservar la confirmación cuando el coste del error es alto.
Las descripciones de herramientas forman parte del límite de confianza. Un nombre ambiguo o un parámetro permisivo puede inducir un uso indebido incluso sin ataque. Los contratos pequeños facilitan la revisión cuando también son específicos.
La especificación sigue en desarrollo
En septiembre de 2026, la especificación se presenta como Draft Community Group Report. Declara explícitamente que no es un estándar del W3C ni se encuentra en el Standards Track. Ese estado cambia la decisión de adopción.
Un equipo puede experimentar con un flujo aislado, medir coste y aprender a diseñar capacidades. No debería convertir el borrador en una dependencia central sin considerar cambios de API, soporte de navegadores e interoperabilidad entre agentes.
El mejor piloto tiene una acción reversible, un contrato limitado y una alternativa funcional mediante la interfaz existente. Así, el experimento produce datos sin bloquear a los usuarios o automatizaciones actuales.
Cómo evaluar la ganancia real
Compara dos recorridos para la misma tarea. En el primero, el agente navega visualmente. En el segundo, descubre y llama una herramienta WebMCP. Registra tokens, latencia, fallos, confirmaciones y calidad de la verificación final.
El resultado puede mostrar que la ejecución se volvió barata mientras el descubrimiento siguió costoso. Puede mostrar menos errores o revelar que la herramienta expone demasiada autoridad. Esos datos orientan el diseño mejor que un benchmark tomado de otro sitio.
WebMCP señala un cambio plausible: los sitios pueden tener una interfaz para personas y una capa operativa para agentes. Su valor aparece al reservar percepción para las decisiones que la necesitan y usar contratos explícitos donde ya existe una operación clara.
El coste de mantenimiento también pertenece a la comparación. Una herramienta abandonada o un contrato divergente de la interfaz pública crea otra forma de ruptura. El experimento solo gana cuando la capacidad explícita recibe tanto cuidado como la acción visible que representa.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
