GitHub's official MCP server: setup, scopes, and what we'd actually use it for

GitHub's official MCP server is free and the install is the boring part. The auth model is the entire decision, and most teams get it wrong in the same way: they reach for a classic Personal Access Token with repo scope because it is one click, and in doing so hand a probabilistic agent write access to every repository the token owner can touch. The thesis here is blunt. A fine-grained PAT (or a GitHub App for orgs) scoped to specific repos and verbs is not the careful option, it is the only correct one, and the blast-radius difference between the two is roughly an order of magnitude. Everything below is a least-privilege rollout rubric anchored to GitHub's own docs and release log.

What the official GitHub MCP server actually exposes

The server, hosted at github/github-mcp-server, exposes the GitHub REST and GraphQL APIs as MCP tools. The current toolset breaks down into a few categories:

• Issues: list, read, create, comment, label, close, and search across repos the token can see.
• Pull requests: list, read, comment, request review, and (depending on scope) merge.
• Code search: GitHub's code search across repos the token has read access to, returned as ranked snippets.
• Repository metadata: branches, releases, file contents, commit history, and contributor lists.
• Notifications: read and mark-as-read for the authenticated user's notification feed.

What it does not do, by design, is give your assistant a generic shell on a GitHub Actions runner or git push access on its own. Writes are mediated through the same API verbs a human user would call: a comment is a comment, a merge is a merge, and each is gated by whatever scopes the token carries. That predictability is the point. You can read the full tool list in the project's README and check the version-pinned set in any tagged release before you upgrade.

Setup walkthrough: local Docker vs the remote hosted endpoint

One detail trips people up first: the official github/github-mcp-server is not the old @modelcontextprotocol/server-github npx package. It ships as a Go binary, a Docker image (ghcr.io/github/github-mcp-server), or a GitHub-hosted remote endpoint at https://api.githubcopilot.com/mcp/. There is no npx path, and configs copied from 2024-era blog posts point at the wrong server. Pick local Docker when you want the PAT to stay on your machine, or the remote endpoint when you want OAuth and zero local runtime.

Local Docker, with a fine-grained PAT

The shape is identical across MCP 1.0 clients: declare the server, point it at a token, restart. For Claude Desktop, edit the user-level config (the quickstart lists the path per OS) and add:

{
  "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-fine-grained-PAT>"
      }
    }
  }
}

Restart the client. If the server does not appear, run that docker run line in a terminal first to surface a pull or auth error before it hides inside the client log. Cursor takes the same block: command palette, MCP: Edit Config, paste, reload.

Remote hosted, with OAuth

For VS Code 1.101+ and any client that supports HTTP transport, skip the local runtime entirely and point at GitHub's hosted server. Auth is OAuth, so there is no long-lived PAT on disk:

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    }
  }
}

The trade-off is explicit. Remote means no Docker dependency and OAuth's revocable, short-lived tokens, at the cost of GitHub seeing the request path. Local Docker keeps the traffic on your machine but puts a PAT in a config file you must rotate yourself. For an individual operator the remote OAuth path is the lower-risk default; the local path matters when policy forbids the hosted endpoint. Whichever you pick, the scope discipline below is the part that actually protects you.

Personal Access Token vs GitHub App auth

The official server supports two auth modes: a Personal Access Token attached to a human GitHub account, or a GitHub App acting on its own credentials. They imply different things.

A classic PAT authenticates as the human user. Every action in audit logs reads as that user. Scopes are coarse: repo covers every repository the user can touch, public or private, with both read and write. This is convenient and dangerous. If your assistant goes off-script, the blast radius is everything that user can see.

A fine-grained PAT is the same human-account model with two important upgrades. You enumerate a specific repository list, and you pick read or write per category (Contents, Issues, Pull requests, Metadata, etc.). The scope surface drops by an order of magnitude.

A GitHub App is a separate identity. It can be installed only on the specific repositories you choose, can be paused or rotated without touching your personal account, and produces audit-log entries clearly attributable to the App. For team or org rollouts this is the right answer. For an individual operator wiring up their own assistant, fine-grained PATs are the lower-friction path that still keeps you out of repo-scope territory. The GitHub PAT documentation walks both flows.

Scopes we'd recommend (least-privilege)

If we were shipping this to a small engineering team this month, here is the rubric we'd apply. The principle is simple: start read-only on a single repository, add scopes only when a workflow proves out.

Workflow	Repos	Contents	Issues	Pull requests	Metadata
Read-only triage	Selected	Read	Read	Read	Read
PR review assist	Selected	Read	Read	Read + Write	Read
Issue dedup + labelling	Selected	Read	Read + Write	Read	Read
Release-notes drafting	Selected	Read	Read	Read	Read
Full agent loop	Selected	Read + Write	Read + Write	Read + Write	Read

