What the command does
`claude mcp list` prints every MCP server registered with Claude Code along with its connection state. It answers the question people usually have at that moment: I edited a config, did it take effect?
It is worth understanding that registration and connection are separate things. A server can be correctly registered — it appears in the list — and still fail to connect, because connecting means actually launching the process and completing the MCP handshake. The list command is the fastest way to see which of those two stages you are stuck at.
Reading the output
Each entry shows the server name you registered it under, the command used to start it, and a status. A connected server has completed the initialize handshake and its tools are available to the model. A failed server was launched but did not respond as expected — the process may have exited immediately, or crashed while starting.
If a server you just added is missing from the list entirely, the config was not read. That points at editing the wrong file or the wrong scope, not at the server itself.
The related commands you will need
`claude mcp add <name> -- <command>` registers a server. The double dash matters: everything after it is the command Claude Code will run, so flags belonging to the server are not mistaken for flags belonging to Claude.
`claude mcp remove <name>` unregisters one. Useful when a half-configured server is failing on every start and cluttering the output.
`claude mcp get <name>` shows the full configuration for a single server, which is the quickest way to confirm that arguments and environment variables were stored the way you intended rather than mangled by shell quoting.
When a server shows as failed
Run the server's command directly in a terminal first. If it fails there, the problem is the server or its package and has nothing to do with Claude Code — you have just saved yourself from debugging the wrong layer.
If it runs fine in the terminal but fails under Claude Code, suspect the environment. Servers that need an API key fail at startup when the key was not passed through, and a PATH that works in your shell may not be available to a GUI-launched client. The same class of problem produces the spawn npx ENOENT error in Cursor, and the diagnosis is the same.
A server that starts but exposes no tools is usually waiting on credentials rather than broken. Our detail pages record the tools each server exposed when we installed it in a clean sandbox with no credentials — comparing that list against what you see is a quick way to tell "this server needs configuration" from "this server is misbehaving".