Auditoría de REA: 15.095 estrellas, 133 herramientas MCP y una factura de 209.619 tokens para analizar ocho archivos

“Ve una función que te guste. Entiende cómo funciona, hasta el nivel del binario.” Ese es el mensaje de REA —un servidor MCP para hacer ingeniería inversa de binarios, aplicaciones y comportamiento en ejecución— y las 15.095 estrellas de morluto/rea confirman que funcionó. El repositorio recibió commits hace menos de una hora de cuando escribo esto, publica 26 versiones en npm en 88 días y ejecuta 16 flujos de GitHub Actions con nombres como Real Hopper E2E y Real Ghidra Windows E2E.

Así que instalé rea-agents@5.0.0, hablé JSON-RPC en crudo con su servidor MCP, construí una aplicación Electron de ocho archivos como banco de pruebas y apunté el analizador a un directorio JavaScript de 14 MB para encontrar su límite. Lo que volvió es una de las herramientas más honestas que he auditado este año, y una factura que el README no menciona en ninguna parte.

Los números que se reproducen

Todo lo siguiente está medido en Debian 13, Node.js 26.5.1, npm 11.17.0, rea-agents 5.0.0 desde npm, el 8 de octubre de 2026.

El dato de los suscriptores es el que no puedo dejar de mirar. Suscribirse es la única señal de GitHub que le cuesta algo al usuario —hay que pedir explícitamente que te avisen— y solo 44 personas quieren saber qué hará este proyecto después. Los 1.569 forks frente a esos 44 suscriptores cuentan una historia distinta de la que cuenta el contador de estrellas. Y no es un repositorio dormido: el histograma semanal de commits va 122, 44, 3, 11, 0, 1, 0, 1, 0, 0, 101, 420 —un parón casi total desde mediados de agosto hasta finales de septiembre, y después un reinicio cuatro veces mayor que el estallido original.

Lo que hace de verdad el modelo de evidencia

La regla por defecto en una reseña de herramientas es desconfiar del marketing y leer el código, pero el argumento de venta de REA es que su salida es auditable. Así que construí lo más pequeño capaz de refutarlo: ocho archivos, 2.595 bytes en disco, con dos manejadores ipcMain, una API contextBridge con tres miembros, una constante URL, una variable de entorno y una llamada a un proceso hijo.

REA emparejó correctamente los dos canales IPC a través de la frontera main/renderer —license:activate (llamada handle en main y invoke en el renderer) y sync:start (on en main y send en el renderer)— y reportó 2 paired_renderer_transmissions, 0 unpaired. Resolvió preload.js a partir de una expresión del sistema de archivos, detectó la API contextBridge llamada desktop con tres miembros expuestos y cero miembros desconocidos, y encontró el enlace con el complemento nativo. Cuarenta nodos, cincuenta y siete aristas, treinta y un hallazgos, 334 nodos del AST visitados.

Más importante: etiquetó su propio trabajo. Cada observación lleva una authority (por ejemplo ast-static-analysis), un state (observed, inferred o unknown), una confianza, el sha256 del artefacto y un rango de línea y columna de origen. El enlace con el complemento nativo va marcado como native_export_verification: not-performed con la limitación “JavaScript syntax identifies requested member names; it does not prove that the native binary exports or implements them.” Informa sender_validation_observations: 0 en lugar de eliminar el campo. Cuando construí sin querer un directorio con dos archivos que solo diferían en mayúsculas, se negó a analizarlo con un error estructurado —category: execution_failure, retryable: false— que nombraba ambos archivos y la diferencia exacta, en vez de adivinar.

Eso es raro. La mayoría de las herramientas para agentes de esta categoría devuelve JSON seguro de sí mismo y deja que descubras las salvedades en producción.

La factura de esa disciplina

Aquí está el mismo análisis, con precio de modelo. REA incluye su propio contador de tokens, así que estos son los números de la herramienta, no mi estimación:

Son unos 60.000 tokens de evidencia por kilobyte de JavaScript, y la proporción se mantiene estable en toda la curva. Ocho archivos pequeños —una app de juguete que un principiante escribiría en una tarde— consumen más contexto del que cabe en la mayoría de los modelos en una sola petición. Con 500 archivos la salida son 52,9 millones de tokens, unas veintiséis veces una ventana de dos millones. Con 883 archivos el proceso murió con FATAL ERROR: Ineffective mark-compacts near heap limit y una traza nativa de V8, código de salida 134, a los 133 segundos, en un equipo con 8 GB de RAM y un heap por defecto de unos 2 GB.

¿En qué se van 209.619 tokens para 2.595 bytes de entrada? Diseccioné el resultado:

