GitHub MCP Server: Setup and What It Costs

What is the GitHub MCP server?

The GitHub MCP server is GitHub's official MCP implementation: it exposes issues, pull requests, repositories, Actions, security alerts and more as tools your AI agent can call directly. You can use it as a hosted endpoint at https://api.githubcopilot.com/mcp/, or run it yourself from the ghcr.io/github/github-mcp-server Docker image. It's genuinely useful — an agent that can read a PR diff, check why CI failed and open an issue without you copy-pasting between tabs removes a lot of friction. It is also, by a comfortable margin, one of the heaviest servers you can leave connected, and almost nobody tells you that when they tell you to install it.

How do you add the GitHub MCP server?

One command for the hosted endpoint, with a GitHub token in the header:

claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
--header "Authorization: Bearer <YOUR_GITHUB_PAT>"

Authentication works two ways: a personal access token as above, or OAuth — HTTP MCP servers negotiate it automatically, and the /mcp panel walks you through browser sign-in. OAuth is the better default for a personal machine; a scoped PAT is easier to reason about in CI or a shared environment. Prefer to keep it local? Run the Docker image instead and point your agent at the process over stdio. Same tools, no traffic to a hosted endpoint, and full control over which flags it starts with — which turns out to matter, for reasons the next section explains. For the wider mechanics — scopes, .mcp.json, secret expansion, connection states — see Claude Code MCP setup.

Why is the GitHub MCP server expensive to leave connected?

Because it is large, and because size in MCP is a per-turn cost rather than a one-off. The server documents around 82 tools across 20 toolsets; 56 of those are read-only, the rest write. Every tool schema it advertises is re-sent to the model on every single turn of your session, whether you call GitHub once or never. That's not a flaw in GitHub's implementation — it's how the protocol works. A model can't call a tool it hasn't been told exists, so the manifest travels with the conversation. The consequence is that a broad server behaves like a subscription you pay per turn. Two honest caveats about numbers here, because this is where write-ups get sloppy: GitHub has never published a token cost for this manifest. Third-party estimates disagree badly — 42,000, 55,000 and 64,600 tokens all circulate for the same server in the same period. Treat any specific figure with suspicion, including ones stated as fact elsewhere. The one vendor number is narrower than it looks. GitHub's January 2026 changelog reports saving "around 23,000 tokens" by consolidating the Projects toolset into three tools. That's savings on one toolset from one change — not the size of the whole manifest, and not a figure you can generalise. What you can do instead is measure yours: run /context in a fresh session before typing anything, connect the server, restart, and compare. Two minutes, and the number is actually yours.

How do you cut its cost without losing it?

Load a slice instead of the whole thing. This is the part that makes GitHub's server unusual: unlike most servers, it ships real controls for narrowing what it advertises. Pick your toolsets. Only five are enabled by default (context, issues, pull_requests, repos, users) out of twenty. If your work is PR review, you may only need two:

--toolsets pull_requests,repos
# or, in the Docker environment
GITHUB_TOOLSETS="pull_requests,repos"

Go read-only if you don't need writes. --read-only (or GITHUB_READ_ONLY=1) drops every write tool, which is most of the difference between 82 tools and 56. It's also a decent safety posture for an autonomous agent — it can investigate, it can't open or close anything. Cherry-pick individual tools. --tools and --exclude-tools let you compose a set by hand: --toolsets repos --tools get_gist adds one tool from outside the selected toolsets. Don't reach for --dynamic-toolsets. It was removed in May 2026. Guides still reference it; it isn't there. The pattern to internalise is that the default install is the expensive install. A few flags at connection time cost nothing and are paid back on every turn for the life of the session — the same logic as lazy MCP loading, applied by hand.

Which toolsets do you actually need?

Fewer than the default, in most cases. The five that ship enabled cover a broad "general GitHub use" profile, which is the right default for a product but rarely the right fit for a specific project. Mapping the work to the toolset is a two-minute decision that pays on every turn. Rough starting points, by what you actually do:

Reviewing pull requests. pull_requests and repos. You need diffs and file contents; you don't need Dependabot, discussions or stargazers.
Triaging issues. issues and labels, plus orgs if you work across several. Drop pull_requests entirely if triage is a separate session from review.
Debugging CI. actions and repos. This is the case where the server most clearly earns its keep — reading a failed workflow run beats an agent guessing from YAML.
Security work. code_security, secret_protection, security_advisories, dependabot. A heavy set, but only loaded in sessions that need it.
Reading a codebase you don't own. repos and context, in --read-only. Minimal surface, no write risk.

The pattern that saves the most is not picking the perfect set — it's having a set instead of accepting twenty. Two toolsets in --read-only is a fraction of the default manifest, and for most single-purpose sessions it's everything you'll call. One caution: narrowing too far has its own cost. If the agent needs a tool you excluded, it can't call it — and it will usually work around the gap by reading files instead, which is more expensive than the tool would have been. Start from the workflow, not from a target tool count.

Should you run it at all?

Yes, if you actually work through GitHub from your agent — and no, if you connected it once and haven't invoked it since. The test isn't whether the server is useful in principle; it's whether it earned its manifest this week. A server that answers "why did CI fail on this PR" in one call beats an agent reading workflow files and guessing. A server sitting idle in a project that never touches GitHub is pure per-turn overhead. If you keep it, scope it to the projects that need it rather than installing it globally, and narrow the toolsets to the work you actually do. If your sessions are dominated by MCP overhead generally, Tokenade loads tool definitions lazily so idle servers stop riding along on every turn — it works with any connected server, GitHub's included, across Claude Code, Cursor, Codex, Copilot and Windsurf.

What goes wrong (anti-patterns)

Installing it with defaults and forgetting it. Five toolsets you didn't choose, advertised on every turn, in every project. Global scope. A GitHub server following you into a repo that isn't on GitHub is paying rent for nothing. Quoting a manifest size from a blog post. They disagree by 20,000+ tokens. Measure yours. Using --dynamic-toolsets. Removed in May 2026. If a guide recommends it, that guide is stale — treat the rest of its advice accordingly. Granting write scope by default. --read-only removes most of the tools and most of the blast radius. Add writes when you need them, not before.

Frequently asked questions

Is the GitHub MCP server free?

The server itself is open source and the Docker image is public, so running it costs you nothing beyond the tokens its manifest occupies in your context. The hosted endpoint is tied to your GitHub account. The real cost is contextual, not monetary — which is exactly why the toolset flags matter.

Do I need a PAT, or is OAuth enough?

Either works. OAuth is smoother for a personal machine — the /mcp panel handles browser sign-in and you never paste a token. A scoped PAT is easier to audit and rotate, which usually makes it the better fit for shared or automated environments.

How many tools does it actually expose?

Around 82 across 20 toolsets, of which 56 are read-only. Only five toolsets are on by default. The count drifts between releases, which is another reason to measure your own context rather than trusting a number you read somewhere — including this one, six months from now.

Can I use it outside Claude Code?

Yes. It's a standard MCP server, so any MCP-speaking host can connect — Cursor, Codex, Copilot, Windsurf and others. Configuration format differs per host; the per-turn manifest cost does not. MCP servers explained covers the agent-agnostic picture.

What's the difference between `--toolsets` and `--tools`?

--toolsets selects whole groups (pull_requests, actions, security_advisories…). --tools selects individual tools by name, and can pull one in from a toolset you haven't otherwise enabled. --exclude-tools removes specific tools from whatever the rest of your configuration selected. They compose.

See also: