repo-graph

Mapa de grafo estructural de cualquier base de código. La LLM consulta el grafo en lugar de buscar a través de todo. 13 idiomas, flujos detectados automáticamente, enlace entre pilas. Cero dependencias.

GitHub

Documentación

repo-graph

Memoria estructural de grafo para asistentes de codificación con IA. Mapea tu código. Navega por estructura. Lee solo lo que importa.

repo-graph ofrece a los LLM un mapa de tu código: entidades, relaciones y flujos, para que puedan navegar a los archivos correctos sin leer todo primero.

En lugar de inundar la ventana de contexto de un LLM con todo tu código (o esperar que adivine correctamente), repo-graph construye un grafo ligero de lo que existe, cómo se conectan las cosas y dónde están los puntos de entrada. El LLM consulta el grafo, encuentra el conjunto mínimo de archivos que necesita y lee solo esos.

Rinde más donde es más difícil hacerlo a mano: repos grandes, monorepos que abarcan varios lenguajes y sistemas multi-servicio donde la ruta de una funcionalidad cruza archivos, stacks y límites de servicio. En un proyecto pequeño de un solo lenguaje, un modelo puede simplemente leer los archivos; consulta Dónde encaja mejor para conocer el punto óptimo honesto.

Instala con un clic:

O un solo comando en tu terminal conecta todos tus agentes: uvx mcp-repo-graph install (consulta Instalación).

Actualización a 0.5.2

La mayoría de la gente no tiene que hacer nada. uvx y pip install mcp-repo-graph incorporan el nuevo motor (glia 0.5.1, fijado exactamente). El grafo cacheado en .glia/graph/ está en un nuevo formato, así que el primer arranque en cada repo lo reconstruye una vez. Después vuelve a la normalidad.

Solo necesitas actuar si también ejecutas los hooks CLI propios de glia (glia install-hooks) en el mismo repo. Reinstala también la CLI desde la etiqueta v0.5.1. Si la CLI y el servidor están en versiones diferentes de glia, reconstruyen la caché del otro en cada commit.

Lo mismo aplica a un equipo que hace commit de la caché con el hook de pre-commit de repo-graph: el siguiente commit la vuelve a añadir una vez en el nuevo formato, y cualquiera cuyo servidor aún ejecute el motor glia 0.5.0 la reconstruye en cada carga hasta que actualice (uv tool upgrade mcp-repo-graph si la instalaste como herramienta uv).

Qué mejora: un grafo más rico (las rutas Go montadas llevan su prefijo, los endpoints de frontend se emparejan mediante su URL base, muchas más llamadas se resuelven), read muestra al host qué cliente WebSocket / gRPC / GraphQL marca, y el servidor ya no aumenta su uso de memoria en sesiones largas.

⚠️ Actualización a 0.5.0

El paquete del motor fue renombrado de repo-graph-py a glia-py. Si instalas con uvx o pip install mcp-repo-graph, no tienes que hacer nada. El nuevo motor se incorpora automáticamente.

Solo necesitas actuar si importas el motor directamente:
- import repo_graph_py as rg
+ import glia_py as rg
Otras tres cosas cambiaron en esa misma versión:

Las respuestas son objetos Python, no cadenas JSON. find, resolve, blast_radius, cross_stack_trace y governing_docs devuelven un dict {"results": [...], "absence": {...}}. Si estabas haciendo json.loads(...) en un resultado, elimínalo.

find_node y find_nodes_by_qname han desaparecido. Un solo find(query, top_k) reemplaza a ambos.

La caché del grafo se movió de .ai/repo-graph/ a .glia/graph/. Se reconstruye automáticamente, así que puedes eliminar el directorio antiguo. El nuevo se ignora a sí mismo y nunca aparece en git status.

Las seis herramientas MCP no han cambiado (orient, find, impact, trace, read, refresh), así que nada en tu configuración de agente necesita tocarse. Detalle completo en las notas de la versión 0.5.0.

Demo

https://github.com/user-attachments/assets/a1e4171b-b225-40d4-9210-39453e14b76a

https://github.com/user-attachments/assets/fc3191e5-fc35-4bd7-8372-72af55995883

Mismo bug, mismo modelo, mismo prompt: la única diferencia es si repo-graph está instalado.

La tarea: corregir un operador de comparación invertido en un monorepo Go + Angular.

