Best MCP Servers for Claude Code in 2026

Claude Code is a different problem from the editors. It already has a shell, so a good number of the things people install MCP servers for, it can simply do. Before adding a server, it is worth asking whether a command would be shorter, faster and less permanent.

That said, there are jobs where MCP is clearly the right answer in Claude Code, and one of them is the reason most people come looking.

Registering a server, with no JSON to edit

Claude Code has its own registration, so you do not hand-edit a config file the way you do in Cursor or Windsurf. For Swytchcode:

npm install -g swytchcode
swy login
swy mcp serve --claude

That registers the server with Claude Code directly. If you want to switch tool profiles later, remove and re-register:

claude mcp remove swytchcode
swy mcp serve --claude --profile full

Check it is alive with swy mcp status. The command reference is in the MCP docs, and the cross-editor walkthrough is in the MCP server setup guide.

When a shell command beats a server

This is the part specific to Claude Code, and it saves real time.

Claude Code can run git log, rg, cat, jq, psql, curl and whatever else is on your machine. So a filesystem MCP server adds little, a git MCP server adds little, and a "run a query" server adds little. The shell is already there, it needs no configuration, it works in CI, and it leaves a readable trace in the transcript.

An MCP server earns its place when one of these is true:

The capability is not a command. A browser, a hosted service with no CLI, an internal system reachable only over HTTP.

You want the model to discover the surface rather than be told it. This is the strong case. A well-built MCP server gives Claude Code a typed, searchable set of operations with real parameter schemas. That is categorically better than the model recalling an API from memory, which is the root of why Claude Code guesses API endpoints.

You need a gate the agent cannot talk its way past. A shell command runs with whatever credentials are in the environment. A server can enforce an allow list, a policy and an audit trail that the model does not control.

If none of those apply, write the command. We argued the general case in designing a CLI for AI agents, not humans, and the comparison of all three doors is in CLI, MCP and SDK.

What is worth adding

The context cost nobody mentions

Every registered MCP server loads its tool definitions into context on every turn, before Claude Code has done anything. Ten servers at twenty tools each is two hundred definitions sitting in front of every request you make.

That is a standing token cost, and it also makes the agent worse. The more similarly-named tools in view, the more often the wrong one gets picked, which is the mechanism in Claude tool use picks the wrong tool.

So the instinct to collect servers is the wrong one. Prefer a small number of servers that each expose few tools.

Swytchcode's default agent profile exposes 7 tools: discover, info, exec, list, search, add, and a read-only policy. Those seven reach all 363 integrations in the catalog. Adding your tenth provider does not add a tenth block of tool definitions. The full profile adds eight more for setup work, and the docs recommend running agent once you are past configuration.

The job MCP actually wins at

Here is the specific thing an MCP server does for Claude Code that a shell command does not: it lets the model search for an operation instead of recalling one.

discover "refund a charge"
info stripe.refund.create3
exec stripe.refund.create3

discover searches operations by plain-English description. info returns the real parameters, their types and which are required. Only then does exec run it. The model never has to remember whether Stripe wants charge or charge_id, because it can look it up in the same turn.

That closes the loop behind most failed API calls from coding agents, which is a model writing from a year-old memory of the documentation. The same failure across other tools is catalogued in why AI coding agents keep using deprecated APIs.

Setting it up safely

swy init --mode=sandbox          # mode is set once, here
swy mcp serve --claude

swy get stripe
swy discover "refund a charge"
swy info stripe.refund.create3
swy add method stripe.refund.create3
swy auth connect stripe

Three things in there are doing more work than they look.

swy add method is the allow list. Only methods you have added can run. An agent reaching for an operation you never approved fails at the runtime rather than hitting the provider.

swy auth connect puts the credential in ~/.swytchcode/credentials.db, outside your project, and the model never sees it. There is no .env file in this setup. That is the whole point of credential brokering.

--mode=sandbox is stored once in .swytchcode/tooling.json. It is not an environment variable and your code never reads it.

Then a policy, because an allow list permits a method and says nothing about how it is used:

{
  "id": "big-refunds",
  "target": ["stripe.refund.create3"],
  "when": { "field": "amount", "operator": ">", "value": 50000 },
  "action": {
    "type": "REQUIRES_APPROVAL",
    "message": "Refunds over 500.00 need approval"
  },
  "approval_timeout": "2h"
}

Keep that file in git and changes to what your agent may do get reviewed in a pull request. The argument is in policy-as-code for AI agents, and the approval side in human-in-the-loop approval.

What the server does not solve

Worth stating plainly, because an MCP server is a transport and people expect more from it.

MCP carries the call. It does not, by itself, make a retried write happen once, check that a 200 OK actually meant success, or keep a record you can hand to an auditor. Those belong to whatever executes the request. We separate the two ideas in MCP gateway vs execution layer, and the spec-level reason idempotency has to live outside the protocol is in MCP went stateless, so where do idempotency keys live now.

Check what happened with:

swy audit network   # what ran, with status and timing
swy audit policy    # what was denied or held

FAQ

What are the best MCP servers for Claude Code?

Fewer than for an editor, because Claude Code has a shell. Skip filesystem and git servers, since rg, cat and git already work. Add a browser server if you need rendered pages, optionally a database connection, and one server for third-party API execution. That last one is where the real value is, because it is where the agent does something you cannot undo.

How do I add an MCP server to Claude Code?

Claude Code registers servers directly rather than through a config file you edit. For Swytchcode, swy mcp serve --claude registers it in one command. To change tool profiles afterwards, run claude mcp remove swytchcode and re-register with --profile full. Confirm with swy mcp status.

Should I use the CLI or the MCP server with Claude Code?

Use the CLI when Claude Code is already running shell commands and you want something that also works in CI and Dockerfiles. Use MCP when you want the agent to see operations as native tools it can search and inspect, which produces better argument accuracy. Both go through the same runtime, with the same allow list, policies and audit trail, so it is a workflow choice rather than a capability one.

How many MCP servers should I register?

As few as cover distinct jobs. Every server's tool definitions load into context on every turn, so each one is a standing cost and a tool-selection risk. Prefer servers that expose a handful of tools over servers that expose one tool per endpoint. Seven tools reaching 363 APIs is a better trade than 363 tools.

Can Claude Code call Stripe, Slack or GitHub through MCP?

Yes. Pull the integration with swy get, find the operation with swy discover, check its real parameters with swy info, allow exactly that method with swy add method, and connect the credential with swy auth connect. From then on Claude Code names the operation and the runtime validates, gates, injects the credential, retries safely and logs it.

Does the MCP server need a token?

Not in stdio mode, which is the default and what --claude uses. HTTP mode, started with swy mcp serve --transport http --port 5476, binds to localhost only and needs a bearer token from ~/.swytchcode/mcp_token, printable and rotatable with swy mcp token.

What is the difference between the agent and full tool profiles?

agent is the default and exposes seven tools for day-to-day use. full exposes fifteen, adding setup commands like init, bootstrap, get, doctor and the policy write operations. The docs recommend full only while you are building and agent for anything deployed, because the extra tools are context you are paying for on every turn.

Commands here come from the Swytchcode MCP docs and the MCP quickstart. For the editor equivalent see best MCP servers for Cursor, and for the enterprise view best MCP servers for enterprise AI agents.