Provides tools for reading and analyzing GitHub repositories, including retrieving file contents, repository structure, statistics, and searching for files.
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 GitHub Reader Analyze the repository skydeckai/mcp-server-aidd"
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.
A lightweight Model Context Protocol (MCP) server for bringing GitHub repositories into context for large language models.
API-based: No local repository cloning required - works directly with GitHub's API
Repository Analysis: Get overview and statistics for any GitHub repository
File Access: Retrieve individual file contents or entire repository file structures
Smart Filtering: Include or exclude files with glob and regex patterns
Cache-enabled: Smart caching and optimized request patterns to avoid GitHub API limits
Search Capabilities: Find files matching specific patterns within repositories
MCP Compatible: Works with any LLM client supporting the Model Context Protocol
Prompt Templates: Ready-to-use prompt templates for common repository analysis tasks
Related MCP server: code-index-mcp
npm install -g mcp-github-readernpm install mcp-github-reader# If installed globally
mcp-github-reader
# If installed locally
npx mcp-github-readerAdd this to your Claude Desktop tools configuration:
"github-reader": {
"runtime": "node",
"command": "npx",
"args": [
"-y",
"mcp-github-reader"
]
}"github-reader-test": {
"command": "node",
"args": [
"/path/to/your/repo/src/mcp-github-reader.js"
]
}Replace /path/to/your/repo with your actual repository location.
The MCP server provides four powerful tools for interacting with GitHub repositories:
Retrieves the content of a specific file from a GitHub repository.
Parameters:
owner: Repository owner (e.g., "skydeckai")
repo: Repository name (e.g., "mcp-server-aidd")
path: Path to the file within the repository (e.g., "README.md")
branch (optional): Branch name (defaults to the default branch)
Get an entire repository's content with smart filtering options.
Parameters:
owner: Repository owner (e.g., "skydeckai")
repo: Repository name (e.g., "mcp-server-aidd")
exclude_patterns (optional): Patterns to exclude (e.g., [".test.js", "node_modules/"])
include_patterns (optional): Only include files matching these patterns (e.g., [".js", ".json", "*.md"])
file_size_limit (optional): Maximum total size of response (e.g., "5m")
individual_file_size_limit (optional): Skip files larger than this size (e.g., "500k")
max_files (optional): Maximum number of files to include (default: 50)
include_contents (optional): Whether to include file contents or just list files (default: true)
use_regex (optional): Treat exclude/include patterns as regular expressions
Analyzes a repository, providing statistics and language breakdown.
Parameters:
repository: Repository name in owner/repo format (e.g., "skydeckai/mcp-server-aidd")
includeFiles (optional): Include file list in analysis (default: false)
Searches for files matching specific patterns within a repository.
Parameters:
repository: Repository name in owner/repo format (e.g., "skydeckai/mcp-server-aidd")
query: Text to search for in filenames (e.g., "function")
path (optional): Filter searches to a specific path (e.g., "src")
The server also includes useful prompt templates to help LLMs interact with repositories:
repositoryOverview: Analyze a repository's purpose and structure
codeExplanation: Explain code from a specific file
codeSearch: Search for patterns in a repository
fileContent: Get content of a specific file
repositoryInfo: Get repository information
repositoryStructure: View repository file structure
branchList: List repository branches
{
"name": "get_individual_file_content",
"parameters": {
"owner": "skydeckai",
"repo": "mcp-server-aidd",
"path": "README.md"
}
}{
"name": "get_entire_repo_contents",
"parameters": {
"owner": "skydeckai",
"repo": "mcp-server-aidd",
"include_patterns": ["*.js", "*.json", "*.md"],
"exclude_patterns": ["*.test.js", "node_modules/*"],
"max_files": 30
}
}{
"name": "analyzeRepository",
"parameters": {
"repository": "skydeckai/mcp-server-aidd",
"includeFiles": true
}
}Currently only works with public GitHub repositories
No support for private repositories or authentication
Subject to GitHub API rate limits (60 requests per hour for unauthenticated requests)
Apache License 2.0. See LICENSE file for details.
Copyright © 2025 SkyDeck AI Inc.
| Name | Required | Description | Default |
|---|---|---|---|
| repository | Yes | Repository name in owner/repo format (e.g., "skydeckai/mcp-server-aidd") | |
| includeFiles | No | Include file list in analysis (default: false) |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | Repository owner (e.g., "skydeckai") | |
| repo | Yes | Repository name (e.g., "mcp-server-aidd") | |
| exclude_patterns | No | Optional: Patterns to exclude (e.g. ["*.test.js", "node_modules/*"]) | |
| include_patterns | No | Optional: Only include files matching these patterns (e.g. ["*.js", "*.json", "*.md"]) | |
| file_size_limit | No | Optional: Maximum total size of response (e.g. "5m") | |
| individual_file_size_limit | No | Optional: Skip files larger than this size (e.g. "500k") | |
| max_files | No | Optional: Maximum number of files to include (default: 50) | |
| include_contents | No | Optional: Whether to include file contents or just list files (default: true) | |
| use_regex | No | Optional: Treat exclude/include patterns as regular expressions |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | Repository owner (e.g., "skydeckai") | |
| repo | Yes | Repository name (e.g., "mcp-server-aidd") | |
| path | Yes | Path to the file within the repository (e.g., "README.md") | |
| branch | No | Optional: Branch name (defaults to the default branch) |
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| repository | Yes | Repository name in owner/repo format (e.g., "skydeckai/mcp-server-aidd") | |
| query | Yes | Text to search for in filenames (e.g., "function") | |
| path | No | Optional: Filter searches to a specific path (e.g., "src") |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0analyzeRepositoryget_entire_repo_contentsget_individual_file_contentsearchRepositoryThe tool names indicate distinct actions: 'analyzeRepository' suggests analysis, 'get_entire_repo_contents' and 'get_individual_file_content' differentiate by scope, and 'searchRepository' is for searching. Without descriptions, the names are clear enough to avoid major confusion.
The naming convention is inconsistent, mixing camelCase ('analyzeRepository', 'searchRepository') with snake_case ('get_entire_repo_contents', 'get_individual_file_content'). This lack of a consistent pattern makes it harder for agents to predict names.
With 4 tools, the set is well-scoped for a 'GitHub Reader' server. Each tool serves a distinct purpose (analysis, full content retrieval, single file retrieval, search) without being overly minimal or bloated.
The tools cover core reading operations (full content, file content, search), but notable gaps exist, such as retrieving repository metadata (e.g., description, stars) or listing branches. The surface is functional but not comprehensive.
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
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A MCP server built for developers enabling Git based project management with project and personal…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/skydeckai/mcp-github-reader-prod'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
