Claude Code MCP Not Working: 3 of My 5 Servers, 4,112 Issues

Tonight claude mcp list on the Mac mini that runs this business printed five MCP servers, and three of them were not working:

claude.ai html.to.design: https://mcp.to.design - ! Needs authentication
claude.ai Supabase: https://mcp.supabase.com/mcp - ✔ Connected
plugin:oh-my-claudecode:t: node …/bridge/mcp-server.cjs - ✔ Connected
plugin:toprank:NotFair-GoogleAds: https://notfair.co/api/mcp/google_ads (HTTP) - ! Needs authentication
plugin:toprank:NotFair-MetaAds: https://notfair.co/api/mcp/meta_ads (HTTP) - ! Needs authentication

I added none of the five with claude mcp add. The user-scope server list in ~/.claude.json is empty, so is this project's local list, and the repo has no .mcp.json. Two servers came from the claude.ai account and three from plugins. The three that need authentication will stay that way. OAuth sign-in runs through the /mcp panel, and every job on this machine is a headless claude -p run that has no panel. One of them already showed the same status when I wrote about headless MCP in July.

That is one way an MCP server stops working in Claude Code. To find the rest I pulled every issue in anthropics/claude-code that carries the area:mcp label, 4,112 of them, sorted the CLI ones by cause, and timed the startup cutoff with a server built to be slow. The short version: read the status word before you read the error.

4,112 issues, and "not planned" mostly means stale

I used the issues list API rather than search, because search stops at 1,000 results. The label covers more than the terminal. By label and title keywords, 424 issues are about claude.ai connectors or the web, 242 about the desktop app, 234 about Chrome, 206 about IDE extensions and 190 about Cowork. That leaves 2,816 for the CLI, and 2,103 once 713 feature requests are set aside.

Across the whole label, 61% of issues are closed as not planned, 21% closed as completed, and 16% still open. Of the 2,508 not-planned closures, 1,943 carry a stale or autoclose label, so most of them timed out rather than being turned down. If a search lands you on a "not planned" issue that matches your error, it says little about whether your bug is real. Filing peaked in April 2026 at 666 issues and ran between 320 and 364 a month from June through August.

Start with the status word

The MCP documentation lists the statuses claude mcp list can print. Each one points at a different bucket in the chart, and each needs a different first move:

Status	What it means	Bucket (CLI reports)	First move
! Needs authentication	OAuth never finished, or a token refresh failed	Authentication (353)	Run claude interactively, open /mcp, sign in
✘ Failed to connect	The process died or the URL answered with an error	Connect / startup (457)	claude mcp get <name> and read its Issue: line
⏸ Pending approval	A project .mcp.json server nobody has approved	Approval / scope / config (292)	Run claude in that folder and approve it
⊘ Disabled for this project	Named in disabledMcpServers	Approval / scope / config	Turn it back on in /mcp
✔ Connected, no tools	The server is up but its tool list is empty or rejected	Tools missing / schema (179)	Check the tool count in /mcp

One failure never shows up here. claude mcp list checks the config, not what the next headless run receives, and in July headless runs got MCP tools late, with no error while this command said Connected.

Needs authentication: the biggest named bucket

353 CLI reports, 226 of them with OAuth in the title. The most-reacted bug in the CLI set is #3433, GitHub's remote MCP server failing OAuth: 152 reactions, opened 2025-07-13, reopened and still open. The changelog shows how many separate ways sign-in has broken. Version 2.1.136 (May 8) stopped refresh tokens being lost when several servers refreshed at once, which the entry says had meant "daily re-authentication". 2.1.229 (August 12) moved the redirect URI from localhost to 127.0.0.1 for strict authorization servers. 2.1.268 (September 10) fixed "No available ports for OAuth redirect". If a server worked last week and needs auth today, check your version before you check the server.

Headless is its own case, and it is mine. The docs say print mode has no /mcp panel and so cannot run the OAuth flow; since 2.1.196, with tool search on, Claude is told the server's tools are unavailable instead of finding them missing. The fix is one interactive session to sign in, or putting the servers in disabledMcpServers. I have done neither, because nothing I run calls those tools. The cost so far is small: this session opened with a notice naming all three.

Failed to connect, or too slow: I timed the cutoff

Connect and startup problems are the largest named bucket, 457 reports. For a stdio server the setting that matters is MCP_TIMEOUT, which the environment variable reference gives as 30,000 ms by default. I wanted to see that number instead of trusting it, and to recheck the July race, which I had measured on 2.1.220. I wrote a stdio server of about 20 lines that sleeps before answering initialize and exposes a single tool, ping, then ran it through print mode on 2.1.270:

DELAY=25   # set in the server's env block in cfg.json
claude -p "Call the mcp__slow__ping tool once, then reply with its output." \
  --mcp-config cfg.json --strict-mcp-config \
  --output-format stream-json --verbose --model haiku \
  --max-turns 3 --allowedTools mcp__slow__ping < /dev/null