The first row is where we'd start. The last row is where you stop pretending the assistant is supervised and treat it as a co-author with the authority to merge. Most teams should not be at the bottom row in week one.

Two failure modes we'd plan for: a token leak (rotate immediately, GitHub's UI revokes a fine-grained PAT in two clicks) and a rogue tool call (set the workflow scope so the worst case is a stray comment, not a force-push to main). The fine-grained model makes both recoveries cheap.

Three workflows it actually wins at

Not every problem looks like a nail when you have an MCP-shaped hammer. Three workflows we think justify the install on day one.

1. Cross-repo PR triage

Reviewing five repos worth of open PRs through a chat interface is faster than five browser tabs. Ask the assistant to list PRs older than seven days across a defined set of repos, summarize the diff focus, and surface the ones touching shared infrastructure. The read-only token is enough. The win is attention compression, not auto-merging.

2. Issue dedup search

Engineering teams accumulate near-duplicate issues. The MCP server's code-search and issue-search tools combined will let an assistant pull a candidate match list for a new issue in seconds. Pair it with a "is this a dup of #X?" workflow and the assistant becomes a triage net rather than a write actor. Issues read scope only.

3. Release-notes drafting

Tag, list merged PRs since the last tag, group by label, draft notes. The assistant does the rote part, a human edits the framing and ships the GitHub release. Read scope on contents and pull requests is enough; the human still hits the publish button.

If you're already paying for a code-completion tool that overlaps with these workflows, layering an MCP server on top of GitHub Copilot is where the GitHub-stack monetization really compounds. Copilot's chat lives inside your editor; the MCP server lets the assistant reach across repos without the human switching context.

When NOT to use the GitHub MCP server

A few scenarios where the answer is "do something else."

You need write access to private package registries, secrets, or GitHub Actions workflows. The MCP server's tool surface is GitHub's content APIs, not the admin plane. If your workflow is "rotate this org secret," use the GitHub CLI under a human's session.

You're rate-limited already. Adding an assistant that calls the API on every prompt will not help. The standard 5,000-requests-per-hour ceiling can drain quickly under heavy code-search use. Watch your X-RateLimit-Remaining header on busy days.

You need real-time updates, not pull-based reads. The MCP server polls. If you want notifications-on-events, run a webhook listener or use the GitHub mobile app. Asking your assistant "did anyone comment in the last five minutes?" is the wrong tool.

You're operating in a regulated environment without GitHub App audit. If your compliance posture requires App-level audit trails, the PAT path is not the answer. Set up a GitHub App, scope it to the org, and pipe the audit log to your SIEM.

Pondero rollout rubric (if we were doing it this month)

A four-week shape we'd suggest. Treat this as a framework, not a transcript.

• Week 1: Single repo, fine-grained PAT, read-only on Contents and Issues. One human operator. The goal is to confirm the server runs, the token works, and your client picks up the tools.
• Week 2: Add a second repo. Add Pull requests read. Run the cross-repo triage workflow against real open PRs.
• Week 3: Promote the workflow you actually used to a written runbook. Add Issues write scope only if labelling or commenting is in that runbook. Document the rotation procedure for the PAT.
• Week 4: Decision point. Either move to a GitHub App for org-level rollout, or stay on fine-grained PATs per-operator. Either is defensible. The wrong answer is the implicit upgrade to classic repo scope.

This is the structure we'd write into a one-pager before any green-light meeting. Four weeks, one decision per week, no implicit scope creep.

FAQ

Is the GitHub MCP server free? Yes. The server itself is open-source under GitHub's standard license. You pay for your GitHub plan and your MCP client; the bridge is free.

Does it work with non-Anthropic clients? Any MCP 1.0 client that reads the standard config format will talk to it. That includes Cursor, Claude Desktop, Claude Code, and a growing list of others. See our MCP client comparison for the current landscape.

What about GitHub Enterprise Server? The server supports GHES targets via configuration. The auth model is identical; the API base URL differs. Check the project README for the active flag name on the version you install.

Should this replace the GitHub CLI? No. The CLI is the right tool for human-driven operations and CI scripts. The MCP server gives an assistant structured access. They coexist.

Where does this fit in the MCP server stack? It is one server in a roster. Our best MCP servers roundup and the MCP 1.0 rollout context put it next to the database, search, and filesystem servers most teams deploy together.

Verdict

If you write code on GitHub and run an MCP-aware assistant, install the official server. The fine-grained PAT is the only correct starting point. Stay read-only for a week. Promote scopes to writes when a specific workflow asks for them, not before. The vendor docs are candid about what the server does; the operational discipline is on your side of the line.