The 55,000-Token Problem With the GitHub MCP Server (and 4 Fixes)

If you have the official GitHub MCP server installed in Claude Code with its full tool surface enabled, roughly 55,000 tokens of your context window are spent before you type your first prompt. That's the cost of tool definitions alone, paid on every model call inside the agent loop. Piotr Hajdas counted the server at 55,000 tokens across its 93 tool definitions (dev.to/piotr_hajdas, 2026). Ken Imoto's independent measurement landed on the same 93 tools and about 55,000 tokens, against roughly 4,200 tokens for the 26-tool standard toolset (dev.to/kenimo49, 2026). A third count, from The Daily Agent on dev.to, came in lower at about 42,000 tokens (dev.to/nebulagg, 2026). Take the range as 42K to 55K: somewhere between a fifth and 27% of a 200K context window, gone before any actual work happens. This is the canonical "context tax": the standing schema cost levied by verbose MCP servers on every turn. Below is a short autopsy of where the 55K goes, followed by four ranked, measured fixes you can apply this week.

Updated September 10, 2026: re-sourced the headline token figure to Piotr Hajdas's 93-tool count (corroborated by Ken Imoto), replaced dead citation links, swapped the illustrative per-category breakdown for measured toolset totals, and refreshed the tool-search and toolset configuration guidance to match the current Claude Code and GitHub MCP docs.

Where does the GitHub MCP server spend the 42,000 tokens?#

Whether you count it at 42,000 or 55,000, the tokens are spent almost entirely on tool-definition JSON Schema, not on any work the agent actually does. The Daily Agent's dev.to autopsy put the official server at about 42,000 tokens for tool definitions alone (dev.to/nebulagg, 2026). Piotr Hajdas's count, which itemizes the tool surface, found 55,000 tokens across 93 tool definitions (dev.to/piotr_hajdas, 2026), and Ken Imoto's measurement reproduced the 93-tool, ~55,000-token figure (dev.to/kenimo49, 2026). The 55,000 figure is the one with a tool count attached, so it's the one this post uses as the headline.

The measured totals look like this:

The two full-surface counts differ, most likely because they were taken against different server versions and toolset configurations. The github-mcp-server README documents a --toolsets switch with a default set and an all set (GitHub, 2026), so "the GitHub MCP server" is not one fixed tool surface. The exact number shifts with each release and with what you enable.

Why so big? GitHub's API surface is one of the largest in the developer ecosystem. MCP requires verbose JSON Schema for every tool, with parameter types, descriptions, examples, and error formats inline. And every definition reloads on every model call inside the agent loop. There is no caching across turns.

Scott Spence put it bluntly after profiling his own Claude Code stack: with his MCP servers loaded, he was burning through a third of a 200K window just loading tools before doing anything useful (scottspence.com, 2025). Stefano Demiliani independently described the same pattern as the "too many tools" problem, with tool definitions eating 22.2% of his context window (demiliani.com, 2025). Samz's dev.to tour of the failure mode called it your MCP server "eating your context window" (dev.to/amzani, 2026). Mert Köseoğlu's Context Mode write-up reaches the same conclusion from a different angle: when MCP servers preload everything, the agent's effective working memory shrinks before it starts (mksg.lu, 2026).

The interesting thing isn't the absolute number. It's that the number tracks the server's tool surface: every toolset GitHub adds, and every toolset you leave enabled, shows up as schema on every turn. The context tax compounds with feature velocity.

Fix 1: Does Claude Code 2.0's tool-search subagent actually cut the bill?#

Yes, and by the largest margin of any single fix. Joe Njenga's production measurement, published in 2026, recorded main-thread token usage dropping from 51,000 to 8,500, a 46.9% cut on a seven-server MCP setup (Joe Njenga, Medium, 2026; figures also reproduced in Avinash Sangle's code-execution write-up, 2026). That's the highest-impact fix on the menu.

How the tool-search subagent works#

Instead of loading every tool definition into the main agent's context, Claude Code lists only the MCP tool names up front and keeps the full schemas deferred. When a task needs a specific tool, Claude loads that schema on demand through a ToolSearch call, so the main thread only ever pays for the definitions it actually uses. Anthropic's engineering guidance frames this as progressive disclosure of tool surface: expose what's needed, when it's needed (Anthropic, 2025). The mechanism is documented on the Claude Code context-window page (Anthropic Claude Code docs, 2026).

When it helps most#

GitHub MCP is the textbook case. A typical session touches a handful of the 93 available tools, so deferring the rest throws away cost the main thread never needed. The savings show up immediately in Claude Code's cost tracking; see the Claude Code costs docs for how to read them (Anthropic Claude Code docs, 2026).

How to turn it on#

