Skip to main content
Glama
codingthefuturewithai

Code Understanding MCP Server

by codingthefuturewithai
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

⚠️ 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

Method 1: Direct execution with uvx (Recommended)

# 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.

Recommended Workflow for AI Assistants

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
ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
branchNo
cache_strategyNoshared

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses key behaviors: no modification to source, background map building, cache strategy options, and indicates it is a setup operation. Lacks discussion of potential errors or time delays, but otherwise thorough given no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections (IMPORTANT, Args, Returns, Recommended Workflow, Note) and bullet points, but somewhat lengthy with some repetition; still efficient for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensive coverage including return format, recommended workflow, and notes on cache staleness and strategy; fully adequate for a setup tool with 3 parameters and no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema coverage, the description adds detailed meaning for all three parameters (url, branch, cache_strategy), including defaults and usage notes, fully compensating for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool clones a repository into MCP's cache for analysis, distinguishes from sibling tools like list_cached_repository_branches and list_remote_branches by specifying it is a setup operation required before analysis endpoints.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance on when to use the tool (before analysis), when not to (if already cached), and recommends checking cache and verifying branch first, with references to alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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
        }
ParametersJSON Schema
NameRequiredDescriptionDefault
filesNo
limitNo
branchNo
repo_pathYes
directoriesNo
cache_strategyNoshared
include_metricsNo

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains that the tool uses complexity metrics and returns importance scores, but does not explicitly state it is read-only or disclose any side effects, prerequisites (beyond repo_path matching clone_repo), or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose sentence, a 'Uses...' sentence, and separate Args/Returns sections. It is not overly verbose, though the Args list could be slightly more concise. Overall, each sentence earns its place.

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?

Given 7 parameters and no annotations or output schema, the description covers the core purpose, most parameters, and return format. However, it lacks details on prerequisites (e.g., repo must be cloned), error conditions, and behavior for invalid inputs, leaving gaps for an agent.

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 coverage is 0%, so the description must compensate. It explains 5 of 7 parameters (repo_path, files, directories, limit, include_metrics) with defaults and purpose, but omits branch and cache_strategy. The return format adds context, but missing parameter descriptions lower the score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool analyzes and identifies structurally significant files using complexity metrics, which is a specific verb-resource pair. It distinguishes from siblings like get_repo_structure (which lists files hierarchically) by focusing on importance scoring.

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 does not explicitly guide when to use this tool versus alternatives like get_repo_structure or get_repo_file_content. It implies use for understanding system structure but offers no exclusions or direct comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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
                    }
                }
            }
ParametersJSON Schema
NameRequiredDescriptionDefault
branchNo
repo_pathYes
cache_strategyNoshared

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It details the return structure and what files are analyzed, but omits behavioral details like caching effects, network dependencies, or whether the operation is read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured as a docstring with clear purpose, Args, and Returns sections. It is front-loaded with the core functionality. While slightly verbose, every section adds information.

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?

Given no output schema, the description provides a detailed return structure. However, it misses parameter descriptions for two out of three parameters, and lacks usage guidance. Overall adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description explains only repo_path (Path or URL matching clone_repo). It ignores the branch and cache_strategy parameters entirely, failing to add value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves and analyzes repository documentation files, listing specific types (README, API docs, etc.). It distinguishes from sibling tools like get_repo_critical_files by focusing solely on documentation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving documentation but does not explicitly state when to use this tool versus alternatives like get_repo_critical_files or get_repo_file_content. No when-not or alternative guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.
ParametersJSON Schema
NameRequiredDescriptionDefault
branchNo
repo_pathYes
resource_pathNo
cache_strategyNoshared

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavioral traits: it returns either file content or directory listing, specifies non-recursive listings, and documents return fields. It does not mention authentication or rate limits, but for a read operation this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with Args, Returns, and Note sections, making it easy to scan. However, it is somewhat verbose; the Returns section could be shortened by referencing the schema, but overall it remains clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description fully documents return values for both file and directory cases. It also explains the non-recursive nature of directory listings, making it complete for an agent to understand the tool's behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains each parameter (repo_path, resource_path, branch, cache_strategy) in detail, including defaults and optionality, adding significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves file contents or directory listings from a repository, using specific verbs and resource context. It distinguishes itself from siblings like get_repo_structure by focusing on specific file content rather than structure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a note about non-recursive directory listings, which is useful context. However, it does not explicitly compare to sibling tools or state when to use this tool over alternatives like get_repo_structure.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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
        }