• 18.391 valores hoja, de los cuales 3.422 son campos de identidad. Las cadenas de identidad suman 199.081 caracteres: el 53,0% de todos los bytes de texto del documento y el 15,5% del archivo.
• 53 hash SHA-256 distintos, y 40 de ellos aparecen una sola vez. La mayoría identifica una observación concreta en lugar de reutilizarse, así que cada registro carga su propio nombre criptográfico.
• 604 entradas de limitations pero solo 35 cadenas distintas: una repetición de unas 17 veces. Las mismas salvedades se vuelven a adjuntar a los 586 objetos de cobertura.
• 12 familias de extractores, las 12 en estado partial, ninguna complete, aunque el coverage.status de nivel superior diga complete y truncated: false. Es coherente por dentro, pero un agente que compruebe “¿la extracción está completa?” ve luz verde mientras cada extractor dice lo contrario.
• call-flow retuvo 0 relaciones y registró 33 incógnitas. data-flow retuvo 123, object-flow 17, closure 13.

Hay un detalle que conviene señalar a quien piense filtrar ese registro. El único punto de proceso hijo de mi banco de pruebas —un spawn cuyo argv se construye con .concat()— queda registrado como incógnita de call-flow: “Call target spawn has ambiguous or unsupported assignments”, anclada a src/updater.js, línea 6, columna 9. Lo cual es correcto y útil. Pero la familia de extractores child-process informa status: partial con 0 relaciones retenidas, 0 omitidas y 0 incógnitas. Un agente al que se le pida “enséñame qué se perdió el extractor de procesos hijo” recibiría una hoja en blanco.

El apretón de manos de 2,10 MiB

El CLI tiene una historia de presupuesto de tokens. El lado MCP no.

Hablando JSON-RPC en crudo por stdio, tools/list del servidor 5.0.0 devuelve 133 herramientas en 2.201.441 bytes. Las 133 llevan outputSchema; el esquema de salida es el 65% del peso y el de entrada otro 32%, con solo 38.739 caracteres de descripción real. En todo el catálogo hay 337 propiedades de esquema de entrada —2,53 por herramienta— y 13 herramientas cuyo esquema de entrada no tiene ninguna propiedad.

Del apretón de manos salieron dos cosas más:

• Solo 5 de las 133 herramientas marcan annotations.readOnlyHint: true —evaluate_reconstruction_coverage, binary_session, get_evidence_bundle, list_unknowns y verify_unknown_resolution—. Las otras 128, incluidas todas las inspect_*, list_*, get_*, search_* y read_*, dejan la anotación sin definir. Los clientes que aprueban automáticamente en función de esa anotación pedirán confirmación para leer una tabla de cadenas.
• La respuesta hay que drenarla en paralelo. Mi primera sonda leyó el stdout del proceso hijo en un único búfer después de que terminara y capturó 63.861 bytes: un objeto JSON truncado. El payload supera el búfer de tubería de 64 KB, así que el servidor se bloquea a mitad de escritura hasta que alguien lee. Es un problema del cliente, no un defecto de REA, pero es una arista afilada para quien escriba su propio arnés MCP, y es la razón de que mi primer tools/list “fallara”.

prompts/list devuelve seis flujos de investigación, exactamente lo que dice la documentación. resources/list devuelve error: no hay capacidad de recursos.

Documentado frente a publicado

El catálogo generado de REA es lo bastante preciso como para poder comprobarlo, así que lo comprobé contra el cable.