(Grabado con un motor anterior, que mapeó ese repo a 566 nodos / 620 aristas. El motor glia 0.5.1 extrae mucho más del mismo código, 3,466 nodos y 6,869 aristas (medido el 2026-10-02), así que el grafo que recibe el modelo hoy es más rico que el del video. Las cifras de tokens y tiempo provienen de la ejecución grabada y se dejan tal como se midieron.)

	Sin repo-graph	Con repo-graph
Tokens usados	75,308	29,838
Tiempo para corregir	4m 36s	~30s
Archivos explorados	~15 (grep, leer, grep, leer...)	2 (búsqueda de traza + archivo del handler)
Resultado	Encontró y corrigió el bug	Encontró y corrigió el bug

2.5x menos tokens. ~9x más rápido. La misma corrección correcta.

Cómo se ejecutó la prueba

Ambas ejecuciones usaron condiciones idénticas para mantener la comparación justa:

Mismo modelo: Claude Opus, 100% (sin enrutamiento Haiku)
Mismo prompt: "Los grupos creados recientemente se muestran como cerrados, y los grupos antiguos como abiertos. Esto está al revés: los grupos nuevos deberían estar abiertos para que los miembros se unan. Encuentra y corrige el bug."
Contexto nuevo: cada ejecución comenzó desde /clear sin conversación previa
Sin otras herramientas: CLAUDE.md, plugins, hooks y todos los demás servidores MCP se eliminaron en ambas ejecuciones: la única variable era si repo-graph estaba instalado
Sin pistas: el prompt describe el síntoma, no la ubicación: Claude tiene que encontrar group_controller.go:57 por sí mismo

Sin repo-graph, Claude usa grep para buscar palabras clave, lee archivos, vuelve a usar grep, lee más archivos y finalmente reduce el bug. Con repo-graph, Claude llama a trace("groups"), recibe la función handler y el archivo exactos, los lee y los corrige.

Explora ejemplos pregenerados para FastAPI, Gin, Hono y NestJS: salida de grafo real que puedes inspeccionar sin instalar nada.

El problema

Los LLM que trabajan con código desperdician la mayor parte de su contexto en orientarse:

Leyendo archivos que resultan irrelevantes
Perdiéndose conexiones entre componentes en diferentes lenguajes
Sin saber dónde comienza una funcionalidad o qué toca
Cargando 50 archivos cuando 5 bastarían

Esto es costoso, lento y empeora a medida que los códigos crecen.

Cómo lo resuelve repo-graph

repo-graph escanea tu código una vez y construye un grafo de:

Entidades: módulos, paquetes, clases, funciones, rutas, servicios, componentes
Relaciones: imports, llamadas, maneja, define, contiene, HTTP entre stacks
Flujos: rutas de extremo a extremo desde el punto de entrada hasta la capa de datos

Luego expone 6 herramientas MCP que permiten al LLM:

Orientarse — "¿Qué lenguajes hay en este repo? ¿Cuáles son las funcionalidades principales? ¿Dónde está el punto ciego del grafo?"
Navegar — "Traza el flujo de inicio de sesión desde la ruta hasta la base de datos" / "¿Cuál es la ruta más corta entre UserService y la API de pagos?"
Delimitar — "¿Qué nodos importan para este bug?" / "Dame solo los archivos que necesito para esta corrección"
Evaluar — "¿Cuál es el radio de impacto de cambiar esta función?" / "¿Qué aquí es código muerto?"

El LLM obtiene contexto estructural en unos pocos cientos de tokens en lugar de leer miles de líneas.

Dónde encaja mejor

repo-graph rinde cuando un código es más grande o más enredado de lo que el modelo puede retener en su cabeza a la vez. El beneficio escala con tres cosas:

Tamaño — suficientes archivos como para que leer los relevantes reviente el presupuesto de contexto.
Complejidad — reglas, indirección y capas, de modo que "solo léelo" deja de funcionar.
Alcance entre límites — la respuesta abarca archivos, lenguajes o servicios que una búsqueda de texto no puede enlazar.

Ajustes fuertes:

Monorepos — un frontend que llama a un backend a través de un límite de lenguaje. repo-graph enlaza la llamada HTTP con la ruta que alcanza y el handler detrás de ella, algo que una búsqueda de texto no puede hacer porque ambos lados no comparten ninguna cadena. Apunta --repo a la raíz del monorepo y un solo grafo abarca todos los proyectos. (La demo anterior es exactamente esto: Go + Angular en un solo repo.)

