██████╗ ██████╗ ██████╗ ███████╗ █████╗ ████████╗██╗ █████╗ ███████╗
██╔════╝██╔═══██╗██╔══██╗██╔════╝ ██╔══██╗╚══██╔══╝██║ ██╔══██╗██╔════╝
██║ ██║ ██║██║ ██║█████╗ █████╗███████║ ██║ ██║ ███████║███████╗
██║ ██║ ██║██║ ██║██╔══╝ ╚════╝██╔══██║ ██║ ██║ ██╔══██║╚════██║
╚██████╗╚██████╔╝██████╔╝███████╗ ██║ ██║ ██║ ███████╗██║ ██║███████║
╚═════╝ ╚═════╝ ╚═════╝ ╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚══════╝╚═╝ ╚═╝╚══════╝
[ M C P ]
Conecta Claude Code, Claude Desktop y Agentes de IA Autónomos directamente a mapas de código AST estructurales, esqueletos eficientes en tokens y análisis de impacto de radio de explosión de PR.
Los agentes de codificación LLM modernos gastan hasta el 70% de su ventana de contexto ingiriendo árboles de archivos sin procesar y contenidos de archivos redundantes. Al modificar bases de código grandes, los asistentes de IA a menudo carecen de visibilidad sobre:
Llamadores y dependientes posteriores: Modificar la firma de una función exportada rompe a los llamadores a 5 directorios de distancia.
Inflación de tokens: Los volcados de archivos completos desperdician contexto en cuerpos de implementación en lugar de definiciones de tipos y firmas.
Radio de explosión de regresión de PR: Falta de conciencia sobre qué suites de pruebas unitarias y de integración cubren los nodos AST modificados.
code-atlas-mcp resuelve esto exponiendo una capa de inteligencia consciente de AST a través del estándar Model Context Protocol (MCP). Analiza archivos fuente en árboles de símbolos estructurales, poda cuerpos de funciones en esqueletos de código eficientes en tokens, aísla nodos AST modificados en diffs de git y calcula el radio de explosión de regresión transitiva.
Related MCP server: MCP Filesystem Server
┌────────────────────────────────────────────────────────────────────────┐
│ AI Coding Clients │
│ (Claude Code CLI / Claude Desktop / Cursor / Custom Agents) │
└──────────────────────────────────┬─────────────────────────────────────┘
│ MCP Protocol (JSON-RPC over stdio)
▼
┌────────────────────────────────────────────────────────────────────────┐
│ code-atlas-mcp │
│ ┌───────────────────────────────┬──────────────────────────────────┐ │
│ │ MCP Request Router │ Tool Schema Validators │ │
│ │ (ListTools / CallTool Handler)│ (Zod Runtime) │ │
│ └───────────────┬───────────────┴──────────────────┬───────────────┘ │
│ ▼ ▼ │
│ ┌───────────────────────────────┐ ┌───────────────────────────────┐ │
│ │ AST Engine │ │ Git Engine │ │
│ │ • TypeScript Compiler API │ │ • Unified Diff Parser │ │
│ │ • Symbol & Hierarchy Extr. │ │ • Line-to-AST Correlation │ │
│ │ • Token-Efficient Skeletons │ │ • Working Tree / Ref Diffs │ │
│ └───────────────┬───────────────┘ └───────────────┬───────────────┘ │
│ └───────────────┬──────────────────┘ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ Impact Analyzer │ │
│ │ • Downstream Callers Graph • Transitive Dependency BFS │ │
│ │ • Test Suite Coverage Map • Risk Scoring & Assessment Engine │ │
│ └──────────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────┬─────────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────────────────┐
│ Local Codebase │
│ Filesystem (.ts, .tsx, .js, .jsx) & .git │
└────────────────────────────────────────────────────────────────────────┘get_repo_structureDevuelve un mapa estructural jerárquico y podado por AST del repositorio con esqueletos de código opcionales eficientes en tokens. Elimina los cuerpos de las funciones mientras conserva firmas completas, interfaces exportadas, tipos y docstrings.
Parámetro | Tipo | Requerido | Descripción | Por defecto |
|
| No | Directorio del repositorio objetivo. | Directorio de trabajo actual |
|
| No | Generar esqueletos de código eficientes en tokens con cuerpos de funciones eliminados. |
|
|
| No | Profundidad máxima de recorrido de directorios (1-20). |
|
|
| No | Matriz de patrones glob de carpetas/archivos a ignorar. |
|
|
| No | Matriz de extensiones permitidas (p. ej. | TS/JS estándar |
{
"rootDir": "/workspace/my-app",
"totalFiles": 42,
"totalSymbols": 318,
"fileTree": {
"name": "src",
"type": "directory",
"children": [
{
"name": "auth.ts",
"type": "file",
"symbolsCount": 4,
"summary": {
"language": "typescript",
"linesOfCode": 120,
"symbols": [
{
"name": "verifyJwt",
"kind": "function",
"signature": "export function verifyJwt(token: string): Promise<JwtPayload>",
"startLine": 15,
"endLine": 42,
"isExported": true
}
],
"astSkeleton": "import { JwtPayload } from \"./types.js\";\n\nexport function verifyJwt(token: string): Promise<JwtPayload>;"
}
}
]
}
}analyze_diff_impactAnaliza los nodos AST modificados entre ramas, confirmaciones o el árbol de trabajo sin confirmar para determinar las funciones, clases y componentes posteriores afectados.
Parámetro | Tipo | Requerido | Descripción | Por defecto |
|
| No | Revisión o rama base de git (p. ej. | Árbol de trabajo sin confirmar |
|
| No | Revisión o rama de git head (p. ej. | Estado del árbol de trabajo |
|
| No | Ruta a la raíz del repositorio git. | Directorio de trabajo actual |
{
"baseRef": "main",
"headRef": "HEAD",
"changedFilesCount": 2,
"modifiedFiles": ["src/auth/jwt.ts"],
"modifiedAstNodes": [
{
"filePath": "src/auth/jwt.ts",
"symbol": {
"name": "verifyJwt",
"kind": "function",
"signature": "export function verifyJwt(token: string, options?: VerifyOptions): Promise<JwtPayload>",
"startLine": 12,
"endLine": 35,
"isExported": true
},
"changeType": "modified",
"modifiedLines": [12, 13, 14]
}
],
"affectedDownstream": [
{
"symbolName": "verifyJwt",
"sourceFile": "src/auth/jwt.ts",
"dependentFile": "src/middleware/auth.ts",
"impactType": "direct_import",
"reason": "File 'src/middleware/auth.ts' directly imports symbol 'verifyJwt' modified in 'src/auth/jwt.ts'"
}
],
"summary": "Diff Impact Analysis: 1 file(s) modified across 1 distinct AST symbol(s). Identified 1 downstream dependent reference(s) that require verification."
}inspect_blast_radiusIdentifica posibles puntos de regresión, dependientes posteriores transitivos (recorrido BFS) y suites de pruebas rotas para un cambio de archivo específico. Calcula una puntuación de riesgo de 0 a 100 con factores críticos.
Parámetro | Tipo | Requerido | Descripción | Por defecto |
|
| Sí | Ruta al archivo fuente objetivo (p. ej. | — |
|
| No | Ruta a la raíz del repositorio. | Directorio de trabajo actual |
{
"targetFile": "src/services/user.ts",
"targetSymbols": [ /* AST Symbols */ ],
"directDependents": [
{
"filePath": "src/controllers/auth.ts",
"importedSymbols": ["getUserById", "updateUser"]
}
],
"transitiveDependents": [
{
"filePath": "src/routes/api.ts",
"depth": 2,
"chain": ["src/services/user.ts", "src/controllers/auth.ts", "src/routes/api.ts"]
}
],
"affectedSuites": [
{
"testFile": "tests/auth.test.ts",
"reliesOn": ["src/services/user.ts", "src/controllers/auth.ts"],
"riskLevel": "HIGH",
"potentialFailures": ["getUserById", "updateUser"]
}
],
"riskAssessment": {
"score": 65,
"level": "HIGH",
"factors": [
"Exports 4 symbol(s)",
"High direct coupling: 3 direct dependent files",
"Moderate cascade: 5 transitive dependents",
"1 test suite(s) actively verify dependent code"
]
}
}npm install -g code-atlas-mcpnpx code-atlas-mcp --root /path/to/your/projectAñade code-atlas-mcp a tu claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"code-atlas": {
"command": "npx",
"args": [
"-y",
"code-atlas-mcp"
]
}
}
}Si deseas fijar un directorio de repositorio específico:
{
"mcpServers": {
"code-atlas": {
"command": "npx",
"args": [
"-y",
"code-atlas-mcp",
"--root",
"/absolute/path/to/your/repository"
]
}
}
}Lanza claude con el servidor MCP adjunto:
claude --mcp-server "npx -y code-atlas-mcp"Node.js >= 18.0.0
npm >= 9.0.0
Git CLI
# Clone the repository
git clone https://github.com/GeorgeTsakonas/code-atlas-mcp.git
cd code-atlas-mcp
# Install dependencies
npm install
# Build TypeScript to dist/
npm run build
# Run unit and integration tests with Vitest
npm test
# Run tests in watch mode
npm run test:watch
# Type check
npm run lintExtracción de AST de TypeScript Compiler API
Generación de esqueletos eficientes en tokens (cuerpos eliminados)
Correlación de líneas de diff de git con nodos AST
Grafo de dependencias posteriores y análisis de impacto en sitios de llamada
Inspección de radio de explosión transitiva e identificación de suites de pruebas
Transporte stdio estándar de MCP
Soporte del motor de análisis AST de Python (ast / Tree-sitter)
Módulos de análisis AST de Rust y Go
Búsqueda semántica vectorial sobre símbolos AST
¡Las contribuciones son bienvenidas! No dudes en enviar un Pull Request.
Haz un fork del proyecto
Crea tu rama de características (git checkout -b feature/AmazingFeature)
Confirma tus cambios (git commit -m 'Add some AmazingFeature')
Sube a la rama (git push origin feature/AmazingFeature)
Abre un Pull Request
Distribuido bajo la Licencia MIT. Consulta LICENSE para obtener más información.
Analyzes modified AST nodes between branches, commits, or uncommitted working tree to determine affected downstream functions, classes, and components.
| Name | Required | Description | Default |
|---|---|---|---|
| baseRef | No | Base git revision or branch (e.g. 'main', 'HEAD~1'). Omit for uncommitted working tree diff. | |
| headRef | No | Head git revision or branch (e.g. 'feature-branch', 'HEAD'). | |
| repoPath | No | Path to repository root. Defaults to current working directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full disclosure burden. It does not state whether the operation is read-only, what the return format is, whether it has side effects, or any permission requirements. It only describes the analysis action without behavioral detail, leaving the agent to infer safety and outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-constructed sentence that front-loads the core action and purpose. Every word contributes to meaning, with no filler or redundancy. It is appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately conveys what the tool does and its input modes, but it lacks details on output format, expected results, limitations, or performance considerations. Given the tool's complexity (AST diff analysis), more context would help an agent know what to expect from the result and how to interpret it. The gap is not severe for a read-style tool, but it is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all three parameters are already documented. The tool description adds minimal extra meaning—it references the diff scope (branches, commits, working tree) which aligns with the parameters but does not enrich the parameter understanding beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (analyze modified AST nodes) and outcome (determine affected downstream functions, classes, components), covering the core purpose. It is clear about the resource and scope, but it does not explicitly differentiate from the sibling tools get_repo_structure and inspect_blast_radius, which could potentially overlap in intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the input modes (between branches, commits, or uncommitted working tree), providing context for when it might apply, but it gives no explicit guidance on when to prefer this tool over its siblings or any conditions that would make it inappropriate. There is no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a hierarchical, AST-pruned structural map of the repository with token-efficient code skeletons, stripping implementation bodies to save context tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| rootDir | No | Target root directory. Defaults to current working directory. | |
| maxDepth | No | Maximum directory depth recursion. Defaults to 5. | |
| fileExtensions | No | Allowed file extensions (e.g. ['.ts', '.tsx', '.js']). | |
| ignorePatterns | No | Patterns to ignore during scan. | |
| includeSkeletons | No | Whether to include token-efficient AST skeletons. Defaults to true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a meaningful behavioral trait—stripping implementation bodies to save tokens—but does not explicitly state that the operation is read-only, mention any side effects, or describe limitations. Some transparency is present, but key aspects remain uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and then adds the pruning detail. It is concise, with no wasted words, and effectively communicates the tool's value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the output concept and the schema covers parameters, but there is no output schema and the description doesn't mention return format or usage context. Given the tool's simplicity, it is mostly complete, though it could benefit from a note on when to use it or what the skeleton structure looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are fully documented in the schema. The description itself adds no parameter-level details beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a hierarchical, AST-pruned structural map with token-efficient code skeletons, which is specific to the resource and operation. It does not explicitly differentiate from sibling tools like analyze_diff_impact or inspect_blast_radius, but the purpose is unambiguous and distinct by nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling tools. It only describes what it does, without any conditions, exclusions, or references to alternatives, leaving usage context entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identifies potential regression points, direct and transitive downstream dependents, and broken test suites for a targeted file change.
| Name | Required | Description | Default |
|---|---|---|---|
| repoPath | No | Path to repository root. Defaults to current working directory. | |
| targetFile | Yes | Path to the target file to inspect (e.g. 'src/auth/token.ts'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states what the tool outputs (regression points, dependents, broken tests) but does not disclose behavioral traits such as whether it is read-only, whether it runs tests, requires special permissions, or has performance implications. It gives an outcome but no process or side-effect details, which is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that lists the key outputs with zero filler. Every clause adds information about what the tool does, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that analyzes blast radius, the description fails to mention the return format or structure (e.g., lists, counts, path groupings) despite having no output schema. It also omits any preconditions (e.g., repository must be initialized) or costs. Given the tool's complexity and lack of output schema, this is a notable completeness gap, though the core purpose is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds no extra meaning beyond referencing the 'targeted file change', which aligns with targetFile. It neither enriches nor contradicts the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'identifies' and specifies the resource: a targeted file change. It enumerates concrete outcomes (regression points, direct/transitive dependents, broken test suites), which is specific. However, it does not explicitly differentiate this from the sibling analyze_diff_impact, so it's clear but not fully distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the siblings analyze_diff_impact or get_repo_structure. The description implies a use case (inspecting impact of a file change) but offers no exclusions, prerequisites, or alternative conditions. The agent is left to infer when this is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0analyze_diff_impactget_repo_structureinspect_blast_radiusScored across 3 tools
get_repo_structure is clearly distinct, but analyze_diff_impact and inspect_blast_radius both focus on downstream impact analysis, creating potential confusion. Their descriptions differentiate them (diff-based vs. single-file-based), but agents may need careful reading to pick correctly.
All three tools follow a consistent verb_noun pattern in snake_case (analyze_diff_impact, get_repo_structure, inspect_blast_radius). The naming is predictable and stylistically uniform, making it easy to infer purpose.
Three tools is on the low end but well-scoped for the server's stated purpose of code structure and impact analysis. Each tool covers a distinct aspect, and the count feels reasonable, not sparse enough to seem incomplete or excessive.
The tool set covers structural overview, diff impact across versions, and blast radius for targeted changes—a solid read-only analysis surface. Minor gaps exist (e.g., no direct dependency graph query), but the core workflows are adequately supported without dead ends.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Codebase intelligence for AI agents — dead code, blast radius, ownership.
Search indexed code, trace dependencies, assess change impact, and recall repository memory.