In current Claude Code, tool search is the default: MCP schemas stay deferred unless you've opted out. Check that nobody has set ENABLE_TOOL_SEARCH=false in your environment, which loads everything up front. The ENABLE_TOOL_SEARCH=auto setting loads schemas eagerly only when they fit within 10% of the context window, per the context-window docs. The MCP docs also note that a custom ANTHROPIC_BASE_URL and some older model configurations run without tool search, so if you're on one of those, you won't see the savings until you move off it (Anthropic Claude Code docs, 2026). You don't need to rewrite any prompts.

ROI: highest of the four fixes. Effort: minutes.

Fix 2: How does MCP tool allow-listing cut the schema cost?#

Allow-listing cuts the GitHub MCP context tax by roughly 90% of its schema overhead, with no code changes. Ken Imoto's measurement puts the 26-tool standard toolset at about 4,200 tokens versus about 55,000 for the full 93-tool surface (dev.to/kenimo49, 2026), a 92% reduction on every turn. GitHub's own README says the same thing in plainer words: enabling only the toolsets you need helps the LLM with tool choice and reduces the context size (GitHub, 2026).

The honest question to ask is whether you really need all 93 GitHub tool definitions, or whether the repos, issues, and pull_requests toolsets cover 90% of your real workflows.

A concrete mcp.json example#

The server reads an allow-list from the GITHUB_TOOLSETS environment variable (or the --toolsets flag). Here's a Claude Code .mcp.json entry that exposes only three toolsets:

json{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
        "-e", "GITHUB_TOOLSETS",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}",
        "GITHUB_TOOLSETS": "repos,issues,pull_requests"
      }
    }
  }
}

For finer control, GITHUB_TOOLS (or --tools) names individual tools, for example get_file_contents,issue_read,create_pull_request, and combines additively with toolsets. --read-only drops every write tool regardless of what else you enable. All three switches are documented in the github-mcp-server README.

What this leaves on the table#

You lose access to actions, code_security, and the long tail of org, project, and release toolsets until you re-enable them. For most engineering teams, that's a non-issue. For platform teams running Actions or release automation through the agent, plan a second profile with GITHUB_TOOLSETS="default,actions" or similar.

Allow-listing stacks well with Fix 1. Tool search defers schema loading at runtime; allow-listing shrinks the surface it has to search in the first place. Together they leave the main thread paying for a few thousand tokens of GitHub schema instead of tens of thousands.

Fix 3: Can the GitHub CLI replace the MCP server outright?#

Often, yes. OnlyCLI's 2026 benchmark measured equivalent CLI tools at 4-32x cheaper per operation than their MCP counterparts; its GitHub example, a query against octocat/Hello-World, cost 44,026 tokens over MCP versus 1,365 over the CLI (OnlyCLI, 2026). Scalekit replicated the experiment on Sonnet 4 at 10,000 operations per month and recorded $3.20 for CLI versus $55.20 for MCP, a 17x gap on identical workloads (Scalekit, 2026).

Why the CLI wins on cost#

The schema preload disappears. The gh CLI is a single executable the agent invokes as a shell command. There's no 55K-token tool definition loaded into context, just one short command and its output. For well-scoped, repeatable operations, clone, list issues, view a PR, this is the simplest possible fix.

Where the CLI loses#

Composition. When the agent needs to chain several GitHub operations into one reasoning step, per-call shell overhead and output parsing start to dominate. The token-per-operation cost stays low, but the round-trip count climbs. MCP's strength is exactly this multi-step composition.

There's a break-even point somewhere in the low single digits of composed operations per agent turn. Below it, the CLI wins on cost and latency. Above it, MCP's batching advantage starts to matter. The exact crossover depends on workload shape and which other MCPs are loaded, so measure it on your own transcripts rather than trusting a rule of thumb.

The pragmatic split#

Use the GitHub CLI for retrieval and one-shot writes (open PR, view issue, clone). Keep MCP available behind allow-listing for workflows that genuinely need composition. See our MCP vs CLI decision rubric for a workload-by-workload breakdown.

Fix 4: When does on-demand retrieval via a context layer win?#

It wins whenever the agent is using GitHub MCP for retrieval rather than mutation, which is most of the time. The honest read on most agent transcripts: the GitHub MCP is being asked "what changed", "who reviewed this", "which issue is this PR closing", far more often than it's being asked to create or merge anything. A context layer that pre-aggregates those answers and exposes them on demand removes the need for live GitHub API calls inside the agent loop entirely.

This isn't another MCP server. It's an architectural shift. Instead of giving the agent tools to fetch GitHub state turn by turn, you give it answers to consult about GitHub state. The retrieval cost moves out of the agent's context window and into a separate service. The context tax drops because the schema isn't there to begin with. The same shift fixes the codebase-shape forgetting pattern — agents that re-explain their stack every session are paying a retrieval problem with memory-store tooling.