ParametersJSON Schema
NameRequiredDescriptionDefault
branchNo
repo_pathYes
directoriesNo
include_filesNo
cache_strategyNoshared

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses the return structure (dict with status, message, directories, total_analyzable_files) and behavior of including files. However, it does not mention error handling, caching strategy, or what happens if repo_path is invalid, which are minor gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured with Args and Returns sections, concise without being overly terse. Each sentence adds value, though the Return block could be slightly shortened. Overall efficient.

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?

Given 5 parameters, no output schema, and no annotations, the description provides a good base but lacks details on error handling, caching, and the branch parameter. The return structure helps, but completeness is limited by omitted parameters.

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 0%, so description must compensate. It explains repo_path, directories, and include_files well, but omits description for branch and cache_strategy (2 of 5 parameters). This partial coverage leaves ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'repository structure information', and distinguishes it from siblings that focus on different aspects like cloning or file content. The addition of 'with optional file listings' adds specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used after clone_repo by mentioning 'Path/URL matching what was provided to clone_repo', but does not explicitly state when to use it versus siblings like get_repo_file_content or get_repo_critical_files. No exclusions or alternatives are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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
ParametersJSON Schema
NameRequiredDescriptionDefault
filesNo
branchNo
repo_pathYes
max_tokensNo
directoriesNo
cache_strategyNoshared

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description fully covers behavioral aspects. It explains that the tool is asynchronous (returns 'building' status), requires prior cloning, and describes the response format including edge cases like errors. This goes beyond basic input/output expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat lengthy but well-structured with Args, Returns, and Notes sections. Every sentence adds value, and the front-loaded purpose is clear. Minor truncation could be done without losing meaning, but current structure aids readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 params, no output schema, asynchronous behavior), the description is remarkably complete. It covers parameter semantics, return format with all fields, and critical notes about prerequisites and background processing. No gaps are evident.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description documents all 6 parameters with detailed explanations (e.g., 'files' optional, 'cache_strategy' defaults to 'shared'). This fully compensates for the lack of schema descriptions, adding significant meaning beyond the schema itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves a 'semantic analysis map' of the repository's code structure, including file hierarchy and code elements. This distinctively separates it from siblings like 'get_repo_structure' (which likely returns only file structure) and 'get_repo_file_content' (which returns file content).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly requires the repository to be cloned via 'clone_repo' and provides guidance on using 'max_tokens' or specific files/directories for large repos. It could be improved by explicitly stating when not to use this tool (e.g., if only file structure is needed, use 'get_repo_structure').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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
ParametersJSON Schema
NameRequiredDescriptionDefault
repo_urlYes

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains that the tool scans the MCP cache, shows shared/per-branch entries, only returns repos cloned via clone_repo, and clarifies meaning of empty list. Lacks explicit statement of being read-only but is implied. Overall transparent and informative.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but well-organized: a concise summary, then usage guidance, argument description, return format, workflow, and notes. Every section adds value, and the key purpose is front-loaded. Slightly wordy but efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter, no output schema, but the description fully specifies the return format (including dictionaries with fields and types), explains typical workflow, and provides notes and interpretations. It is complete enough for an AI agent to use correctly without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter repo_url has 0% schema description coverage. The description adds essential context: 'must match exact URL used in clone_repo'. This goes beyond the schema's bare title and helps ensure correct usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks if a repository is cached and lists cached branch versions. It uses specific verbs ('check', 'list') and distinguishes from siblings like clone_repo. The purpose is unambiguous and well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to use this tool first before clone_repo to avoid redundant clones. Provides a detailed typical workflow with conditional steps (if cached >0 skip clone, else use list_remote_branches and clone_repo). This is exemplary usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.)
ParametersJSON Schema
NameRequiredDescriptionDefault
repo_urlYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must carry full burden. It describes using git ls-remote --heads, that it is fast and does not clone, and requires network access. It does not mention rate limits or potential error scenarios beyond a generic error field in the output. Could be more exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured with sections for critical use case, args, returns, common branch names, and workflow. Though lengthy, every section adds value and is easy to scan. Slightly verbose but justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is highly complete. It covers purpose, usage context, technical method, output format, real-world guidance on branch names, and a typical workflow. An agent can use this tool effectively.

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?