Server delay	Status at init	ping called	Exit code	Wall time
0 s	connected	yes	0	10.3 s
3 s	connected	yes	0	12.3 s
8 s	connected	yes	0	17.2 s
25 s	connected	yes	0	30.6 s
35 s	failed	no	0	35.1 s
40 s	failed	no	0	38.2 s
40 s, MCP_TIMEOUT=60000	connected	yes	0	45.5 s

Three things came out of it. For this path, the July race is gone: 2.1.221 made print mode wait for --mcp-config servers, and even a 25-second start reached the first turn. The ceiling sits between my 25 and 35 second runs, which fits the documented 30 seconds, and raising MCP_TIMEOUT moves it. And a server that misses the ceiling still leaves you with exit code 0. The model replies that it can't call the tool, and the run counts as a success. If a scheduled job depends on an MCP tool, read the status from the init event:

claude -p "…" --output-format stream-json --verbose … \
  | jq -c 'select(.type=="system" and .subtype=="init") | .mcp_servers'
# [{"name":"slow","status":"failed"}]

I only went as high as 60,000. #16837, open since January, reports that values above 60 seconds are ignored, so a server that needs more than a minute should start faster instead. In July a pinned local binary answered initialize in 0.24 s where npx -y …@latest took 0.8 s.

Pending approval and the .mcp.json cases

292 reports. A server in a project .mcp.json does nothing until someone approves it, and since 2.1.196 claude mcp list reads approvals only from settings files that aren't committed to the repo, until you accept the workspace trust dialog. Print mode, SDK and cloud sessions skip the question and load project servers without asking, so the same file can behave differently in a terminal and in a script. Three reports show the usual mistakes. #5037 is about a file at .claude/.mcp.json; the docs put it at the project root. #13107, with 73 reactions, found the SDK ignored .mcp.json until the CLI had been run in that directory once; it was closed as completed eleven days after filing. #11927, still open, reports that env values in settings.json don't reach MCP servers. The documented route is --env KEY=value on claude mcp add, which writes the variable into the server's own entry.

Connected, with no tools

179 reports where the server is up and its tools are missing or rejected. The fixed ones are specific. Tool names over 64 characters produced an API 400 (#21136). 2.1.259 (September 2) fixed servers that dropped while their tools were being listed and then showed as connected with none. /mcp now flags a server that advertises tools and exposes zero. One lookalike is not a bug: with Claude Code tool search on, MCP tools are deferred and stay out of the model's tool list until it searches for them. The Supabase tools in this session arrived that way.

The order I would check things

1. claude --version, then the changelog entries after it. 211 lines begin with "Fix" and mention MCP, 36 of them from August releases, so yours may already be fixed.
2. claude mcp list, and the status word on your server's line.
3. claude mcp get <name> for the Issue: line on a failed server.
4. For a slow stdio server, MCP_TIMEOUT=60000 and a pinned command instead of npx with @latest.
5. In scripts, the mcp_servers array in the init event, never the exit code.

The same census approach found six causes behind a blank status line in Claude Code statusline not working, and for connectors that suddenly fail after a login change, Claude Code OAuth session expired covers the account side.

FAQ

Why does Claude Code say my MCP server needs authentication?

The server uses OAuth and Claude Code holds no valid token for it, either because sign-in never finished or because a refresh failed. Run claude interactively, open /mcp and sign in. A claude -p run has no /mcp panel, so the sign-in has to happen in an interactive session first.

How do I increase the MCP server startup timeout in Claude Code?

Set MCP_TIMEOUT in milliseconds, for example MCP_TIMEOUT=60000 claude, against a default of 30,000. On 2.1.270, a stdio server that took 35 seconds to answer failed under the default and connected with 60,000.

Why is my .mcp.json MCP server not loading?

Project servers need approval. Put .mcp.json at the project root, run claude in that folder, accept the workspace trust dialog and approve the server; claude mcp list shows ⏸ Pending approval until then. Print mode and SDK sessions load project servers without asking.

Sources and method: the census is every issue labeled area:mcp in anthropics/claude-code, pulled through the GitHub issues list API on 2026-09-14 at 21:15 KST (4,112 issues, no pull requests). I split surfaces by labels plus title words (Cowork, desktop, Chrome, claude.ai or connector, IDE) and counted feature requests as anything with the enhancement label or request-shaped wording; cause buckets are title regexes, first match wins, and states will drift as issues close. Changelog counts are from CHANGELOG.md on main the same evening, with version dates from the npm registry. Status names and the MCP_TIMEOUT default come from the MCP and environment-variable docs fetched today. The claude mcp list output and all seven probe runs are from this Mac mini on Claude Code 2.1.270, one run per row, and wall times include the model's turn. The 0.24 s and 0.8 s figures are from my July measurements on 2.1.220. The launchd runner that starts these claude -p jobs is part of the Playbook ($12), the one paid link in this post; there are no affiliate links.