docs/product-catalog.json en main declara tools.total: 134 y mcp_tools: 134, con una familia de navegador de 12 herramientas. El servidor 5.0.0 en vivo anuncia 133. La única herramienta que está en el catálogo y no en el servidor publicado es inspect_web_network_capture, que corresponde exactamente al commit feat(browser): inspect historical web network captures (#992), integrado el 7 de octubre de 2026, después de publicarse la 5.0.0. La tabla de familias del README publicado suma 133, así que el artefacto distribuido es coherente consigo mismo y main simplemente va una función por delante.

La misma forma en el CLI: el catálogo declara 89 comandos principales y rea --help lista 90 entradas, incluidas las de infraestructura mcp y completions. El paquete publicado coincide con su propia documentación; la distancia es entre main y la release, algo que el README sí admite. Es buena señal que la diferencia sea una herramienta y no treinta.

Dónde está realmente la frontera

REA eleva la calidad de la evidencia con la que trabaja un agente. No puede elevar al agente. Para calibrar esa distancia, la referencia útil no es el material propio de REA sino SRE-Bench, The Next Challenge for Agentic Cybersecurity (arXiv:2608.11469, 11 de agosto de 2026, doce autores entre ellos Raluca Ada Popa y Eric Wallace): 19 programas privados a escala real con una media de 16,9 mil líneas de código, 44 mecanismos anti-análisis propios, 262 instancias binarias y 1.572 tareas con calificación determinista. En 13 configuraciones agénticas y 11 modelos, el artículo informa de que “GPT-5.6-Sol y Claude-Fable-5.1, pese a sus sólidas capacidades en seguridad de código fuente, resuelven por completo solo el 31,5% y el 26,9% de las instancias calificadas”.

Ese es el techo que REA intenta subir, y hoy está entre el 27% y el 32%. También reencuadra para qué sirve una herramienta así: no para que un agente clone una app, sino para que cada paso de una investigación sea citable, de modo que una conclusión equivocada se pueda encontrar y corregir. La propia documentación de REA es explícita: “REA shows how it reached its conclusions. It does not claim to recover original source code or automatically clone an application.”

Quién valida a quién

Ninguna de las fuentes de REA publica una cifra de precisión, una tasa de acierto ni una evaluación comparativa de REA en sí. La prueba de utilidad son tres casos de estudio que el proyecto escribió sobre sí mismo —DX-Ball, Notion, TH04— y el de DX-Ball merece mirarse de cerca porque es el único con números.

La web informa de 55 funciones C mantenidas, 45.380 comparaciones con el código original y 33 funciones con bytes compilados idénticos, con punto de control del 7 de octubre de 2026. El README, por separado, dice que la investigación del sound-pan “pasa 3.205 casos originales de x86 y reproduce los 63 bytes compilados de la función”: una afirmación más estrecha sobre una sola función. No es una contradicción, son dos alcances que se parecen mucho al leerlos de reojo.

El artefacto que hay detrás, N0zoM1z0/dx-ball, es donde el asunto se vuelve estructuralmente interesante. En el momento de esta medición:

• Fue creado el 7 de octubre de 2026 a las 04:55 UTC, un día antes de esta auditoría y el mismo día del punto de control que cita el caso de estudio.
• Tiene 2 estrellas, 0 suscriptores, 0 forks, 0 issues, 0 releases y 0 etiquetas.
• Sus 49 commits vienen de un único colaborador, y todos los mensajes empiezan por gpt-6.1-sol:: un agente escribiendo la historia del proyecto que demuestra la herramienta de agentes.
• Su campo homepage apunta a https://github.com/morluto/rea, y entre sus topics figura rea-showcase.
• Su único colaborador es además el segundo mayor contribuidor de REA (248 commits).

Es decir, la herramienta, el caso de estudio, el repositorio de demostración y los propios mensajes de commit salen de las mismas dos personas y un modelo, y la historia pública del artefacto de verificación tiene un día de profundidad. Eso no convierte en falsas las 45.380 comparaciones diferenciales —el repositorio contiene de verdad 24 módulos de test diferencial y la derivación de ensamblador a C del caso de estudio se puede comprobar línea a línea— pero sí significa que un lector no puede corroborar por su cuenta la trayectoria de varias semanas que sugiere el caso de estudio, porque el historial de git no llega tan atrás.

Siendo justos, la misma disciplina de auditoría corta en la dirección contraria. La cultura de verificación del proyecto es inusualmente profunda: 16 flujos de trabajo, 5.448 ejecuciones, con carriles separados Real Hopper E2E, Real Hopper Linux E2E, Real Ghidra Windows E2E, Real browser verification, Real JavaScript recovery y Real website source-map verification. De las últimas 100 ejecuciones de todos los flujos, 80 terminaron bien, 13 fallaron y 6 se cancelaron. El fallo más reciente del flujo CI (8 de octubre, 00:29) es un solo job de veintitrés: Native package baseline (darwin x64) fallando en npm run verify:package, con los otros 22 en verde. Un proyecto de 15.000 estrellas con el check principal en rojo en una rama de trabajo es normal; un proyecto de 15.000 estrellas con carriles E2E sobre herramientas reales con nombre propio, no.

Los remedios son reales y son drásticos

Lo más útil que puedo darte no es un veredicto, es una opción. REA cuesta 209.619 tokens con mi banco de pruebas por defecto. El mismo comando con un filtro:

rea analyze-javascript-application ./app --filter-output normalized_result.summary --token-count
# 193

193 tokens en lugar de 209.619. Una reducción de unas 1.086 veces, para el resumen sobre el que un agente razona primero. --format md renderiza el mismo resultado en 265.409 bytes frente a 1.285.968 de --json —4,8 veces menos— y existen --token-limit y --token-offset para paginar.

Una salvedad que solo puedo reportar, no explicar: --token-count devuelve 209.619 tanto con --json como con el formato TOON por defecto, aunque TOON ocupa 1.002.841 bytes frente a los 1.285.968 del JSON. El contador parece medir el sobre del resultado y no el texto que realmente recibes, así que trátalo como un orden de magnitud, no como una factura.

Configuración práctica para una sesión de agente: usa rea doctor --provider ghidra --json para una comprobación de preparación acotada (solo los scope_checks deciden el indicador healthy, así que un motor ausente que no usas queda como informativo), empieza cada investigación con un resumen filtrado y luego pide subárboles filtrados bajo demanda en lugar de ingerir el sobre completo.

¿Deberías usarlo?

Úsalo si quieres que un agente te explique cómo funciona una función, ya tienes Hopper o Ghidra, y valoras un resultado que dice “esto es inferido, aquí está el hash del artefacto, aquí está la línea” por encima de uno que no dice nada sobre su propia confianza. Para trabajo de IPC con Electron y JavaScript en concreto, el emparejamiento de canales que verifiqué es el tipo de salida que resulta genuinamente difícil de conseguir en otro sitio.

Ten cuidado si tu objetivo es una aplicación real y no un banco de pruebas. Un directorio de 500 archivos ya produce 52,9 millones de tokens, y 883 archivos de 11,7 MB abortan con un error de memoria de V8 en lugar de una negativa estructurada del tipo “objetivo demasiado grande”: el único punto donde la disciplina de la herramienta sobre fallos accionables no se sostuvo en mis pruebas.

Conoce esto antes de comprometerte comercialmente:

La lista de plataformas también es más estrecha de lo que sugiere “Linux”: macOS 12+, Ubuntu 24.04+, Fedora 41+, Arch de 64 bits o CachyOS. En Debian 13, rea doctor --json devuelve healthy: false con unsupported_host, detail debian 13, mientras que el análisis estático de JavaScript funciona perfectamente en ese mismo equipo, con código de salida 0, porque no necesita desensamblador. La comprobación de sistema es una declaración de soporte, no una puerta funcional, y conviene saber cuál de las dos estás leyendo.

Preguntas frecuentes

¿Necesita REA Ghidra, Hopper o IDA? No. El análisis estático de JavaScript y Electron solo necesita Node.js. El análisis de binarios nativos necesita uno de los tres motores; el README indica que los flujos condicionados requieren “a selected deep provider”.

¿Por qué el catálogo MCP ocupa 2,10 MiB? Porque las 133 herramientas publican un outputSchema JSON completo, que es el 65% del peso. Los modelos no suelen consumir el esquema de salida, pero los clientes que lo registran o lo validan moverán 2 MiB al conectar.

¿Puedo conectarlo a cualquier agente? Trae configuración para doce clientes (Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, Devin, OpenCode, Antigravity, GitHub Copilot CLI, Command Code y VS Code) y documenta la configuración MCP manual para cualquier otro.

¿Puede recuperar el código fuente de una aplicación? No, y lo dice. Produce pseudocódigo, ensamblador, símbolos, cadenas, metadatos y relaciones: una base de evidencia sobre la que un agente puede razonar.

¿Y si se cuelga con un objetivo grande? Hay dos casos distintos: pasarse de memoria aborta el proceso de Node con un error fatal de V8 (el mío tardó 133 s con 883 archivos), mientras que un problema estructural devuelve un error correcto, como hizo cuando mi banco de pruebas contenía dos archivos que solo diferían en mayúsculas.

¿Es fiable la evidencia? Fíate de las etiquetas, no del volumen. Un observed con confidence: exact y un rango de líneas es comprobable; un inferred con confidence: medium es un candidato. En mi banco de pruebas, algo menos de la mitad de las familias de extracción devolvieron cero relaciones retenidas mientras registraban sus incógnitas, lo cual es honesto y también un recordatorio de que 40 nodos y 57 aristas son un mapa parcial.

Conclusión

REA es ingeniería seria apuntada a un problema difícil, y hace bien la parte difícil: produce evidencia que un auditor puede comprobar en lugar de prosa que un lector debe creerse. Su cultura de verificación —dieciséis flujos, carriles reales de extremo a extremo con Hopper y Ghidra, el 80% de las ejecuciones recientes en verde— es mejor que la de la mayoría de proyectos con diez veces su volumen de descargas.

La distancia es económica, no técnica. Una herramienta construida para alimentar a un modelo le cobra a ese modelo por byte, y a unos 60.000 tokens por kilobyte de código fuente su salida por defecto está tarifada para una máquina que lee archivos, no para una ventana de contexto que razona sobre ellos. La solución ya está publicada, escondida tras una opción: 193 tokens para el resumen en lugar de 209.619. Empieza por ahí, baja más profundo solo cuando el resumen te lo indique, y ten presente el carácter cerrado de los casos de estudio autoeditados a la hora de decidir cuánto de la afirmación de las 45.380 comparaciones te tomas por fe.

15.095 estrellas, 44 suscriptores, 133 herramientas y un apretón de manos de 2,10 MiB. El trabajo artesanal se ve; el número de suscriptores es el dato honesto de la sala.