Skip to main content
Glama
Code Understanding MCP Server

Code Understanding MCP Server

⚠️ Platform Support Notice

This MCP server has been tested on macOS and Linux. Windows support is currently unverified (not yet tested).

If you try Windows and encounter issues, please open an issue so we can improve cross-platform support.

Code Understanding MCP Server

An MCP (Model Context Protocol) server designed to understand codebases and provide intelligent context to AI coding assistants. This server handles both local and remote GitHub repositories and supports standard MCP-compliant operations.

🤖 AI Assistant Installation

Have an AI coding assistant help you install this server! Copy and paste the contents of our Setup Assistant Prompt to your AI assistant (Claude, ChatGPT, Cursor, etc.) and it will guide you through the entire installation process.

Related MCP server: cctx-mcp

Features

  • Clone and analyze GitHub repositories or local codebases

  • Get repository structure and file organization

  • Identify critical files based on complexity metrics and code structure

  • Generate detailed repository maps showing:

    • Function signatures and relationships

    • Class definitions and hierarchies

    • Code structure and dependencies

  • Retrieve and analyze repository documentation

  • Target analysis to specific files or directories

  • Keep analysis up-to-date with repository changes via refresh

Quick Start: MCP Client Configuration

Prerequisites

Required: uv Installation

This server requires uv, a modern Python package manager. If you don't already have uv installed:

# Install UV (macOS/Linux)
curl -sSf https://astral.sh/uv/install.sh | sh

# Install UV (Windows PowerShell)
irm https://astral.sh/uv/install.ps1 | iex

For more installation options, visit the official uv installation guide at astral.sh/uv.

Installation Methods

# Run directly without installing a global binary
uvx code-understanding-mcp-server

This launches the server in an isolated environment managed by UV each time.

Method 2: Virtual environment install (Optional)

If you prefer a persistent binary inside a dedicated virtual environment:

# Create a dedicated virtual environment
uv venv ~/.venvs/mcp-code-understanding

# Activate it (macOS/Linux)
source ~/.venvs/mcp-code-understanding/bin/activate

# Install the package into the venv
uv pip install code-understanding-mcp-server

# Run the server
code-understanding-mcp-server

Verify Installation

Depending on your chosen method:

# Method 1 (uvx): runs via uvx; no persistent binary is installed
uvx --version

# Method 2 (venv install): verify the binary inside your venv
which code-understanding-mcp-server
# Expected output example: /Users/username/.venvs/mcp-code-understanding/bin/code-understanding-mcp-server

Configure Your MCP Client

Use one of the following configurations for your MCP client:

{
  "mcpServers": {
    "code-understanding": {
      "command": "uvx",
      "args": [
        "code-understanding-mcp-server"
      ]
    }
  }
}

Alternatively, if you installed into a virtual environment, point directly to the binary in that environment:

{
  "mcpServers": {
    "code-understanding": {
      "command": "/path/to/.venvs/mcp-code-understanding/bin/code-understanding-mcp-server",
      "args": []
    }
  }
}

Why Use this MCP Server?

MCP Code Understanding Server

Value Proposition

The MCP Code Understanding Server empowers AI assistants with comprehensive code comprehension capabilities, enabling them to provide more accurate, contextual, and practical assistance with software development tasks. By creating a semantic bridge between repositories and AI systems, this server dramatically reduces the time and friction involved in code exploration, analysis, and implementation guidance.

Common Use Cases

Reference Repository Analysis

  • Examine external repositories (libraries, dependencies, etc.) to inform current development

  • Find implementation patterns and examples in open-source projects

  • Understand how specific libraries work internally when documentation is insufficient

  • Compare implementation approaches across similar projects

  • Identify best practices from high-quality codebases

Knowledge Extraction and Documentation

  • Generate comprehensive documentation for poorly documented codebases

  • Create architectural overviews and component relationship diagrams

  • Develop progressive learning paths for developer onboarding

  • Extract business logic and domain knowledge embedded in code

  • Identify and document system integration points and dependencies

