MCP was originally developed by Anthropic, so Claude's support for it is the most direct — but "Claude" actually means three different products with three different connection mechanisms (Claude Desktop, Claude Code, and the API), and mixing up which one you're configuring is a common source of "why isn't my server showing up" confusion.
Claude supports MCP across multiple surfaces: Claude Desktop connects to local MCP servers via a configuration file, Claude Code connects both locally and to remote servers through its own configuration, and the Claude API supports MCP through the Messages API's tool-use mechanism (with an MCP connector for remote servers). Each has a distinct setup path worth understanding separately.
Why MCP With Claude Matters (and When a Simpler Integration Suffices)
Connecting an MCP server to Claude gives you access to a capable model with strong tool-use reasoning across whichever surface fits your workflow — Claude Desktop for personal/exploratory use with local tools, Claude Code for development workflows needing filesystem and git access, and the API for building your own application on top of Claude's MCP support.
A simpler integration (direct API tool-use definitions, without MCP) may suffice if you're building a single application with a fixed, small set of tools you fully control — MCP's standardization benefit shows up most clearly when you want tools to be reusable across multiple different clients, not just your own single application.
Getting Started with MCP and Claude
Claude Desktop configuration, connecting a local MCP server via claude_desktop_config.json:
{
"mcpServers": {
"my-server": {
"command": "node",
"args": ["/path/to/my-server/index.js"]
}
}
}
Claude Code, connecting an MCP server via the CLI:
claude mcp add my-server -- node /path/to/my-server/index.js
Using the MCP connector with the Claude API, for remote servers:
response = client.beta.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
messages=[{"role": "user", "content": "What's the status of project X?"}],
mcp_servers=[{
"type": "url",
"url": "https://my-mcp-server.example.com/mcp",
"name": "project-tools",
}],
)
Core MCP With Claude Concepts Every Developer Should Know
Claude Desktop connects to local (stdio-based) MCP servers by default, launching them as a subprocess and communicating over standard input/output — this is well-suited to servers running on your own machine with access to local files or tools, but requires the server binary/script to be present locally, not just a URL.
Claude Code's MCP support is oriented around development workflows, commonly connecting to servers exposing filesystem access, version control, and project-specific tooling — its configuration can be scoped per-project or globally, letting different projects have different connected servers based on their actual needs.
The Claude API's MCP connector supports remote, URL-based servers directly in the Messages API, without requiring you to manage the tool-calling loop yourself for MCP-specific tools — this differs from Claude Desktop/Code, which are end-user applications; the API's MCP support is for building your own application that uses Claude with MCP-exposed tools.
Tool descriptions and schemas matter more with Claude than a simple "make it work" implementation might suggest, since Claude's tool-selection reasoning quality is directly influenced by how clearly a tool's purpose and parameters are described — this is a general MCP principle but worth emphasizing specifically because Claude's strong reasoning can still be undermined by poorly-described tools.
Common Mistakes Connecting MCP to Claude and How to Fix Them
Mistake 1: confusing which Claude surface you're configuring — editing Claude Code's config when you meant to configure Claude Desktop, or vice versa. Fix: confirm which specific product (Desktop, Code, API) you're setting up, since each has its own configuration location and mechanism.
Mistake 2: expecting Claude Desktop to connect directly to a URL-based remote server without additional setup, when its default connection model is local, stdio-based subprocess launching. Fix: check current documentation for remote server support specifics for the surface you're using, since capabilities and configuration options evolve.
Mistake 3: underinvesting in tool description quality, assuming Claude's general capability compensates for a poorly documented tool. Fix: write clear, specific tool descriptions and precise parameter schemas regardless of which client you're targeting.
When Should You Use the API's MCP Connector Instead of Claude Desktop or Code?
Use the API's MCP connector when you're building your own application or service that needs Claude to use MCP-exposed tools programmatically, without a human directly interacting with Claude Desktop or Code. Use Claude Desktop or Claude Code when you (or your team) are the direct user, interacting with Claude conversationally and wanting it to have tool access during that interactive session.
MCP With Claude in Production
Confirm which Claude surface (Desktop, Code, API) actually matches your use case before configuring, since the setup and capabilities genuinely differ between them despite all being "Claude with MCP." Also invest in tool description and schema quality regardless of surface, since this is what most directly determines reliable tool usage.
If you're setting up MCP with Claude for the first time, start with Claude Code if your use case is development-workflow-oriented (filesystem, git, project tools) — it's the most directly aligned surface for that kind of work.