MCP Server Not Showing Up in Claude Desktop: Fixes (2026)

When an MCP server is not showing up in Claude Desktop, work in this order: check the Connectors menu and Developer settings, validate the config JSON, fully quit and reopen the app, read mcp.log, then confirm you edited the file the app actually reads.¹²

TL;DR

Claude Desktop starts the servers listed under mcpServers in claude_desktop_config.json when you launch it.¹ The chain from "I edited a file" to "a tool appears in a conversation" has several links, and the ones that cost the most time are the ones that fail quietly: a config file the app never read, which on one reported Windows configuration produces no error, no logs and no indication in Developer settings³; an app that was closed rather than quit, and a managed-device policy that is set outside the app entirely.⁴ That quietness is what makes guessing expensive and reading a log file cheap.

The sections below tackle an MCP server not showing up in Claude Desktop in an order that puts the checks costing you nothing — looking in a menu, running one command — before the ones that require you to change something. That ordering is about cost, not likelihood; your particular cause may well be near the bottom, but you will reach it faster having ruled the free ones out first.

One scoping note. Claude Desktop can gain tools through more than one mechanism, and they fail differently. If you are not certain which you set up, start with "Which mechanism did you actually use?".

What you'll learn

• Which MCP mechanism you actually configured, and why that changes every step that follows
• How to check whether the server is already connected before you change anything
• How to validate the config file's JSON, and what Claude Desktop does when it will not parse
• Why closing the Claude Desktop window is not a restart
• How to read mcp.log and mcp-server-NAME.log, and what each one rules in or out
• Where claude_desktop_config.json lives — and the reported Windows case where "Edit Config" opens a file the app does not read
• Why a server that runs fine in your terminal can fail under Claude Desktop, and how to fix the environment
• How a stray line of logging can start your server and still break the protocol
• How to prove the server itself works, using MCP Inspector
• What to do when a desktop extension installs but its tools never appear
• The managed-device policy key that disables local MCP servers outright, and how to read its current value yourself
• Why a connector can work on claude.ai and not in Claude Desktop, and the reverse
• Which plan and organisation limits are documented, and which mechanism each one applies to

Which mechanism did you actually use?

Several different things put tools in Claude Desktop, and the troubleshooting for each is different. Identify yours first.

That last row catches people out. Anthropic's guidance is explicit that "a plugin can bundle either remote or local MCP servers (or both)," and that a plugin referencing a remote MCP "makes it available everywhere," while one referencing a local MCP "works in Desktop and Claude Code."⁶ So if you installed a plugin and are debugging where its tools went, first work out which kind of server it brought with it — then follow that mechanism's section below.

The distinction matters because the availability rules are not symmetric. Desktop extensions and local config servers are machine-local and do not appear on the web client; remote connectors are reached from Anthropic's infrastructure and appear everywhere.⁶⁵

How do I check whether an MCP server connected in Claude Desktop?

Do this before you change anything, because it costs nothing and it can end the search on the spot.

There are two places to look, and Anthropic's help centre names both: "Click the '+' button on bottom the chat box within Claude Desktop, then select 'Connectors.' … Alternatively, you can visit Developer settings (under Desktop app) to see connection status and look at the logs for any MCP servers."⁷ MCP's own pages describe the same first route in more detail — click the "Add files, connectors, and more" indicator at the bottom-left of the conversation input, hover Connectors, then Manage connectors, and select your server to see the tools it exposes.¹²

Two things worth knowing before you go looking:

• The menu is called Connectors regardless of mechanism. Anthropic's own instructions send you to it to check local MCP servers,⁷ so the name tells you nothing about which mechanism you configured — do not conclude your local server is in the wrong place because the menu says "Connectors."
• Check Developer settings too, not just the menu. Anthropic describes the Connectors route as showing "connected MCP servers and their tools", and Developer settings as showing connection status and logs.⁷ The second is the one to trust when something is wrong, because a status field is more specific than a list. If your server is listed but unusable, jump to per-tool disabling.