Codebase Assessment and Improvement

  • Analyze technical debt and prioritize refactoring efforts

  • Identify security vulnerabilities and compliance issues

  • Assess test coverage and quality

  • Detect dead code, duplicated logic, and optimization opportunities

  • Evaluate implementation against design patterns and architectural principles

Legacy System Understanding

  • Recover knowledge from systems with minimal documentation

  • Support migration planning by understanding system boundaries

  • Analyze complex dependencies before making changes

  • Trace feature implementations across multiple components

  • Understand historical design decisions and their rationales

Cross-Project Knowledge Transfer

  • Apply patterns from one project to another

  • Bridge knowledge gaps between teams working on related systems

  • Identify reusable components across multiple projects

  • Understand differences in implementation approaches between teams

  • Facilitate knowledge sharing in distributed development environments

For detailed examples of how the MCP Code Understanding Server can be used in real-world scenarios, see our Example Scenarios document. It includes step-by-step walkthroughs of:

  • Accelerating developer onboarding to a complex codebase

  • Planning and executing API migrations

  • Conducting security vulnerability assessments

How It Works

The MCP Code Understanding Server processes repositories through a series of analysis steps:

  1. Repository Cloning: The server clones the target repository into its cache

  2. Structure Analysis: Analysis of directories, files, and their organization

  3. Critical File Identification: Determination of structurally significant components

  4. Documentation Retrieval: Collection of all documentation files

  5. Semantic Mapping: Creation of a detailed map showing relationships between components

  6. Content Analysis: Examination of specific files as needed for deeper understanding

AI assistants integrate with the server by making targeted requests for each analytical stage, building a comprehensive understanding of the codebase that can be used to address specific user questions and needs.

When working with repositories, AI assistants should follow this workflow for optimal results:

  1. Check Cache First: Use list_cached_repository_branches to see if the repository is already cached

    • If cached: Skip to step 3 (refresh)

    • If not cached: Continue to step 2

  2. Discover Branch Names: Many repositories use "master", "develop", or other names instead of "main"

    • Use list_remote_branches to discover available branches

    • Identify the correct default branch before cloning

  3. Refresh Before Analysis: Cached repositories become stale over time

    • Use refresh_repo to pull latest changes before any analysis

    • This ensures analysis is based on current code, not outdated cache

  4. Perform Analysis: Once repository is current, use analysis tools

    • get_source_repo_map for code structure

    • get_repo_critical_files for identifying key components

    • get_repo_documentation for documentation discovery

This workflow prevents common issues like clone failures from incorrect branch names, redundant clone attempts, and analysis based on stale cached data.

Design Considerations for Large Codebases

The server employs several strategies to maintain performance and usability even with enterprise-scale repositories:

  • Asynchronous Processing: Repository cloning and analysis occur in background threads, providing immediate feedback while deeper analysis continues

  • Progressive Analysis: Initial quick analysis enables immediate interaction, with more detailed understanding building over time

  • Scope Control: Parameters for max_tokens, files, and directories enable targeted analysis of specific areas of interest

  • Threshold Management: Automatic detection of repository size with appropriate guidance for analysis strategies

  • Hierarchical Understanding: Repository structure is analyzed first, enabling intelligent prioritization of critical components for deeper semantic analysis

These design choices ensure that developers can start working immediately with large codebases while the system builds a progressively deeper understanding in the background, striking an optimal balance between analysis depth and responsiveness.

GitHub Authentication (Optional)

If you need to access private repositories or want to avoid GitHub API rate limits, add your GitHub token to the configuration:

{
  "mcpServers": {
    "code-understanding": {
      "command": "/path/to/code-understanding-mcp-server",
      "args": [],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your-github-token-here"
      }
    }
  }
}

Advanced Configuration Options

For advanced users, the server supports several configuration options:

{
  "mcpServers": {
    "code-understanding": {
      "command": "/path/to/code-understanding-mcp-server",
      "args": [
        "--cache-dir", "~/custom-cache-dir",     // Override repository cache location
        "--max-cached-repos", "20",              // Override maximum number of cached repos
        "--transport", "stdio",                  // Transport type (stdio or sse)
        "--port", "3001"                         // Port for SSE transport (only used with sse)
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your-github-token-here"
      }
    }
  }
}

Available options:

  • --cache-dir: Override the repository cache directory location (default: ~/.cache/mcp-code-understanding)

  • --max-cached-repos: Set maximum number of cached repositories (default: 10)

  • --transport: Choose transport type (stdio or sse, default: stdio)

  • --port: Set port for SSE transport (default: 3001, only used with sse transport)

Platform-Specific Notes

macOS

  • With uvx, no persistent binary is installed; no PATH changes are required

  • With a virtual environment, ensure you activate it or reference the full path to the venv binary

Linux

  • With uvx, no persistent binary is installed; no PATH changes are required

  • With a virtual environment, you may prefer adding a helper alias or activating the venv before use

Windows

  • Not currently supported - Windows support is planned for a future release

  • Development work is ongoing to enable Windows compatibility

Troubleshooting

Dependency Conflicts

If you encounter dependency conflicts when using uvx, create an isolated environment and install the package there:

# Create a dedicated virtual environment
uv venv ~/.venvs/mcp-code-understanding

# Activate it (macOS/Linux)
source ~/.venvs/mcp-code-understanding/bin/activate

# Install the package
uv pip install code-understanding-mcp-server

# Run the server
code-understanding-mcp-server

Binary Not Found

If the installed binary is not found:

  1. Check installation location:

    # macOS/Linux
    find ~/.local -name "code-understanding-mcp-server" 2>/dev/null
  2. Add to PATH if needed:

    # Add to ~/.bashrc, ~/.zshrc, or appropriate shell config
    export PATH="$HOME/.local/bin:$PATH"
  3. Use the absolute path to your venv binary in MCP configuration if not activating the venv

Server Configuration

The server uses a config.yaml file for base configuration. This file is automatically created in the standard configuration directory (~/.config/mcp-code-understanding/config.yaml) when the server first runs. You can also place a config.yaml file in your current directory to override the default configuration.

Here's the default configuration structure:

name: "Code Understanding Server"
log_level: "debug"

repository:
  cache_dir: "~/.cache/mcp-code-understanding"
  max_cached_repos: 10

documentation:
  include_tags:
    - markdown
    - rst
    - adoc
  include_extensions:
    - .md
    - .markdown
    - .rst
    - .txt
    - .adoc
    - .ipynb
  format_mapping:
    tag:markdown: markdown
    tag:rst: restructuredtext
    tag:adoc: asciidoc
    ext:.md: markdown
    ext:.markdown: markdown
    ext:.rst: restructuredtext
    ext:.txt: plaintext
    ext:.adoc: asciidoc
    ext:.ipynb: jupyter
  category_patterns:
    readme: 
      - readme
    api: 
      - api
    documentation:
      - docs
      - documentation
    examples:
      - examples
      - sample

For Developers

Prerequisites

  • Python 3.11 or 3.12: Required for both development and usage

    # Verify your Python version
    python --version
    # or
    python3 --version
  • UV Package Manager: The modern Python package installer

    # Install UV
    curl -sSf https://astral.sh/uv/install.sh | sh

Development Setup

To contribute or run this project locally:

# 1. Clone the repository
git clone https://github.com/yourusername/mcp-code-understanding.git
cd mcp-code-understanding

# 2. Create virtual environment
uv venv

# 3. Activate the virtual environment
#    Choose the command appropriate for your operating system and shell:

#    Linux/macOS (bash/zsh):
source .venv/bin/activate

#    Windows (Command Prompt - cmd.exe):
.venv\\Scripts\\activate.bat

#    Windows (PowerShell):
#    Note: You might need to adjust your execution policy first.
#    Run: Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process
.venv\\Scripts\\Activate.ps1

# 4. Install dependencies (editable mode with dev extras)
#    (Ensure your virtual environment is activated first!)
uv pip install -e ".[dev]"

