Chrome DevTools Protocol + Claude Code: El Patrón que Equipos Open Source Tardaron Años en Perfeccionar
Lo admito: la curiosidad es tanto un defecto como una virtud en mi caso.
Cada app que usas a diario puede hacer más de lo que te muestran. A menudo hay funciones beta ocultas tras una bandera, endpoints no documentados, ejecutándose, respondiendo en silencio.
Apunté Claude Code a una instancia local de Ghost con Chrome DevTools como servidor MCP. En una tarde, el agente encontró 27 endpoints que la documentación oficial no menciona por ningún lado. Estadísticas detalladas de miembros, un registro de auditoría completo, una exportación de base de datos en una sola llamada. Todo eso estaba ahí. Desde el principio.
Hablo de Ghost aquí, pero lo que importa es que el método funciona con cualquier app (incluyendo las comerciales...). Y lo que solía tomar semanas a los obsesivos detrás de yt-dlp, ahora un dev solitario con un agente lo hace entre el café y el almuerzo.
TL;DR: Agentes de IA + Chrome DevTools convierten la ingeniería inversa de APIs internas en un proceso reproducible de una sola vez. 27 endpoints no documentados encontrados en Ghost en una tarde, wrapper tipado + tests incluidos. El método funciona con cualquier herramienta. Así es como.
Advertencia justa: experimentos en software open-source que ejecuto localmente. ¿Herramientas propietarias? Revisa los TOS primero. Comparto un método, no consejo legal.
La Documentación Es el Menú Infantil
Estás en un restaurante y te dan el menú infantil. Seis platos, letras grandes, dibujos de pollitos felices. Mientras tanto, la cocina maneja una carta completa de 40 platos con cosas que realmente querrías pedir. Nadie te lo está ocultando. Simplemente asumieron que no preguntarías.
Eso es la documentación de aplicaciones. Una selección curada, no un inventario técnico.
Tres fuerzas la mantienen así. Funciones que no están "listas" para consumo público pero ya funcionan internamente (la UI de admin las usa, tú simplemente no puedes). Capacidades restringidas a niveles premium que técnicamente responden a cualquiera que toque el endpoint correcto. Y cosas que el equipo construyó para sus propias operaciones y nunca se molestó en documentar porque no estaban pensadas para ti.
Para ser justos con los proveedores, hay una razón sólida para esto. Cada endpoint que pones en los docs se convierte en un contrato implícito de estabilidad. Rómpelo, y mil desarrolladores abren un issue en GitHub antes de que termines tu café matutino. Así que los equipos documentan la superficie mínima viable y siguen adelante. Eso no es malicioso. Simplemente es caro hacer lo contrario.
Los docs te muestran lo que quieren que uses. No lo que la app puede hacer.
Los Obsesivos Que Vinieron Antes Que Nosotros
Antes de que los agentes entraran en escena, la ingeniería inversa de APIs internas ya era una cosa. Una cosa gloriosa, dolorosa y que consumía mucho tiempo.
Considera yt-dlp. Cientos de contribuyentes manteniendo una pieza de software cuyo único propósito es entender la API interna de YouTube. Cada vez que Google cambia algo (que es constantemente, a veces aparentemente por despecho), alguien tiene que descifrar el nuevo flujo, parchearlo, enviarlo. Funciona. Pero también es un proyecto de tiempo completo para un pequeño ejército de voluntarios.
Luego estaba Nitter. Un hermoso frontend alternativo de Twitter construido enteramente sobre endpoints de ingeniería inversa. Funcionó genial, hasta que Elon bloqueó las APIs y se acabó. Años de trabajo, desaparecidos en un cambio de política. Recuerda ese, vuelve más tarde.
Estos proyectos probaron algo importante: las capacidades no documentadas son reales, útiles, y la gente construirá cosas notables encima de ellas. Pero el costo era absurdo. Semanas de inspección manual de tráfico. Experiencia profunda en protocolos. Mantenimiento constante contra objetivos móviles. Era un deporte para obsesivos (recuerdo debuggear juegos en ASM en Amstrad CPC, así que entiendo el atractivo, pero aún así).
yt-dlp tiene cientos de contribuyentes para mantener un solo esfuerzo de ingeniería inversa. Yo necesité cero.
Un Agente de IA Acaba de Colapsar Semanas en Minutos
El cambio fundamental no es sobre mejores herramientas. Es sobre quién hace el trabajo de exploración.
Aquí está la configuración técnica. Chrome DevTools Protocol (CDP) expone todo lo que el navegador sabe: árbol DOM, solicitudes de red, salida de consola, métricas de rendimiento. Normalmente interactúas con él a través de la GUI de DevTools o vía automatización estilo Puppeteer. Un servidor MCP envuelve CDP en un protocolo que los agentes de IA hablan nativamente. El agente obtiene tres capacidades que importan aquí: javascript_tool (ejecutar JS arbitrario en el contexto de la página, incluyendo llamadas fetch() con las cookies de sesión activas), computer (esperar, hacer clic, navegar), y acceso a toda la cascada de red.
Esa combinación es lo que cambia el juego. El agente no solo lee sobre APIs. Hace llamadas en vivo dentro de una sesión autenticada, inspecciona las respuestas, e itera. Todas las cosas que harías manualmente con la pestaña Network abierta, excepto que el agente lo hace sistemáticamente y no se aburre después del endpoint número siete.
Google enviando Chrome DevTools como un servidor MCP oficial en marzo de 2026 es lo que hace que esto no sea un hack sino un flujo de trabajo soportado. La empresa que construye el navegador decidió que dar a los agentes de IA acceso en vivo al DOM, la pestaña de red, y la consola valía la pena mantener. Esa es una señal de la industria, no un experimento comunitario.
Antes de esto, los agentes eran esencialmente ciegos al comportamiento en tiempo de ejecución. Podían leer documentación, generar código, llamar APIs conocidas. Pero no podían observar lo que una aplicación realmente hace en el cable. Ahora pueden. El agente lee el tráfico, no los docs. En open source, ese es tu derecho fundamental. En software propietario, tu millaje de TOS varía, que es por lo que existe el descargo de responsabilidad de arriba.
Google acaba de hacer oficial el patrón. Los agentes ahora leen tráfico de red, no documentación.
Ghost, 27 Endpoints, Una Tarde
La configuración: Ghost v6.22.0 ejecutándose localmente, Claude Code con Chrome DevTools MCP conectado al panel de admin en localhost:2368/ghost/.
El primer prompt no fue "ve a explorar" (eso sería vibe coding). Fue estructurado: interceptar todas las solicitudes del panel de admin, catalogar endpoints únicos por ruta y método HTTP, registrar formas de respuesta, luego sondear sistemáticamente patrones de URL adyacentes. El agente usó javascript_tool para inyectar llamadas fetch() directamente en el contexto de la página de admin, lo que significaba que heredaba las cookies de sesión activas y permisos de nivel admin. No se necesitó danza de autenticación separada.
Fase 1: intercepción pasiva. Mientras navegaba por el admin de Ghost (dashboard, posts, miembros, configuraciones), el agente registró cada llamada API que hizo el frontend. Trece endpoints en vivo surgieron inmediatamente. Estos son los que la UI de admin realmente usa pero que los docs oficiales de API no mencionan.
Fase 2: sondeo activo. Aquí es donde se pone interesante. El agente tomó los patrones de URL que ya había visto (/ghost/api/admin/stats/..., /ghost/api/admin/actions/...) y comenzó a sondear variaciones. Probó rutas adyacentes, diferentes parámetros de consulta, las formas plural y singular de lo que ya conocía. Obtuvo los docs oficiales de Ghost Admin API y los docs de Content API en paralelo, luego computó el delta entre lo que está documentado y lo que realmente responde con un 200. Al final: 27 endpoints en total, todos devolviendo datos válidos.
Fase 3: construcción de wrapper. El agente generó un wrapper TypeScript de 830 líneas (ghost-enhanced-api.ts) con dos clientes. Un GhostOfficialClient que envuelve la Admin API documentada (tu línea base), y un GhostEnhancedClient que añade cada endpoint no documentado encontrado. Interfaces TypeScript estrictas para cada forma de respuesta, porque cuando trabajas con endpoints que no tienen documentación, los tipos son tu documentación.
La autenticación también fue interesante. La Admin API de Ghost usa JWT firmado con HMAC-SHA256, derivado de una clave API codificada en hex dividida en la posición 24 (la primera mitad es el ID de clave, la segunda es el secreto). El agente descifró esto observando los propios headers de auth del panel de admin y lo implementó con crypto.subtle en el wrapper. No se consultó documentación para esa parte.
Lo que el agente encontró, en términos concretos:
Endpoints de estadísticas (8 total) — stats/member_count/, stats/mrr/, stats/subscriptions/, stats/referrers/ con seguimiento de conversión, stats/top-posts-views/. Ghost ejecuta un backend completo de analíticas que los docs oficiales pretenden que no existe. MRR desglosado por moneda, atribución de referrers con tasas de conversión, crecimiento diario de miembros. Este es el tipo de datos que normalmente necesitarías una herramienta de analíticas de terceros para obtener.
Registro de auditoría — endpoint actions/. Diario completo de cada operación de admin: quién cambió qué configuración, quién publicó qué post, cuándo. Campos completos action_type, resource_type, actor. El tipo de función que usualmente es "nivel Enterprise, contacta ventas."
Sistema de email — tres grupos de endpoints separados: emails/ (estadísticas de entrega por email), links/ (seguimiento de clics), automated_emails/ (métricas de automatización de newsletter). Independiente de endpoints de posts, significando que puedes consultar rendimiento de email sin pasar por la API de posts.
Exportación de base de datos — GET /ghost/api/admin/db/ devuelve un backup JSON completo. Una llamada. (Y su espejo, POST /ghost/api/admin/db/, hace una importación destructiva. Ese va en la categoría "no tocar" por razones obvias.)
También descubierto: mentions/ (Webmentions/ActivityPub), recommendations/ e incoming_recommendations/ (el motor de recomendaciones), snippets/, labels/, roles/, y configuración completa del servidor.
La suite de tests (40 tests) pasó 39/40 en la primera ejecución. La única falla fue un desajuste de clave de respuesta: incoming_recommendations/ devuelve sus datos bajo una clave recommendations, no incoming_recommendations. Exactamente el tipo de inconsistencia que solo aparece cuando realmente tocas el endpoint y miras lo que regresa. El fix fue una línea. 40/40.
Ya he visto Claude Code absorber una herramienta open-source completa y volverse más competente que su propia documentación. La misma energía aquí, aplicada a superficies de API que nadie había mapeado.
Clasificación: 22 endpoints seguros (solo lectura), 9 usar-con-precaución (operaciones de escritura), 1 no-tocar (POST /db/, la importación destructiva). Y la parte no negociable: endpoints no documentados no tienen contrato de estabilidad. Cambian entre versiones sin una entrada de changelog. Un health check en cada endpoint es lo primero que construyes, antes que cualquier otra cosa.
Tiempo total del agente: menos de 17 minutos. El resto de la tarde fue yo leyendo el reporte y decidiendo qué construir encima.
27 endpoints. Cero documentación. Una tarde. Reproducible en cualquier herramienta que ejecutes.
Lo Que Esto Desbloquea (Y Por Qué Importa Ahora)
Servidores MCP personalizados en cualquier herramienta. Descubres los endpoints, los envuelves en clientes tipados, los expones a tus agentes vía MCP (o un CLI, tú decides). Tu agente ahora puede operar dentro de apps que tienen cero soporte oficial de agentes. El ecosistema MCP ya tiene miles de servidores comunitarios, pero la mayoría construyen solo sobre endpoints documentados. Esto va una capa más profundo.
Pipelines de agentes que no esperan al proveedor. ¿Necesitas que Ghost envíe estadísticas de miembros a tu dashboard de monitoreo cada mañana? La API oficial no lo soporta. Los endpoints no documentados stats/ sí. Escribes un cron job que llama getStatsReferrers() y canaliza los datos donde quieras. Ya no estás bloqueado por lo que alguien más decidió priorizar este trimestre.
Extensiones personalizadas que la UI nunca imaginó. Combina el registro de auditoría con los endpoints de seguimiento de email para construir un dashboard interno de compliance que Ghost probablemente nunca enviará. Conecta dos herramientas a través de sus endpoints internos para automatizar un flujo de trabajo que de otro modo requeriría tres pestañas del navegador y copy-paste manual. El tipo de cosa que solía requerir "nivel enterprise, por favor contacta ventas."
Ahora, la elección entre CLI y MCP para conectar agentes a herramientas es un debate activo con tradeoffs reales de rendimiento. Ambos funcionan. El punto es que necesitas algo que exponer primero. El descubrimiento viene antes del empaquetado.
La hoja de ruta del proveedor es la lista de prioridades de alguien más. Tu agente no necesita estar en ella.
Las Reglas del Juego
Open source primero. Siempre. En software open-source estás leyendo código que está públicamente disponible, no hay zona gris, punto final. En herramientas propietarias la situación se vuelve turbia rápido, y los TOS podrían tener opiniones muy fuertes sobre acceso automatizado. Comienza con open source, siéntete cómodo con el método, luego toma decisiones informadas sobre dónde más lo llevas.
Los health checks no son opcionales, y me refiero estructuralmente no opcionales. Los endpoints no documentados no tienen garantía de estabilidad. La versión 5.92 podría exponer un endpoint que 5.93 remueve sin siquiera una entrada de changelog. Tu wrapper necesita detectar roturas antes de que corrompa algo. Cada endpoint obtiene un health check. Cada wrapper obtiene una suite de tests. Esta es la parte aburrida, y también la parte sin la cual nada se sostiene.
Y la regla que me tatuaría en algún lugar visible: nunca construyas un SaaS sobre endpoints internos. Uso personal, herramientas internas, automatizaciones para tu propio stack, adelante. Pero en el momento que vendes un producto que depende de un endpoint no documentado, estás construyendo sobre arena. Nitter aprendió esto por las malas 🫠. Un cambio de política upstream y el proyecto estaba muerto. Mantén la exploración para ti.
El enfoque en sí también demanda estructura. Apuntar un agente a una pestaña de red sin restricciones claras técnicamente funciona, pero produce basura a escala. Explorar APIs internas con un agente demanda el mismo rigor que cualquier trabajo de producción. Contratos de prompts, límites explícitos, formatos de salida definidos. No vibe coding.
Explora todo. Construye lo que necesites. Pero nunca vendas un producto sobre un endpoint sin contrato.
Durante años, usamos nuestras herramientas como buenos estudiantes. Los docs decían "puedes hacer esto," y nosotros decíamos OK. Punto.
Ese acuerdo silencioso acaba de romperse. Un agente + DevTools explora las capacidades reales de cualquier aplicación en 30 minutos. La ingeniería inversa que le tomó a yt-dlp cientos de contribuyentes y años de mantenimiento se convirtió en un one-shot para cualquier dev solitario en una tarde aleatoria de martes.
La documentación oficial es el folleto. El código fuente es el contrato. Y ahora tienes un agente que lee ambos ;-)
Fuentes y enlaces:
Google Chrome DevTools MCP — lanzamiento oficial, marzo 2026
Si eres un dev enviando cosas reales con agentes de IA, esto es sobre lo que escribo. Suscríbete y obtendrás los métodos antes de que se conviertan en tendencias de Medium.
(*) La portada es generada por IA. Los 27 endpoints, sin embargo, son muy reales y ligeramente ofendidos de que nunca fueron documentados.