Andrei Antanovich, Engineering Lead at Waste Logics, described how his team operationalized this pattern:

"The first instruction in every agent project file is: before making any changes, gather context. That pulls from Jira, Confluence, and Slack via Unblocked, because that's where most of our knowledge actually lives, in threaded discussions. I set it up the day it was announced and now I don't even think about it. I just get the relevant information."

Unblocked is the context layer for coding agents. It fetches PR descriptions, commit history, and related issues on demand, and unifies code repos with PRs, Slack, Jira, Notion, and Confluence at the moment of decision, so the agent doesn't pay the 55K context tax just to ask "what happened on this PR last week".

The teams who pick this path generally aren't trying to optimize the GitHub MCP. They've decided the agent's working memory is too valuable to spend on schema, and they want retrieval handled by a service designed for it.

Which fix should you start with?#

Start with Fix 1, then layer Fix 2 on top, before considering 3 or 4. The ROI ranking below assumes you have the official GitHub MCP installed in Claude Code and want measurable token savings this week.

Stacking compounds#

Fix 1 and Fix 2 compound cleanly. Tool search defers schema loading at runtime, allow-listing shrinks the surface it defers. Together they take the GitHub MCP's standing cost on the main thread from tens of thousands of tokens down to the handful of definitions each turn actually needs, without touching prompts. Verify the drop with Claude Code's cost tracking before and after each change; the Claude Code costs docs cover how to read it (Anthropic Claude Code docs, 2026).

Substitution vs. layering#

Fix 3 partially substitutes for Fixes 1 and 2 by removing MCP from scoped operations entirely. Fix 4 is the structural answer: the context tax exists because retrieval lives in the agent loop. Move retrieval out and the tax disappears.

The fix you choose is really a statement about how you treat the agent's context window. Fixes 1 and 2 say "keep MCP, pay less." Fix 3 says "use the right tool per workload." Fix 4 says "stop paying schema rent for retrieval at all."

For the underlying budget math, the P8 token-budget autopsy walks through the full accounting. For why MCP alone doesn't solve context loss, see MCP isn't a context strategy.

FAQ#

How many tokens does the GitHub MCP server actually use?#

Three 2026 community counts bracket it: Piotr Hajdas measured 55,000 tokens across 93 tool definitions (dev.to/piotr_hajdas, 2026); Ken Imoto reproduced 93 tools at about 55,000 tokens, against about 4,200 for the 26-tool standard toolset (dev.to/kenimo49, 2026); The Daily Agent recorded about 42,000 tokens (dev.to/nebulagg, 2026). Plan for 42K to 55K with the full surface enabled, paid on every turn until you intervene.

Does Claude Code's tool-search subagent work for the GitHub MCP?#

Yes, and it's the highest-ROI single fix. Joe Njenga's measurement showed main-thread tokens dropping from 51K to 8.5K (46.9%) on a seven-server MCP setup (Joe Njenga, Medium, 2026). The deferred-loading mechanism and the ENABLE_TOOL_SEARCH setting are documented on the Claude Code context-window page (Anthropic, 2026).

Can I just remove the GitHub MCP and use gh instead?#

For scoped operations, yes. Scalekit's 2026 benchmark put monthly cost at $3.20 for CLI vs $55.20 for MCP at 10,000 ops on Sonnet 4 (Scalekit, 2026). The trade-off: you lose cross-tool composition. Most teams end up using both, with allow-listing on the MCP side. See the MCP vs CLI decision rubric.

Is the official GitHub MCP server the only option?#

No. Several community MCP servers expose smaller subsets of the GitHub API at much lower token cost. The 55K number applies specifically to the official server with its full 93-tool surface. Allow-listing toolsets reduces it without switching servers, and is usually the simpler path.

What about the GitHub Copilot extension? Does it have the same problem?#

The Copilot extension is a different surface that doesn't expose MCP-style schema preloads inside the Claude Code agent loop, so it doesn't levy the same context tax. The trade-off is reduced flexibility: you can't compose Copilot operations the way you can with MCP tools. Different tool, different shape, different cost profile.

Choose your fix#

If you take one action this week, confirm Claude Code's tool search is on and audit your mcp.json for a GITHUB_TOOLSETS allow-list. Together, those two changes remove most of the GitHub MCP context tax from the main thread with no prompt rewrites. Verify the drop with Claude Code's cost tracking, before and after.

Within the month, pick one workflow, PR review automation is a good candidate, and run it through the gh CLI instead of MCP. Compare cost, latency, and reliability. If it wins on all three, expand the pattern.

Quarterly, ask the bigger question: how much of the GitHub MCP's job is actually retrieval the agent could consult instead of fetch? If the answer is "most of it", evaluate whether on-demand retrieval via a context layer architecture fits your stack. The fixes above buy you breathing room. Moving retrieval out of the loop is the structural answer to the context tax.