Claude Desktop and Claude Code keep separate MCP registries; same-named tools may hit different backends

Separate MCP registries in Claude Desktop and Claude Code

Observed July 2026 on Windows 11.

Two independent config files

• Claude Desktop app: %APPDATA%\Claude\claude_desktop_config.json, with a top-level "mcpServers" key. Desktop must be fully restarted, not just the conversation, to pick up changes.
• Claude Code CLI: ~/.claude.json, a large file in which mcpServers entries are nested per project path. A server can be registered here independently of the Desktop config, with different values, even under a similarly named key.

If the same logical server (same OAuth app) is registered in both places, diff the two before assuming a fresh entry is correct. The copy set up earlier and separately is more likely to hold correctly typed values.

Tool names do not prove which backend a call reaches

While debugging OAuth for an MCP server deployed to three environments (dev, test, prod), a connection that had just authenticated in Claude Desktop was expected to give a separate Claude Code session write access to the test environment. It did not, and the tool names gave no hint: mcp__<server>__get_record and mcp__<server>__update_record looked identical regardless of the underlying instance.

The mcp__<server>__<tool> prefix reflects the config key in the current session's own registry. It is not a server-declared identity, and it is not another application's registry. A deferred-tool search for the test connection returned only the generic tool set, because that connection lived solely in Desktop's config file, which the Code session never reads.

Resolution: call a read tool on a record known in advance to belong to one environment only (a record created during dev app registration, whose name and URL pointed at the dev subdomain). It came back, proving the session was still hitting dev.

Before writing through an MCP tool whose target has several environments, read a record unique to one environment first. Routing should not be inferred from a tool name, from what another application reported, or from a tool-search result.

Do not transcribe secrets from screenshots

Characters I, l, 1 and ! are frequently indistinguishable in UI screenshot fonts. A client secret transcribed as Yhl26YbZmul7... where the real value was YhI26YbZmu!7... caused an OAuth token exchange to fail with 401 for several restart-and-retry cycles. The authorization step, which does not need the secret, succeeded and looked fine, producing a misleading "it works, then it does not" pattern.

Ask for the value as text, or cross-check against another existing copy of the same credential, before trusting an OCR read for anything security-sensitive.