A note on the icon, because it sends a lot of people down the wrong path. Many third-party guides tell you to look for a hammer icon at the bottom-right of the input box. MCP's documentation still uses that phrasing as a symptom label — one troubleshooting accordion is titled "Server not showing up in Claude / hammer icon missing" — but every actual instruction on both current MCP pages points at the plus icon and the Connectors menu instead.¹² If you are hunting for a hammer and not finding one, that on its own tells you nothing about whether your server connected.

Does my config file actually parse?

This is the second free check, and it is an easy one to skip because the file looks fine. Claude Desktop's config is a single JSON document; if it is not valid JSON, there is nothing for the app to read, and the quickstart's own troubleshooting list puts "Check your claude_desktop_config.json file syntax" second only to restarting.¹

Validate it with a parser rather than by eye. These forms print OK or an error position and deliberately do not echo the file, because your config may contain API keys in an env block and this output tends to end up pasted into forum threads:

# macOS
python3 -c 'import json,sys; json.load(open(sys.argv[1])); print("OK")' \
  ~/Library/Application\ Support/Claude/claude_desktop_config.json

# Windows PowerShell
$null = Get-Content "$env:APPDATA\Claude\claude_desktop_config.json" -Raw | ConvertFrom-Json; "OK"

On a clean macOS install python3 may not be present — it is a stub that offers to install the command line developer tools. If you would rather not, any parser will do; the point is that a machine reads the file, not you.

Not from the docs, but from experience, the usual offenders are: a trailing comma after the last entry; a // comment, which JSON has no syntax for; a missing closing brace; curly quotation marks pasted in from a word processor or a web page; a UTF-8 byte-order mark, which Notepad and PowerShell 5.1 both like to add and which some parsers reject while ConvertFrom-Json quietly accepts; and — on Windows — single backslashes in a path. In JSON, \ starts an escape sequence, so a backslash-separated Windows path has to double each one: C:\\Users\\username\\Desktop. Forward slashes are also valid JSON and work on Windows, so C:/Users/username/Desktop sidesteps the problem entirely.

One trap a parser will not catch: two mcpServers keys in the same document is valid JSON, and every parser I tested silently keeps only the last one. If you merged a snippet in rather than editing the existing key, half your servers disappear with no error anywhere. grep -c '"mcpServers"' <file> should print 1.

A clean parse here proves the file you tested is valid; on Windows it does not yet prove it is the file the app reads — see the Windows two-file case below. And this check has a Windows-specific cousin worth doing at the same time: text editors that append .txt on save. If your file browser is hiding known extensions, claude_desktop_config.json.txt looks identical to the file you meant to create, and produces exactly the same symptom as having no config at all.

There is a log line worth recognising while you are here. Issue #38830 quotes a Claude Desktop main.log entry reading [error] Error reading or parsing config file: followed by a SyntaxError and a character position.⁸ It tells you the app tried to read a config and could not. It does not tell you which file, and it is not proof your syntax is wrong: that reporter's files parsed cleanly under ConvertFrom-Json, and they described the source of the error as unidentified.⁸ So treat the string as a prompt to check both your syntax and the Windows two-file case, not as a verdict on either.

Do I have to fully quit Claude Desktop for the config to take effect?

Yes, and closing the window does not count. The quickstart's instruction after saving the config is to "completely quit Claude Desktop and restart it," because "the application needs to restart to load the new configuration and start the MCP server."¹ MCP's debugging guide says the same for server code changes, in terms worth quoting because they name the exact mistake: "Restart the client (for Claude Desktop, fully quit and reopen; closing the window is not enough)."²

On macOS this is the difference between the red close button and quitting the application outright — the first leaves the process running, so nothing is re-read and your edit appears to have done nothing.

Issue #26073's reproduction steps mention a Developer → Reload MCP Configuration menu item as an alternative.³ Treat it as a faster loop once things work, not as your first test: a full quit is the behaviour the documentation describes, and you want your first negative result to be trustworthy.

How do I read Claude Desktop's MCP logs?

Claude Desktop writes MCP logs to ~/Library/Logs/Claude on macOS and %APPDATA%\Claude\logs on Windows.¹ Two kinds of file live there and they answer different questions:

• mcp.log — "general logging about MCP connections and connection failures."¹ This is where you see whether Claude Desktop attempted your server at all.
• mcp-server-NAME.log — written mcp-server-SERVERNAME.log in the docs, where the placeholder is the key you gave the server in your config. It holds that one server's stderr. The docs warn that "stdio servers may use stderr for all their logging, so these files are not limited to errors," so a busy file is not automatically a bad sign.¹

Do this as a sequence rather than a live tail, because on a first-time failure mcp-server-NAME.log does not exist yet — it gets created by the restart, and a shell glob expands once, before that happens:

# macOS: quit Claude Desktop fully, reopen it, wait a few seconds, then
ls -la ~/Library/Logs/Claude/
tail -n 100 ~/Library/Logs/Claude/mcp*.log

On Windows, MCP's debugging page gives this form, which expands the environment variable correctly under PowerShell:²

type "$env:AppData\Claude\logs\mcp*.log"

That concatenates every matching file with no filename headers and no tail limit, which is awkward when the whole point is telling mcp.log apart from mcp-server-NAME.log. This does the same job as the macOS pair above — list first, then read each file labelled:

Get-ChildItem "$env:APPDATA\Claude\logs"
Get-ChildItem "$env:APPDATA\Claude\logs" -Filter mcp*.log | ForEach-Object {
  "`n==> $($_.Name) <=="; Get-Content $_.FullName -Tail 100
}

Read a blank result carefully on either platform: a glob that matches nothing prints nothing, which looks identical to files that exist and are empty. The listing step is what tells those apart.

The logs capture connection events, configuration issues, runtime errors, and message exchanges.² What you are reading for is which layer failed:

If you are on Windows and the log folder itself does not exist at the documented path, that matches what issue #26073 reports for the packaging problem in the next section — though a Claude Desktop that has never started an MCP server is another explanation, so treat it as a pointer rather than a diagnosis.³

Where is claude_desktop_config.json, and am I editing the one the app reads?

The documented locations are ~/Library/Application Support/Claude/claude_desktop_config.json on macOS and %APPDATA%\Claude\claude_desktop_config.json on Windows.¹ The in-app route on macOS starts from the Claude menu in your system menu bar — not the settings inside the Claude window — then Settings…, then the Developer tab, then Edit Config, which opens the file and creates it first if it does not exist.¹

The config schema MCP documents for this file is narrow: an mcpServers object, one key per server, each holding a command plus optional args and env.¹² Neither MCP page cited here shows a type key in a Claude Desktop example. That is an observation about the documentation, not a rule — if you copied a "type": "stdio" line from a guide it may still be harmless, but it is not something these docs ask for, so do not assume its presence or absence is what fixed or broke things.

The quickstart tells you to "replace the contents of the configuration file" with a complete document.¹ That is fine on a fresh install, but if your file already holds other servers or a preferences block, you want to merge instead. Here is the mcpServers key on its own, to nest inside the braces you already have:

"mcpServers": {
  "filesystem": {
    "command": "npx",
    "args": [
      "-y",
      "@modelcontextprotocol/server-filesystem",
      "C:\\Users\\YOUR-USERNAME\\Desktop"
    ]
  }
}

And here is the same thing as a complete file, for the empty-config case — note the outer braces, without which nothing above parses:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "C:\\Users\\YOUR-USERNAME\\Desktop"
      ]
    }
  }
}

The Windows two-file case

On Windows there is a publicly reported exception to everything above, and it is worth ten seconds to rule out. First, check whether it can apply to you at all:

Get-AppxPackage *Claude* | Select-Object Name, PackageFamilyName
Test-Path "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc"

If Get-AppxPackage returns nothing at all, you are not on an MSIX build and the rest of this section does not apply. Do not lean on the Test-Path line alone: issue #26073 notes that "a second package also exists at Anthropic.ClaudeDesktop_h6f0761 which may be related to the confusion," so a False against one package name does not by itself rule the case out.³

If either command shows an MSIX package, you may have the build described in issue #26073, filed in February 2026. The reporter states that "Edit Config" opens C:\Users\<username>\AppData\Roaming\Claude\claude_desktop_config.json while the app reads C:\Users\<username>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json — two separate files that are never synchronised.³ The attributed mechanism is MSIX filesystem virtualisation: the app's own reads of %APPDATA% are redirected into the package's LocalCache, while the shell call that opens your editor resolves the real, non-virtualised path.³

