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 use, mostly because of how much it sends back, 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:

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?

Because of what it returns, and, on some setups, because of its size. Its responses are the main cost: list_issues, list_pull_requests or get_pull_request come back as pages of JSON full of URLs, node IDs, avatars, label objects and nested user records, most of which the model never reads. Each result lands in context and stays in history, so it is re-sent on every later turn of the session.

The manifest is large too. The server documents around 82 tools across 20 toolsets; 56 of those are read-only, the rest write. On agents that load tool definitions upfront, every one of those schemas rides along on every turn. Current agents mostly don't: Claude Code defers MCP tool definitions by default through tool search (Claude 4.5 and later models), loading a schema only when the model reaches for it. Behind a third-party API proxy, with alwaysLoad, or in an agent without tool search, the full manifest is back on every 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. Then work through a few issues or PRs and look again: the jump is what its responses cost. Two minutes, and the numbers are actually yours.

How do you cut its cost without losing it?

Two levers: narrow what it exposes, and shrink what it returns. The first is the part that makes GitHub's server unusual: unlike most servers, it ships real controls for narrowing what it advertises. Fewer tools means fewer chances for the model to pick the wrong one, no write powers you didn't intend, and a smaller manifest wherever tools still load upfront.

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:

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.

Shrink the responses. The flags above don't change how verbose each result is. For that you need a layer between the agent and the server: Tokenade's MCP proxy (tokenade mcp-wrap install github) runs GitHub's output through a dedicated compactor before it reaches the model, keeping the fields the agent works with and folding the rest. The full result stays recoverable if the agent needs a detail.

The pattern to internalise is that the default install is the broad install. A few flags at connection time cost nothing; on setups without deferred loading they pay back on every turn, 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 keeps the agent focused on the tools it needs.

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 matters most is not picking the perfect set — it's having a set instead of accepting the defaults. Two toolsets in --read-only is a fraction of the default surface, 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 place 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 clutter at best, and per-turn overhead on setups that load tools upfront.

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 output, Tokenade compacts what MCP servers return before it reaches the context — GitHub's output gets a dedicated compactor, and every other connected server a generic one — across Claude Code, Cursor, Codex, Copilot and Windsurf.

What are the GitHub MCP alternatives with lower token usage?

The cheapest alternative is often no MCP server at all: let the agent run GitHub's own gh CLI in its shell. A CLI adds no tool listing at all, and flags like --json with --jq return only the fields you ask for. If you keep the MCP server, a narrow toolset in --read-only is the low-cost version of it.

Three options, from no setup to most:

• gh through the agent's shell. gh pr view 123 --json title,files, gh pr diff 123, or gh run view <run-id> --log-failed for only the failed steps of a CI run. You pay for the output of the call you make, nothing else.
• GitHub's server, narrowed. --toolsets plus --read-only, as above. Same server, a fraction of the surface.
• A compaction layer on top. Tokenade compacts MCP results (with a dedicated GitHub compactor) and command output, gh included, before they reach the model. It runs locally, through an MCP proxy and your agent's hooks.

The trade-off: gh output is text the model has to parse, while MCP returns structured results. For a one-off "why did CI fail", the CLI wins. For a long session working through many issues and PRs, a narrow MCP server can be the cleaner choice.

What goes wrong (anti-patterns)

Installing it with defaults and forgetting it. Five toolsets you didn't choose, in every project, and on every turn if your setup loads tools upfront.

Letting raw responses pile up. A long triage session can fill the context with issue JSON the model skimmed once. Compact it before it lands.

Global scope. A GitHub server following you into a repo that isn't on GitHub is clutter 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 it puts in your context, mostly through its responses. The hosted endpoint is tied to your GitHub account. The real cost is contextual, not monetary.

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, and so does whether tool definitions are deferred; the size of its responses 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:

• MCP servers: what they are and what they cost — the agent-agnostic overview.
• Claude Code MCP: how to set it up — transports, scopes, secrets.
• Best Claude Code MCP servers, ranked by real cost — where GitHub's sits against the rest.
• Lazy MCP loading — now built into most agents, and where you still set it up.