Context7 MCP not connecting: error codes and fixes

Triage in two commands

Almost every report resolves to one of three states, and two commands tell you which. Do this before editing config, because most of the fixes circulating online change the wrong thing.

A 405 from the second command is the healthy response. It means the endpoint is reachable and simply refused a bare GET, which is correct for a protocol endpoint. A timeout or a DNS failure there means the problem is upstream or on your network, and no amount of config editing will help.

1. Run claude mcp list. Absent, or listed and dead: they have different causes.
2. Run curl -s -o /dev/null -w '%{http_code}' https://mcp.context7.com/mcp. Expect 405.
3. 405 plus a dead entry means the config is wrong. A timeout means the server or your network is the problem.

context7 is not in claude mcp list

The add did not persist, or the running session predates it. The add command writes config; a session already open does not reread it. Quit the client completely and open it again, then list.

If it is still missing, you may have added it in a scope you are not currently in. --scope user registers it for every project; without that flag it is written for the current directory only, so it disappears when you open a different repo. Re-run with the flag: claude mcp add --scope user --transport http context7 https://mcp.context7.com/mcp

failed to connect, over HTTP, in Claude Code

Check reachability before you touch config. The most-linked instance of this failure was an upstream provider outage, not a user configuration error, and every config change suggested in that thread was noise. The curl above distinguishes the two cases in one second.

If curl returns 405 and the client still cannot connect, the usual causes are local: a proxy or VPN intercepting TLS, a corporate root certificate, or a stray character pasted into the URL. Angle brackets copied from documentation are a common one.

• Confirm the endpoint answers with 405 before changing anything.
• If curl fails too, it is not your config. Wait, and check the provider status.
• Re-copy the URL by hand: https://mcp.context7.com/mcp. No angle brackets, no trailing punctuation.

MCP error -32000

MCP error -32000: Connection closed is the form of this people usually paste into a search box. The number on its own is not diagnostic, which is why the threads carrying it disagree about the fix. Read the message beside it.

Connection closed generally means a transport mismatch: the client is speaking one protocol and the server another. On this endpoint that usually means a config left over from the SSE era. The remote server is Streamable HTTP at https://mcp.context7.com/mcp, added with --transport http.

Method not allowed is a different thing entirely and is what a healthy server returns to a plain GET. Seeing it from curl is good news, not a fault.

MCP error -32001

MCP error -32001: Request timed out is the common form, but two unrelated conditions report this code, so again the message matters.

Request timed out has most often been traced to running an unofficial container image rather than the official remote endpoint. If you are pointing at a third-party Docker build, point at the endpoint above instead and see whether the timeout follows you.

Authentication required is not a fault. It is what the authenticated endpoint returns when no credential is present, and it confirms the endpoint is alive. It only needs action if you meant to be authenticated, in which case the key is missing or malformed.

SSE returns 404

Expected. The SSE endpoint is gone. A request to /sse now answers 404 with a body telling you to use /mcp, and that is the current, correct behaviour rather than an outage.

Advice recommending an SSE transport for this server is stale, including advice that was accurate when it was written. There is one supported remote transport now, Streamable HTTP, and one URL: https://mcp.context7.com/mcp

spawn context7-mcp ENOENT

This is a local stdio install that cannot find its binary. Nothing is wrong with the remote server, because this configuration never reaches it: the client is trying to launch a process on your machine and failing.

Either install the local package properly, or drop the local path and use the remote endpoint, which needs no binary and no Node process at all. The remote add is claude mcp add --scope user --transport http context7 https://mcp.context7.com/mcp

Tool names must be unique

Stated plainly: the root cause of the reported instances of this was never established upstream, and anyone claiming a definitive fix is guessing. What follows is what is worth ruling out, in order of likelihood, not a confirmed remedy.

The error is about a collision in the assembled tool list, so two servers exposing the same tool names is the first thing to check. That happens easily if you added context7 twice under different names, or kept a local npx entry alongside the remote one. One registration is enough.

• Run claude mcp list and look for two entries backed by the same server.
• Remove any leftover local npx entry if you have since moved to the remote endpoint.
• Check both user and project scope: a duplicate can hide in the scope you are not looking at.

If none of this applies

Collect the two commands from the top of this page and the exact message, including the code and the text beside it. The code alone is not enough to identify the fault, as the sections above show. The install pages are /install for Claude Code and /cursor, /vscode, /claude, /windsurf for the others.