MCP servers for Claude Code: the essential first ten to wire up

The Model Context Protocol — the open spec Anthropic introduced in late 2024 — is what turns Claude Code from “a good CLI with web fetch” into something materially more capable. MCP servers are small processes that expose tools (read your Postgres, query your filesystem outside the project root, call your GitHub API, drive a browser) to Claude Code via a standardised protocol.

The hard part is not the protocol — it’s choosing which servers to actually wire up. Wire too few and you’re not getting the benefit. Wire too many and you blow your context window with tool definitions you never use.

After three months of using Claude Code with MCP, here are the ten servers that earn permanent space in my ~/.claude/settings.json. The order is roughly priority — if you only have time for the first three, start there.

1. filesystem (@modelcontextprotocol/server-filesystem)

What it does: gives Claude Code access to files OUTSIDE the project root. By default Claude Code can only see the project directory you opened. The filesystem MCP server lets you whitelist additional directories.

Why it matters: cross-project work. “Look at how I solved this in another repo and apply the same pattern here” — without filesystem MCP, you have to manually copy code over. With it, just point Claude at the other directory.

"filesystem": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"]
}

Trade-off: be careful what you whitelist. The whole point is the agent can read these directories.

2. github (@modelcontextprotocol/server-github)

Reads issues, PRs, repository metadata via the GitHub API. Plus opens PRs, comments, reviews when you authorise write access.

The killer use: “look at PR #123, read the failing CI logs, propose a fix as a new PR.” Without GitHub MCP, this needs you to paste links and logs manually. With it, the agent does the whole loop.

Token cost: low. The schema is small and the responses are structured.

3. postgres (@modelcontextprotocol/server-postgres)

Read-only Postgres queries plus schema inspection. You configure a connection string (please use a read-only role) and Claude Code can query your database during a coding session.

Use case: “users hitting this bug — find a pattern in the request_logs table.” Saves the open-DBeaver-copy-paste-results loop.

If you have multiple databases, run multiple postgres MCP servers with different prefixes.

4. brave-search or perplexity-mcp

What it does: web search. Claude Code has a built-in web fetch but it’s URL-based; for general search you want a real search MCP.

The Brave Search MCP is the cleanest free option. Perplexity-mcp is paid but better for research-heavy queries because it returns synthesised summaries instead of raw links.

Real use: “the API for library X changed last month — find the new signature.” Without web search, Claude Code can hallucinate older API patterns.

5. puppeteer or playwright (@modelcontextprotocol/server-puppeteer)

What it does: drives a headless browser. Navigate, click, fill forms, read DOM.

Why this matters: testing your own app, scraping documentation, debugging frontend issues from the AI’s perspective. “The button on this page isn’t doing anything — open the page in puppeteer, click the button, tell me what console errors appear.”

Token cost: high — screenshots and DOM dumps eat context. Use it sparingly and clear context after.

6. memory (@modelcontextprotocol/server-memory)

What it does: gives the agent a small persistent knowledge graph. Add facts, retrieve them later, build up project-specific knowledge across sessions.

The community pattern (popularised in the Boris setup thread) is to use memory as a “stable preferences” store — coding conventions, gotchas about specific files, contact context, etc. Across sessions, Claude Code remembers without you re-pasting.

Important: this is per-machine. Not synced. Treat it as augmented personal memory, not enterprise knowledge management.

7. sequentialthinking (@modelcontextprotocol/server-sequentialthinking)

What it does: gives the model an explicit “think out loud” tool. For complex problems, the model uses this to reason in steps before producing a final answer.

Why it earns a slot: on hard debugging tasks the structured thinking improves outcomes meaningfully. On routine tasks it’s overhead. The model decides when to call it.

8. linear or jira (your project tracker MCP)

What it does: reads tickets, lets the agent comment, optionally creates new tickets.

The use case is twofold: (a) “what does this ticket actually say?” without leaving the terminal; (b) “the ticket said this fix is needed — make it and link the PR back to the ticket.”

If you don’t use Linear/Jira, skip this. If you do, it’s high-value.

9. slack-mcp or messaging integration

What it does: reads recent Slack/Discord/Telegram messages in specific channels. Optionally posts.

Why it matters less than it sounds: the read use case (looking up a recent thread) is real but the post use case is risky. I configure read-only and only enable specific channels.

10. cloudflare-mcp (if you ship on Cloudflare)

What it does: Workers, KV, R2, D1 introspection and management via the Cloudflare API.

For our TopInsight site running entirely on Cloudflare Workers, this is essential. The agent can check deploys, inspect KV namespaces, query D1 — all without leaving the Claude Code session.

If you ship on Vercel, AWS, or elsewhere, there are equivalent MCP servers. Use whichever matches your stack.

What I do NOT install

Several popular MCP servers that look appealing but cost more than they’re worth in my workflow:

• time / weather / calendar servers — too narrow, easier to just ask Claude directly
• Multiple AI model bridges (GPT-via-MCP, Gemini-via-MCP) — model orchestration belongs in higher layers, not via MCP
• Heavyweight CRM / business-tool integrations — overkill for coding-context use; better as separate workflows

The pattern: install servers for tools you actually touch during coding sessions. Not for general utility.

Configuration: one place, version-controlled

All my MCP configuration lives in ~/.claude/settings.json (user-level) or a per-project .claude/settings.json for project-specific servers. I keep the user-level one in a private dotfiles repo so it travels across machines.

Per-project configs are useful for things like project-specific Postgres connections, or project-specific filesystem whitelists.

What the Reddit community emphasises

The r/ClaudeAI threads in early 2025 keep coming back to one point: MCP is the actual moat for Claude Code. The model is competitive across vendors. The CLI is replicable. The MCP ecosystem and Anthropic’s first-class support is the thing that’s hard to copy.

The Boris setup thread is the canonical reference for “how do power users actually configure this?” — it’s worth reading even if your setup ends up different.

The Anthropic donates MCP to Linux Foundation news is also relevant: MCP is becoming an open standard adopted across vendors, which means your investment in MCP server setups will outlive any specific tool.

The Claude Code Divide post is a more provocative read — but its core observation is right: there’s a real productivity gap between engineers who’ve configured their MCP setup and those who haven’t.

How to start, today

1. Install Claude Code if you haven’t: npm install -g @anthropic-ai/claude-code
2. Add filesystem + github + postgres to ~/.claude/settings.json (these three give you 80% of the value)
3. Restart Claude Code
4. Verify with claude mcp list — should show your servers
5. Use for a week before adding more

Adding everything on day one means you’ve burned context budget on tools you don’t use. Add as you reach for them.

For the wrapper review of Claude Code itself, see our Claude Code review. For the head-to-head against Cursor, see Claude Code vs Cursor.