██████╗ ██████╗ ██████╗ ███████╗ █████╗ ████████╗██╗ █████╗ ███████╗
██╔════╝██╔═══██╗██╔══██╗██╔════╝ ██╔══██╗╚══██╔══╝██║ ██╔══██╗██╔════╝
██║ ██║ ██║██║ ██║█████╗ █████╗███████║ ██║ ██║ ███████║███████╗
██║ ██║ ██║██║ ██║██╔══╝ ╚════╝██╔══██║ ██║ ██║ ██╔══██║╚════██║
╚██████╗╚██████╔╝██████╔╝███████╗ ██║ ██║ ██║ ███████╗██║ ██║███████║
╚═════╝ ╚═════╝ ╚═════╝ ╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚══════╝╚═╝ ╚═╝╚══════╝
[ M C P ]
Подключайте Claude Code, Claude Desktop и автономных AI-агентов напрямую к структурным AST-картам кода, токен-эффективным скелетам и анализу радиуса поражения PR.
Современные LLM-агенты для написания кода тратят до 70% своего контекстного окна на поглощение сырых деревьев файлов и избыточного содержимого файлов. При изменении больших кодовых баз AI-ассистенты часто не видят:
Нисходящих вызывающих и зависимых компонентов: Изменение сигнатуры экспортируемой функции ломает вызывающих её за 5 каталогов отсюда.
Раздувание токенов: Полные дампы файлов расходуют контекст на тела реализаций вместо определений типов и сигнатур.
Радиус поражения регрессий PR: Отсутствие информации о том, какие наборы модульных и интеграционных тестов покрывают изменённые AST-узлы.
code-atlas-mcp решает эту задачу, предоставляя AST-ориентированный интеллектуальный слой через стандартный Model Context Protocol (MCP). Он разбирает исходные файлы в структурные деревья символов, обрезает тела функций до токен-эффективных скелетов кода, изолирует изменённые AST-узлы в git-диффах и вычисляет транзитивный радиус поражения регрессий.
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_structureВозвращает иерархическую, AST-обрезанную структурную карту репозитория с опциональными токен-эффективными скелетами кода. Удаляет тела функций, сохраняя полные сигнатуры, экспортируемые интерфейсы, типы и docstring-комментарии.
Параметр | Тип | Обязательный | Описание | По умолчанию |
|
| Нет | Целевой каталог репозитория. | Текущий рабочий каталог |
|
| Нет | Генерировать токен-эффективные скелеты кода с удалёнными телами функций. |
|
|
| Нет | Максимальная глубина обхода каталогов (1-20). |
|
|
| Нет | Массив glob-шаблонов папок/файлов для игнорирования. |
|
|
| Нет | Массив разрешённых расширений (например, | Стандартные TS/JS |
{
"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_impactАнализирует изменённые AST-узлы между ветками, коммитами или незакоммиченным рабочим деревом для определения затронутых нисходящих функций, классов и компонентов.
Параметр | Тип | Обязательный | Описание | По умолчанию |
|
| Нет | Базовая git-ревизия или ветка (например, | Незакоммиченное рабочее дерево |
|
| Нет | Целевая git-ревизия или ветка (например, | Состояние рабочего дерева |
|
| Нет | Путь к корню git-репозитория. | Текущий рабочий каталог |
{
"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_radiusОпределяет потенциальные точки регрессий, транзитивных нисходящих зависимых (обход BFS) и сломанные наборы тестов для целевого изменения файла. Вычисляет оценку риска от 0 до 100 с указанием критических факторов.
Параметр | Тип | Обязательный | Описание | По умолчанию |
|
| Да | Путь к целевому исходному файлу (например, | — |
|
| Нет | Путь к корню репозитория. | Текущий рабочий каталог |
{
"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/projectДобавьте code-atlas-mcp в ваш 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"
]
}
}
}Если вы хотите закрепить конкретный каталог репозитория:
{
"mcpServers": {
"code-atlas": {
"command": "npx",
"args": [
"-y",
"code-atlas-mcp",
"--root",
"/absolute/path/to/your/repository"
]
}
}
}Запустите claude с подключённым MCP-сервером:
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 lintИзвлечение AST через TypeScript Compiler API
Генерация токен-эффективных скелетов (с удалёнными телами)
Сопоставление строк git-диффа с AST-узлами
Граф нисходящих зависимостей и анализ влияния на места вызовов
Проверка транзитивного радиуса поражения и определение наборов тестов
Транспорт stdio по стандарту MCP
Поддержка Python-движка парсинга AST (ast / Tree-sitter)
Модули парсинга AST для Rust и Go
Семантический векторный поиск по AST-символам
Вклад приветствуется! Пожалуйста, не стесняйтесь отправлять Pull Request.
Сделайте форк проекта
Создайте свою ветку функции (git checkout -b feature/AmazingFeature)
Зафиксируйте изменения (git commit -m 'Add some AmazingFeature')
Отправьте изменения в ветку (git push origin feature/AmazingFeature)
Откройте Pull Request
Распространяется под лицензией MIT. См. LICENSE для получения дополнительной информации.
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.
