██████╗ ██████╗ ██████╗ ███████╗ █████╗ ████████╗██╗ █████╗ ███████╗
██╔════╝██╔═══██╗██╔══██╗██╔════╝ ██╔══██╗╚══██╔══╝██║ ██╔══██╗██╔════╝
██║ ██║ ██║██║ ██║█████╗ █████╗███████║ ██║ ██║ ███████║███████╗
██║ ██║ ██║██║ ██║██╔══╝ ╚════╝██╔══██║ ██║ ██║ ██╔══██║╚════██║
╚██████╗╚██████╔╝██████╔╝███████╗ ██║ ██║ ██║ ███████╗██║ ██║███████║
╚═════╝ ╚═════╝ ╚═════╝ ╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚══════╝╚═╝ ╚═╝╚══════╝
[ 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シンボルに対するセマンティックベクトル検索
コントリビューションを歓迎します！お気軽にプルリクエストを送信してください。
プロジェクトをフォークする
フィーチャーブランチを作成する（git checkout -b feature/AmazingFeature）
変更をコミットする（git commit -m 'Add some AmazingFeature'）
ブランチにプッシュする（git push origin feature/AmazingFeature）
プルリクエストを開く
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.