The failure mode is what makes it hard to spot. Per that report: no error in the app, no logs folder at the documented %APPDATA%\Claude\logs\ location, and nothing in Developer settings indicating the config was not loaded.³

Two caveats before you act on it. First, this is a user-filed bug report in Anthropic's public claude-code tracker rather than vendor documentation. It carries both a bug and an invalid label, but note what that second one means on this repository — its description reads "Issue doesn't seem to be related to Claude Code," which is a routing judgement about the tracker (this is Claude Desktop, a different product), not a finding that the report is wrong.³ Second — and this is why it is a hypothesis rather than a diagnosis — it does not explain every case. A later report, #38830, describes an MSIX install on version 1.1.8629.0 where the reporter placed mcpServers in both files, states that "Both files have been kept in sync and both contain valid JSON with mcpServers," and still saw "No servers added" in Settings → Developer with no mcp-server-*.log files created at all. That report's own log excerpt shows a JSON SyntaxError against files that "validate successfully with ConvertFrom-Json in PowerShell — the source of this parse error is unidentified."⁸ So syncing the two files is worth doing, but do not assume it is sufficient.

If a second config file does exist, merge your mcpServers key into it rather than replacing it — the report notes the virtualised file already carries a preferences block.³ Then stop using Edit Config on that machine and open the LocalCache path directly from then on, or your next edit lands back in the file the app ignores.

Why does my MCP server work in the terminal but not in Claude Desktop?

Because the two are not the same environment. MCP's debugging guide states that servers launched over stdio — the local kind, which talk to Claude Desktop over standard input and output — "inherit only a limited subset of environment variables automatically (the exact set is platform-dependent)."² Your shell has a PATH assembled by your login profile, your version manager, and your package manager. The process Claude Desktop spawns does not necessarily have any of that, so a bare npx, uvx, python, or docker in command can resolve in your terminal and fail under the app.²

Two documented fixes, and one detail that decides whether the first actually works.

1. Use absolute paths. The guide's advice under path issues is "Try using an absolute path for command", and more broadly, "Always use absolute paths in your configuration and .env files to ensure reliable operation."²
2. Declare what the server needs via env. The env key exists to "override the default variables or provide your own."²

The detail, which is not in the docs but follows from them: if you use a Node version manager, pointing command at the manager's npx may not be enough on its own, because those launcher scripts typically resolve node from PATH at run time — and PATH is the thing that is missing. Point command at the node binary itself, pass your server's script as the first argument, and add the directory containing node to PATH in the env block. Run which node on macOS, or where.exe node on Windows — plain where in PowerShell is an alias for Where-Object and will silently print nothing, which looks exactly like "Node is not installed". If your version manager uses shims (asdf, Volta), which hands you the shim rather than the binary; node -e 'console.log(process.execPath)' always prints the real path. Either way, do not guess at /usr/local/bin.

Again the mcpServers key alone, to merge into your existing braces — replace every YOUR-USERNAME and version number with the real values from your own machine:

"mcpServers": {
  "myserver": {
    "command": "/Users/YOUR-USERNAME/.nvm/versions/node/v22.19.0/bin/node",
    "args": ["/Users/YOUR-USERNAME/servers/myserver/dist/index.js"],
    "env": {
      "PATH": "/Users/YOUR-USERNAME/.nvm/versions/node/v22.19.0/bin:/usr/bin:/bin",
      "MYAPP_API_KEY": "some_key"
    }
  }
}

The working directory is the second trap in this family. The guide notes it "may be undefined (like / on macOS)" because the client could have been started from anywhere.² Any relative path in args is therefore resolved against a directory you did not choose. The same goes for ~, though this one is not in the docs: the tilde is expanded by your shell, and JSON has no such rule, so a literal "~/Desktop" inside the config reaches your server as a directory name that does not exist. Write /Users/you/Desktop. The quickstart says the same thing from the other side — make sure the paths in claude_desktop_config.json "are valid and that they are absolute and not relative."¹

