Allows to explore remote Git repositories by cloning and analyzing their contents, generating structured text representations with token counting and .gitignore support.
Integrates with GitLab to access private repositories using token-based authentication, enabling exploration of GitLab-hosted code.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Git Explorer explore https://github.com/example/repo"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Simple MCP (Model Context Protocol) server for fetching the remote git repository content as a structured text file.
Clone and analyze Git repositories
Generate a structured text representation of repository contents
Quickly estimate codebase size and token count without retrieving all content
Support for public repositories and private GitLab repositories with token authentication
Tokenization counting using OpenAI's tiktoken library
Respect for .gitignore and .repomixignore patterns
Skip binary files and empty text files
Integration with Claude's Model Context Protocol
Related MCP server: Gitingest MCP Server
pip install mcp-git-exploreruv pip install mcp-git-exploreruvx mcp-git-explorer# Basic usage
mcp-git-explorer
# Using SSE transport
mcp-git-explorer --transport sse
# Providing GitLab token
mcp-git-explorer --gitlab-token YOUR_TOKENGIT_EXPLORER_GITLAB_TOKEN: Your GitLab personal access token for accessing private repositories
MCP Git Explorer provides Claude with the ability to:
Explore Git repositories without needing to manually download and upload files
Access the full contents of repositories, with automatic token counting
Navigate through repository structure and file contents
Quickly assess repository size before deciding whether to retrieve full content
Use estimate_codebase when you want to quickly check the size and structure of a repository before analyzing its contents. This is especially useful for large repositories where you need to check if retrieving the full content is feasible within token limits.
Use get_codebase when you need to analyze the actual code and content of the files in the repository.
get_codebase(repo_url: str, use_token: bool = True) -> str: Clone and analyze a Git repository, returning full file contents
estimate_codebase(repo_url: str, use_token: bool = True) -> str: Quick analysis providing repository statistics including file count, structure, and token estimation
check_gitlab_token_status() -> str: Check if a GitLab token is configured
# Clone the repository
git clone https://github.com/jmiedzinski/mcp-git-explorer.git
cd mcp-git-explorer
# Install development dependencies
uv pip install -e ".[dev]"# Run directly
python -m mcp_git_explorer.cli
# Run via MCP CLI
mcp dev mcp_git_explorer/cli.py
# Run via uvx
uvx mcp-git-explorerMIT
Check if the GitLab token is configured in the environment. Returns: A message indicating whether the GitLab token is configured
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states that the tool checks configuration and returns a message, but it does not clarify what 'configured' means (e.g., env variable presence vs. actual token validity) or explicitly confirm there are no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with the main action in the first sentence. The second sentence repeats the return value but is not overly verbose; it could be streamlined but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status check, the description adequately covers the tool's purpose and return value. It does not provide surrounding context, such as why one would need to check the token (e.g., before calling GitLab APIs), but this is not critical for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not add parameter semantics. The baseline of 4 applies because no parameters exist to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if the GitLab token is configured in the environment, using the specific verb 'check' and a distinct resource. This is well differentiated from sibling tools focused on codebase and file operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While sibling tools are clearly different, there is no explicit context, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics about a Git repository without downloading all content.
This tool clones a git repository from the provided URL, analyzes its structure,
and returns statistical information useful for LLM processing, including:
- Estimated token count
- Total file count
- Repository structure
Args:
repo_url (str): The URL of the Git repository to clone
use_token (bool, optional): Whether to use the GitLab token for authentication.
Defaults to True.
Returns:
str: A formatted text representation of the repository statistics
Raises:
GitCommandError: If there is an error during the git clone operation
Exception: For any other errors that occur during processing
| Name | Required | Description | Default |
|---|---|---|---|
| repo_url | Yes | ||
| use_token | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure responsibility. It explicitly states that the tool 'clones a git repository' and analyzes its structure, which is a key side effect. It also discloses error conditions via the Raises section. It does not mention cleanup of the cloned repo or performance implications, which would be additional useful context, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, detailed items, and sections for Args, Returns, and Raises. The opening sentence is a clear one-liner, and the rest provides necessary detail without repetition. Every section serves a purpose, and the document is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (cloning, analysis, return format) and no output schema or annotations. The description covers the main aspects: purpose, parameters, return format, and error handling. It lacks a few contextual details such as whether the clone is temporary or if network/git availability is required, but it is sufficiently complete for most agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are absent (0% coverage), so the description must compensate. It fully explains both parameters: repo_url is the Git repository URL to clone, and use_token indicates whether to use GitLab token authentication (default True). This provides clear meaning beyond the plain schema types and is crucial for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get statistics about a Git repository without downloading all content.' It specifies the resource (Git repository) and the output (statistics like token count, file count, and structure), distinguishing it from sibling tools like get_codebase (which presumably retrieves content). The verb 'Get' plus the listed outputs make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when statistical information about a repository is needed for LLM processing. The phrase 'without downloading all content' hints at a contrast with tools that download content, implying this is for lightweight analysis. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clone a Git repository and generate a structured text file containing its contents.
This tool clones a git repository from the provided URL, processes its contents,
and returns a single text file containing the repository structure and the content
of all files. Binary files and empty text files are excluded. The tool respects
.gitignore and .repomixignore patterns. The output includes an estimated token count
using the o200k_base encoding.
Args:
repo_url (str): The URL of the Git repository to clone
use_token (bool, optional): Whether to use the GitLab token for authentication.
Defaults to True.
Returns:
str: A formatted text representation of the repository contents, including
file structure, estimated token count, and the content of all text files.
Raises:
GitCommandError: If there is an error during the git clone operation
Exception: For any other errors that occur during processing
| Name | Required | Description | Default |
|---|---|---|---|
| repo_url | Yes | ||
| use_token | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: binary/empty files are excluded, .gitignore and .repomixignore are respected, token count uses o200k_base, optional GitLab token usage, and specific exceptions like GitCommandError. Missing cleanup/disposal details, but this is a strong disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, detailed behavior, Args, Returns, and Raises sections. It is slightly verbose but every sentence adds useful information, and the main purpose is front-loaded. More concise than most tool descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the input, processing behavior, output format, error handling, and authentication nuance. There is no output schema, so the Returns section adequately explains the return value. For a tool of this complexity, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description's Args section fully explains both parameters: repo_url is the repository URL, use_token controls GitLab token authentication with a default of True. This completely compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Clone a Git repository and generate a structured text file containing its contents.' It clearly distinguishes this from sibling tools like get_file (which likely fetches a single file) by specifying the full repository processing scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states what the tool does and the general context for use. However, it does not explicitly mention when not to use it or provide alternatives such as 'get_file' for single-file access or 'estimate_codebase' for token estimation, so it misses the explicit exclusion/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the content of a single specified file from a Git repository.
This tool clones a Git repository from the provided URL, reads the content
of the specified file, and returns it as a string. The repository is cloned
with depth=1 for efficiency. If the file does not exist or an error occurs,
an appropriate error message is returned.
Args:
repo_url (str): The URL of the Git repository to clone.
file_path (str): The relative path to the file within the repository.
use_token (bool, optional): Whether to use the GitLab token for authentication.
Defaults to True.
Returns:
str: The content of the specified file, or an error message if retrieval fails.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_url | Yes | ||
| file_path | Yes | ||
| use_token | No |
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 discloses that the tool clones the repository, uses depth=1 for efficiency, returns the file content as a string, and returns an error message on failure. It also mentions the optional use_token authentication. It stops short of detailing cleanup, rate limits, or potential clone sizes, but the main behaviors are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, behavioral details, and Args/Returns sections. It is somewhat longer than strictly necessary—the Returns section duplicates the earlier 'returns it as a string'—but every piece adds useful information and the front-loaded opening is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple file-fetching tool, the description is complete enough: it explains the cloning behavior, depth optimization, authentication option, and return/error behavior. It lacks an explicit note on temporary storage or cleanup, but these are peripheral. With no output schema, the return type is clearly stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no property descriptions, so the description's Args section adds essential semantics for all three parameters: repo_url is the repository URL, file_path is relative path, and use_token is optional with default True. This fully compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Fetch the content of a single specified file from a Git repository.' It clearly distinguishes this tool from siblings like get_codebase (which likely retrieves the whole repository) and estimate_codebase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's intended use case is clear: retrieve one file by cloning the repo. It provides operational details (depth=1, token auth) but does not explicitly state when to prefer get_codebase or other alternatives. No exclusions or when-not-to-use guidance are given, but the context strongly implies the single-file use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.0check_gitlab_token_statusestimate_codebaseget_codebaseget_fileThe tools are mostly distinct: get_codebase returns full content, estimate_codebase returns statistics, get_file retrieves a single file, and check_gitlab_token_status checks configuration. There is minor overlap between get_codebase and estimate_codebase (both analyze the repo), but their outputs are clearly different.
All tool names follow the verb_noun pattern in snake_case (get_, check_, estimate_). The naming is consistent and predictable, with no mixed conventions.
Four tools is well-suited for a Git explorer. The scope is focused on repository inspection, and each tool serves a distinct purpose without bloat or excessive overlap.
The tool set covers the core needs: full codebase extraction, single file retrieval, and statistics. A minor gap is the lack of a dedicated tool for listing the repository tree without content, though estimate_codebase partially addresses this. Overall, it is reasonably complete for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Access the GitHub API, enabling file operations, repository management, search functionality, and…
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jmiedzinski/mcp-git-explorer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
