Claude Code + MCP: A Productive Setup Guide (2026)

Q: How many MCP servers should I run?

Five to fifteen is the productive sweet spot. Pick servers that match your actual daily tools, not 'everything that looks cool'.

Q: Are MCP servers safe to give Claude Code access to?

Depends on the server. Read-only servers are low-risk. Write-capable servers require thought about what scopes you grant and what confirmation prompts you set.

Last updated: April 2026

Claude Code without MCP is a strong code agent. Claude Code with MCP is the operations center for everything I do — code, writing, planning, memory, ops. This is the practical guide to setting it up: what MCP actually is, how to configure servers, which ones are worth running, and the daily-driver loop that comes out of it. No theory beyond what you need to be productive in an hour.

This is part of the OpenClaw series. For when to use Claude Code at all, see Claude Code vs Cursor. For the original take on Claude's CLI surface, see Claw Code: Claude Source.

What MCP actually is (in 90 seconds)

MCP (Model Context Protocol) is an open protocol that lets Claude Code talk to external tools without bespoke integration code. An MCP server exposes a typed tool surface — search, write, get, update, etc. — plus resources (read-only data the model can fetch). Claude Code connects to your configured servers at startup, sees the available tools, and can invoke them during conversation.

Practically, you want to think of MCP servers as roles for Claude Code:

The "memory" server lets it remember things across sessions
The "documents" server lets it read and write your docs
The "planner" server lets it create and close tasks
The "web" server lets it fetch and screenshot URLs
The "shell" server (built-in to Claude Code) lets it run commands

Each role makes Claude Code more useful for one type of work.

Where to configure

MCP servers live in claude.json (typically ~/.claude.json) under the mcpServers key:

{
  "mcpServers": {
    "mesh": {
      "command": "node",
      "args": ["/path/to/mesh-mcp/dist/index.js"],
      "env": {
        "MESH_API": "https://mesh.example.com",
        "MESH_TOKEN": "..."
      }
    },
    "doci": {
      "command": "python",
      "args": ["-m", "doci_mcp"],
      "env": {
        "DOCI_API_KEY": "..."
      }
    }
  }
}

Per-project .claude.json overrides global config. Use this for repo-specific servers (a project planner, a dev-environment shell wrapper).

The five MCP servers I would not work without

After three months of running Claude Code daily, these are the servers that I genuinely use every day:

1. Memory / search server

Whatever your memory store is — Mesh, a vector DB, a dedicated note system — wrap it as MCP. The win: Claude Code can search what you have written before, what decisions you've made, what worked and what failed. This single server changes the agent from "smart but amnesiac" to "smart and contextual".

For my setup, I use Mesh exposed as MCP. The tool surface is: search, bytag, recent, add, get. About half my Claude Code conversations now start with the agent searching memory before doing anything.

2. Document store server

Not memory (which is short-form notes), but a real document store — for plans, specs, RFCs, longer-form work. I use DOCI; the tool surface is create, get, update, search. This is where Claude Code reads existing plans before working, and where it writes worklogs and updates after.

3. Planner / task server

Connect Claude Code to your task system. The win: tasks can be created, updated, and closed by the agent without me touching a UI. After a coding task, Claude Code closes the planner task with a worklog, sets status to done, and links the worklog ID. I do not have to remember.

If you do not already have a planner with an API, this is the time to either build one (~200 lines of SQL + a thin API) or use an existing one with an MCP wrapper.

4. Web fetch / search server

For when Claude Code needs to look up current information — vendor pricing, library docs, news. WebSearch and WebFetch are built into Claude Code, but for repeated workflows you want a dedicated web server with caching and screenshot ability. Tools like Surfer or the built-in WebFetch handle this.

5. Shell / project-aware tools

Claude Code has built-in shell access via the Bash tool, but most projects benefit from a wrapper that exposes high-level operations: deploy, run-tests, db-shell, tail-logs. These can be implemented as a thin MCP server in 100 lines that delegates to your existing scripts. The win: agent calls a named tool with a typed signature, instead of fragile string-based shell commands.

A few servers worth knowing about (but optional for solo dev)