Windows has one more documented variant. If your server's log shows an error referring to ${APPDATA} inside a path, add the expanded value of %APPDATA% to that server's env key. The docs also warn that npx "may continue to fail if you have not installed npm globally" — you can confirm a global install by checking whether %APPDATA%\npm exists, and create one with npm install -g npm.¹

Could my server be starting and then breaking the protocol?

This one produces a server that launches, logs normally, and still exposes nothing — so it is worth knowing about even though it only applies if you wrote the server yourself.

Local MCP servers speak the protocol over stdout. MCP's guide is unambiguous: local servers "should not log messages to stdout (standard out), as this will interfere with protocol operation."² A print() or console.log() anywhere in a startup path is enough to violate that. Send logs to stderr instead, which the host application — Claude Desktop, here — captures automatically for stdio servers.² (The rule flips for the Streamable HTTP transport, where "stderr is not captured by the client" and the docs point you at your own server-side log aggregation or OpenTelemetry, plus ordinary HTTP tooling such as curl or the browser's Network panel. Note while you are there that protocol-level logging via notifications/message is "deprecated as of protocol version 2026-07-28," so do not build new servers around it.²)

There is a related class of failure in capability negotiation, where the two sides do not agree on what each supports. In the 2026-07-28 protocol the docs are specific about where to look: every request must carry io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities in its _meta, a request missing either is rejected with -32602 ("Invalid params", also returned for many other malformed inputs), and a server that needs a capability the client never declared — elicitation, for instance — returns MissingRequiredClientCapabilityError (-32021) naming what is missing. The suggested check is to "inspect the request's _meta and the server/discover response to verify both sides declared what you expect."² Inspector's monitoring sidebar is the easiest place to watch that traffic.⁹ These names and codes are specific to that protocol version, so check them against the version your server targets.

How do I test my MCP server with MCP Inspector?

Use MCP Inspector to establish whether the server is even the problem. The debugging guide lists it first among debugging tools and says plainly: "This should be your first stop."² It ships as one package, @modelcontextprotocol/inspector, with three clients behind a single binary — a web UI, a scriptable CLI, and a terminal UI — all sharing the same core, transports, and configuration.⁹ The docs give its floor as "Node 22.19.0 or newer", so check node -v first; on an older runtime, fall back to running the server's command directly in a terminal, which the quickstart also suggests as a troubleshooting step.⁹¹

# Web UI, pointed at a local stdio server
npx -y @modelcontextprotocol/inspector node /abs/path/to/server/index.js

# List the tools and exit — the fastest possible sanity check
npx -y @modelcontextprotocol/inspector --cli node /abs/path/to/server/index.js --method tools/list

# A published npm server, launched the way your config launches it
npx -y @modelcontextprotocol/inspector npx -y @modelcontextprotocol/server-filesystem /Users/YOUR-USERNAME/Desktop

The third form is the useful one here, because it runs the same command and args your config does — provided you write out the same literal strings. Use the absolute path in both places rather than ~, or the two invocations are not comparable for exactly the reason described in the previous section.

Now read the result as a branch, not a checklist:

• Inspector fails too. The fault is in the server or its dependencies. Stop editing JSON.
• Inspector succeeds, Claude Desktop shows nothing. The server itself is fine, so the difference is something between your config and the process Claude Desktop spawns. In rough order: the environment your shell provides and the spawned process does not — go to absolute paths and PATH and hardcode command, args and PATH; then whether the app read your config at all (logs, the Windows two-file case); then device policy.

For a remote server, the docs' CLI example passes the URL positionally (their web-mode example uses --server-url instead):⁹

npx -y @modelcontextprotocol/inspector --cli https://api.example.com/mcp --transport http --method tools/list

Two syntax rules that cause avoidable confusion:⁹

• Mode flags (--web, --cli, --tui) are recognised only at the front of the command line, so a later --cli is forwarded to your server untouched.
• Passing two of them errors with "Specify at most one of --web, --cli, or --tui."

My desktop extension installed, but its tools never appeared