# 5. Set up pre-commit hooks
pre-commit install

# 6. Run tests
uv run pytest

# 7. Test the server using MCP inspector
# Without GitHub authentication:
uv run mcp dev src/code_understanding/mcp/server/app.py

# With GitHub authentication (for testing private repos):
GITHUB_PERSONAL_ACCESS_TOKEN=your_token_here uv run mcp dev src/code_understanding/mcp/server/app.py

This will launch an interactive console where you can test all MCP server endpoints directly.

Development Tools

The following development tools are available after installing with dev extras (.[dev]):

Run tests with coverage:

uv run pytest

Format code (using black and isort):

# Format with black
uv run black .

# Sort imports
uv run isort .

Type checking with mypy:

uv run mypy .

All tools are configured via pyproject.toml with settings optimized for this project.

Publishing to PyPI

When you're ready to publish a new version to PyPI, follow these steps:

  1. Update the version number in pyproject.toml:

    # Edit pyproject.toml and change the version field
    # For example: version = "0.1.1"
  2. Clean previous build artifacts:

    # Remove previous distribution packages and build directories
    rm -rf dist/ 2>/dev/null || true
    rm -rf build/ 2>/dev/null || true
    rm -rf src/*.egg-info/ 2>/dev/null || true
  3. Build the distribution packages:

    uv run python -m build
  4. Verify the built packages:

    ls dist/
  5. Upload to PyPI (use TestPyPI first if unsure):

    # Install twine if you haven't already
    uv pip install twine
    
    # For PyPI release:
    uv run python -m twine upload dist/*

You'll need PyPI credentials configured or you'll be prompted to enter them during upload.

Version History

v0.1.6 (Latest)

  • Dependency Fix: Explicitly pinned configargparse==1.7 to resolve installation issues caused by the yanked version in PyPI

  • This ensures clean installation with uvx and other package managers by preventing dependency resolution failures

  • No functional changes to the server capabilities

License

MIT

Available Tools

10 tools
clone_repoA
    Clone a repository into MCP server's cache and prepare it for analysis.

    This tool must be called before using analysis endpoints like get_source_repo_map
    or get_repo_documentation. It copies the repository into MCP's cache and
    automatically starts building a repository map in the background.

    IMPORTANT - BEFORE CLONING:
        1. CHECK IF ALREADY CACHED: Use list_cached_repository_branches(url) first to avoid
           redundant clone attempts. Returns empty list if not cached, or existing branches if cached.

        2. VERIFY DEFAULT BRANCH NAME: Many repositories use "master", "develop", or other names
           instead of "main". If branch is not specified and clone fails:
           - Use list_remote_branches(url) to discover available branches
           - Look for "main", "master", "develop", or check repo documentation
           - Explicitly specify the correct branch parameter

        3. AFTER CLONING: The cached repository can become stale over time. Before analysis,
           consider using refresh_repo() to ensure you're working with the latest code.

    Args:
        url (str): URL of remote repository or path to local repository to analyze
        branch (str, optional): Specific branch to clone for analysis. Defaults to "main" if not
            specified, but many repositories use "master" or other names - verify first!
        cache_strategy (str, optional): Cache strategy - "shared" (default) or "per-branch"
            - "shared": One cache entry per repo, switch branches in place
            - "per-branch": Separate cache entries for each branch (useful for PR reviews)

    Returns:
        dict: Response with format:
            {
                "status": "pending" | "already_cloned" | "switched_branch" | "error",
                "path": str,  # Cache location where repo is being cloned
                "message": str,  # Status message about clone and analysis
                "cache_strategy": str,  # Strategy used for caching
                "current_branch": str,  # (if applicable) Current active branch
                "previous_branch": str,  # (if switched) Previous branch name
            }

    Recommended Workflow:
        1. Check cache: cached = list_cached_repository_branches(url)
        2. If not cached, discover branches: branches = list_remote_branches(url)
        3. Clone with correct branch: clone_repo(url, branch=discovered_branch)
        4. Before analysis, refresh if needed: refresh_repo(url)
        5. Perform analysis: get_source_repo_map(url, ...)

    Note:
        - This is a setup operation for MCP analysis only
        - Does not modify the source repository
        - Repository map building starts automatically after clone completes
        - Use get_source_repo_map to check analysis status and retrieve results
        - Per-branch strategy allows simultaneous access to different branches
    

Inputs: url (required), branch, cache_strategy.

get_repo_critical_filesB
    Analyze and identify the most structurally significant files in a codebase.

    Uses code complexity metrics to calculate importance scores, helping identify
    files that are most critical for understanding the system's structure.

    Args:
        repo_path: Path/URL matching what was provided to clone_repo
        files: Optional list of specific files to analyze
        directories: Optional list of specific directories to analyze
        limit: Maximum number of files to return (default: 50)
        include_metrics: Include detailed metrics in response (default: True)

    Returns:
        dict: {
            "status": str,  # "success", "error"
            "files": [{
                "path": str,
                "importance_score": float,
                "metrics": {  # Only if include_metrics=True
                    "total_ccn": int,
                    "max_ccn": int,
                    "function_count": int,
                    "nloc": int
                }
            }],
            "total_files_analyzed": int
        }
    

Inputs: repo_path (required), files, limit, branch, +3 more.

get_repo_documentationA
    Retrieve and analyze repository documentation files.

    Searches for and analyzes documentation within the repository, including:
    - README files
    - API documentation
    - Design documents
    - User guides
    - Installation instructions
    - Other documentation files

    Args:
        repo_path (str): Path or URL matching what was originally provided to clone_repo

    Returns:
        dict: Documentation analysis results with format:
            {
                "status": str,  # "success", "error", or "waiting"
                "message": str,  # Only for error/waiting status
                "documentation": {  # Only for success status
                    "files": [
                        {
                            "path": str,      # Relative path in repo
                            "category": str,  # readme, api, docs, etc.
                            "format": str     # markdown, rst, etc.
                        }
                    ],
                    "directories": [
                        {
                            "path": str,
                            "doc_count": int
                        }
                    ],
                    "stats": {
                        "total_files": int,
                        "by_category": dict,
                        "by_format": dict
                    }
                }
            }
    

Inputs: repo_path (required), branch, cache_strategy.

get_repo_file_contentA
    Retrieve file contents or directory listings from a repository.

    Args:
        repo_path (str): Path or URL to the repository
        resource_path (str, optional): Path to the target file or directory within the repository. Defaults to the repository root if not provided.
        branch (str, optional): Specific branch to read from (only used with per-branch cache strategy)
        cache_strategy (str, optional): Cache strategy - "shared" (default) or "per-branch"

    Returns:
        dict: For files:
            {
                "type": "file",
                "path": str,  # Relative path within repository
                "content": str,  # Complete file contents
                "branch": str,  # Current branch name
                "cache_strategy": str  # Cache strategy used
            }
            For directories:
            {
                "type": "directory",
                "path": str,  # Relative path within repository
                "contents": List[str],  # List of immediate files and subdirectories
                "branch": str,  # Current branch name
                "cache_strategy": str  # Cache strategy used
            }

    Note:
        Directory listings are not recursive - they only show immediate contents.
        To explore subdirectories, make additional calls with the subdirectory path.
    

Inputs: repo_path (required), branch, resource_path, cache_strategy.

get_repo_structureA
    Get repository structure information with optional file listings.

    Args:
        repo_path: Path/URL matching what was provided to clone_repo
        directories: Optional list of directories to limit results to
        include_files: Whether to include list of files in response

    Returns:
        dict: {
            "status": str,
            "message": str,
            "directories": [{
                "path": str,
                "analyzable_files": int,
                "extensions": {
                    "py": 10,
                    "java": 5,
                    "ts": 3
                },
                "files": [str]  # Only present if include_files=True
            }],
            "total_analyzable_files": int
        }
    

Inputs: repo_path (required), branch, directories, include_files, +1 more.

get_source_repo_mapA
    Retrieve a semantic analysis map of the repository's code structure.

    Returns a detailed map of the repository's structure, including file hierarchy,
    code elements (functions, classes, methods), and their relationships. Can analyze
    specific files/directories or the entire repository.

    Args:
        repo_path (str): Path or URL matching what was originally provided to clone_repo
        files (List[str], optional): Specific files to analyze. If None, analyzes all files
        directories (List[str], optional): Specific directories to analyze. If None, analyzes all directories
        max_tokens (int, optional): Limit total tokens in analysis. Useful for large repositories
        branch (str, optional): Specific branch to analyze (only used with per-branch cache strategy)
        cache_strategy (str, optional): Cache strategy - "shared" (default) or "per-branch"

    Returns:
        dict: Response with format:
            {
                "status": str,  # "success", "building", "waiting", or "error"
                "content": str,  # Hierarchical representation of code structure
                "metadata": {    # Analysis metadata
                    "excluded_files_by_dir": dict,
                    "is_complete": bool,
                    "max_tokens": int
                },
                "message": str,  # Present for "building"/"waiting" status
                "error": str     # Present for "error" status
            }

    Note:
        - Repository must be previously cloned using clone_repo
        - Initial analysis happens in background after clone
        - Returns "building" status while analysis is in progress
        - Content includes file structure, code elements, and their relationships
        - For large repos, consider using max_tokens or targeting specific directories
    

Inputs: repo_path (required), files, branch, max_tokens, +2 more.

list_cached_repository_branchesA
    Check if a repository is already cached and list all cached branch versions.

    USE THIS FIRST before calling clone_repo to avoid redundant clone attempts.
    If the repository is already cached, you can proceed directly to refresh_repo
    and analysis instead of cloning again.

    This tool scans the MCP cache to find all entries for a given repository URL,
    showing both shared and per-branch cache entries. Useful for understanding
    what branches are available and their current status.

    Args:
        repo_url (str): Repository URL to search for (must match exact URL used in clone_repo)

    Returns:
        dict: Response with format:
            {
                "status": "success" | "error",
                "repo_url": str,  # Repository URL searched
                "cached_branches": [  # List of cached branch entries (empty if not cached)
                    {
                        "requested_branch": str,  # Branch that was requested during clone
                        "current_branch": str,    # Current active branch in the cache
                        "cache_path": str,        # File system path to cached repository
                        "cache_strategy": str,    # "shared" or "per-branch"
                        "last_access": str,       # ISO timestamp of last access
                        "clone_status": dict,     # Clone operation status
                        "repo_map_status": dict   # Repository map build status
                    }
                ],
                "total_cached": int  # Total number of cached entries (0 if not cached)
            }

    Typical Workflow:
        1. Check cache first: result = list_cached_repository_branches(url)
        2. If result["total_cached"] > 0:
           - Repository is cached, skip clone
           - Use refresh_repo(url) to update cached code
        3. If result["total_cached"] == 0:
           - Repository not cached yet
           - Use list_remote_branches(url) to discover branch names
           - Use clone_repo(url, branch=correct_branch)

    Note:
        - Only returns repositories that have been cloned via clone_repo
        - Empty cached_branches list means repository is NOT cached
        - Useful for PR review workflows to see all available branch versions
        - Shows both active and completed cache entries
        - Helps identify which cache strategy was used for each entry
    

Inputs: repo_url (required).

list_remote_branchesA
    Discover all available branches in a remote repository without cloning.

    CRITICAL USE CASE: Many repositories use "master", "develop", or other names instead
    of "main" as their default branch. Use this tool BEFORE clone_repo to discover the
    actual default branch name and avoid clone failures.

    This tool uses git ls-remote --heads to query the remote repository, which is fast
    and does not require cloning the entire repository.

    Args:
        repo_url (str): Remote repository URL (e.g., https://github.com/user/repo)

    Returns:
        dict: Response with format:
            {
                "status": "success" | "error",
                "repo_url": str,  # Repository URL queried
                "remote_branches": [str],  # List of branch names (e.g., ["main", "develop", "feature-x"])
                "total_remote": int,  # Total number of branches found
                "error": str  # (Only on error) Error message
            }

    Common Default Branch Names to Look For:
        - "main" (modern GitHub default)
        - "master" (traditional Git default)
        - "develop" or "development" (common for dev workflows)
        - Check repository documentation if unclear

    Typical Workflow:
        1. Discover branches: branches = list_remote_branches(url)
        2. Identify default branch from branches["remote_branches"]
           - Look for "main", "master", or "develop"
           - If unsure, check the repository's web page
        3. Clone with correct branch: clone_repo(url, branch=identified_branch)

    Note:
        - Fast operation, does not clone the repository
        - Requires network access to the remote repository
        - Works with any Git repository (GitHub, GitLab, Bitbucket, etc.)
    

Inputs: repo_url (required).

list_repository_branchesD

Inputs: repo_url (required).

refresh_repoA
    Update a previously cloned repository in MCP's cache and refresh its analysis.

    CRITICAL: Cached repositories become stale over time. ALWAYS refresh before analysis
    to ensure you're working with the latest code. Failure to refresh means your analysis
    may be based on outdated code that could be days, weeks, or months old.

    For Git repositories, performs a git pull to get latest changes.
    For local directories, copies the latest content from the source.
    Then triggers a new repository map build to ensure all analysis is based on
    the updated code.

    RECOMMENDED WORKFLOW:
        1. Check if repository is cached: list_cached_repository_branches(url)
        2. If cached, ALWAYS refresh first: refresh_repo(url)
        3. Wait a moment for refresh to complete
        4. Then perform analysis: get_source_repo_map(url, ...)

        This ensures your analysis reflects current code, not stale cached data.

    Args:
        repo_path (str): Path or URL matching what was originally provided to clone_repo
        branch (str, optional): Specific branch to switch to during refresh
        cache_strategy (str, optional): Cache strategy - must match original clone strategy

    Returns:
        dict: Response with format:
            {
                "status": str,  # "pending", "switched_branch", "error"
                "path": str,    # (On pending) Cache location being refreshed
                "message": str, # (On pending) Status message
                "error": str    # (On error) Error message
                "cache_strategy": str  # Strategy used for caching
            }

    Note:
        - Repository must be previously cloned and have completed initial analysis
        - Updates MCP's cached copy, does not modify the source repository
        - Automatically triggers rebuild of repository map with updated files
        - If branch is specified, switches to that branch after pulling latest changes
        - cache_strategy should match the strategy used during original clone
        - Operation runs in background, check get_repo_map_content for status
    

Inputs: repo_path (required), branch, cache_strategy.

Tool Schema Changelog

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

Loading tool schema changelog…

    TDQS

    C2.9/5.0

    Scored across 10 tools

    Disambiguation3/5

    Tools are mostly distinct but there is overlap between get_repo_structure and get_source_repo_map, and between get_repo_file_content and get_repo_structure. The tool list_repository_branches has no description, causing ambiguity.

    Naming Consistency3/5

    Naming uses a mix of 'get_', 'list_', 'clone_', 'refresh_' but inconsistently uses 'repo' vs 'repository' (e.g., clone_repo vs list_cached_repository_branches). The naming is readable but not fully consistent.

    Tool Count4/5

    10 tools are a reasonable number for a code understanding server, though some tools have overlapping functionality. The count is slightly above the ideal range but not excessive.

    Completeness3/5

    The tool surface covers core cloning, caching, and analysis operations, but lacks common features like code search, diff, or blame. The list_repository_branches tool is undescribed, indicating a gap.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      An MCP server that provides structure-aware code analysis (symbol trees, dependencies, docs) to reduce AI agent token consumption by up to 99%, along with Git commit intelligence.
      MIT
    • A
      license
      A
      quality
      D
      maintenance
      Universal MCP server that analyzes any codebase and provides structured context to AI assistants. Dynamic, accurate, and token-efficient.
      18
      12 npm
      MIT