Only one parameter repo_url with no schema description coverage. The description provides an example URL but does not add much meaning beyond the name. For a single required string parameter, this is adequate but minimal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool discovers all branches in a remote repo without cloning. The verb 'discover' and resource 'branches in a remote repository' are specific. Distinguishes from siblings like 'clone_repo' by emphasizing it does not clone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes the critical use case of discovering default branch before cloning, and provides a typical workflow. However, it does not explicitly state when not to use this tool or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_repository_branchesD
ParametersJSON Schema
NameRequiredDescriptionDefault
repo_urlYes

TDQS

D1/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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
ParametersJSON Schema
NameRequiredDescriptionDefault
branchNo
repo_pathYes
cache_strategyNoshared

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully discloses behavioral traits: it performs git pull or local copy, triggers a repository map rebuild, runs in background, does not modify the source repository, and requires prior clone completion. It also notes that the operation is asynchronous and status can be checked via get_repo_map_content. No contradictions.

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 well-structured with clear sections: overview, critical note, recommended workflow, args, returns, and notes. It is front-loaded with the core action and uses bold for emphasis. Each sentence adds value without redundancy. Despite length, it is efficient for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description includes a sample return dict with all fields. It covers prerequisites (must be cloned and analyzed), background operation, and status checking. The notes address edge cases like branch switching and cache_strategy matching. The description is complete for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, but the description adds value by explaining the meaning and constraints of each parameter: repo_path must match original clone, branch switches to specific branch, cache_strategy must match original. It could have elaborated on cache_strategy values (e.g., 'shared' default), but provides sufficient context for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Update a previously cloned repository in MCP's cache and refresh its analysis.' It distinguishes from sibling tools like clone_repo and get_repo_* by specifying that it operates on already-cloned repositories and performs git pull or directory copy. The verb 'refresh' is specific and appropriate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance, including a 'RECOMMENDED WORKFLOW' that tells the agent to check cache first (using list_cached_repository_branches) and always refresh before analysis. It warns that failure to refresh leads to stale data, effectively directing the agent away from direct analysis without refresh.

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. Dates show when Glama detected each change.

  1. 10 tool updatesv0.2.0
    • First observedclone_repo
    • First observedget_repo_critical_files
    • First observedget_repo_documentation
    • First observedget_repo_file_content
    • First observedget_repo_structure
    • First observedget_source_repo_map
    • First observedlist_cached_repository_branches
    • First observedlist_remote_branches
    • First observedlist_repository_branches
    • First observedrefresh_repo
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.9/5.0
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 issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • cctx-mcp

    nikondrat
    A
    license
    Not graded
    quality
    C
    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

  • reposynapse

    Jul879n
    A
    license
    Not graded
    quality
    D
    maintenance
    Universal MCP server that analyzes any codebase and provides structured context to AI assistants. Dynamic, accurate, and token-efficient.
    14
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/codingthefuturewithai/mcp-code-understanding'

If you have feedback or need assistance with the MCP directory API, please join our Discord server