GitHub MCP Server
OfficialActiveThe GitHub MCP server connects AI tools directly to GitHub through the Model Context Protocol (MCP). GitHub maintains the server and provides both local and remote deployment options. It exposes repository, issue, pull request, code search, GitHub Actions, security, organization, project, notification, and other GitHub capabilities through configurable MCP toolsets. Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Copilot CLI, Codex, and other MCP hosts have documented setup paths.
Should you use GitHub MCP?
Agents that repeatedly inspect or act on repositories, issues, and pull requests.
You only need an occasional GitHub action and already have reliable shell access.
GitHub operations are exposed as structured tools that agents can chain into workflows.
The tool surface is large, so context use and permission scope need active control.
This guide covers what the GitHub MCP server exposes, which personal access token scopes to set for your specific workflow, how to configure it in Claude Desktop, Cursor, and VS Code, the tradeoff between the local Docker version and the remote hosted version, and the token cost realities that GitHub’s own documentation does not mention.
Why GitHub MCP scores 84/100
Our verdict is based on the current first-party GitHub MCP surface, its permission controls, current protocol support, recent maintenance history, and the operational cost of exposing a very large tool catalog. The score is an MCPVerdict assessment, not a GitHub rating and not a claim that every tool was independently exercised.
Overall evaluation. Strong first-party capability and unusually mature surface controls, offset by large context/result payloads and high-impact write authority.
Scan grade. Appropriate for a server that can legitimately receive privileged credentials and perform substantial repository, PR, issue, release, project, and CI-related writes.
Approximate full tool inventory in the evaluated release line. This is not a fixed number: enabled toolsets, deployment mode, release version, feature flags, and permissions change what a client actually sees.
Default toolsets when no explicit selection is supplied: context, issues, pull_requests, repos, and users.
What drives the verdict
| Parameter | Score | MCPVerdict finding |
|---|---|---|
| Effectiveness | 92 | Direct first-party GitHub context and actions map well to repository, issue, pull-request, CI, and security workflows. |
| Reliability | 78 | Active development is a strength, but recent regressions and GHES/client interoperability issues matter for production use. |
| Safety | 86 | Write authority is powerful, but read-only mode, exact-tool selection, exclusions, scope filtering, and lockdown give operators unusually strong controls. |
| Efficiency | 75 | Tool-surface pruning is good; large PR patches, search results, issue threads, and CI logs can still dominate context cost. |
| Compatibility | 87 | Local and hosted deployment, multiple authentication paths, Enterprise support, and current MCP protocol work provide broad coverage. |
| Maintainability | 97 | GitHub-owned, frequently updated, with an active repository and current protocol migration. |
| Setup friction | 90 | Hosted OAuth can be straightforward; local Docker/PAT/OAuth configuration remains manageable but requires permission discipline. |
Scores are MCPVerdict-derived judgments. They are not official GitHub metrics and should be read together with the evidence section below.
Task-specific parameters
| Parameter | Score | Why it matters |
|---|---|---|
| Repository-context accuracy | 87 | Wrong files, refs, branches, or commits can produce plausible but incorrect code changes. |
| Write-operation containment | 90 | Toolsets, exact tools, exclusions, scopes, and read-only mode can materially reduce mutation authority. |
| Prompt-injection containment | 82 | Lockdown is unusually useful for public repository content, but GitHub explicitly describes it as best-effort rather than an authorization boundary. |
| PR/review context efficiency | 68 | Full patches and large review payloads can consume substantial model context. |
| Permission fidelity | 92 | Available scopes and GitHub permissions strongly constrain what successful calls can do. |
| Enterprise compatibility | 79 | Enterprise is supported, but GHES API/schema lag has produced real compatibility issues. |
| Automation observability | 80 | Agents can usually inspect results and status, while some client/resource failures can complicate confirmation. |
| Context-surface control | 96 | The ability to compose toolsets, exact tools, exclusions, read-only mode, and scope filtering is the standout design strength. |
Use the GitHub-maintained server, not the archived Anthropic reference
Anthropic published the original GitHub MCP server as a reference implementation in November 2024. GitHub replaced it with a vendor-maintained version in 2025, and the Anthropic version was archived with no further security updates.
The archived server is at modelcontextprotocol/servers under the servers-archived directory. The current server is at github/github-mcp-server. Tutorials written in early 2025 still link to the archived version. The archived server connects to current clients without errors but has not been updated for the November 2025 or later specification changes. Install github/github-mcp-server. Do not install the archived reference.
What does the GitHub MCP server expose?
Repository intelligence
File reading, directory listing, commit history, and code search.
Issue operations
Search, create, update, close, label, assign, and comment.
Pull request operations
Create, review, comment on, inspect, and merge pull requests.
Branch and commit operations
Create branches, list commits, and view diffs.
Workflow operations
Inspect workflow runs and jobs, read logs and artifacts, and trigger supported GitHub Actions workflows.
Security operations
Work with code scanning, Dependabot, secret protection, and security advisories when the relevant toolsets and permissions are enabled.
The GitHub MCP server exposes repository operations to any MCP-compatible AI application: issues, pull requests, file contents, branches, commits, and code search across both public and private repositories.
A 2026 community measurement counted 93 tool definitions. The current server is organized around 22 documented toolsets plus remote-specific additions, so the exact tool count is version- and configuration-dependent. GitHub exposes toolsets as the primary control surface, allowing a client to load only the capabilities relevant to the current workflow.
- Repository intelligence exposes file reading, directory listing, commit history, and code search. The model can read any file at any ref (branch, tag, or commit SHA) and explore a repository’s full directory structure without cloning.
- Issue operations expose searching, creating, updating, closing, and labeling issues. The search supports GitHub’s full issue search syntax: filter by label, assignee, milestone, state, repository, and date.
- Pull request operations expose creating, reviewing, commenting on, and merging pull requests. The model can read diffs, examine changed files, and submit structured review comments.
- Branch and commit operations expose branch creation, commit listing, and diff viewing.
The server primarily exposes MCP tools, while toolsets may also include relevant MCP Resources and Prompts where applicable. This means the exact primitive surface can depend on the toolsets and server mode enabled rather than being fixed permanently for every installation.
| Family | Example tools | Action | Impact |
|---|---|---|---|
| Repositories | get_file_contents, list_commits | Read | Low |
| Issues | search_issues, update_issue | Read + Write | High |
| Pull requests | get_pull_request, merge_pull_request | Read + Write | Critical |
| Search | search_code, search_repositories | Read | Low |
What personal access token scopes does GitHub MCP need?
The server can only perform actions allowed by the credentials you provide. The important decision is therefore not just “is the server safe?” but “what scope am I granting?”
Grant the smallest scope that completes the workflow.
A server with powerful actions is not automatically insecure. Capability impact and implementation safety are separate signals.
Start read-only where possible, then add narrowly scoped write permissions only for workflows that need them.
GitHub MCP supports both OAuth and Personal Access Token authentication. On github.com, the local stdio server can open a browser-based OAuth login and keep the resulting token in memory only; a PAT remains available when you want explicit token-based control. The remote hosted server can use OAuth when the MCP host supports GitHub's OAuth flow, or a PAT in the Authorization header.
PAT scope still matters. A token with broader repository or organization permissions than the workflow needs increases what the server can do if the agent calls a write-capable tool. Prefer a fine-grained PAT limited to selected repositories and only the permissions required by the enabled toolsets. Classic PATs are also supported, but their broad scopes make over-granting easier.
For read-only repository work: Prefer OAuth with narrowly approved scopes or a fine-grained PAT limited to the repositories you want the agent to inspect. Grant read permissions only for the surfaces you actually use. Read-only mode can additionally remove write tools from the server itself.
For private repositories: Limit the credential to specific repositories whenever possible. Private-repository access is sensitive even when the enabled tools are read-only because source code, issues, pull requests, security findings, and internal discussions can all contain confidential data.
For write workflows: Add write permissions only for the specific surfaces the agent needs, such as Issues, Pull requests, or repository Contents. Avoid administrative, organization-wide, repository deletion, hook-management, or other elevated permissions unless the workflow explicitly requires them.
For the remote hosted version: OAuth is the cleanest path when the MCP host has configured GitHub OAuth support. Hosts without that OAuth integration can still connect to the remote server with a PAT. GitHub also performs scope challenges in OAuth flows when a requested tool needs a permission that has not yet been granted.
If you choose PAT authentication, avoid hardcoding the token directly into a client config when the host can read it from an environment variable or secure input. Some hosts still require a literal token in configuration. Local OAuth avoids a stored PAT on github.com: the official server opens a browser login and keeps the resulting OAuth token in memory only.
Authentication options by deployment
| Mode | OAuth | PAT | Important behavior |
|---|---|---|---|
| Local stdio / Docker | Yes | Yes | On github.com the official server can start OAuth with no PAT. In Docker, a loopback callback port is published so the browser flow can return to the container. |
| Remote hosted | Yes, when host supports GitHub OAuth | Yes | Any remote-capable MCP host can use PAT auth; OAuth setup depends on the host application's GitHub integration. |
| GitHub Enterprise Server | Local with app configuration | Yes | GitHub Enterprise Server does not receive GitHub's remote hosted MCP endpoint, so deployment is local. |
How much of GitHub MCP do you actually expose?
GitHub MCP is deliberately configurable. You can enable whole toolsets, load individual tools, exclude specific tools, force read-only behavior, reduce untrusted public-repository content with lockdown mode, and opt into experimental features without changing the server binary.
Toolsets
Load related capability groups such as repositories, issues, pull requests, Actions, code security, notifications, projects, or organizations. The default configuration currently includes context, repos, issues, pull_requests, and users.
Individual tools
Load only exact tools when a full toolset is unnecessary. Toolsets and individual tools are additive, while explicitly excluded tools always remain excluded.
Read-only mode
Removes write-capable tools even when those tools are included in an enabled toolset. This is one of the simplest ways to reduce the operational impact of a broad GitHub integration.
Lockdown mode
Filters public-repository content from authors without push access to reduce prompt-injection exposure. GitHub describes it as a best-effort content filter, not an authorization boundary.
Scope filtering
Classic PATs can have tools filtered at startup according to detected scopes. OAuth can request additional scopes when a tool needs them. Other token types may rely on the GitHub API to reject unauthorized calls.
Insiders + feature flags
Experimental capabilities can be enabled without switching to a different profile structure. MCP Apps are currently available through Insiders Mode or specific feature flags.
Documented toolsets
Remote GitHub MCP also documents remote-specific capabilities such as Copilot Spaces and GitHub support-document search. The exact tool surface therefore depends on deployment mode, enabled toolsets, token permissions, release version, and whether Insiders features are enabled.
The useful way to run a ~90-tool server is to make it smaller
GitHub MCP's strongest operational feature is not the size of its catalog. It is the number of independent ways the surface can be reduced before an agent starts acting.
all tools + broad credential. Useful for testing inventory, but it maximizes tool-selection complexity, schema exposure, and write authority.
repos + issues + pull_requests. Keep only the capability families required for the workflow.
needed toolsets + read-only. Read-only takes precedence over requested write tools.
needed toolsets + read-only + lockdown. Lockdown reduces exposure to untrusted public-repository content, but does not change credential authority.
exact tools + minimum OAuth/PAT scopes + lockdown where appropriate. This is the configuration pattern MCPVerdict prefers for task-specific use.
GitHub states that lockdown is a best-effort filter for public-repository content. It does not reduce what the underlying credential can access or change, and filtered content may still be reachable through another tool or direct API access.
How do you set up the GitHub MCP server?
Add the GitHub MCP server to your client’s configuration file with the server command, your personal access token, and the GitHub user or organization you want to connect to, then fully quit and reopen the client.
The setup differs slightly by client. All three use the same server binary. The differences are config file location, JSON format, and restart behavior.
For local use on github.com, OAuth is now available and avoids creating a PAT up front. The PAT examples below remain useful for explicit token-based setups, hosts that require PATs, GitHub Enterprise configurations, or cases where you want direct control over repository and organization permissions.
{
"mcpServers": {
"github": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
"ghcr.io/github/github-mcp-server"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "<your-token>"
}
}
}
}Claude Desktop
Open the config file at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows. Add the server entry shown above.
Fully quit Claude Desktop (not just close the window) and reopen it. Verify the server appears in the MCP server list. A window close does not restart the MCP connection. The application must fully quit and relaunch.
Docker must be running before you open Claude Desktop. The server runs as a Docker container. No Docker means the server will not start.
Common GitHub MCP setup and tool problems
| Symptom | Likely cause | What to check |
|---|---|---|
| Server fails to start | Docker is not running, the image cannot be pulled, or an invalid tool name was supplied. | Start Docker, verify the image can be pulled, and use exact tool names from the current GitHub MCP documentation. |
| Write tools are missing | Read-only mode is enabled or the credential does not have the required permission. | Check --read-only, GITHUB_READ_ONLY, or the remote X-MCP-Readonly header, then inspect token permissions. |
| Expected tools do not appear | The relevant toolset is not enabled, a tool was explicitly excluded, or scope filtering removed it. | Review configured toolsets, individual tools, excluded tools, and authentication scopes. |
| Remote server will not authenticate | The host has not configured GitHub OAuth or the PAT header is missing/invalid. | Use the host's documented OAuth flow where available; otherwise connect with a PAT in the Authorization header. |
| Local OAuth callback fails in Docker | The callback port is not published to loopback. | Publish a fixed loopback port such as 127.0.0.1:8085:8085 and set GITHUB_OAUTH_CALLBACK_PORT to the same value. |
| Tools work but a public-repository item is missing | Lockdown mode may be filtering content from authors without push access. | Check whether lockdown mode is enabled and remember that it is a content filter, not a permission boundary. |
Historical safety regression worth knowing about
A reported GitHub issue documented that HTTP mode could still expose and execute write tools such as branch and pull-request operations while read-only was enabled. The issue was subsequently fixed and GitHub added follow-up regression work. We treat this as historical evidence about why read-only behavior should be verified in the deployment you actually run, not as a claim that the current release is still affected.
GitHub issue #2156 ↗What is the difference between the local and remote hosted versions?
The local version runs as a Docker container on your machine through stdio transport, authenticates with a personal access token, and requires Docker installed. The remote hosted version runs on GitHub’s infrastructure through streamable HTTP, authenticates through OAuth, and requires no Docker.
| Attribute | Local Docker | Remote Hosted |
|---|---|---|
| Transport | stdio (local process) | Streamable HTTP (remote) |
| Auth | OAuth or Personal Access Token | OAuth when host supports it, or PAT |
| Infrastructure | Docker required on your machine | No Docker. GitHub hosts the server. |
| URL | None (local process) | https://api.githubcopilot.com/mcp/ |
| Updates | Manual. Pull new Docker image. | Automatic. GitHub pushes updates. |
| Toolset control | Full. Flag to disable toolsets. | Full. Same flags. |
| Enterprise | GitHub Enterprise Server, Enterprise Cloud, and ghe.com with the appropriate app/token configuration | Enterprise Cloud; ghe.com uses an enterprise-specific hosted URL. GitHub Enterprise Server has no GitHub-hosted remote endpoint. |
The remote hosted version remains the lowest-maintenance path when your MCP host supports remote servers. GitHub handles the server infrastructure and updates. Authentication can use the host's GitHub OAuth integration or a PAT, depending on the host. The tradeoff is that server execution occurs on GitHub's infrastructure rather than on your machine.
The local version gives you more control over the server process and configuration. It can run through Docker or a local binary, can authenticate through OAuth or PAT, and exposes the same configuration concepts through flags and environment variables. Local deployment is also the required path for GitHub Enterprise Server because GitHub does not host a remote MCP endpoint for GHES.
The GitHub blog describes the hosted version as the recommended path for most developers (Andrea Griffiths, “A practical guide on how to use the GitHub MCP server,” July 2025).
GitHub Enterprise Cloud with data residency can use a hosted MCP URL under the enterprise's ghe.com domain. GitHub Enterprise Server requires the local server. OAuth for local Enterprise environments requires an appropriate OAuth or GitHub App configuration rather than the built-in github.com application.
Which MCP clients can use GitHub MCP?
GitHub maintains host-specific installation guidance for major desktop, IDE, and terminal MCP clients. Local stdio support is broadly portable; remote OAuth behavior varies more because each host must configure its own GitHub OAuth application or integration.
| Client / host | Local | Remote | OAuth note | Setup status |
|---|---|---|---|---|
| VS Code + GitHub Copilot | Yes | Yes | Remote OAuth supported in current VS Code releases; local OAuth also available. | Official guide |
| Claude Desktop / Claude Code | Yes | Yes | Remote OAuth depends on host support; PAT remains available. | Official guide |
| Cursor | Yes | Yes | Local OAuth supported by the official image; remote host behavior varies. | Official guide |
| Windsurf | Yes | Yes | Local OAuth supported; remote PAT is documented. | Official guide |
| GitHub Copilot CLI | Yes | Yes | Built-in GitHub MCP integration plus custom local/remote configuration. | Official guide |
| Codex | Yes | Yes | Host-specific authentication behavior applies. | Official guide |
| JetBrains / Visual Studio / Eclipse / Xcode | Yes | Varies by host | Follow host-specific transport and authentication requirements. | Official guidance available |
Which parts of MCP does the GitHub server use?
Local deployments normally use stdio; GitHub's hosted endpoint uses remote HTTP transport.
Toolsets organize the main capability surface. Relevant MCP Resources and Prompts may also be included where a toolset provides them.
GitHub's v1.7.0 release notes include the latest changes required for the 2026-07-28 MCP specification.
Enabled through Insiders Mode or the relevant feature flag on hosts that support the MCP Apps extension.
Classic PATs can be filtered at startup; OAuth can challenge for new scopes as tools require them.
Toolsets, individual tools, exclusion lists, and read-only mode change the exposed surface without changing the underlying server.
Protocol currency
GitHub migrated the server to the official MCP Go SDK. In the evaluated release line, GitHub's release notes state that the SDK includes changes for the MCP 2026-07-28 specification. MCPVerdict therefore marks protocol status as adopted/current for that release line, while still treating future compatibility as version-sensitive.
GitHub MCP token usage and AI model costs
GitHub MCP has no universal token count per action. Your AI client decides which tool definitions and GitHub results reach the model; the model provider bills the resulting usage.
What uses tokens?
- Tool definitions: names, descriptions and argument schemas exposed to the model. The footprint varies with server version, enabled tools, tokenizer and client tool discovery.
- GitHub content: code, diffs, issue threads, search results and Actions logs returned to the model.
- Conversation and output: instructions, previous turns, generated tool calls and the final answer. Include billable reasoning tokens where applicable.
Context occupied in one request is not the same as total billable input across a session. Repeatedly sending the same context can add input usage on each turn; eligible cache hits may be priced differently.
Example budgets—not measured GitHub benchmarks
A small review is modeled below as 20,000 total input + 3,000 output tokens; a larger review as 70,000 input + 15,000 output tokens. These are planning assumptions summed across all requests, including tool definitions and returned content. They do not predict a particular repository or guarantee equal quality across models.
| AI model | Input / 1M | Output / 1M | Small review | Larger review |
|---|---|---|---|---|
| GPT-6 Astra | $10 | $50 | $0.3500 | $1.4500 |
| GPT-6 Sol | $2 | $10 | $0.0700 | $0.2900 |
| GPT-6 Luna | $0.1 | $0.5 | $0.0035 | $0.0145 |
| Claude Opus 5.5 | $4 | $20 | $0.1400 | $0.5800 |
| Claude Sonnet 5 | $2 | $10 | $0.0700 | $0.2900 |
| Claude Haiku 4.5 | $1 | $5 | $0.0350 | $0.1450 |
| Gemini 3.1 Flash-Lite | $0.25 | $1.5 | $0.0095 | $0.0400 |
Formula: (uncached input tokens × input rate + output tokens × output rate) ÷ 1,000,000.
USD, standard direct API rates checked September 27, 2026. OpenAI figures use short-context rates; Gemini figures use text input. Examples assume no caching or batch discounts and exclude cache writes/storage, long-context premiums, taxes, hosting, GitHub plans, Copilot subscriptions and other paid tools. Subscription clients may use allowances or credits instead of passing these API costs directly to you.
Official pricing: OpenAI · Anthropic · Google Gemini. Confirm the model, tier and current rates before budgeting.
Measure and reduce your actual spend
- Enable only the GitHub tools needed for your workflow. See the official tool configuration documentation.
- Fetch targeted files, bounded diffs and short result pages instead of full repositories or logs.
- Record input, cached-input and output usage for every model request in a representative task. Use the provider’s usage reporting; token counts vary by tokenizer.
- Compare total cost and successful outcomes with the same task and permissions. Apply caching only when your provider reports eligible cache usage.
What can you actually build with the GitHub MCP server?
The GitHub MCP server delivers the clearest productivity gains in code review, issue triage, repository exploration, and pull request automation.
Ask the model to review a PR’s diff, identify potential bugs, check for security issues, and post structured review comments. The model reads the changed files, compares them against the repository’s patterns, and leaves comments on specific lines.
Ask the model to search for open issues matching specific criteria (label, assignee, age, activity), summarize them, and apply labels or reassign them. A single prompt can triage a backlog that would take an hour manually.
Ask the model to explore an unfamiliar codebase. It reads files, traverses the directory tree, searches code, and explains architecture. Useful before integrating a third-party library or onboarding onto a new project.
Ask the model to create a PR with a title, description, and target branch after making changes through other tools (Filesystem, a code editor MCP, or direct file operations).
Additional workflows we include in the evaluation
Diagnose GitHub Actions
Inspect workflows, runs, jobs, logs, and artifacts, then use that context in a code-fix loop. This is a primary use case when the Actions toolset is enabled.
Security analysis
Use optional code-security, Dependabot, secret-protection, and related toolsets where the underlying GitHub feature is available.
Repository and project automation
Issues, discussions, projects, releases, and repository operations can become agent-managed workflow surfaces. That usefulness comes with higher write authority.
Copilot delegation
Some Copilot-related operations are exposed when the required GitHub/Copilot entitlement and toolset are available.
What the server cannot do
The GitHub MCP server now includes GitHub Actions tools for inspecting workflows, runs, jobs, artifacts, logs, and triggering supported workflow actions. That makes the older idea that it cannot participate in CI/CD workflows outdated. It still does not become a general-purpose deployment engine or a complete replacement for every GitHub API endpoint, cloud deployment tool, webhook integration, or custom automation. Use MCP when an agent benefits from structured GitHub capabilities; use the GitHub CLI or API when the task depends on unsupported endpoints, deterministic scripting, or infrastructure outside GitHub's MCP surface.
Large tool surface
Exposing many GitHub actions at once can increase tool-selection complexity and context use.
Permission scope matters
A broad token can turn a useful repository assistant into a high-impact write-capable integration.
CLI can be simpler
For isolated or deterministic GitHub actions, an agent with terminal access may still be better served by the GitHub CLI than by keeping a broad MCP tool surface loaded.
Hosted and local are not identical
Transport, authentication, operational control, and update behavior differ between deployment modes.
Operational costs that are easy to miss
Credential design
A broad classic PAT can undermine careful tool filtering. Narrow credentials and repository selection still matter even when the visible MCP tool surface is small.
Prompt injection
Issues, PR descriptions, comments, commit messages, discussions, and generated files can contain adversarial instructions. Treat repository content as untrusted model input.
Wrong target
An agent can execute a valid GitHub action against the wrong repository or branch if task context is unclear. Destructive intent is not required for a damaging outcome.
Public identity
Issue comments, PR reviews, reactions, and other social actions can represent the user publicly. Approval and write-scope choices should reflect that.
Enterprise lag
GitHub Enterprise Server can trail github.com API and GraphQL behavior, so tool compatibility should be checked against the target GHES version.
Large payloads
CI logs, diffs, code-search results, and issue threads can dominate context even after the schema surface is pruned.
What should you use instead?
GitHub MCP Server Questions
Does GitHub provide an MCP server?
Yes. GitHub maintains its own MCP server at github.com/github/github-mcp-server. It entered public preview in April 2025 and is available as both a local Docker image and a remote hosted endpoint.
Is the GitHub MCP server free to use?
Does GitHub have a remote MCP server?
Is GitHub MCP useful?
Version and verification timeline
Current live profile metadata lists this as the latest update date.
The release notes call out support work for the 2026-07-28 MCP specification together with GitHub App server-to-server authentication and lockdown improvements.
The older reference implementation was archived and should not be used for new installations.
The maintained implementation became available as a local Docker image and later as a remote hosted endpoint.
Why freshness belongs on the profile
MCP servers can change tools, authentication, transports, compatibility, and security posture. A profile should always show exactly when its important claims were last checked.
What supports this profile?
| Claim | Evidence | State | Checked |
|---|---|---|---|
| Maintained by GitHub | Official GitHub repository | Primary | Aug 2026 |
| Local + remote deployment | Official project documentation | Primary | Aug 2026 |
| OAuth / PAT authentication options | Official setup documentation | Primary | Aug 2026 |
| 93-tool community measurement | Piotr Hajdas, dev.to (2026); exact count is version/config dependent | Reported | 2026 |
| 17,600–55,000 token definition range | StackOne, Nebulagg, Piotr Hajdas measurements | Reported | 2026 |
| High context impact | Tool-count + footprint evidence | Derived | 2026 |
| 22 documented local toolsets | Official GitHub MCP README | Primary | Sep 2026 |
| Local OAuth with in-memory token | Official local OAuth documentation | Primary | Sep 2026 |
| Read-only, lockdown, tool and toolset controls | Official server configuration guide | Primary | Sep 2026 |
| GitHub Actions / CI-CD toolset | Official GitHub MCP README | Primary | Sep 2026 |
| 2026-07-28 MCP support in v1.7.0 | Official GitHub release notes | Primary | Jul 2026 |
| Host-specific setup across major clients | Official installation guides | Primary | Sep 2026 |
Recent issue and maintenance evidence
| Finding | Evidence type | Date | What we conclude |
|---|---|---|---|
| HTTP read-only mode failed to suppress functional write tools; issue later fixed. | Historical GitHub issue | Mar 2026 | Read-only is a strong control, but regression testing matters for a high-authority server. |
| GitHub added/needed explicit read-only regression coverage for dynamic toolsets and aliases. | Historical GitHub issue | Mar 2026 | Control behavior is actively maintained rather than assumed. |
| Different deployment paths have exposed different tool counts or missing Actions functionality. | Historical GitHub issue | Apr 2026 | Hosted/local parity should not be assumed across every release. |
| Remote HTTP interoperability and session/resource errors have been reported by clients. | Historical GitHub issues | Apr–Aug 2026 | Broad compatibility is good, but protocol/client edges still exist. |
| GHES GraphQL/schema mismatches caused issue-list/search failures on some versions. | Historical GitHub issues | Jul–Aug 2026 | Enterprise support is real but not identical to github.com behavior. |
| PR file reads can return large complete patches. | Current/recent issue evidence | Sep 2026 | Result payload efficiency remains a material cost even when schemas are pruned. |
| Current releases continue adding granular issue/PR actions and protocol work. | GitHub releases | Sep 2026 | The server remains under active development, so exact inventory and behavior are version-sensitive. |
Issue evidence is used as maintenance/history evidence. Unless explicitly stated as tested by MCPVerdict, we do not present an issue report as something we personally reproduced.