Home · Guides

Where the MCP logs are

Verified against each vendor's own documentation on 2026-09-08.

The two Claude Desktop files do different jobs

mcp.log holds general logging about MCP connections and connection failures. That is where a launch failure appears, and where spawn npx ENOENT shows up.

mcp-server-<name>.log holds the stderr output of that one server. The documentation makes a point of saying these files are not limited to errors, because a stdio server may legitimately use stderr for all of its logging. A large file here is not a symptom.

tail -f ~/Library/Logs/Claude/mcp.log
tail -f ~/Library/Logs/Claude/mcp-server-invoice.log

Why stderr and not stdout

Because stdout is the wire. The stdio binding says the server MUST NOT write anything to stdout that is not a valid MCP message, and that the client MAY capture, forward or ignore stderr and SHOULD NOT assume stderr output indicates an error. So a server logs to stderr because stdout is already carrying JSON-RPC, and a client keeps stderr because it is the only place a crashing server can say anything.

This is the single most useful thing to know when a connection dies during startup. A JSON parse error in mcp.log usually means the server printed something friendly.

When there is no log to read

Reproduce the launch yourself, with the exact command and arguments from the config:

node /Users/you/mcp-servers/servers/invoice/dist/index.js
# then paste one line and press enter:
{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}

A server that answers here and not in the client has an environment or path problem, not a code problem. A server that does not answer here was never going to work.

Output size limits, which look like truncation bugs

Claude Code warns when any MCP tool output exceeds 10,000 tokens and refuses past a default maximum of 25,000, adjustable with MAX_MCP_OUTPUT_TOKENS. A tool returning a large CSV or a whole PDF's text will meet that before it meets any limit of yours. It is documented behaviour, not a failure, and it does not appear in a log file.

The MCP Inspector

The specification site lists an Inspector under its developer tools, alongside a debugging guide. It speaks to a server directly, so it separates "the server is wrong" from "the client's config is wrong" without involving a client at all. That is the same separation the manual launch above achieves, with a UI instead of a pasted JSON line.

These paths were collected while shipping 30 MCP servers to six clients, where the per-server stderr file is what turns a silent absence into a one-line answer. The per-client install pages are under setup.

Questions

Is there a Linux log path for Claude Desktop?

None is published, because no Linux path is published for the application at all. Its documentation lists macOS and Windows.

My server's log file is huge. Is that a problem?

Not by itself. mcp-server-<name>.log is that server's stderr, and the documentation says stdio servers may use stderr for all logging, so the file grows in normal operation. Read the last lines rather than the size.

Where does Claude Code keep MCP logs on disk?

The documentation points at commands rather than files: claude mcp get <name> for a per-server health check and /mcp inside a session for connection state. Treat those as the supported surface.

Nothing is in any log and the server is absent. What then?

That is usually a config that was never read: the wrong top-level key, the wrong scope, or an unparseable file. There is no log entry for a server the client never knew about. The ordered list is at /guides/why-an-mcp-server-does-not-appear.

Related

All MCP servers and prices · All guides · Buy the bundle $39