GitHub MCP — read issues, PRs, files; useful when you work in a team
Filesystem MCP — explicit FS access (Claude Code already has Read/Write/Edit, but this is useful for sandboxed environments)
Sentry / Datadog MCP — read errors and logs from observability tools
Browser automation MCP — for tasks requiring real browser control
Slack / Discord MCP — for team communication automation

The pattern across all of these: when you find yourself doing cmd-tab + click + copy + paste back into Claude Code repeatedly, that is the signal to build (or install) an MCP for that thing.

Permission model

MCP servers can do a lot. The permission model matters:

Allowlist read-only by default — let Claude Code read memory, docs, web. Confirm before write.
Prompt-on-write for write operations — Claude Code will ask before publishing a worklog, closing a task, sending a Slack message. You can flip this off after you trust the loop.
Deny destructive operations until explicitly approved — file deletion, repo force-push, prod migrations. Set deny rules in your project .claude.json.

Your claude.json permissions section specifies the rules. The default (everything is "ask") is the right starting point — relax once you know what the agent is doing.

The daily-driver loop

What this enables, in actual use:

Morning: "Hey, what's on my plate today?" Claude Code searches memory (recent worklogs), reads the planner (tasks for today), summarizes. I read the summary, refine priorities.

During work: I describe a task. Claude Code reads existing plans (DOCI), checks recent decisions (Mesh), writes code, runs tests via shell, opens the planner, closes the task with a worklog. I review the diff and the worklog.

Evening: "Wrap up the day." Claude Code reads git log, recent worklogs, summarizes what shipped, what is pending, posts to a daily log. I check.

This loop replaces the "open 8 tabs, copy context, paste into agent, copy answer back, manually update tracker" flow that I had a year ago. The wins are not magical — they are the elimination of friction.

What I do not use MCP for (yet)

Email — I draft replies in Gmail UI and let Claude Code suggest text via paste, not via MCP. Email is too high-stakes for autonomous send.
Calendar — same reason. Reading is fine; writing requires human approval per event.
Production deploys — I deploy via standard ops, not via Claude Code direct. Build / test verification, yes. Push-to-prod, no.

The principle: write operations on systems where mistakes are expensive get human-in-the-loop. Read operations are cheap to grant.

Frequently asked questions

What is MCP and why does Claude Code need it? MCP (Model Context Protocol) is the open protocol that lets Claude Code talk to external tools and data sources without bespoke integration code. With MCP servers configured, Claude Code can read your memory store, query your task planner, fetch web pages, look at GitHub PRs — without you copy-pasting context. Without MCP, Claude Code is a strong code agent. With MCP, it becomes the operations center for your day.

Where do I configure MCP servers for Claude Code? MCP servers are configured in claude.json (typically at ~/.claude.json) under the 'mcpServers' key. Each server entry specifies its command, args, and any environment variables. The Claude Code CLI also supports per-project .claude.json overrides. Most users start with a global config and add project-specific servers as needed.

How many MCP servers should I run? Five to fifteen is the productive sweet spot. Fewer than five and you are leaving capability on the table. Beyond fifteen, you start hitting context-bloat issues — Claude Code has to enumerate available tools at startup, and very large tool lists slow down model decision-making. Pick servers that match your actual daily tools, not 'everything that looks cool'.

Are MCP servers safe to give Claude Code access to? Depends on the server. Read-only servers (memory search, docs read, web fetch) are low-risk. Write-capable servers (file system, planner update, email send) require thought about what scopes you grant and what confirmation prompts you set. The Claude Code permission model lets you allowlist specific tool calls, deny others, and prompt for risky operations — configure this before pointing Claude Code at production systems.

Can I write my own MCP server? Yes — and it is straightforward. The MCP spec is small and well-documented; you can build a basic server in 100-200 lines of Python or TypeScript. Most useful internal MCP servers are 'wrap an existing internal API as an MCP tool surface' — exposing a search endpoint, a write endpoint, and a config-aware help message. If you have an internal service you reach for daily, building an MCP wrapper for it is one of the highest-leverage afternoons of work you can do.

Claude Code vs Cursor — when to use which tool
Claw Code: Claude Source — original take
What I Shipped in 24h with Claude Code — case study putting MCP to work

What is the most useful MCP server in your config? Reply — I will fold productive setups into a follow-up post.