Retrieve file contents or directory listings from a repository. For files, returns the complete file content. For directories, returns a non-recursive listing of immediate files and subdirectories.

PARAMETERS:

• repo_path: Repository identifier (GitHub URL, Azure DevOps URL, or local path) Examples: 'https://github.com/user/repo', 'https://dev.azure.com/org/project/_git/repo', '/home/user/project'

• resource_path: (Optional) Path within the repository. Defaults to root directory if not provided.

⚠️ MANUAL SYNC ONLY: Update a repository with latest changes. Only use when explicitly requested by the user.

IMPORTANT:

• DO NOT use this automatically or proactively

• ONLY use when user explicitly asks to "refresh", "sync", or "update" the repository

• The initial clone already provides the latest code - no refresh needed after cloning

WHAT IT DOES:

• Git repos: Performs git pull to fetch latest commits

• Local dirs: Re-copies from source directory

• Triggers re-analysis of changed files

PARAMETER:

• repo_path: Repository identifier (GitHub URL, Azure DevOps URL, or local path) Examples: 'https://github.com/user/repo', 'https://dev.azure.com/org/project/_git/repo', '/home/user/project'

Check if a repository is cloned and ready for analysis without triggering any operations.

USE THIS TO:

• Check if a repository needs to be cloned

• Verify if analysis is complete or in progress

• See which branch is currently active

• Understand the cache state before using other tools

RETURNS:

• is_cloned: Whether the repository exists in cache

• clone_status: Current state ('complete', 'cloning', 'failed', or None)

• analysis_status: State of code analysis ('complete', 'building', or None)

• current_branch: The active branch name

• cache_strategy: Which strategy is being used

• last_updated: When the repository was last accessed

List all cached versions of a repository across different branches. Shows information about each cached branch including paths, strategies, and metadata.

Remove a cached repository from the MCP server's cache, including all associated metadata and analysis results.

⚠️ DESTRUCTIVE OPERATION: This permanently removes cached repositories and cannot be undone.

WHAT IT DOES:

• Removes ALL cached versions of the repository (shared and per-branch cache entries)

• Deletes associated metadata including clone status and analysis results

• Frees up disk space and cache slots

• Cleans up in-memory references

IDENTIFICATION METHODS:

• Repository URL: Use the same URL format provided to clone_repo Examples: 'https://github.com/user/repo', 'https://dev.azure.com/org/project/_git/repo'

• Direct cache path: Use the absolute file system path to the cached repository Example: '/path/to/cache/dir/github_com_user_repo_main'

PARAMETER:

• repo_identifier: Repository URL or direct cache path to identify which repository to delete

USE CASES:

• Clean up repositories no longer needed for analysis

• Free cache space when approaching maximum cached repositories limit

• Remove corrupted or problematic cache entries

• Cache management and maintenance operations

NOTE: After deletion, the repository will need to be re-cloned via clone_repo before it can be analyzed again.

List all repositories currently in the MCP server's cache with their complete metadata including clone status, analysis status, branches, and cache sizes.

Initialize a repository for analysis by copying it to MCP's cache. This is a prerequisite for all other analysis tools.

WHEN TO USE:

• First time analyzing a repository

• When explicitly switching cache strategies

• NOT needed if already cloned (check with list_repos first if unsure)

RETURNS:

• 'already_cloned': Repository ready for analysis, no action needed

• 'pending': Clone started, will complete in background. You can proceed with other tools

• 'switched_branch': Branch changed successfully (shared cache only)

• 'error': Operation failed, see error message

CACHE STRATEGIES:

• 'shared' (default): One cache per repo, can switch branches in-place

• 'per-branch': Separate cache for each branch, useful for comparing branches

Retrieve a semantic analysis map of the repository's source code structure, including file hierarchy, functions, classes, and their relationships. Repository must be previously cloned via clone_repo.

PARAMETER:

• repo_path: Repository identifier (GitHub URL, Azure DevOps URL, or local path) Examples: 'https://github.com/user/repo', 'https://dev.azure.com/org/project/_git/repo', '/home/user/project' The format will be normalized automatically

RESPONSE CHARACTERISTICS:

1. Status Types:

• "threshold_exceeded": Indicates analysis scope exceeds processing limits

• "building": Analysis in progress

• "waiting": Waiting for prerequisite operation