Otras herramientas enlazan fetch/axios a rutas de Express, Fastify y Koa. Lo que difiere aquí es el alcance: el mismo emparejamiento funciona en Go, Python, Java, C#, Rust, PHP, Ruby y el resto, en un solo grafo, y cubre gRPC, GraphQL, WebSockets, colas y eventos en igualdad de condiciones. Esa amplitud no está comparada con ellas, así que tómala como una diferencia de diseño más que como una victoria medida.
Sistemas multi-servicio / polyrepo — coloca los servicios bajo un directorio y apunta --repo a él; el grafo traza una funcionalidad a través de los límites de servicio en una sola llamada.
Códigos grandes de un solo repositorio — miles de archivos donde la orientación en sí es el costo.
Código desconocido o legacy — donde aún no sabes qué toca qué.

Donde no rinde: un repo pequeño, de un solo lenguaje y con una tarea clara. El modelo puede simplemente leer los archivos: grep gana y el grafo es sobrecarga. Tampoco lo uses para ahorrar tokens: la capa MCP es un costo fijo por turno, así que en tareas fáciles puede costar más. La ganancia de tokens aparece solo cuando evita una espiral de grep-leer-grep (como en la demo anterior). Lo que te compra de forma fiable es respuestas correctas, completas y entre límites en unas pocas llamadas en código demasiado grande o interconectado para caber en contexto, ya sea el tuyo o el del modelo. (¿No quieres la capa MCP en absoluto? Omítela y llama al motor directamente.)

Úsalo sin MCP

El servidor MCP es la ruta de configuración cero, pero el grafo no está atado a él. El motor se distribuye como una rueda Python simple: pip install glia-py — así que puedes construir el grafo y llamar a las mismas primitivas de respuesta directamente, desde un script o tu propia herramienta, con ninguno de los costos MCP por turno:

import glia_py as rg

g = rg.load_from_gmap(rg.default_gmap_dir("."), ".")   # builds it if there's no cache yet

g.find("checkout")                              # ranked, located nodes for a name
g.blast_radius(["checkout", "Cart.add"], "both")  # many seeds, one walk, one ranking
g.cross_stack_trace("notifications")            # feature path across the stack, mechanism-labelled
g.resolve(open("error.log").read())             # stacktrace / test / diff → the nodes that matter
g.coverage()                                    # where extraction is partial (grep those)

Cada una de estas devuelve Python simple: un dict {"results": [...], "absence": {...}} para las búsquedas, una lista para coverage(). Cuando results está vacío, absence dice por qué, para que un script pueda ramificar en ello en lugar de adivinar.

Mismo grafo, mismas respuestas, solo que sin los esquemas de herramientas en tu contexto. Es el mismo motor Rust (glia) que envuelve el servidor MCP; glia-py es su rueda publicada. Ideal para comprobaciones de CI, análisis por lotes o conectar el grafo a tu propio agente.

Lenguajes soportados

Idioma	Detección	Qué extrae
Go	`go.mod`	Paquetes, funciones, rutas HTTP (gin/echo/chi/stdlib), imports
Rust	`Cargo.toml`	Crates, módulos, structs, traits, funciones, rutas (Actix/Rocket/Axum)
TypeScript	`tsconfig.json` / `package.json`	Módulos, clases, funciones, relaciones de import
React	`react` en `package.json`	Componentes, hooks, proveedores de contexto, rutas de React Router, llamadas fetch/axios, flujos
Angular	`@angular/core` en `package.json`	Componentes, servicios, guards, inyección de DI, llamadas HTTP, flujos de funcionalidades
Vue	`vue` en `package.json`	SFCs, composables, rutas de Vue Router, llamadas fetch/axios
Python	`pyproject.toml` / `setup.py` / `requirements.txt`	Paquetes, módulos, clases, funciones, rutas (Flask/FastAPI/Django)
Java/Kotlin	`pom.xml` / `build.gradle`	Paquetes, clases, rutas (Spring/JAX-RS/Ktor/WebFlux/Micronaut)
Scala	`build.sbt`	Paquetes, objetos/clases/traits, rutas (Play/Akka HTTP/http4s)
Clojure	`project.clj` / `deps.edn`	Namespaces, defn/defprotocol/defrecord, rutas (Compojure/Reitit)
C#/.NET	`.csproj` / `.sln`	Namespaces, clases, rutas (ASP.NET/Minimal API)
Ruby	`Gemfile` / `.gemspec`	Archivos, clases, módulos, rutas de Rails
PHP	`composer.json`	Namespaces, clases, interfaces, rutas (Laravel/Symfony)
Swift	`Package.swift` / `.xcodeproj`	Archivos, tipos (class/struct/enum/protocol/actor), rutas de Vapor
C/C++	`CMakeLists.txt` / `Makefile` / `meson.build`	Fuentes, cabeceras, clases, structs, enums, namespaces, includes
Dart/Flutter	`pubspec.yaml`	Módulos, clases, widgets, rutas go_router/shelf
Elixir/Phoenix	`mix.exs`	Módulos, funciones, scopes y rutas del router de Phoenix
Solidity	`.sol` archivos / `foundry.toml` / `hardhat.config.*`	Contratos, interfaces, librerías, eventos, herencia
Terraform	`.tf` archivos	Módulos, recursos, variables, outputs, fuentes de módulos
SCSS	`.scss` archivos presentes	Análisis de bloat a nivel de archivo

