InfoQ publicó el 10 de agosto su artículo sobre la vista previa WebMCP de Cloudflare. El anuncio canónico de Cloudflare está fechado el 6 de agosto y figura como actualizado el 10 de agosto. La fuente primaria describe un solo interruptor en Agent Readiness > WebMCP. Una vez activado, Cloudflare usa HTMLRewriter en el borde para inyectar en cada respuesta HTML una referencia del mismo origen a /.webmcp/bridge.js. El puente encuentra la interfaz propuesta del navegador document.modelContext, reúne los paquetes habilitados y registra herramientas con nombre y esquemas de entrada. Si el navegador no ofrece la interfaz, Cloudflare dice que el puente se detiene sin cambiar el comportamiento de la página. No hay que modificar el código de la aplicación en el servidor de origen.

La vista previa comienza con 2 paquetes. Según Cloudflare, Content Credentials lee los primeros kilobytes de metadatos de procedencia C2PA de las imágenes, pero no verifica criptográficamente las firmas y devuelve signatureVerified: false. El paquete Site MCP Server descubre las herramientas de un servidor existente mediante tools/list. Su proxy envía tools/call al endpoint del mismo origen /mcp con las credenciales configuradas como same-origin, por lo que usa la sesión existente del visitante. Cloudflare afirma que cada herramienta actual se ejecuta en el navegador del visitante sin un viaje de ida y vuelta a un servidor de Cloudflare. Eso evita entregar al agente una clave de API del backend. También convierte al navegador autenticado en una frontera activa de autoridad: una interfaz más limpia no vuelve segura por sí sola una acción con consecuencias.

Para quienes construyen agentes, el cambio sustantivo es el contrato. Cloudflare e InfoQ describen con claridad el ciclo actual: la automatización visual del navegador gasta tokens interpretando diseños, puede entender mal un control y suele romperse cuando un sitio cambia su interfaz. Una herramienta con nombre y un esquema de entrada JSON acota la acción y el resultado esperado. Igual de importante, una llamada estructurada puede distinguir entre una herramienta ausente, un error de ejecución y un resultado vacío válido. Un cliente que vuelve silenciosamente al scraping recrea la ambigüedad y puede presentar una llamada fallida como si no hubiera nada nuevo. WebMCP reduce una clase de fragilidad solo cuando los clientes mantienen separados esos estados.

Para los editores, la misma maquinaria es una superficie de control. Cloudflare permite que el propietario del sitio seleccione paquetes y active más después sin volver a desplegar el servidor de origen. La documentación de Chrome dice que WebMCP exige un documento aislado por origen y que la política de permisos tools usa self de forma predeterminada, lo que bloquea el acceso desde un iframe de otro origen salvo autorización explícita. Son límites reales. Pero el menú del sitio está curado: un editor puede exponer una acción útil, omitir otra y moldear cómo un agente percibe el servicio. Legible por máquinas no significa completo ni neutral. Significa una superficie negociada y controlada por el origen.

Esto no debe leerse como un estándar de navegador disponible en todas partes. Las fuentes se contradicen sobre las versiones. Cloudflare llama a WebMCP experimental en Chrome 146. InfoQ dice Chrome 145+. La documentación de Chrome, actualizada el 7 de agosto, dice que su prueba de origen comienza con Chrome 149 y que las pruebas locales requieren una bandera. Esos números no pueden describir todos la misma disponibilidad. En conjunto, las fuentes solo respaldan que WebMCP sigue siendo una propuesta, exclusiva de Chrome y sujeta a cambios. La web legible por máquinas llega aquí como un contrato opcional entre sitio, navegador y agente, no como un reemplazo universal de HTML.