Analyzes GitHub repositories by cloning and reading key files to generate documentation.
Uses Gemini AI to perform analysis and generate comprehensive documentation from repository content.
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., "@codeglance-mcp Analyze the GitHub repo https://github.com/tiangolo/fastapi"
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.
An MCP (Model Context Protocol) server that analyzes GitHub repositories using Gemini AI and generates comprehensive documentation — project overviews, architecture guides, file insights, and more.
Works with any MCP-compatible client: Claude Code, Claude Desktop, Cursor, Windsurf, etc.
Get a free API key from Google AI Studio.
claude mcp add codeglance -e GEMINI_API_KEY=your_key_here -- uvx codeglance-mcpThat's it. Verify with:
claude mcp listAdd to your MCP config file (claude_desktop_config.json, .cursor/mcp.json, etc.):
{
"mcpServers": {
"codeglance": {
"command": "uvx",
"args": ["codeglance-mcp"],
"env": {
"GEMINI_API_KEY": "your_gemini_api_key_here"
}
}
}
}pip install codeglance-mcpThen configure your MCP client to run codeglance-mcp as the command instead of uvx codeglance-mcp.
Related MCP server: revibe-mcp
When you ask your AI assistant to analyze a repository, CodeGlance:
Clones the repository (shallow clone for speed)
Reads key files (README, package.json, config files, entry points)
Sends the context to Gemini AI with specialized analysis prompts
Generates 6 documentation files in codeglance-analysis/guide/
File | Description |
| 5-minute project overview |
| Annotated directory structure |
| Key files and their purposes |
| System architecture deep-dive |
| Getting started guide |
| Comprehensive technical analysis |
Tool | Description |
| Run full analysis on a GitHub repo |
| Check if a repo is already cloned |
| List generated documentation files |
Prompt | Description |
| Full analysis workflow |
| Fast overview only |
| Architecture-focused analysis |
| Security-focused review |
All settings can be customized via environment variables in your MCP config:
Variable | Default | Description |
| (required) | Your Google Gemini API key |
|
| Max characters per file to analyze |
|
| Max files to include in analysis |
|
| API request timeout |
|
| Concurrent Gemini API calls |
|
| In-memory cache TTL |
Example with custom settings:
{
"mcpServers": {
"codeglance": {
"command": "uvx",
"args": ["codeglance-mcp"],
"env": {
"GEMINI_API_KEY": "your_key",
"TIMEOUT_SECONDS": "180",
"MAX_CONCURRENT_REQUESTS": "5"
}
}
}
}Python 3.11+
Git (for cloning repositories)
A Gemini API key (free tier works)
git clone https://github.com/lucidopus/codeglance-mcp.git
cd codeglance-mcp
uv sync
# Run locally
GEMINI_API_KEY=your_key uv run codeglance-mcpMIT
Execute comprehensive code analysis workflow on a GitHub repository.
Clones the repository, analyzes it with Gemini AI, and generates 6 documentation
files covering overview, structure, file insights, architecture, quick-start, and
a master analysis.
Args:
repo_url: GitHub repository URL to analyze
working_directory: Directory where to create analysis folder (default: current directory)
| Name | Required | Description | Default |
|---|---|---|---|
| repo_url | Yes | ||
| working_directory | No | . |
| Name | Required | Description |
|---|---|---|
| success | Yes | Whether analysis completed successfully |
| message | Yes | Status message |
| output_files | Yes | List of generated documentation files |
| repository_path | Yes | Path to the cloned repository |
| gemini_available | Yes | Whether Gemini API was available for analysis |
| context_file_content | No | AI context file content generated from the analysis. You MUST save this as your context file at the ROOT of the analyzed project (e.g. CLAUDE.md for Claude Code, .cursorrules for Cursor, .windsurfrules for Windsurf, .github/copilot-instructions.md for Copilot). Do NOT modify any other files in the project — only create this one context file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: cloning, AI analysis, and file generation. However, it omits potential side effects (disk usage, network usage, time to complete) and any required permissions (e.g., GitHub token). It does not contradict annotations as none exist.
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 three sentences: first sentence states purpose, second explains the process, third lists arguments. It is front-loaded, has no fluff, and every sentence adds value.
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 purpose and parameters but lacks usage guidance, prerequisites, and behavioral details like time or disk impact. With an output schema present, return values are not needed, but additional context for a complex tool would improve completeness.
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?
Schema description coverage is 0% (no descriptions in schema). The description adds clear semantics: repo_url is the GitHub URL, working_directory is the folder for analysis output with a default of '.'. This compensates fully for the lack of schema 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 clearly states the tool executes a comprehensive code analysis workflow, cloning a repository and generating 6 specific documentation files. It distinguishes from siblings like get_repository_info and list_generated_guides by describing the full analysis process and specific outputs.
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 like get_repository_info or list_generated_guides. There is no mention of prerequisites, scenarios, or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a repository and whether it's already cloned locally.
Args:
repo_url: GitHub repository URL
working_directory: Directory where analysis folder should be located
| Name | Required | Description | Default |
|---|---|---|---|
| repo_url | Yes | ||
| working_directory | No | . |
| Name | Required | Description |
|---|---|---|
| repo_url | Yes | GitHub repository URL |
| repo_name | Yes | Repository name |
| local_path | Yes | Local path where repository would be/is stored |
| already_cloned | Yes | Whether repository is already cloned locally |
| working_directory | Yes | Working directory used |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it checks local clone status, implying filesystem access, but does not specify network requirements, authorization, or other behaviors. It adds some context but lacks completeness.
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 concise with a clear first sentence stating purpose, followed by parameter descriptions. No unnecessary words or redundancy.
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?
Given the tool's simplicity (2 parameters, no nested objects, output schema exists), the description adequately covers purpose and parameter meanings. However, it lacks usage guidelines and behavioral details that would be helpful for an agent, but it's not severely incomplete.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaningful descriptions: 'GitHub repository URL' for repo_url and 'Directory where analysis folder should be located' for working_directory, which go beyond the schema's just names and types.
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 'Get information about a repository and whether it's already cloned locally', providing a specific verb and resource. It distinguishes this from sibling tools like 'analyze_repository' which likely performs analysis, and 'list_generated_guides' which lists guides.
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?
No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or when not to use it. Given the existence of sibling tools, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all generated guide files in the codeglance-analysis/guide directory.
Args:
working_directory: Directory where codeglance-analysis folder should be located
| Name | Required | Description | Default |
|---|---|---|---|
| working_directory | No | . |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 describes what the tool does (list files) but does not disclose error behavior if the directory is missing or access issues. For a simple listing operation, the transparency is adequate but not detailed.
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 concise with two sentences and a parameter list. However, it partially duplicates the schema information. The structure is clear but could be more streamlined by focusing on unique insights.
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?
Given that an output schema exists, the description does not need to explain return values. It adequately describes the resource and the parameter. However, it could mention what kind of guide files are listed (e.g., file types) to be fully 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?
Schema description coverage is 0%, so the description adds meaning. It explains that working_directory should point to where the codeglance-analysis folder is located, clarifying the parameter's role beyond the schema's title. However, it does not describe the default behavior or constraints like valid formats.
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 verb 'List' and the specific resource 'generated guide files in the codeglance-analysis/guide directory'. It distinguishes from siblings like analyze_repository and get_repository_info, which have different purposes.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or conditions that would help an agent decide to invoke this tool.
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.1.3analyze_repositoryget_repository_infolist_generated_guidesEach tool has a distinct purpose: analyzing a repository, checking its status, and listing output guides. No overlap in functionality.
All tools use a consistent verb_noun snake_case pattern (analyze_repository, get_repository_info, list_generated_guides) making predictions easy.
Three tools are slightly on the lower end for a code analysis server, but they cover the essential workflow without being excessive. The count is reasonable.
The tools cover the core analysis and listing workflow, but lack retrieval of individual guide content, deletion, or configuration options, which are notable gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that gives your AI access to the source code and docs of all public github repos
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lucidopus/codeglance-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