Extractores transversales (funcionan en todos los lenguajes):

HTTP cross-stack: llamadas de frontend fetch/axios vinculadas a la ruta de backend que golpean, y el handler detrás de ella
WebSockets: handlers y clientes (gorilla, browser, Python, Java, C#), emparejados por ruta
gRPC: servicios, métodos y tipos de mensaje de .proto, más stubs de cliente e implementaciones de servidor
GraphQL: resolvers y las operaciones que los llaman
Colas: consumidores y productores (Celery, Dramatiq, BullMQ, Sidekiq, Oban, NATS), con topics resueltos por const
Eventos: emisores y handlers
Trabajos cron: puntos de entrada programados
Navegación de páginas: rutas de frontend y los enlaces entre ellas (NAVIGATES_TO)
Fuentes de datos: clientes de DB / caché / cola / blob / búsqueda / email, y qué código toca cuál
Entidades de datos: esquemas compartidos y el código que los lee o escribe
Puntos de entrada CLI: Python click, JS commander/yargs, Go cobra, Rust clap, Java picocli, C# System.CommandLine y Spectre
Contratos: operaciones OpenAPI / AsyncAPI / Pact vinculadas a las rutas que las implementan
Inyección de dependencias: inyección por constructor conectada a lo inyectado
Claves de configuración: dónde se define una clave y todos los lugares que la leen
Infra: recursos de Terraform y Kubernetes
Docs: secciones de documentación vinculadas a los símbolos que gobiernan (lo que read muestra como gobernado por)
Tests: qué tests cubren qué código

Múltiples lenguajes pueden coincidir en un repo (por ejemplo, backend Go + frontend Angular + SCSS). Cada uno contribuye con sus nodos y aristas a un único grafo unificado.

Instalación

Un comando

uvx mcp-repo-graph install

Esto detecta los agentes de codificación de IA que tienes instalados (Claude Code, Claude Desktop, Cursor, Windsurf, VS Code, Codex, Gemini CLI, opencode, Kiro), escribe la configuración MCP de cada uno, y añade un bloque de uso breve a su archivo de instrucciones para que el agente recurra al grafo antes de hacer grep. Donde el agente lo soporta, también concede auto-permiso para que las herramientas de repo-graph no pregunten en cada llamada.

Es seguro volver a ejecutarlo, y uvx mcp-repo-graph uninstall revierte todo (config, instrucciones, permisos) dejando tus datos de grafo en su lugar.

uvx mcp-repo-graph install --agents all          # every supported agent, not just detected
uvx mcp-repo-graph install --scope user          # your global config, not this project
uvx mcp-repo-graph install --dry-run             # show what it would write, change nothing
uvx mcp-repo-graph install --yes                 # no prompt (scripts and CI)
uvx mcp-repo-graph install --print-config cursor # print one agent's config, write nothing

Manual, por cliente

Si prefieres configurarlo tú mismo, el nombre del paquete es el comando de ejecución. uvx mcp-repo-graph simplemente funciona. Sin pip install previo, nada que mantener en PATH. Este es el mismo comando que VS Code, Cursor y el registro MCP usan internamente.

Requisitos: Python 3.11+, y uv si usas la ruta de uvx. Se distribuyen wheels precompilados para el motor Rust en Linux (x86_64, aarch64), macOS (Intel + Apple Silicon) y Windows (x86_64) — no se necesita toolchain de Rust.

Claude Code

claude mcp add repo-graph -- uvx mcp-repo-graph --repo .

(--repo . apunta el grafo al proyecto actual; usa una ruta absoluta para fijarlo.)

VS Code

Un comando — añade el servidor a tu configuración de usuario:

code --add-mcp '{"name":"repo-graph","command":"uvx","args":["mcp-repo-graph","--repo","${workspaceFolder}"]}'

O haz clic en Instalar en la entrada de la galería MCP, o añádelo a .vscode/mcp.json manualmente (ver abajo).

Cursor / cualquier cliente MCP — configuración manual

Añade esto a la configuración MCP de tu cliente (.mcp.json, .cursor/mcp.json, .vscode/mcp.json, o ~/.claude.json):

{
  "mcpServers": {
    "repo-graph": {
      "command": "uvx",
      "args": ["mcp-repo-graph", "--repo", "/path/to/your/project"]
    }
  }
}

¿Prefieres una instalación persistente? pip install mcp-repo-graph (o uv tool install mcp-repo-graph) puts a mcp-repo-graph / repo-graph command on your PATH; luego usa "command": "mcp-repo-graph" en la configuración anterior.

--repo también acepta una URL de git. Apúntalo a cualquier repo público sin clonar primero — hace un shallow-clone y lo mapea (requiere git):

uvx mcp-repo-graph --repo https://github.com/org/repo

Inicio rápido

1. Inicializa el repo objetivo (opcional)

uvx --from mcp-repo-graph repo-graph-init --repo /path/to/your/project
# or, if installed:  repo-graph-init --repo /path/to/your/project

Esto genera el grafo, escribe .mcp.json e instrucciones CLAUDE.md, y prepara a tu asistente de IA para usar repo-graph. Si usaste los one-liners anteriores, puedes omitir esto — el servidor construye el grafo en la primera conexión.

2. Úsalo

El asistente de IA ahora tiene acceso a las 6 herramientas. Ejemplos de consultas que puede responder:

"¿Qué hace este codebase?" → herramienta orient
"Traza el flujo de checkout" → herramienta trace
"¿Qué se rompería si cambio UserService?" → herramienta impact
"¿Qué nodos son relevantes para este bug?" / "Aquí hay un stacktrace — ¿dónde miro?" → herramienta find
"Muéstrame el source de esa función" → herramienta read
"Dame el contexto completo del grafo de forma barata" → orient full=true
"Reconstruye después de un gran refactor" → herramienta refresh

3. Frescura (automática)

El grafo se mantiene actualizado solo. Mientras el servidor está en ejecución, observa el repo y hace un rebuild incremental un momento después de que guardes, así una pregunta estructural justo después de una edición refleja el cambio sin refresh manual. Además, el grafo se auto-repara en el arranque en frío — si el .gmap cacheado está obsoleto, en un formato antiguo o falta, el motor lo reconstruye y lo escribe de vuelta, así nunca está obsoleto cuando tu asistente se conecta.

El watcher está activado por defecto. Establece REPO_GRAPH_WATCH=0 para desactivarlo (el refresco de arranque en frío sigue aplicándose). Necesita el paquete watchdog, que se incluye como dependencia.

¿Quieres el caché pre-construido y commiteado para que compañeros y CI también lo tengan? Añade el hook de pre-commit automáticamente:

uvx mcp-repo-graph install --agents none --git-hook

Eso instala un hook pre-commit delimitado por marcadores que refresca el grafo y prepara .glia/graph/ en cada commit. uvx mcp-repo-graph uninstall lo elimina de nuevo.

Consejo: El directorio del grafo se ignora a sí mismo (.glia/graph/.gitignore), así que nunca aparece en git status a menos que el hook lo prepare con git add -f. Omite el hook y el watcher más el refresco de arranque en frío lo mantienen fresco localmente.

Referencia de herramientas MCP

repo-graph expone 6 herramientas — un verbo natural cada una, respaldadas por una primitiva del motor Rust.

Herramienta	Parámetros	Descripción
`orient`	`seed` (opcional), `full`, `budget`	La primera llamada en un repo: conteos de nodos/aristas, tipos detectados, puntos de entrada, y una nota de puntos ciegos que señala qué lenguajes/aristas están poco enlazados (para que hagas grep deliberadamente). `seed=<node>` → mapa con alcance; `full=true` → mapa denso de todo el repo
`find`	`query`, `expand`, `kind`, `top_k`, `budget`	Convierte cualquier texto en los nodos clasificados que importan — un símbolo/palabra clave, o un stacktrace pegado / id de test fallido / diff (resuelto al código que implica). `expand=true` se expande al vecindario circundante. Cada fila lleva `path:line`
`impact`	`nodes` (separados por comas), `direction`, `depth`, `live_only`, `top_k`, `budget`	Radio de explosión: qué afecta un cambio (`forward`) o de qué depende / qué lo usa (`backward`), como un cierre clasificado y ubicado — cada fila con la razón de arista `via` y un `⊘` cuando el motor lo encuentra inalcanzable (probablemente muerto). Pasa varios nodos para un radio de diff completo
`trace`	`from_node`, `to_node` (opcional), `depth`, `budget`	Un argumento: una funcionalidad de extremo a extremo a través del stack, cada salto etiquetado con su mecanismo (llamada / HTTP / cola / evento) y los saltos entre servicios marcados. Dos argumentos: el camino más corto entre dos nodos
`read`	`node` (separados por comas), `context_lines`, `budget`	El source exacto de un nodo, cortado de su archivo por el span de líneas del grafo, más un pie de página `context:` (método HTTP, llamadores cross-stack o el target de dial de un cliente, tests que cubren, docs que gobiernan). Separa por comas para leer por lotes un conjunto clasificado
`refresh`	`repo_path` (opcional), `full`	Reconstruye el grafo (incremental por defecto — solo los archivos cambiados se re-analizan). `repo_path` re-apunta a una ruta o URL de git diferente; `full=true` fuerza un re-análisis limpio. Las ediciones rutinarias son detectadas automáticamente por el watcher de archivos

La mayoría de las herramientas también aceptan un budget (máx. caracteres) para que un resultado quepa en la ventana de contexto de un modelo pequeño.

Estas 6 se redujeron de unas 13 anteriores una vez que el motor desarrolló primitivas con forma de respuesta — find, blast_radius, cross_stack_trace, resolve, coverage — que devuelven resultados completos, clasificados, ubicados y filtrados en vivo en una sola llamada. Menos herramientas = menos overhead fijo por turno y menos confusión para el agente.

Te dice cuándo no sabe

La mayoría de las herramientas responden a una consulta vacía con nada, lo que deja al asistente adivinando si eso significa "no existe tal arista" o "no pude verla". Desde 0.5.0 un resultado vacío vuelve como una ausencia estructurada: la razón, si esa razón es un HECHO o una HEURÍSTICA, y qué extracciones son parciales para el mecanismo que salió vacío.

  No answer (no_edges, FACT): no carry edge touches `backend::server::server` in this graph;
  `backend::server::server` is a container: structural IMPORTS/CONTAINS/DEFINES are not carry
  edges, so seed a symbol inside it
    looked over: CALLS
    blind spots (grep to confirm):
      ⚠ CALLS (*): calls through reflection, dynamic dispatch, or higher-order indirection are
        not resolved — verify: grep the callee name
    searched 26 nodes

orient muestra los mismos puntos ciegos de antemano, para que el modelo sepa cuándo hacer grep en lugar de confiar en un vacío. Lo que medimos. 14 símbolos en FastAPI, Gin, Hono y NestJS, cada uno un caso donde el grafo honestamente no tiene arista pero existen llamadores reales. Mismo agente, misma tarea, la única diferencia si una respuesta vacía se explicaba a sí misma. La ausencia estructurada redujo el costo alrededor de 3x en tareas idénticas, en 28 de 28 pares coincidentes, con el mismo número de turnos: al decirle por qué la respuesta está vacía, el agente deja de re-consultar. No cambió la corrección. Sonnet 5 respondió "no es seguro eliminar" en las 56 ejecuciones, así que si esperabas que esto detenga a un agente de eliminar código en vivo, no tenemos evidencia de eso y algo de evidencia en contra en un modelo cuidadoso. El arnés y los resultados crudos están en bench/absence/. Un modelo, n=14, nuestro propio arnés: trátalo como direccional.

0.5.0 también añade impact de diff completo en una sola llamada (los nombres no resueltos se reportan, no se descartan), rutas distintas clasificadas entre stacks en trace, y etiquetas conscientes del rol para que un componente o servicio declarado no se aplaste a "clase".

Cómo funciona

mcp-repo-graph es un servidor MCP de Python delgado que envuelve glia, un motor en Rust.

Analizar — los parsers tree-sitter por lenguaje extraen nodos crudos y referencias no resueltas
Extraer — los extractores transversales añaden rutas HTTP, fuentes de datos, puntos de entrada CLI, servicios gRPC, consumidores de colas
Resolver — el constructor de grafos resuelve referencias dentro del repositorio; los resolvedores entre grafos enlazan stacks (llamadas HTTP del frontend → rutas del backend, etc.)
Almacenar — el grafo fusionado aterriza en .glia/graph/ como un .gmap fragmentado de copia cero (rkyv + mmap) más un manifiesto
Servir — el servidor MCP carga el grafo en memoria y expone las 6 herramientas

El motor en Rust vive en su propio repositorio glia; mcp-repo-graph es el envoltorio delgado orientado a MCP.

Detección de diseño

repo-graph encuentra tus proyectos por sí mismo — go.mod, package.json, pyproject.toml, Cargo.toml, pom.xml, build.gradle, composer.json, pubspec.yaml, mix.exs, Package.swift, CMakeLists.txt y amigos. Apunta --repo a la raíz de un monorepo y cada proyecto debajo de ella aterriza en un solo grafo.

También poda por su cuenta: node_modules, vendor, .venv, site-packages, salida de compilación (dist, target, .next, .nuxt, .angular, coverage) y directorios de bundles con hash se colapsan a un único ancla de región en lugar de analizarse archivo por archivo, y .gitignore se respeta.

Nota: versiones anteriores documentaban una vía de escape config.yaml con claves skip: / roots:. Eso era una característica de la era Python y el motor en Rust no la lee — si tienes una, se está ignorando. Si la auto-detección no capta tu diseño, por favor abre un issue con la forma del repositorio; eso es más útil que un archivo de configuración que nadie puede ver.

Formato de datos del grafo

Los archivos generados viven en .glia/graph/ dentro del repositorio objetivo:

repo-<id>.gmap: el grafo en sí, fragmentado, como rkyv de copia cero (mmap al cargar)
manifest.json: versión del formato, etiquetas del repositorio, raíces y errores de análisis, para que una carga en caliente sea igual a una generación fresca
parse_cache.bin: caché de análisis con hash de contenido por archivo, para que una reconstrucción incremental solo re-analice archivos editados
.gitignore: el propio directorio de ignorados, para que nunca aparezca en git status

Todo el directorio se regenera: bórralo y la siguiente llamada lo reconstruye.

El motor lleva 36 categorías de aristas. Las que verás más a menudo: CALLS, IMPORTS, CONTAINS, DEFINES, USES, HANDLED_BY, HTTP_CALLS, IMPLEMENTS, INHERITS_FROM, INJECTS, ACCESSES_DATA, TESTS, DOCUMENTS, NAVIGATES_TO, más las de canal (GRPC_CALLS, QUEUE_FLOWS, WS_CONNECTS, EVENT_FLOWS, GRAPHQL_CALLS, RPC_CALLS). Hay 49 tipos de nodos. Ambas tablas vienen del motor, así que orient siempre reporta el conjunto que tu versión realmente tiene.

Política de privacidad

repo-graph se ejecuta en tu máquina y está construido para mantener tu código allí. Texto completo: PRIVACY.md.

Telemetría / analíticas: Ninguna. Sin seguimiento, sin comprobaciones de actualización, sin llamadas a casa.
Recopilación y compartición de datos: Ninguna. Tu código fuente y los datos del grafo nunca se envían a repo-graph, su autor o terceros.
Procesamiento y almacenamiento local: El escaneo y la construcción del grafo ocurren localmente; el grafo se cachea en el directorio .glia/graph/ de tu proyecto y permanece en tu dispositivo.
Acceso a red — solo dos casos, ambos iniciados por el usuario:
1. Instalación — uvx/pip descarga el paquete y su rueda de motor precompilada desde PyPI.
2. Objetivos de URL Git — si pasas una URL git a --repo, repo-graph ejecuta git clone contra la URL que tú especificaste; nada se envía a repo-graph o su autor. Una ruta --repo local (la predeterminada) hace cero llamadas de red.
Retención de datos: La caché local persiste hasta que la elimines — completamente bajo tu control.
Contacto: Issues de GitHub

Licencia

MIT

Soporte

Si repo-graph te ahorró tiempo, considera invitarme un café.

buymeacoffee.com/polycrisis