How do I use code-atlas-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@code-atlas-mcp What files are impacted by my current branch changes?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

code-atlas-mcp

by GeorgeTsakonas

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

  ██████╗ ██████╗ ██████╗ ███████╗      █████╗ ████████╗██╗      █████╗ ███████╗
 ██╔════╝██╔═══██╗██╔══██╗██╔════╝     ██╔══██╗╚══██╔══╝██║     ██╔══██╗██╔════╝
 ██║     ██║   ██║██║  ██║█████╗ █████╗███████║   ██║   ██║     ███████║███████╗
 ██║     ██║   ██║██║  ██║██╔══╝ ╚════╝██╔══██║   ██║   ██║     ██╔══██║╚════██║
 ╚██████╗╚██████╔╝██████╔╝███████╗     ██║  ██║   ██║   ███████╗██║  ██║███████║
  ╚═════╝ ╚═════╝ ╚═════╝ ╚══════╝     ╚═╝  ╚═╝   ╚═╝   ╚══════╝╚═╝  ╚═╝╚══════╝
                                 [ M C P ]

High-Performance AST-Aware Model Context Protocol Server

License: MIT TypeScript Node.js MCP Standard Vitest

Connect Claude Code, Claude Desktop, and Autonomous AI Agents directly to structural AST code maps, token-efficient skeletons, and PR blast-radius impact analysis.

📖 Overview

Modern LLM coding agents spend up to 70% of their context window ingesting raw file trees and redundant file contents. When modifying large codebases, AI assistants often lack visibility into:

Downstream Callers & Dependents: Modifying an exported function signature breaks callers 5 directories away.
Token Inflation: Full-file dumps waste context on implementation bodies instead of type definitions and signatures.
PR Regression Blast Radius: Lack of awareness about which unit and integration test suites cover the modified AST nodes.

code-atlas-mcp solves this by exposing an AST-aware intelligence layer via the standard Model Context Protocol (MCP). It parses source files into structural symbol trees, prunes function bodies into token-efficient code skeletons, isolates modified AST nodes across git diffs, and computes transitive regression blast radius.

Related MCP server: MCP Filesystem Server

🏛️ Architecture

┌────────────────────────────────────────────────────────────────────────┐
│                        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                 │
└────────────────────────────────────────────────────────────────────────┘

⚡ Core MCP Tools

1. `get_repo_structure`

Returns a hierarchical, AST-pruned structural map of the repository with optional token-efficient code skeletons. Strips function bodies while preserving complete signatures, exported interfaces, types, and docstrings.

Parameters

Parameter	Type	Required	Description	Default
`rootDir`	`string`	No	Target repository directory.	Current working directory
`includeSkeletons`	`boolean`	No	Generate token-efficient code skeletons with stripped function bodies.	`true`
`maxDepth`	`number`	No	Maximum directory traversal depth (1-20).	`5`
`ignorePatterns`	`string[]`	No	Array of folder/file glob patterns to ignore.	`[]`
`fileExtensions`	`string[]`	No	Array of allowed extensions (e.g. `['.ts', '.tsx']`).	Standard TS/JS

Example Tool Output

{
  "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>;"
        }
      }
    ]
  }
}

2. `analyze_diff_impact`

Analyzes modified AST nodes between branches, commits, or the uncommitted working tree to determine affected downstream functions, classes, and components.

Parameters

Parameter	Type	Required	Description	Default
`baseRef`	`string`	No	Base git revision or branch (e.g. `'main'`, `'HEAD~1'`).	Uncommitted working tree
`headRef`	`string`	No	Head git revision or branch (e.g. `'feature-auth'`, `'HEAD'`).	Working tree state
`repoPath`	`string`	No	Path to git repository root.	Current working directory

Example Tool Output

{
  "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."
}

3. `inspect_blast_radius`

Identifies potential regression points, transitive downstream dependents (BFS traversal), and broken test suites for a targeted file change. Calculates a 0-100 risk score with critical factors.

Parameters

Parameter	Type	Required	Description	Default
`targetFile`	`string`	Yes	Path to the target source file (e.g. `'src/services/ast-engine.ts'`).	—
`repoPath`	`string`	No	Path to repository root.	Current working directory

Example Tool Output

{
  "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"
    ]
  }
}

🚀 Installation & Quick Start

Global CLI Installation

npm install -g code-atlas-mcp

Run Directly via NPX

npx code-atlas-mcp --root /path/to/your/project

🤖 Claude Integration Configuration

Claude Desktop Setup

Add code-atlas-mcp to your 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"
      ]
    }
  }
}

If you want to pin a specific repository directory:

{
  "mcpServers": {
    "code-atlas": {
      "command": "npx",
      "args": [
        "-y",
        "code-atlas-mcp",
        "--root",
        "/absolute/path/to/your/repository"
      ]
    }
  }
}

