WebKit lanza un servidor MCP para Safari con 17 herramientas de depuración

El proyecto WebKit ha publicado un servidor MCP oficial para Safari que expone 17 herramientas de depuración a agentes de IA, según recoge PPC Land este 5 de julio. Con este movimiento, el motor de Apple entra por fin en un terreno donde hasta ahora mandaba Chromium: el de los agentes de programación capaces de inspeccionar un navegador real mientras escriben y corrigen código.

La pieza que faltaba no era pequeña. MCP (Model Context Protocol), el estándar abierto que Anthropic presentó a finales de 2024, se ha consolidado como la vía habitual para que modelos como Claude usen herramientas externas: navegadores, bases de datos, APIs internas. Que el propio equipo de WebKit mantenga un servidor MCP significa que un agente puede depurar Safari con soporte de primera mano, sin puentes de terceros ni automatizaciones frágiles montadas encima de WebDriver.

Qué ha llegado exactamente

Según PPC Land, el servidor incluye 17 herramientas orientadas a agentes de depuración. El patrón que estableció chrome-devtools-mcp, el servidor equivalente que Google publicó para Chrome DevTools en septiembre de 2025, pasa por exponer las capacidades del inspector del navegador: leer la consola, inspeccionar el DOM, observar peticiones de red o ejecutar JavaScript en la página abierta. Lo relevante aquí no es tanto el catálogo concreto como la firma: es el propio proyecto WebKit, el motor de código abierto sobre el que Apple construye Safari, quien asume el desarrollo y el mantenimiento de la integración.

Para quien trabaja con Claude Code, la mecánica es la habitual con cualquier servidor MCP: se registra en la configuración (claude_desktop_config.json en Claude Desktop, o con el comando claude mcp en la CLI) y sus herramientas quedan disponibles para el agente, que decide cuándo invocarlas durante la sesión de trabajo.

Por qué Safari era el eslabón que faltaba

Hasta ahora, el flujo de agente que programa y verifica en navegador estaba resuelto casi en exclusiva sobre Chromium. Google mantiene su servidor MCP para Chrome DevTools y Microsoft hace lo propio con Playwright MCP para automatización. El resultado práctico: muchos equipos verificaban sus cambios solo en Chrome, y Safari quedaba como asignatura pendiente que se revisaba a mano, cuando se revisaba.

Y Safari no es un navegador cualquiera. En iOS, WebKit sigue renderizando la inmensa mayoría del tráfico web, también dentro de navegadores de terceros. Los bugs específicos de WebKit, desde comportamientos peculiares de CSS hasta APIs con soporte parcial, son un clásico en cualquier equipo front-end. Un agente que solo ve Chromium es un agente ciego a una parte sustancial de los problemas que aparecen en producción.

Para quién es útil

Los primeros beneficiados son los equipos front-end y de QA que ya trabajan con agentes: ahora pueden pedir a Claude Code que reproduzca un bug en Safari, inspeccione qué está ocurriendo y verifique el arreglo en el mismo motor donde se manifestaba el fallo. También gana el ecosistema de subagentes y plugins de Claude Code: un subagente de verificación multiplataforma deja de ser una idea teórica y pasa a ser un archivo de configuración más en el repositorio.

Para quien construye integraciones hay una lectura adicional. Los fabricantes de navegadores están tratando MCP como superficie oficial de producto, no como un experimento de la comunidad: primero Google con Chrome DevTools, ahora el proyecto WebKit con Safari. Cuando los motores dominantes del mercado documentan y mantienen sus propios servidores, apostar por MCP como capa de integración deja de ser una decisión arriesgada y pasa a ser el camino por defecto.

En ElephantPink llevamos meses montando pipelines en los que el agente no da por cerrada una tarea hasta verla funcionar en un navegador real, y la ausencia de WebKit era la excusa habitual para dejar Safari fuera del circuito. Que esa pieza llegue firmada y mantenida por el propio proyecto es de esas noticias que hacen poco ruido y cambian rutinas de trabajo.