Esta semana Apple ha metido un servidor MCP nativo en Safari Technology Preview 247. Chrome lleva meses empujando WebMCP. Y mientras lees esto, seguro que tienes un cliente que aún no ha migrado a HTTPS bien configurado. Bienvenido al 2026: te piden preparar la web para agentes de IA antes de que la mayoría de usuarios sepa qué es un agente.
Lo de Safari no es un rumor de foro. TechTimes recoge el anuncio de WebKit: cualquier agente que hable MCP — Claude, Codex, Gemini, lo que venga — puede conectarse a una ventana activa de Safari, leer el DOM en vivo, sacar logs de consola, capturar pantalla y ejecutar JavaScript en la pestaña abierta. Diecisiete herramientas documentadas. Sin pasar por la nube de Apple.
A la par, Google y Microsoft empujan WebMCP, un borrador en el W3C que ya apareció en Chrome 146 y que en junio pasó a un origin trial público en Chrome 149. La idea: tu web registra herramientas tipadas — con nombre, esquema JSON y función execute — para que un agente las llame directamente en lugar de raspar el HTML como un scraper de 2012. Rohit Raj lo resume bien: no sustituye MCP de backend, complementa la pestaña viva del navegador.
En papel suena elegante. En la práctica me suena a otro estándar que llega antes de tiempo y con la factura mal repartida.
El problema de fondo: dos vías, cero consenso
Apple apuesta por MCP en Safari: el agente se conecta al navegador y opera sobre lo que ya está renderizado. Google apuesta por WebMCP: la web expone contratos de herramientas antes de que el agente toque nada. Son filosofías distintas. Una externaliza la inteligencia al agente que ya tienes en el IDE; la otra te obliga a ti, desarrollador, a definir qué puede hacer un bot sobre tu dominio.
OpenHermit calcula mejoras brutales de eficiencia frente a métodos basados en capturas de pantalla. Vale. Pero Firefox y Safari participan en el grupo comunitario del W3C sin haber comprometido implementación completa de WebMCP, mientras Apple ya ha soltado su propio servidor MCP en paralelo. ¿Te suena? Me suena a la guerra de PWA, a AMP, a «primero lo hacemos en Chrome y luego vemos».
Y aquí está lo que me molesta de verdad: quien vende hosting, themes o consultoría va a empezar a decirte que tu web «no es agent-ready» como si fuera un nuevo Core Web Vitals. Spoiler: no lo es. Todavía no hay tráfico real de agentes consumiendo esas herramientas en producción masiva. Lo que hay es especificación en movimiento, flags de Chrome y previews de Safari para early adopters.
Quién paga la fiesta (spoiler: tú)
Implementar WebMCP no es meter un meta tag y olvidarte. Tienes que definir esquemas, validar entradas, decidir qué acciones requieren confirmación humana y mantener eso cada vez que cambies el checkout, el buscador o el formulario de contacto. Rohit Raj lo advierte explícitamente: cualquier herramienta que cambie estado debe ir detrás de confirmación. Bien dicho. Mal repartido si eres una pyme con un WordPress y un plugin de reservas que ya te da guerra cada martes.
El enfoque de Safari es distinto pero no más barato en todos los casos. Facilita que un agente de coding pruebe tu web en el navegador real — genial para quien desarrolla con Copilot o Claude Code. Pero abre preguntas incómodas: ¿quién autoriza que un agente haga clic en «Confirmar pedido» en una sesión con cookies activas? ¿Qué pasa cuando el agente ejecuta JavaScript en una pestaña donde el usuario tiene una sesión bancaria abierta en otra? Apple dice que el servidor MCP corre localmente. Me calma un poco. No me calma del todo.
Porque el mercado no va a esperar a que tú medites. Van a llegar plugins de «Agent Ready en un clic», agencias que te cobran auditoría de /.well-known/mcp.json y comparativas de quién tiene más herramientas registradas que nadie va a invocar este trimestre. Lo he visto con GDPR mal implementado, con accesibilidad maquillada y con «optimización para IA» que era solo añadir un bloque de schema.org genérico.
Lo que sí me parece sensato (y lo que no)
No niego el vector. Si los agentes van a navegar webs — y Visa ya está metiendo pagos iniciados por agentes, lo conté hace unos días en otro post — tiene sentido que no dependan de OCR sobre capturas para rellenar un formulario. WebMCP, bien hecho, reduce fricción y errores. Safari MCP en el flujo de desarrollo puede ahorrar horas de «abre DevTools, copia el error, pégalo en el chat».
Pero la narrativa dominante ahora mismo es de urgencia artificial. Chrome 149 en origin trial no significa que tu cliente de turismo rural en Asturias pierda reservas en julio porque no expone document.modelContext. Significa que Google quiere datos de implementación real antes de congelar la API — y que quien se mueva primero tendrá ventaja si esto despega en 2027 o 2028.
Mi consejo, si me preguntas en el pasillo de un evento: no ignores el tema, pero tampoco metas WebMCP en producción sin due diligence. Lee la spec. Prueba en entorno de staging con el token del origin trial si tienes equipo front. Registra herramientas de solo lectura primero — consultar stock, buscar producto — antes de dejar que un agente modifique carritos. Y desconfía de quien te venda esto como obligatorio mañana.
También vigila el detalle técnico que cambia entre versiones: navigator.modelContext deprecado desde Chrome 150 en favor de document.modelContext. Un rename que te come una tarde si copiaste el tutorial de febrero sin mirar la fecha.
El elefante en la habitación: ¿para quién es esto?
Hoy esto es herramienta para developers con flujos agentic en el IDE y para SaaS grandes que quieren que los asistentes reserven, comparen o configuren cosas sin integración API clásica. No es, todavía, infraestructura que tu fontanero digital necesite el lunes.
Apple cubriendo Xcode con MCP y Safari con MCP a la vez es interesante: controlan el ciclo completo de quien programa para web en su ecosistema. Google empujando WebMCP desde el navegador es interesante: controlan cómo las webs se anuncian a agentes que probablemente correrán sobre Chromium de todos modos. Ninguno te está regalando esto por filantropía. Te están posicionando dentro de su grafico de herramientas.
Y mientras tanto, el 76% de developers usa IA según las encuestas que repiten todos los blogs — lo leí otra vez esta semana — pero el 40% del código generado sigue llevando vulnerabilidades que alguien tiene que auditar a mano. Antes de registrar doce herramientas MCP en tu e-commerce, ¿has revisado quién puede ejecutar SQL a través del endpoint de búsqueda que lleva tres años sin parchear? Prioridades.
WebMCP y Safari MCP van a formar parte del mapa. Lo tengo claro. Lo que no tengo claro es que merezca la pena ser early adopter pagando de tu bolsillo cuando el estándar aún se mueve, el tráfico de agentes es marginal y el sector ya te vendió tres «revoluciones» que acabaron en un plugin abandonado.
Esperaré a ver quién implementa qué en stable, qué exige realmente el tráfico de agentes comerciales y si esto converge o se queda en dos vías incompatibles. Mientras, seguiré recomendando HTTPS, backups y que no metas un chatbot en el footer solo porque sí.
Si mañana tu proveedor de hosting te subiera la cuota un 15% a cambio de dejarte «certificado agent-ready» con WebMCP preinstado en WordPress, ¿lo pagarías antes de saber cuántas visitas reales vienen de agentes — o preferirías invertir ese dinero en arreglar el checkout que se cae en móvil?