Claude Code CLI Setup

Launch claude with the MCP server attached:

claude --mcp-server "npx -y code-atlas-mcp"

🛠️ Development & Testing

Prerequisites

Node.js >= 18.0.0
npm >= 9.0.0
Git CLI

Setup

# 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

🗺️ Roadmap

TypeScript Compiler API AST extraction
Token-efficient skeleton generation (stripped bodies)
Git diff line-to-AST node correlation
Downstream dependency graph & call-site impact analysis
Transitive blast-radius inspection & test suite identification
MCP Standard stdio transport
Python AST parser engine support (ast / Tree-sitter)
Rust and Go AST parsing modules
Semantic vector search over AST symbols

🤝 Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Fork the Project
Create your Feature Branch (git checkout -b feature/AmazingFeature)
Commit your Changes (git commit -m 'Add some AmazingFeature')
Push to the Branch (git push origin feature/AmazingFeature)
Open a Pull Request

📄 License

Distributed under the MIT License. See LICENSE for more information.

Available Tools

3 tools

analyze_diff_impactB

Analyzes modified AST nodes between branches, commits, or uncommitted working tree to determine affected downstream functions, classes, and components.

ParametersJSON Schema

Name	Required	Description
`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.

TDQS

B3.1/5.0

Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

get_repo_structureB

Returns a hierarchical, AST-pruned structural map of the repository with token-efficient code skeletons, stripping implementation bodies to save context tokens.

ParametersJSON Schema

Name	Required	Description
`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.

TDQS

B3.4/5.0

Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

inspect_blast_radiusB

Identifies potential regression points, direct and transitive downstream dependents, and broken test suites for a targeted file change.

ParametersJSON Schema

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').

TDQS

B3.3/5.0

Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv1.0.0Aug 27, 2026
- First observedanalyze_diff_impact
- First observedget_repo_structure
- First observedinspect_blast_radius

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored 2026-08-27 10:55 across 3 tools

Disambiguation3/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Brain ScannerOAuth
io.github.kevin-lozada-santos
Codebase graphs, caller impact analysis, and recorded project context for AI coding agents.
Code Analysis Developer Tools Knowledge & Memory
1
ArchGraphOAuth
dev.archgraph
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Code Analysis Software Architecture Developer Tools
2
SpiderbrainOAuth
ai.spiderbrain
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Code Analysis Developer Tools RAG Systems
13
Mapnostics
io.github.ffteema
Codebase intelligence for AI agents — dead code, blast radius, ownership.
Code Analysis Developer Tools
1

Related MCP Servers

XRAY MCP
Code Analysis Developer Tools
srijanshukla18
A
license
A
quality
D
maintenance
Enables AI assistants to understand and navigate codebases through structural analysis. Provides code mapping, symbol search, and impact analysis using ast-grep for accurate parsing of Python, JavaScript, TypeScript, and Go projects.
Updated 9 months ago (2025-12-11 12:41 UTC)
4
52
MIT
MCP Filesystem Server
Code Analysis Developer Tools File Systems
williamRR
A
license
Not graded
quality
D
maintenance
Provides LLM-optimized tools for advanced code analysis, repository complexity evaluation, and call graph generation. It enables users to visualize directory structures, detect code patterns, and build semantic context with significant token savings.
Updated 5 months ago (2026-04-09 08:56 UTC)
8 npm
MIT
mcp-repo-graph
Developer Tools Knowledge & Memory RAG Systems
James-Chahwan
A
license
A
quality
A
maintenance
Structural graph map of any codebase. Scans entities, relationships, and feature flows across 13 languages so LLMs navigate by structure instead of reading everything.
Updated 14 hours ago (2026-09-16 03:22 UTC)
6
130 PyPI
15
MIT
mcp-code-context
Developer Tools Code Analysis
achatainga
A
license
B
quality
B
maintenance
Enables LLMs to efficiently read, write, and refactor code using precise AST-based operations, reducing token usage and context window waste.
Updated 2 months ago (2026-07-17 21:47 UTC)
25
27 npm
3
MIT

High-Performance AST-Aware Model Context Protocol Server

📖 Overview

🏛️ Architecture

⚡ Core MCP Tools

1. get_repo_structure

Parameters

Example Tool Output

2. analyze_diff_impact

Parameters

Example Tool Output

3. inspect_blast_radius

Parameters

Example Tool Output

🚀 Installation & Quick Start

Global CLI Installation

Run Directly via NPX

🤖 Claude Integration Configuration

Claude Desktop Setup

Claude Code CLI Setup

🛠️ Development & Testing

Prerequisites

Setup

🗺️ Roadmap

🤝 Contributing

📄 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. `get_repo_structure`

2. `analyze_diff_impact`

3. `inspect_blast_radius`