• "success": Analysis complete

• "error": Operation failed

2. Resource Management:

• Repository size impacts processing time and token usage

• 'max_tokens' parameter provides approximate control of response size Note: Actual token count may vary slightly above or below specified limit

• File count threshold exists to prevent overload

• Processing time scales with both file count and max_tokens Important: Clients should adjust their timeout values proportionally when:

  • Analyzing larger numbers of files

  • Specifying higher max_tokens values

  • Working with complex repositories

3. Scope Control Options:

• 'files': Analyze specific files. If only this is provided, the entire repository will be searched for matching file names.

• 'directories': Analyze all source files within specific directories.

• If BOTH 'files' and 'directories' are provided, the tool will perform an INTERSECTION, analyzing only the files named in 'files' that are also located within the specified 'directories'.

4. Response Metadata:

• Contains processing statistics and limitation details

• Provides override_guidance when thresholds are exceeded

• Reports excluded files and completion status

NOTE: This tool supports both broad and focused analysis strategies. Response handling can be adapted based on specific use case requirements and user preferences.

Retrieve directory structure and analyzable file counts for a repository to guide analysis decisions.

PARAMETER:

• repo_path: Repository identifier (GitHub URL, Azure DevOps URL, or local path) Examples: 'https://github.com/user/repo', 'https://dev.azure.com/org/project/_git/repo', '/home/user/project' The format will be normalized automatically

RESPONSE CHARACTERISTICS:

1. Directory Information:

• Lists directories containing analyzable source code

• Reports number of analyzable files per directory

• Shows directory hierarchy

• Indicates file extensions present in each location

2. Usage:

• Requires repository to be previously cloned via clone_repo

• Helps identify main code directories

• Supports planning targeted analysis

• Shows where analyzable code is located

NOTE: Use this tool to understand repository structure and choose which directories to analyze in detail.

Identify and analyze the most structurally significant files in a repository to guide code understanding efforts.

PARAMETER:

• repo_path: Repository identifier (GitHub URL, Azure DevOps URL, or local path) Examples: 'https://github.com/user/repo', 'https://dev.azure.com/org/project/_git/repo', '/home/user/project' The format will be normalized automatically

RESPONSE CHARACTERISTICS:

1. Analysis Metrics:

   • Calculates importance scores based on:

     • Function count (weight: 2.0)

     • Total cyclomatic complexity (weight: 1.5)

     • Maximum cyclomatic complexity (weight: 1.2)

     • Lines of code (weight: 0.05)

   • Provides detailed metrics per file

   • Ranks files by composite importance score

2. Resource Management:

   • Repository must be previously cloned via clone_repo

   • Analysis performed on-demand using Lizard

   • Efficient for both small and large codebases

   • Supports both full-repo and targeted analysis

3. Scope Control Options:

   • 'files': Analyze specific files. If only this is provided, the entire repository will be searched for matching file names.

   • 'directories': Analyze all source files within specific directories.

   • If BOTH 'files' and 'directories' are provided, the tool will perform an INTERSECTION, analyzing only the files named in 'files' that are also located within the specified 'directories'.

   • 'limit': Control maximum results returned.

4. Response Metadata:

   • Total files analyzed

   • Analysis completion status

NOTE: This tool is designed to guide initial codebase exploration by identifying structurally significant files. Results can be used to target subsequent get_source_repo_map calls for detailed analysis.

Retrieve and analyze documentation files from a repository, including README files, API docs, design documents, and other documentation. Repository must be previously cloned via clone_repo.

PARAMETER:

• repo_path: Repository identifier (GitHub URL, Azure DevOps URL, or local path) Examples: 'https://github.com/user/repo', 'https://dev.azure.com/org/project/_git/repo', '/home/user/project'

Get the current status of the auto-refresh system.

    Returns information about:
    - Whether auto-refresh is enabled and running
    - Number of repositories scheduled for refresh
    - Next scheduled refresh times
    - Configuration settings
    - Recent refresh activity
    

Manually start the auto-refresh system if it's not already running.

    This is typically not needed as auto-refresh starts automatically with the server,
    but can be useful for recovery scenarios or manual management.
    

Manually stop the auto-refresh system.

    This will cancel all scheduled refreshes and stop the background worker.
    Repositories will no longer be automatically refreshed until the system is restarted.