AI disclosure: Sho Naka (nomurasan). Originally investigated and written up in Japanese; this English version is an AI-assisted rewrite, not a translation — the logs, the commands, and the conclusions are mine.
Every tool the GitHub MCP server offered was sitting right there in the list — all 26 were recognized correctly. Call any one of them and it failed in under 1 second, every time, with one line on screen: Tool execution failed. No reason attached. Even reading a fully public repository — something that needs no permission at all — failed the exact same way.
TL;DR: my AI assistant's first guess — "maybe the token's gone bad" — was right the whole time. I ran an experiment that looked like it ruled that out, filed the token away as cleared, and spent the next few hours on a different trail. The experiment couldn't have ruled it out. I just misread what a failed test actually proved.
Everything below was measured on one machine: Windows 11, Claude Desktop 1.28929.0, on 2026-08-12. Versions move fast and behavior changes between them — read this as a dated data point, not a permanent description of the product.
The symptom
-
tools/listfor the GitHub MCP server correctly returned all 26 tools. - Calling any of them failed almost instantly — well under 1 second.
- The only error shown was
Tool execution failed. No code, no detail, nothing to search for. - Reading a fully public repository failed exactly the same way as everything else.
If the tools simply hadn't shown up, this would be a short investigation. What made it strange was that they were all visible and all still failed.
The hypothesis, and the experiment that seemed to kill it
I described the symptom to my AI assistant, and its first suggestion was ordinary: maybe the token has gone bad. Reasonable enough to check first. So I checked it — three different ways, in the wrong order.
1. I re-authorized the GitHub App
Full permissions, redone from scratch. 3 times. The symptom didn't move by a millimeter.
2. I tried a public repository
This felt like the deciding test. If the problem were insufficient scope on the token, a repository anyone can read without authenticating should still work fine.
It didn't. Same Tool execution failed.
At that point I concluded the problem wasn't permissions-related, and folded "the token has gone bad" into that same conclusion — discarded, both at once, in one motion. That fold was the mistake, and I'll come back to exactly why.
3. I switched from Desktop to the web client
GitHub's tools disappeared from the list entirely on the web. That told me something true and useful — the GitHub connector is Desktop-local configuration, not something shared across clients. It told me nothing about the actual cause. I didn't know that yet, so I took it as forward progress and started searching for a matching known issue instead.
What the logs actually said
Before writing any of this up, I went back over what I was about to claim and checked it piece by piece. That's when I noticed something I hadn't done once in several hours of troubleshooting: open my own mcp.log and look at whether tools/call was actually leaving the client.
Windows keeps it at %APPDATA%\Claude\logs\ — a mcp.log, plus a mcp-server-<name>.log per server. macOS keeps the equivalent under ~/Library/Logs/Claude/. Opening it surfaced what the UI had been swallowing:
2026-08-12T02:58:07.223Z [info] [github] Message from client: method="tools/list" id=1 params
2026-08-12T02:58:07.242Z [info] [github] Message from server: id=1 result
2026-08-12T07:06:06.486Z [info] [github] Message from client: method="tools/call" id=2 params
2026-08-12T07:06:06.816Z [info] [github] Message from server: id=2 error(code=-32603)
2026-08-12T07:06:11.249Z [info] [github] Message from client: method="tools/call" id=3 params
2026-08-12T07:06:11.482Z [info] [github] Message from server: id=3 error(code=-32603)
Three things came out of that immediately:
-
tools/callwas reaching the server (Message from client). - The server was replying (
Message from server) — not hanging, not timing out. - What it replied with was
-32603— JSON-RPC 2.0's generic Internal error.
So this was never "the call vanishes somewhere." The server was doing work and returning an error. One look at the log said more than the previous few hours of repeating the same fix had.
The known issues looked similar, until I checked the direction
By that point I'd found two open issues on anthropics/claude-code that looked close enough to be worth writing up as the cause:
| Issue | What it reports |
|---|---|
| #79986 | External stdio MCP tools appear in the list but are never dispatched — zero tools/call ever fires |
| #80094 | macOS filesystem MCP: tools on the new schema are never dispatched; tools on the old schema fail at registration |
Both were still open on the day I checked. #79986's own title is specific about the count that matters: zero tools/call. Mine wasn't zero — it was 11 calls, all through the same log window. The surface symptom rhymed ("tools are visible, calls fail"), but the layer where it actually broke was the opposite of what #79986 describes. Writing this up as the same root cause would have been wrong.
One thread on #80094 speculates that Desktop refuses to dispatch tools whose schema declares outputSchema/structuredContent — worth flagging that this is the reporter's theory, not something Anthropic confirmed. It also doesn't apply here regardless: out of my 26 tools, 0 were found to have declared an outputSchema.
Reproducing it directly
-32603 only says "internal," so I went and got the actual content. I ran the same MCP server Desktop was running — same command, same environment variables — directly over stdio, and sent it one tools/call:
{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": -32603,
"message": "Authentication Failed: Bad credentials"
}
}
An authentication error. So I took the same token straight to the GitHub API, no MCP layer involved:
GET https://api.github.com/user -> 401 Bad credentials
GET https://api.github.com/repos/modelcontextprotocol/servers -> 401 Bad credentials
The second line is the one that matters. modelcontextprotocol/servers is a fully public repository — anyone can read it with no credentials at all. It still came back 401.
What I actually got wrong
Mistake 1: "still failed on a public repo" only killed half of "it's a permissions problem."
I'd been treating "the token doesn't have the right permissions" as one hypothesis. It's really two, and a public-repo test tells them apart very differently:
| Hypothesis | Result on a public repo |
|---|---|
Token's scope is too narrow (missing repo, etc.) |
Dies. Insufficient scope still reads public data fine |
| Token itself is invalid (whatever the reason) |
Survives. A broken Authorization header gets 401 even on public resources |
Anonymous, no-header requests can read public repos all day. That's not what I sent. I sent a request carrying a token — a bad one — and GitHub answers a bad token with 401 regardless of whether the resource behind it needed a token in the first place.
An experiment can only kill one hypothesis at a time. "Still failed on a public repo" killed the scope hypothesis. It said nothing about the invalid-token hypothesis, which was still standing the entire time. I filed both under "not a permissions problem" and moved on.
I thought I'd disproven the hypothesis. What I was actually looking at was a result the hypothesis predicted.
Mistake 2: three re-authorizations touched a credential I wasn't actually using.
What I redid, three times, was the GitHub App / connector authorization. What the server was actually reading was a Personal Access Token hardcoded into claude_desktop_config.json:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..." }
}
}
}
Those are two separate credentials. No amount of re-authorizing the App reaches into that config file and touches the PAT sitting in env. Three attempts, zero change in symptom — that flat result wasn't "not quite enough yet," it was "wrong target" from the start. A third identical retry almost never teaches you anything a first one didn't.
Mistake 3: I mistook narrowing the search for approaching the cause.
Desktop → web losing the GitHub tools was real, and it correctly told me the connector was local Desktop configuration. It just had nothing to do with why calls were failing — that was authentication, unrelated to which client I had open. The search space genuinely got smaller. That's not the same as getting closer to the answer, and the feeling that it was is exactly what sent me toward known-issue-hunting instead of my own logs.
The discipline that would have caught this sooner
The piece I was missing wasn't a debugging technique, it was a question to ask before running the experiment, not after:
If this experiment fails, which hypothesis does that kill — and which one survives?
"What happens if this hypothesis is true" isn't enough on its own. It misses exactly the case I hit here, where the failure of the experiment was itself evidence for the hypothesis I thought I'd just ruled out.
The other half of it: an AI assistant will not stop you from repeating the same fix. "Let's try re-authorizing with full permissions again" is available as a suggestion an unlimited number of times. Capping the repeat count is a job only the human in the loop actually does.
A short checklist, for next time
-
See
Tool execution failed? Open the log before touching anything.mcp.logplusmcp-server-<name>.logtell you in one read whether the break is client→server or server→client — that alone would have saved the first hour here. -
Suspect auth? Test the credential outside MCP entirely.
curl -H "Authorization: Bearer $TOKEN" https://api.github.com/usersettles it in one request. Every layer you go through instead is one more place to misread the result. - A UI-level re-authorization does not touch a token hardcoded in a config file. Check which credential is actually in play before repeating the same fix a third time.
-
Check whether the server package is still alive.
@modelcontextprotocol/server-githubis deprecated on npm — "Package no longer supported. Contact Support at https://www.npmjs.com/support for more info." — last published 2025.4.8. "Not working" is sometimes the package, not your setup. -
If a plain CLI can do the same job, that's one fewer layer to debug later. Everything in this investigation was also doable with
gh.
How I actually fixed it
Rotating the token would have brought GitHub's tools back on its own. It wouldn't have addressed the actual design problem: as long as a long-lived PAT sits in a config file in plaintext, this happens again the next time it lapses. So I switched servers instead of just rotating the secret.
One thing in GitHub's own docs is easy to miss here. Claude Desktop can't use GitHub's remote MCP server at all:
However, the GitHub remote MCP server requires OAuth authentication through a registered GitHub App (or OAuth App), which is not currently supported. Use the local Docker setup instead.
— github/github-mcp-server, Claude installation guide
Other clients can reach https://api.githubcopilot.com/mcp/ directly; Desktop can't, which is an easy assumption to carry over by mistake. The local stdio server is the supported path.
The official release binaries — and the official Docker image — ship with a GitHub OAuth app already registered and baked in, so they start up with no PAT at all. The first tool call triggers a browser-based authorization, and the token that comes back is kept in memory only, never written to disk. The docs recommend the native binary specifically, which picks a random local callback port and opens your browser automatically.
{
"mcpServers": {
"github": {
"command": "<path to the github-mcp-server binary>",
"args": ["stdio"]
}
}
}
The config file no longer holds a secret at all. That's the part of this that actually matters going forward — nothing left in the file to go bad.
What I can't claim
In the interest of not overstating this:
-
I can't call this a regression. The logs I have on hand go back well over six months, and none of them show an earlier
tools/callat all. Whether this used to work and broke, or this was simply the first time it was ever exercised, isn't something this record can answer. - I don't know why the PAT went invalid. Expiry, revocation, some GitHub-side invalidation policy — I have no way to tell those apart from what I collected.
- This doesn't refute #79986 or #80094. My environment hit a different failure shape — calls reaching the server and erroring, not calls that never fire — and that's all I can say about it. Both issues were still open the day I checked. A symptom that looks similar from the outside doesn't guarantee the same cause underneath.
-
My Claude Desktop had auto-updated the same day, from 1.26832.0 to 1.28929.0 (confirmed via
Squirrel-Update.log). The timing is close, but since the authentication error reproduces regardless, that's not a basis for tying the update to the failure. "There was an update right before" isn't evidence of a cause.
The takeaway
Doing the same thing three times isn't verification. When you think you've disproven something, say out loud what you actually disproved before you act on it. And once you're in the mode of crossing hypotheses off a list, check your own arithmetic on each cross-off — don't just trust the motion of crossing things off.
Half a day of investigation brought me back to what the AI told me after just 1 minute. What actually went wrong wasn't the hypothesis. It was the experiment I ran to try to kill a hypothesis that happened to be correct.
References
The two open issues referenced above are anthropics/claude-code#79986 and anthropics/claude-code#80094. The GitHub MCP server docs cited here are the Claude installation guide and the OAuth login guide.
