Claude Code supports Model Context Protocol servers natively, which turns it from an agent that only knows your filesystem into one that can query your database, hit internal APIs, or check a project tracker as part of a normal coding session — without you manually pasting that context into every prompt.
Why MCP Matters Specifically for Claude Code (and When to Skip It)
Claude Code already has strong filesystem and shell access — it can read your code and run your tests without any extra setup. MCP extends that reach to systems outside the repo: a production database schema, a ticket tracker, a design system's component library. The value is proportional to how often you'd otherwise be manually copying context from those systems into a prompt.
Skip it if your work is entirely self-contained within the repo — if you never reference external systems while coding, MCP setup is pure overhead with no payoff.
Getting Started
Add servers via the CLI or by editing .claude/mcp.json (project-scoped, committable) or your user-level config (personal, global):
claude mcp add postgres -- npx -y @modelcontextprotocol/server-postgres "$DATABASE_URL"
claude mcp add github -- npx -y @modelcontextprotocol/server-github
Or directly in .claude/mcp.json:
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres", "${DATABASE_URL}"]
}
}
}
List connected servers and their exposed tools with claude mcp list. Once connected, Claude Code can call those tools mid-task — for example, checking the actual database schema before writing a migration, instead of guessing from a stale model file.
Core Concepts Every Developer Should Know
1. Project-scoped config is shareable. Commit .claude/mcp.json (with secrets referenced via env vars, never hardcoded) so every teammate using Claude Code on the repo gets the same tools automatically.
2. Tool approval still applies. Write-capable tools (creating a ticket, running a mutation) prompt for approval by default — the same permission model that governs file edits and shell commands extends to MCP tool calls.
3. Combine with subagents for heavy queries. If an MCP tool call returns a large result (a big table dump, a long API response), delegate that step to a subagent so the raw data doesn't consume your main session's context — only the summary comes back.
4. Read-only roles for anything touching production. Scope database credentials in MCP config to read-only roles wherever possible — the agent doesn't need write access to answer "what's the shape of this table."
Common Mistakes and How to Fix Them
Mistake 1: Wiring in write-capable production access casually. A misinterpreted instruction executing a real mutation against production is the failure mode to design against — use read-only roles and staging environments by default.
Mistake 2: One server doing too much. A single MCP server touching database, ticket tracker, and deploy tooling has a larger blast radius if misconfigured. Split by concern, same as any service boundary.
Mistake 3: Not committing the config. Keeping MCP setup personal-only means every teammate re-discovers and re-configures the same integration. Commit the non-secret parts.
When Should You Wire Up MCP?
Wire it up the moment you're regularly pasting the same external context — schema, ticket details, API responses — into Claude Code sessions manually. That repetition is the signal.
In Practice
On suhailroushan.com's tooling I run a read-only Postgres/Mongo MCP server so schema questions get answered directly instead of me hunting through a separate database client, and keep any write-capable server behind explicit per-call approval. Small setup, recurring payoff every session afterward.
Wire up one read-only MCP server for the external system you reference most during coding, and see how much manual context-pasting it eliminates.