Provides tools to list repositories, view file trees, read files, search code, list issues, get commits, and retrieve repository statistics via the GitHub API.
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., "@github-mcp-server Show me my recent repositories"
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 minimal MCP server for GitHub in ~140 lines of Python. Browse repos, read code, search, and get insights — all through natural language via Claude, Cursor, or any MCP client.
Tool | Description |
| List repositories with language, stars, and last update |
| View the file tree of any repo |
| Read any file's content |
| Search code across your repos |
| Get open/closed issues |
| Recent commit history |
| Languages breakdown, stars, forks, dates |
Related MCP server: MCP GitHub Reader
# Clone
git clone https://github.com/ArnabbLank/github-mcp-server.git
cd github-mcp-server
# Install
pip install -e .
# Configure
cp .env.example .env
# Edit .env with your GitHub token (Settings → Developer settings → Personal access tokens)
# Run
mcp dev server.pyAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"github": {
"command": "python",
"args": ["/path/to/github-mcp-server/server.py"],
"env": {
"GITHUB_TOKEN": "ghp_your_token",
"GITHUB_OWNER": "your_username"
}
}
}
}Restart Claude Desktop. You can now ask things like:
"Show me my recent repos"
"Read the README from my EnvCraft project"
"Search for uses of FastAPI across my repos"
"What issues are open on github-mcp-server?"
This server implements the Model Context Protocol using fastmcp. Each tool is a Python function decorated with @mcp.tool() — the MCP client (Claude, Cursor) discovers them automatically and calls them when relevant.
┌─────────────┐ MCP (stdio/SSE) ┌──────────────┐ HTTPS ┌────────┐
│ Claude/Cursor│ ◄──────────────────────────► │ server.py │ ◄──────────────► │ GitHub │
│ (MCP Client)│ │ (MCP Server) │ │ API │
└─────────────┘ └──────────────┘ └────────┘@mcp.tool()
async def my_tool(repo: str, owner: str = "") -> str:
"""Description shown to the LLM."""
owner = owner or OWNER
data = await _get(f"/repos/{owner}/{repo}/whatever")
return format_data(data)That's it. The LLM sees the function name, docstring, and parameter types — no extra config needed.
The GitHub token needs these scopes:
repo — for private repo access (optional, skip for public-only)
read:user — for listing repos
Generate one at: https://github.com/settings/tokens
MIT
Get recent commits for a repository.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | ||
| limit | No | ||
| owner | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states 'Get recent commits.' No disclosure of ordering, pagination, what constitutes 'recent,' rate limits, or required permissions. The behavioral traits are entirely opaque.
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 very concise (one sentence), but this comes at the cost of crucial information. It is not fluff, but it is under-specified for the task of tool invocation.
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 three parameters and the existence of an output schema (not shown), the description is incomplete. It does not explain how parameters affect results, what the 'limit' defaults to, or what the output contains. The tool is not fully documented for an agent to use correctly.
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%, and the description adds no meaning beyond the parameter names. While 'repo' and 'limit' are somewhat self-explanatory, 'owner' is ambiguous (repository owner or committer?). The description fails to compensate 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 identifies the action ('Get') and resource ('recent commits') and specifies the scope ('for a repository'). However, it does not differentiate from sibling tools like list_repos or repo_stats, which might be related to repository data.
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 on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions. The description is insufficient for an agent to decide between this and similar tools like get_file or list_issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a file's content from a GitHub repository.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | ||
| path | Yes | ||
| branch | No | main | |
| owner | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation, which is non-destructive, but lacks details on authorization, rate limits, or error handling. With no annotations, this is minimally adequate.
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?
Single sentence, no unnecessary words, directly states the tool's purpose.
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?
Despite low complexity, the description lacks parameter details and behavioral context. The presence of an output schema does not compensate for missing parameter semantics.
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% and the description does not explain any of the four parameters (repo, path, branch, owner). The description adds no value beyond the schema structure.
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 uses a specific verb ('Read') and resource ('file's content from a GitHub repository'), clearly distinguishing it from sibling tools like get_commits or get_repo_structure.
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 on when to use this tool versus alternatives (e.g., search_code). No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the file/directory tree of a repository (one level deep).
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | ||
| path | No | ||
| owner | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It only states the depth constraint but omits behavioral traits like read-only nature, permissions, or pagination. Destructive hint is absent but not contradicted.
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?
Single sentence, overly terse for a tool with 3 parameters and a tree return. Lacks structure; every word is earned but too little information is conveyed.
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 output schema exists, description still fails to clarify return format or depth semantics. Entirely incomplete for a tool that returns a tree structure; needs more context about what 'one level deep' means in practice.
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 coverage is 0% and description does not explain any parameter (repo, path, owner). Agent receives no guidance on how these fields work, e.g., path for subdirectory or owner for repo ownership. Completely inadequate.
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 retrieves a file/directory tree, limited to one level deep. This specific verb and resource distinguishes it from siblings like get_file (single file) and list_repos (list repositories).
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 on when to use this tool versus alternatives. Lacks context about prerequisites, typical use cases, or when not to use it (e.g., for deeper structures).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List issues for a repository.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | ||
| state | No | open | |
| owner | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits such as pagination, filtering behavior (e.g., state parameter), or rate limits. It only states the basic function.
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 a single short sentence, which is concise but lacks sufficient detail. It earns its place but is minimally adequate.
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 presence of an output schema and four parameters (one required), the description is too sparse. It omits essential context like parameter semantics, filtering, and usage scenarios.
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%, and the description adds no meaning to the parameters (repo, state, owner, limit). The agent must infer their purpose from names alone.
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 'List issues for a repository.' clearly states the action (list) and the resource (issues) with a scope (repository), distinguishing it from sibling tools like list_repos or get_commits.
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 (e.g., search_code for broader search), nor any context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List repositories for a user/org. Returns name, language, stars, and last updated.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | No | ||
| limit | 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 does not disclose authentication needs, rate limits, default behavior when owner is empty, or pagination beyond the limit parameter. The returned fields are mentioned, but deeper behavioral traits are missing.
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, each providing necessary information (action and returned fields). No unnecessary words, though it could be slightly more informative without losing conciseness.
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 and the presence of an output schema, the description adequately explains the purpose and returned fields. However, it omits details like default behavior for an empty owner and authentication requirements, which 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%, and the description adds no explanation of the parameters. While 'owner' and 'limit' are somewhat self-explanatory, the description fails to clarify that 'owner' is the user/org name and 'limit' controls the number of repos returned.
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 action 'List repositories' with a specific scope 'for a user/org' and mentions the returned fields (name, language, stars, last updated). This distinguishes it from sibling tools like get_commits or get_file.
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. The description does not mention exclusions, prerequisites, or suggest other tools for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get repository stats: languages, size, open issues, forks, creation date.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | ||
| owner | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as authentication requirements, rate limits, or whether the operation is read-only. It only lists output fields, omitting context like 'returns aggregated data' or 'does not include commit history.'
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 a single, efficient sentence that conveys the essential purpose without extraneous words. It is front-loaded and earns its place.
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 simple tool (2 parameters, basic output) and the presence of an output schema, the description is minimally adequate. However, it lacks context on usage scope (e.g., any repository? GitHub?) and does not mention the optional owner parameter's default behavior.
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%, and the description does not explain the parameters beyond their names. While 'repo' and 'owner' are somewhat self-explanatory, the tool description fails to clarify their precise meaning (e.g., owner defaults to empty, repo is required) or add value beyond the schema.
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 explicitly states the tool's purpose with a specific verb ('Get') and resource ('repository stats'), listing concrete attributes (languages, size, open issues, forks, creation date). It clearly distinguishes from sibling tools like get_commits, list_issues, etc., which target different aspects of a repository.
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 implies usage when repository summary statistics are needed, but lacks explicit guidance on when to use this tool versus alternatives, such as distinguishing it from list_repos (which lists all repos) or search_code (which searches within). No 'when not to use' or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search code across repositories. Optionally filter by owner or language.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| owner | No | ||
| language | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose behavioral traits such as pagination, rate limits, authentication needs, or result format. It only states basic search functionality.
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?
Single sentence, efficient and front-loaded with the main action. Minor improvement could be structuring with bullet points for filters, but still concise.
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?
Despite an output schema existing, the description omits context like search scope, result limits, ordering, or error handling. A search tool should provide more contextual clues for effective use.
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?
With 0% schema coverage, the description adds basic meaning: query is the search term, owner and language are optional filters. However, it lacks details on parameter constraints, allowed values, or behavior (e.g., case sensitivity, wildcards).
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?
Description clearly states the tool searches code across repositories and mentions optional filters by owner or language. It differentiates from siblings like get_file or list_repos, but lacks specifics on search semantics (e.g., exact match vs. regex).
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 on when to use this tool versus alternatives. The description implies usage for code search but does not mention exclusions, prerequisites, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource and action: commits, file content, repo structure, issues, repos list, stats, and code search. No two tools have overlapping purposes.
Most tools follow a consistent verb_noun snake_case pattern (e.g., get_commits, list_issues). The exception is 'repo_stats', which uses noun_noun, but overall style remains uniform.
Seven tools is a well-scoped set for a read-oriented GitHub client. Each tool provides distinct functionality without redundancy.
Basic read operations are covered (repos, files, commits, issues, search), but gaps exist: no single-repo details, no single-issue view, and no write operations (create/update). Agents may face dead ends.
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…
MCP server for siGit (sigit.si): browse repos, search code, manage PRs/issues, web search.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ArnabbLank/github-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
