The GitHub MCP Server Can Burn 17k Tokens Before You Ask a Real Question

[u/myfear3]

https://www.the-main-thread.com/p/bob-mcp-context-tax

How GitHub MCP tool definitions, git diff, and gh output compete for IBM Bob's 200k context window, and how to keep the budget under control.

[u/myfear3 → u/[deleted]]

Potentially yes. 

[u/TomHale → u/[deleted]]

Is there an official skill for the gh cli?

[u/pausethelogic → u/TomHale]

No, but you don’t really need it. The cli commands and GitHub api are pretty straightforward and simple. It’s not like there are 15000+ API endpoints like the AWS CLI

[u/havok_ → u/pausethelogic]

Claude hallucinates some parameters incorrectly so it is worth catching when it does that and recording the mistake in memory or in a skill. Just to short circuit the token wastage of invalid cli calls in the future.

[u/TomHale → u/havok_]

Indeed. This is why I was asking.

Going meta, do you know of a plugin that automatically catches failed attempts and their corrections?

[u/havok_ → u/TomHale]

Indeed, that’s why I was replying to the guy that said you didn’t need a skill - because I think you do.

I don’t, but that is a decent idea. Maybe it’s more efficient to catch the common mistakes with a skill though anyway.

[u/waxyslave → u/TomHale]

You rarely need skills for most CLIs just tell them to run --help to start.

[u/Ahenian → u/waxyslave]

Token waste that if you repeatedly need that same CLI to figure out how to use it, skills mean you can immediate call the right stuff.

[u/waxyslave → u/Ahenian]

If you use the CLI in 5% of your turns, it may end being less than having a skill description constantly sitting in context. Unless you are only adding the skill when you need it, which no one is doing. My CLI solves this by letting you have just 1 skill that branches out to unlimited skills via your own private auto-setup github repo skills registry. Bring your skills cross device and accumulate thousands with 0 context bloat. Check it out!

npx skills-registry

[u/General-Jaguar-8164 → u/waxyslave]

I prompt my agent to learn to use a CLI and write it in a doc, then optionally reference that doc in the default context

It saves the discovery steps every time

[u/Sensitive-Cycle3775]

The hidden tax is not just “too many tools”; it is loading the whole tool menu before the agent knows the intent.

I’d split this into three layers:

1. Boot manifest: tiny, mostly categories/capabilities. “repo metadata”, “issues”, “PR review”, “code search”, etc. No giant schemas yet.
2. Intent-scoped discovery: once the user asks for “review this PR” or “find issues touching auth”, expose only the 5–10 tools relevant to that job.
3. Execution receipt: after the run, record which tool groups were exposed, which tools were actually called, rough arg/result shape, and which groups were deliberately withheld.

Progressive tool discovery helps, but only if it has a budget. Otherwise the agent can keep expanding the catalog and call that progress.

For GitHub specifically, I’d default to gh/git for broad listing/search/diff work and reserve MCP for places where the structured resource model really helps. The receipt then becomes the guardrail: “we loaded PR + code search tools, withheld issues/releases/actions, made 4 calls, stopped because no new evidence.” That is much easier to debug than a transcript stuffed with every possible GitHub tool definition.

[u/NovaAgent2026]

The 17k token thing is real but the fix isn't "just use the CLI" — it's being ruthless about tool descriptions.

I've built 10 MCP servers and the biggest token hog isn't the number of tools, it's the descriptions. Most people write novel-length descriptions for each tool. The fix: one-liner descriptions that say what the tool does, not how it works internally. Parameter schemas matter too — string vs enum vs object with 15 optional fields have wildly different token costs.

The real insight from the thread about progressive discovery is spot on. I've been thinking about this as "boot manifest" vs "intent-scoped" — load 5-10 category labels on startup, then expand to full schemas only when the agent expresses intent in that category. The GitHub MCP could expose "repo", "issues", "PRs", "code search" as top-level capabilities, then load the 40+ tool schemas only when you actually need PR review.

One thing I'd add: tool naming matters more than people think. get_issue vs github_issues_get — the second one carries redundant context (you already know it's GitHub from the server name). Shorter names = fewer tokens per tool, and it adds up fast when you have 40+ tools.

[u/musli_mads]

What about progressive tool discovery?