Extensions are installed through Settings rather than by editing claude_desktop_config.json, and Anthropic's remedy for a misbehaving one is to "restart Claude Desktop to refresh the extension registry" — so the config-file checks above are not where to look. Anthropic's documented remedies for "extension appears installed but tools aren't available" are: restart Claude Desktop to refresh the extension registry; check the extension's configuration settings for missing required fields; and verify that any API keys or authentication credentials were entered correctly.⁷ A separate list for configuration problems adds the navigation — Settings → Extensions, then click the extension to review its settings — and notes that any file paths you supply need to point at directories that exist and that you can access.⁷

Worth knowing while you are in there: extensions do not depend on your Node installation. Claude Desktop "includes a built-in Node.js environment, so Node.js installation isn't required" for extensions, and they support Node.js, Python, and binary MCP servers.⁷ In practice that means an extension can work on a machine where a hand-configured npx server fails for PATH reasons — useful to know when you are deciding which mechanism to bother debugging. Sensitive fields marked "sensitive": true in the manifest are encrypted using the operating system's secure storage, such as Keychain on macOS or Credential Manager on Windows.⁷

If you are installing a .mcpb extension you built or received rather than one from the directory, the path is Settings → Extensions → "Advanced settings" → the Extension Developer section (a different pane from Settings → Developer) → "Install Extension…" → select the file.⁷ And if you built it, it stays current only if you reinstall: directory extensions update automatically by default, while for privately distributed extensions, "users will need to install updated .mcpb files manually."⁷

Can an admin policy disable local MCP servers on my machine?

Yes — and on a work laptop this deserves checking before you spend more time on JSON. Administrators on Team or Enterprise plans can control Claude Desktop through system policies, and the documented policy table includes isLocalDevMcpEnabled, a Boolean that defaults to true and is described as "Enable local MCP servers."⁴ Two sibling keys govern the other mechanism: isDesktopExtensionEnabled ("Enable/disable extensions") and isDesktopExtensionDirectoryEnabled ("Enable extension directory access"), both also defaulting to true.⁴

Delivery differs by platform. On macOS the settings arrive by MDM configuration profile against the preferences domain com.anthropic.claudefordesktop, with Jamf Pro, Kandji, and Intune named as tools.⁴ On Windows they arrive by Group Policy or Intune, written under HKLM:\SOFTWARE\Policies\Claude for machine-wide settings or the HKCU equivalent per user, with machine-level settings taking priority when both are set.⁴ Anthropic also notes that enterprise policy controls at the user-machine level override the in-app extension allowlist.⁴

You can look at the documented locations yourself rather than waiting on IT. On Windows, check both scopes — Anthropic's own example writes to HKLM:\SOFTWARE\Policies\Claude, and the article names HKCU as the per-user equivalent:⁴

foreach ($p in 'HKLM:\SOFTWARE\Policies\Claude','HKCU:\SOFTWARE\Policies\Claude') {
  if (Test-Path $p) {
    "$p ->"
    Get-ItemProperty $p | Select-Object isLocalDevMcpEnabled, isDesktopExtensionEnabled, isDesktopExtensionDirectoryEnabled
  } else { "$p -> key not present (no policy set at this scope)" }
}

Written this way rather than with -ErrorAction SilentlyContinue, because silently swallowing errors makes "no policy set" and "you are not allowed to read this key" look identical.

macOS is less conclusive, because MDM-delivered settings do not live in the per-user preferences that defaults read <domain> returns. Check the managed-preferences location as well as the user domain, and expect to need administrator rights for a full picture:

# device-scoped payload, then user-scoped, then the user's own preferences
defaults read "/Library/Managed Preferences/com.anthropic.claudefordesktop" 2>/dev/null || echo "no device-scoped payload"
defaults read "/Library/Managed Preferences/$USER/com.anthropic.claudefordesktop" 2>/dev/null || echo "no user-scoped payload"
defaults read com.anthropic.claudefordesktop 2>/dev/null || echo "no user preferences"

sudo profiles show -all                  # every installed configuration profile

Both scopes matter: MDM tools deliver payloads at device or user level, and checking only /Library/Managed Preferences/ misses the second. defaults read on a domain that does not exist writes its complaint to stderr and exits non-zero, which is why the fallbacks above are there.

If isLocalDevMcpEnabled comes back as 0 or false, that is your answer, and the fix is not yours to make — it is a request to whoever manages the device to set the key back to true (or 1 on Windows). Read a null result carefully on either platform: an empty response means you did not find a policy in the place you looked, not that no policy exists. On a machine you do not administer, treat this section as a question to ask rather than a check you can close out.

