All 26 of My MCP Tools Failed the Same Way. My Test to Rule Out the Token Proved It Was the Problem.

A developer troubleshooting the GitHub MCP server in Claude Desktop found that all 26 tools failed with 'Tool execution failed' in under a second, despite being listed correctly. After initially suspecting an expired token and ruling it out, the developer discovered via the mcp.log that the server was returning a generic JSON-RPC error (-32603), indicating the issue was not permissions. The developer concluded that the token was indeed the problem, as a public repository read also failed, and noted that the experiment to rule out the token was misinterpreted.

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. tools/list for the GitHub MCP server correctly returned all Tool execution failed . No code, no detail, nothing to search for.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. 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. Full permissions, redone from scratch. 3 times. The symptom didn't move by a millimeter. 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. 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. 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/call Message from client . Message from server — not hanging, not timing out. -32603 — JSON-RPC 2.0's generic 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. 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 | |---|---| | tools/call ever firesBoth 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 . -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: php 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 . 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. 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. 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 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. Tool execution failed ? Open the log before touching anything. mcp.log plus mcp-server-<name .log tell you in one read whether the break is client→server or server→client — that alone would have saved the first hour here. curl -H "Authorization: Bearer $TOKEN" https://api.github.com/user settles it in one request. Every layer you go through instead is one more place to misread the result. @modelcontextprotocol/server-github is deprecated on npm — "Package no longer supported. Contact Support at gh .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 https://github.com/github/github-mcp-server/blob/main/docs/oauth-login.md . 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. In the interest of not overstating this: tools/call at 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. 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.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. The two open issues referenced above are anthropics/claude-code 79986 https://github.com/anthropics/claude-code/issues/79986 and anthropics/claude-code 80094 https://github.com/anthropics/claude-code/issues/80094 . The GitHub MCP server docs cited here are the Claude installation guide https://github.com/github/github-mcp-server/blob/main/docs/installation-guides/install-claude.md and the OAuth login guide https://github.com/github/github-mcp-server/blob/main/docs/oauth-login.md . 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.