██████╗ ██████╗ ██████╗ ███████╗ █████╗ ████████╗██╗ █████╗ ███████╗
██╔════╝██╔═══██╗██╔══██╗██╔════╝ ██╔══██╗╚══██╔══╝██║ ██╔══██╗██╔════╝
██║ ██║ ██║██║ ██║█████╗ █████╗███████║ ██║ ██║ ███████║███████╗
██║ ██║ ██║██║ ██║██╔══╝ ╚════╝██╔══██║ ██║ ██║ ██╔══██║╚════██║
╚██████╗╚██████╔╝██████╔╝███████╗ ██║ ██║ ██║ ███████╗██║ ██║███████║
╚═════╝ ╚═════╝ ╚═════╝ ╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚══════╝╚═╝ ╚═╝╚══════╝
[ M C P ]
Claude Code, Claude Desktop, 자율 AI 에이전트를 구조적 AST 코드 맵, 토큰 효율적 스켈레톤, PR 블래스트 반경 영향 분석에 직접 연결하세요.
최신 LLM 코딩 에이전트는 컨텍스트 윈도우의 최대 70% 를 원시 파일 트리와 중복된 파일 내용을 읽는 데 소비합니다. 대규모 코드베이스를 수정할 때 AI 어시스턴트는 종종 다음에 대한 가시성이 부족합니다:
다운스트림 호출자 및 의존자: 내보낸 함수 시그니처를 수정하면 5개 디렉터리 떨어진 호출자가 깨집니다.
토큰 인플레이션: 전체 파일 덤프는 타입 정의와 시그니처 대신 구현 본문에 컨텍스트를 낭비합니다.
PR 회귀 블래스트 반경: 수정된 AST 노드를 커버하는 단위 및 통합 테스트 스위트에 대한 인식 부족.
code-atlas-mcp 는 표준 Model Context Protocol (MCP) 을 통해 AST 인지 인텔리전스 레이어를 노출하여 이 문제를 해결합니다. 소스 파일을 구조적 심볼 트리로 파싱하고, 함수 본문을 토큰 효율적 코드 스켈레톤으로 정리하며, git diff 전반의 수정된 AST 노드를 분리하고, 전이적 회귀 블래스트 반경을 계산합니다.
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/projectcode-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"
]
}
}
}MCP 서버를 연결한 상태로 claude를 실행하세요:
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 lintTypeScript Compiler API AST 추출
토큰 효율적 스켈레톤 생성 (본문 제거)
Git diff 라인 대 AST 노드 상관관계 매핑
다운스트림 의존성 그래프 및 호출 지점 영향 분석
전이적 블래스트 반경 검사 및 테스트 스위트 식별
MCP 표준 stdio 전송
Python AST 파서 엔진 지원 (ast / Tree-sitter)
Rust 및 Go AST 파싱 모듈
AST 심볼에 대한 의미론적 벡터 검색
기여는 언제나 환영합니다! 자유롭게 Pull Request를 제출해 주세요.
프로젝트를 Fork 하세요
기능 브랜치를 생성하세요 (git checkout -b feature/AmazingFeature)
변경 사항을 커밋하세요 (git commit -m 'Add some AmazingFeature')
브랜치에 푸시하세요 (git push origin feature/AmazingFeature)
Pull Request를 여세요
MIT License 하에 배포됩니다. 자세한 내용은 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.
