Provides tools for interacting with GitHub, including listing and creating issues, managing pull requests, searching code, and reading file contents.
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 Get issue #1234 in cli/cli"
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.
GitHub MCP server for Claude Code, Cursor, Cline, Windsurf, and any MCP-compatible client.
Exposes GitHub tools (issues, pull requests, code search, file content) to your LLM via the Model Context Protocol.
🔁 Connection pooling & retry — single HTTP client per process, exponential backoff on 429/5xx, honors Retry-After.
🛡️ Typed errors — GitHubError carries HTTP status, parsed message, and endpoint.
✅ Input validation — catches bad inputs before the network round-trip.
📄 Text files decoded — get_file_content returns UTF-8 text under decoded_content for text files.
🧪 Fully tested — 75 mock-based tests, plus opt-in live integration tests.
🪶 Tiny — three runtime deps (mcp, httpx, pydantic); no PyGithub.
Related MCP server: GitHub MCP Agent Server
Tool | Description |
| List issues (filter by state, labels, since) — PRs filtered out |
| Get a single issue by number |
| Create an issue (with optional labels) |
| List PRs (filter by state) |
| Get a single PR by number |
| Search code across GitHub (requires code-search scope) |
| Read a file at a ref; text files returned UTF-8-decoded |
Full parameter docs: docs/USAGE.md.
pip install github-mcpOr with uv:
uv tool install github-mcpRequires Python 3.10+.
Create a GitHub personal access token:
Fine-grained (recommended): https://github.com/settings/personal-access-tokens/new
Classic (legacy): https://github.com/settings/tokens/new
Set the token:
export GITHUB_TOKEN="ghp_..." # macOS / Linux / Git Bash
# or PowerShell: $env:GITHUB_TOKEN = "ghp_..."See docs/AUTH.md for Windows and per-client config.
claude mcp add --transport stdio github -- github-mcpAdd to ~/.cursor/mcp.json:
{
"mcpServers": {
"github": {
"command": "github-mcp",
"env": {
"GITHUB_TOKEN": "ghp_..."
}
}
}
}See your client's docs for adding a stdio MCP server. Command: github-mcp. Env: GITHUB_TOKEN.
"List the 5 most recent open issues in
cli/clilabeledbug."
"Get issue #1234 in
cli/cliand summarize the discussion."
"Create a new issue in
my-org/my-repotitledBug: login fails on Safariwith bodySteps to reproduce: ...."
"Show me the contents of
src/main.pyincli/clion themainbranch."
"Search GitHub for
function authenticateincli/cli."
git clone https://github.com/AbdeeBuilds/github-mcp
cd github-mcp
python -m venv .venv
source .venv/Scripts/activate # Git Bash on Windows
pip install -e ".[dev]"
pytest # mock-based suite
GITHUB_TOKEN=*** pytest tests/test_live.py -v # live integrationQuality gates (run on every PR):
ruff check src tests
ruff format --check src tests
mypy srcMIT — see LICENSE.
Create a new issue in a GitHub repository you have write access to.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Issue body in markdown | |
| repo | Yes | Repository name | |
| owner | Yes | Repository owner (user or org) | |
| title | Yes | Issue title (required, non-empty) | |
| labels | No | Optional list of label names to apply at creation time. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly indicates a write operation and permission requirement, but does not detail return values, error handling, or rate limits.
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?
One sentence, 12 words, no wasted content. Purpose is front-loaded and clearly stated.
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 is simple, schema covers all parameters, and sibling tools provide contrast. No output schema is needed; overall description is sufficient for typical 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?
Schema coverage is 100%, so the description adds no new parameter information beyond the schema. Baseline 3 is appropriate.
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 (create), the resource (issue), and a specific prerequisite (write access). It is specific and distinguishes from sibling tools which are read-only.
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 notes the prerequisite of write access, which is helpful. However, it does not explicitly state when not to use or mention alternatives (e.g., get_issue for reading), so some guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the contents of a file from a GitHub repository at a given ref (branch, tag, or commit SHA). Defaults to the repo's default branch. Text files are returned UTF-8-decoded under 'decoded_content'.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Branch, tag, or commit SHA (optional) | |
| path | Yes | File path within the repo (e.g., 'src/main.py') | |
| repo | Yes | Repository name | |
| owner | Yes | Repository owner (user or org) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must cover behavioral aspects. It mentions that text files are returned UTF-8-decoded under 'decoded_content', but does not explain behavior for binary files, error handling, or permission requirements. Adequate but not comprehensive.
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?
Two sentences that front-load purpose and provide key details. No unnecessary words; every sentence 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?
The description covers main behavior (reading file, ref handling, text file decoding) for a simple read tool. It lacks details on error cases or output format for non-text files, but given 100% schema coverage and no output schema, it is fairly 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 coverage is 100%, so the baseline is 3. The description adds value by clarifying that 'ref' is optional and defaults to the default branch, and implies that 'path' is the file path. This slightly enhances understanding beyond 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 'Read the contents of a file from a GitHub repository', with specific verb and resource. It adds nuance about ref (branch/tag/commit SHA) and default branch behavior, distinguishing it from sibling tools focused on issues, PRs, and search.
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 explains when to provide a ref (branch/tag/commit SHA) and that it defaults to the repo's default branch when omitted. It doesn't explicitly list when not to use, but sibling tools are unrelated, so context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single GitHub issue by its number.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repository name | |
| owner | Yes | Repository owner (user or org) | |
| number | Yes | Issue number |
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 only states the basic action without disclosing behavioral traits like required permissions, rate limits, error handling, or what happens if the issue does not exist. For a simple read tool, the description is adequate but minimal.
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 concise sentence of 8 words, front-loaded with the main action and key identifier ('by its number'). No extraneous information.
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 simplicity of the tool (3 required params, no output schema, no nested objects), the description covers the core purpose. However, it could mention that the tool returns the full issue object, but this is a minor gap. The sibling tools provide additional context.
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 100%, so all three parameters (owner, repo, number) have descriptions in the input schema. The tool description adds no additional meaning beyond what the schema already provides, thus baseline score of 3 is appropriate.
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 a single GitHub issue by its number', which is a specific verb and resource. It distinguishes this tool from siblings like 'get_pull_request' and 'list_issues' by specifying it retrieves a single issue by number.
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 for fetching a single issue but does not provide explicit guidance on when to use this tool over alternatives, such as when to use 'list_issues' for multiple issues, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single GitHub pull request by its number.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repository name | |
| owner | Yes | Repository owner (user or org) | |
| number | Yes | Pull request number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'Get' indicates non-destructive behavior, but it doesn't disclose rate limits, authentication needs, or the structure of the returned data. Adequate but not enriched.
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 front-loads the core purpose with zero waste. Every word 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?
The tool is simple with three well-described parameters, but there is no output schema and the description omits what the response contains or error conditions. Adequate but incomplete for an agent without additional context.
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 100% and the description adds only 'by its number', which restates the number parameter. No additional meaning beyond what the schema provides, so baseline 3.
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 'Get', the resource 'a single GitHub pull request', and the method 'by its number', making it distinct from siblings like list_pull_requests which lists multiple PRs.
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 you have the pull request number, but does not explicitly state when to use over alternatives like list_pull_requests or get_issue. It provides clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List issues in a GitHub repository. Returns the most recent issues in the specified state. Pull requests are filtered out.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repository name | |
| limit | No | Maximum number of issues to return | |
| owner | Yes | Repository owner (user or org) | |
| since | No | Optional ISO 8601 timestamp; only return issues updated at or after this time (e.g. '2026-01-01T00:00:00Z'). | |
| state | No | Filter by issue state | open |
| labels | No | Optional comma-separated label names to filter by (e.g. 'bug,priority:high'). |
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 results are 'most recent' and that pull requests are excluded, but does not explain ordering, pagination, or authentication requirements. Adequate but not rich.
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?
Two sentences with no redundancy. The first sentence states the purpose, the second adds key behavior. Every word 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?
The description covers purpose, filtering options (state, labels, time), and result nature (most recent, no pull requests). It lacks mention of pagination, but the schema has a limit parameter. For a simple list tool, it is fairly 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 100%, so the baseline is 3. The description adds context about 'most recent issues' and filtering out pull requests, but these are not parameter-specific. The description does not add significant meaning 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 clearly states the action ('List issues'), the resource ('GitHub repository'), and includes specific behavior ('Returns the most recent issues in the specified state. Pull requests are filtered out.'). This distinguishes it from sibling tools like get_issue (single issue) and list_pull_requests.
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 this tool: to list issues with filtering by state, labels, and time. It implicitly distinguishes from list_pull_requests by noting pull requests are filtered out. No explicit when-not-to-use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pull requests in a GitHub repository.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Repository name | |
| limit | No | Maximum number of pull requests to return | |
| owner | Yes | Repository owner (user or org) | |
| state | No | Filter by pull request state | open |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states it lists pull requests. It does not disclose aspects like pagination, rate limiting, authentication needs, or that it is a read-only operation.
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 sentence, very concise, but it lacks structure and could be more informative without being verbose. It earns its place but does not add value beyond the bare minimum.
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 tool with 4 parameters and no output schema or annotations, the description is minimal. It does not cover default sorting, pagination behavior, or return format, leaving gaps for the agent.
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 100% with parameter descriptions, so the description adds no additional meaning. It does not repeat parameter details, but also does not enhance understanding 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 clearly states the verb 'List', the resource 'pull requests', and the location 'GitHub repository'. It distinguishes from sibling tools like 'get_pull_request' which retrieves a single PR.
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 does not provide explicit guidance on when to use this tool versus alternatives such as 'get_pull_request' or 'list_issues'. Usage is implied for listing multiple pull requests, but no exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for code across GitHub repos. Requires a fine-grained token with 'Code: Read' scope, or a classic token with repo scope.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of code-search results to return | |
| query | Yes | Search query in GitHub code search syntax, e.g. 'repo:owner/name function_name' or 'language:python async' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses token requirements but omits key behavioral traits such as return format, pagination, rate limits, or any side effects. As a search tool, it is likely read-only, but this is not stated.
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 two sentences, front-loaded with purpose, and includes a critical prerequisite. Every word earns its place with no redundancy or filler.
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 two-parameter schema with full descriptions and no output schema, the description adequately covers the tool's core functionality and token requirements. It could mention output structure but is not severely lacking.
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 100%, so baseline is 3. The tool description adds no additional meaning beyond the schema's parameter descriptions. It does not explain syntax details or provide examples beyond what is in 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 clearly states the tool searches for code across GitHub repos, with a specific verb and resource. It distinguishes from sibling tools which focus on issues, pull requests, or file content. No ambiguity.
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 mentions required token scopes as a prerequisite but does not explicitly state when to use this tool over alternatives like get_file_content, nor does it provide scenarios or exclusions. Usage context is implied but not fully articulated.
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.2.0create_issueget_file_contentget_issueget_pull_requestlist_issueslist_pull_requestssearch_codeEach tool targets a distinct GitHub resource (issues, pull requests, files, code search) with clear boundaries. No two tools could be confused for the same task.
All tool names follow the verb_noun pattern in snake_case (e.g., create_issue, list_pull_requests, search_code), providing a predictable and uniform naming convention.
With 7 tools, the server is well-scoped for basic GitHub interactions. The number is neither too sparse nor excessive for its purpose.
The tool set is missing fundamental operations like update and delete for issues and pull requests, and lacks the ability to create pull requests. This creates significant gaps that hinder common workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
An MCP server that gives your AI access to the source code and docs of all public github repos
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AbdeeBuilds/github-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
