ASK KNOX
beta
Learn/MCP for Beginners: Giving Your AI Hands/Lesson 342
LESSON 342

MCP Across Claude Code, Desktop, and IDEs

The same MCP server works everywhere — Claude Code, Claude Desktop, Cursor, VS Code extensions — the only thing that changes is where you put the config file.

6 min read·MCP for Beginners: Giving Your AI Hands

Introduction

One of MCP's most practical properties is one that gets undersold in beginner tutorials: write the server once, use it everywhere. The same server binary or script works in Claude Desktop, Claude Code, Cursor, and any other MCP-compatible client.

This is the payoff of a universal protocol. Your investment in building or configuring a server is not locked to one tool.

Core Concept

The Server Is Client-Agnostic

An MCP server does not know or care which client is talking to it. It speaks the protocol. The client speaks the protocol. They connect and exchange messages. The server's code is identical regardless of whether a request comes from Claude Code or from Cursor.

This is exactly like a web API. Your REST server doesn't know whether the request came from a browser, a mobile app, or Postman. The HTTP protocol is the abstraction layer.

MCP's protocol is the abstraction layer between server and client.

Config Locations Per Client

Each client has its own place to store the server list. Here is where to find it for common clients:

Claude Code (CLI)

Global config — applies to all sessions everywhere:

~/.claude.json

Project config — applies only when Claude Code is run inside this directory (and can be checked into version control so the whole team shares it):

<project-root>/.mcp.json

Claude Desktop (Mac)

The app config lives in:

~/Library/Application Support/Claude/claude_desktop_config.json

Cursor (IDE)

Cursor stores MCP config in its settings UI (Settings → MCP) which writes to:

~/.cursor/mcp.json

VS Code with the Copilot/Claude extension

Check the extension's documentation for its config path — it varies by extension version, but it is typically in .vscode/settings.json or the extension's own config directory.

The Config Structure Is Consistent

Even though the file locations differ, the JSON structure inside them is nearly identical across clients. The mcpServers block you learned in the “Connecting Your First MCP Server” lesson is recognized by Claude Desktop, Cursor, and Claude Code.

Here is the same server configured for both Claude Code and Claude Desktop:

Claude Code (~/.claude.json):

{
  "mcpServers": {
    "word-counter": {
      "command": "python",
      "args": ["/Users/yourname/mcp-servers/word_count_server.py"]
    }
  }
}

Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "word-counter": {
      "command": "python",
      "args": ["/Users/yourname/mcp-servers/word_count_server.py"]
    }
  }
}

The content is identical. Only the file path where you save it differs. The server script itself is unchanged.

Practical Application

Choosing the Right Scope

(Claude Code: ~/.claude.json, Desktop: app config) makes the server available in every session. Use this for servers you always want: your memory server, your web search server, your core toolset.

(.mcp.json at the project root) makes the server available only in that project's sessions. Use this for project-specific servers: a database server scoped to this project's DB, a filesystem server scoped to this project's directory.

A clean setup for a software project looks like this:

// ~/.claude.json — global, always available
{
  "mcpServers": {
    "memory": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-memory"] },
    "web-search": { "command": "npx", "args": ["-y", "grok-search-mcp"],
      "env": { "GROK_API_KEY": "your-key" }
    }
  }
}

// my-project/.mcp.json — project-scoped
{
  "mcpServers": {
    "project-files": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem",
               "/Users/yourname/my-project"]
    }
  }
}

When you run Claude Code inside my-project, you get all three servers: memory, web-search (from global), and project-files (from project config). Outside that folder, you get only memory and web-search.

When to Use HTTP (Streamable HTTP) Instead of stdio

stdio servers run as child processes — they start when the client starts and stop when the client stops. This works perfectly for single-client use.

Remote HTTP servers run at a URL and stay running. (Older docs call this transport SSE — Server-Sent Events. The original HTTP+SSE transport was deprecated in favor of Streamable HTTP, but the old name still shows up in tutorials and configs.) Use HTTP when:

  • You want multiple clients (Desktop + Code + Cursor) to share one persistent server instance — useful for a memory server where all clients should read/write the same knowledge base
  • The server has expensive startup time (loading a model, connecting to a database) and you do not want to restart it every session
  • The server maintains state that should persist across client restarts

A remote HTTP server config looks slightly different — instead of command/args, you provide a url:

{
  "mcpServers": {
    "shared-memory": {
      "url": "http://localhost:8080/mcp"
    }
  }
}

All your clients point at the same URL. The server runs independently and serves all of them.

The semantic memory layer server is a real example of this pattern: it runs persistently on a dedicated host, and both Claude Code sessions and OpenClaw's Agent Gateway can connect to it simultaneously. One server instance, multiple consumers.

Common Mistakes

Using absolute paths that only exist on one machine. If you configure a server with /Users/yourname/scripts/server.py and try to use the same config on another machine, the path will not exist. Use environment variables or relative paths when config needs to be portable.

Not realizing project config and global config are merged. Servers do not replace each other — they are combined. If you define a server named "memory" in both your global config and your project config, the project-level entry wins for that name. But other global servers remain available.

Expecting automatic sync between clients. Adding a server to Claude Code does not add it to Claude Desktop. Each client has its own config. If you want a server available in both, add it to both.

Summary

  • MCP servers are client-agnostic — the same server works in Claude Code, Claude Desktop, Cursor, and any compatible IDE
  • The config JSON structure (mcpServers block) is consistent across clients; only the file location differs
  • Global config makes servers available in all sessions; project config scopes servers to a specific directory
  • stdio servers (child process) are right for single-client use; remote HTTP — Streamable HTTP — servers (persistent URL) are right for multi-client or state-preserving use cases
  • A production setup typically uses Streamable HTTP for the semantic memory layer (shared across Claude Code and Agent Gateway) and stdio for per-session tools like grok-search

What's Next

The final lesson pulls back to give you the discipline you need now that you can use MCP fluently: knowing when not to reach for it. Not every task belongs in an MCP server — and the ability to tell the difference is what separates a thoughtful practitioner from someone who over-engineers everything.