Why does my connector work on claude.ai but not in Claude Desktop?

Start by ruling out the mechanism itself, because for remote connectors this symptom should not occur. Anthropic documents that "Claude connects to your remote MCP server from Anthropic's cloud infrastructure, rather than from your local device," and that this holds "across every Claude client, including claude.ai, Claude Desktop, Cowork, and the mobile apps."⁵ A remote connector that works in the browser is therefore reaching the server the same way in the desktop app.

If you are genuinely seeing the difference, the variable is not the connector — it is per-conversation or per-tool state in that specific chat:

• Per-conversation toggles. The "+" button shows your configured connectors "with toggles allowing you to enable/disable them per conversation."⁵ A connector switched off for this chat is not a broken connector.
• Per-tool disabling. The "Search and tools" menu lets you disable individual tools you do not want Claude to invoke.⁵ A connector can be listed with the specific tool you are looking for turned off.
• Where the tool call is coming from. This one applies to local servers rather than remote connectors, but it belongs in the same family of "connected yet unused": advanced research is "not currently able to invoke tools from local MCP servers."⁵ If your local server appears under Connectors in an ordinary conversation but never gets used during research, that is documented behaviour rather than a fault.

There is a second asymmetry, and it runs the other way. Because remote connectors are reached from Anthropic's infrastructure, a server "hosted on a private corporate network, behind a VPN, or blocked by a firewall won't connect, even if you can reach them from your own machine" — the documented remedy being to allowlist Anthropic's published IP ranges.⁵ And the reverse of the section title is not a fault at all: a local server configured in claude_desktop_config.json runs on your machine, and Anthropic states these "aren't available in Cowork or claude.ai."⁵ Its absence from the web client is the design, not a bug to chase.

Does my plan or my organisation's setup limit this?

For remote custom connectors, availability is documented directly: they are "available on Claude, Cowork, and Claude Desktop for users on Free, Pro, Max, Team, and Enterprise plans," and "Free users are limited to one custom connector."⁵ A separate article puts remote connectors on "web, mobile, Cowork, Desktop, and Claude Code."⁶ So on a free account, expect that documented one-connector limit rather than a fault.

On Team and Enterprise plans there is an extra gate. "Only Owners can add them to Team and Enterprise plans," after which individual members connect to the connector themselves.⁵ If you are a member rather than an Owner and your custom connector never shows up, adding it may simply not be an action available to you — the Owner adds it at the organisation level first, and it then appears in your list for you to connect. Anthropic also notes that connectors cannot be edited in place: to change one, remove it and add it again.⁵

No comparable plan requirement is documented for local claude_desktop_config.json servers in any of the pages cited here. The plan limits above apply to remote custom connectors specifically, so do not infer that a free account is the reason a local server is missing.

Bottom line

The causes behind an MCP server not showing up in Claude Desktop that cost the most time are the quiet ones — a config file the app never read, an app that was never actually quit, and a policy key set outside the application entirely. None of the three announces itself in the interface, so the instinct to go straight to the config is usually acting on no evidence at all.

Invert that instinct. Open the Connectors menu and see whether the server is already there. Run your config through a JSON parser. Quit the app fully, reopen it, and list the log directory — ~/Library/Logs/Claude/ on macOS, %APPDATA%\Claude\logs on Windows — to see whether a per-server log was created. Those three observations cost nothing, and between them they tell you which of the sections above you actually need. If no launch was attempted at all, the problem is upstream of your server, and no amount of editing command and args will surface it.

When you do change something, change one thing, quit fully, and re-read the log. And if you are building the server rather than installing one, prove it in MCP Inspector first — a server whose tools/list works outside Claude Desktop turns an open-ended search into an environment problem with a short list of causes.

Next steps: if you are writing your own server, our production MCP server tutorial in TypeScript covers OAuth and Streamable HTTP end to end, and the MCP client tutorial for stdio tools shows the other half of the connection you are debugging here. If your server connects but Claude ignores its tools, that is a different problem with its own research — see how many tools an AI agent can handle before adding more.