Last Tuesday at about 1am, one of our claude code MCP servers saved me from a very stupid evening. I was staring at a Postgres query that was eating our staging database alive. I had a rough idea of which index was missing. I did not want to context-switch into psql, copy the schema, paste it back into Claude Code, and play the telephone game. So I typed @postgres show me the query plan for the slow one into my running Claude Code session and it just, you know, did it. The plan came back, the missing index was obvious, the migration wrote itself, and I went to bed.
That tiny moment is why I am, finally, a believer in MCP. Not because they are glamorous. They are not. They are plumbing. But the right plumbing is the difference between a house you love and a house that floods every spring.
A quick warning on hype. MCP, the Model Context Protocol that Anthropic introduced in late 2024, crossed 97 million monthly installs across all clients by early 2026 according to community trackers. That number is unreal. It also means the ecosystem is full of half-finished servers that will happily blow up your context window and your weekend. I have burned about sixty hours installing, uninstalling, and cursing MCP servers so you do not have to.
This post is the shortlist. Fifteen servers Marcus and I actually keep installed in 2026. What each one does, the install command, one real use case, and the gotcha nobody warns you about.
What MCP actually is
MCP is an open standard, a bit like USB, that lets any AI client talk to any tool through a common socket. The client (Claude Code, in our case) speaks MCP. The server (Postgres, GitHub, a filesystem) speaks MCP. They shake hands, exchange a menu of tools, and your agent can now call those tools without you wiring up a bespoke integration. Think of it less like a plugin and more like a standard plug shape. If you can boil water with it, it probably has a plug.
How to install an MCP server
In Claude Code, the baseline install looks like this.
claude mcp add github --scope user -- npx -y @modelcontextprotocol/server-githubThree things matter here. The name is what you will type to invoke it. The scope decides whether this server is available only in this repo, to your whole user, or locally to this one session. The transport is either a local command (stdio) that Claude Code spawns for you, or a remote URL (HTTP/SSE) that some teams prefer behind a firewall. Most good servers ship as an npm or Python package you can run with one line. A few fancier ones, like the official GitHub server, also have a hosted HTTP version you can point at.
The official spec lives at modelcontextprotocol.io, the main server registry is github.com/modelcontextprotocol/servers, and Claude Code's own docs on how to wire them up are at docs.claude.com.
One piece of napkin math before the list. Every MCP server you install eats context. A typical server's tool manifest is somewhere between 800 and 3,000 tokens. If you install twenty of them, you have just burned roughly 40,000 tokens of your window before you type a single character. On a 200k model that is fine. On a smaller one, it is the difference between finishing a task and running out of room mid-thought. Install fewer than you think you need.
The 15 servers worth your context window
I think of MCP servers the way a guitarist thinks about pedals. You do not need every pedal on the board. You need the three or four that define your sound, and you need them in the right order. Below are the fifteen I would keep if I could only keep fifteen, grouped by the job they actually do.
File and Search
1. filesystem (official)
The default Claude Code filesystem is scoped to your current working directory, which is sensible. The official filesystem MCP server breaks that boundary for the cases when you need it. Read and write across multiple project roots, chase a symlink, pull a spec file from a sibling repo.
claude mcp add filesystem --scope user -- npx -y @modelcontextprotocol/server-filesystem ~/code ~/notesReal use case. I run it pointed at ~/code and ~/notes so the agent can pull patterns from an old project into a new one without me copy-pasting. Gotcha: scope it. If you pass / as a root, you will let the model read your SSH keys, and you will deserve what happens next.
2. git
The git MCP server is a wrapper around the boring but essential ops: log, blame, diff between arbitrary refs, cherry-pick. Claude Code can already shell out to git directly, which is why this one is controversial. I keep it installed because it returns structured output the agent can reason about, instead of a wall of terminal text.
claude mcp add git -- npx -y @modelcontextprotocol/server-git --repository .Real use case. "Summarize what changed in this repo since the v4.2 tag" used to mean a messy shell session. Now it is one sentence. Gotcha: it is read-mostly by design. For writes, let the agent use the normal git CLI.
3. ripgrep-mcp
Big monorepos eat naive search tools for lunch. A ripgrep-backed MCP server gives the agent a proper index-aware grep, which in practice means the agent stops reading whole files when it only needed three lines.
claude mcp add rg -- npx -y ripgrep-mcpReal use case. On a 1.2 million line backend repo I work in, searching for a config key through normal file reads cost about 40k tokens. Ripgrep MCP cuts that to under 2k. Gotcha: double-check the server respects your .gitignore. Some variants do not, and you will waste tokens reading node_modules with a straight face.
Data and Databases
4. postgres
The one that made me write this post. Connect read-only (please, please read-only) to a Postgres instance and the agent can introspect schemas, describe tables, run EXPLAIN, and even run sandboxed SELECTs.
claude mcp add postgres -- npx -y @modelcontextprotocol/server-postgres "$DATABASE_URL"Real use case. Debugging slow queries without round-tripping through a human DBA. Schema questions stop being a forty-minute Slack thread. Gotcha: use a read-only role. I cannot repeat this enough. MCP servers are not infrastructure you harden once and forget, they are agents with hands, and an agent with DROP TABLE privileges is a bad roommate.
5. sqlite
The SQLite server is the junior sibling, and I actually use it more than Postgres on small side projects. Point it at a .db file, let the agent treat it like a first-class citizen.
claude mcp add sqlite -- npx -y @modelcontextprotocol/server-sqlite ./data.dbReal use case. Analytics on a local dump. "How many unique users hit endpoint X last week" becomes a conversation, not a script. Gotcha: WAL files. If another process is writing, open the db as read-only or you will get phantom rows.
6. supabase
If your stack is Supabase, the official Supabase MCP server is probably the single highest-value install in this list. Schema introspection, RLS policy review, migration suggestions, auth user lookups.
claude mcp add supabase -- npx -y @supabase/mcp-server --url $SUPABASE_URL --key $SUPABASE_SERVICE_KEYReal use case. "Draft an RLS policy that lets users read their own rows but not write to the role column." Draft appears. I review. It ships. Gotcha: service keys are sharp edges. Treat this server like production credentials, because it holds them.
Dev Tools and APIs
7. github
The official GitHub MCP server opens up issues, PRs, code search, reviews, and the GitHub Actions API. It is the single server I find myself reaching for across the widest number of projects.
claude mcp add github -- npx -y @modelcontextprotocol/server-githubReal use case. "Find every open PR in the org that touches src/auth and draft a one-line summary of each for the security review meeting." Agent does it in about thirty seconds. Gotcha: token scopes. Give it the narrowest PAT you can stomach. The full repo scope is a lot of power in the hands of an agent that occasionally misreads a prompt.
8. linear
Linear's MCP server is the unsung hero of focused work. The agent can read tickets, comment, move states, and pull sprint context without you ever switching tabs.
claude mcp add linear -- npx -y @linear/mcp-server --api-key $LINEAR_API_KEYReal use case. Starting a task becomes "read ticket ENG-4412 and draft a plan." The plan arrives with the right links, the right labels, and a pre-filled PR description. Gotcha: set a token scope limited to your team. Otherwise the agent will happily search the whole org and return tickets you are not supposed to see.
9. sentry
Sentry's MCP server connects errors, releases, and issue tracking straight into the agent's working memory. Paste a stack trace, the agent resolves the frames, proposes a fix, and updates the ticket when the fix ships.
claude mcp add sentry -- npx -y @sentry/mcp-server --auth-token $SENTRY_TOKENReal use case. After a deploy, "Which new errors appeared in the last hour and which ones correlate with my PR?" is a real, answerable question now. Gotcha: rate limits. If you turn the agent loose on a busy project, it will cheerfully pull fifty issues and blow through your API quota before lunch.
Browser and Web
10. playwright
A headless browser as a tool. The agent can open pages, click things, assert, screenshot, and pull console logs. The old puppeteer server still works, but Playwright's cross-browser support and its built-in tracing make it the better modern pick.
claude mcp add playwright -- npx -y @modelcontextprotocol/server-playwrightReal use case. "Reproduce this bug in Safari and Chrome, and tell me which one breaks first." The agent runs both in parallel, captures traces, and hands me a clear answer. Gotcha: browsers are heavy. The first install downloads about 500MB of binaries, and every session spawns a real Chromium process. Not a great fit on a laptop with an already-full disk.
11. fetch
The simplest server here. Plain HTTP requests, with a body, with headers, with redirects. Boring. Essential.
claude mcp add fetch -- npx -y @modelcontextprotocol/server-fetchReal use case. Hitting an internal API that does not have a dedicated MCP server. Or quickly validating a public endpoint's response shape without spinning up a REPL. Gotcha: no built-in SSRF protection. If you expose this server to a remote agent on your network, someone can ask it nicely to hit 169.254.169.254 and exfil cloud metadata. Keep it local.
Docs and Knowledge
12. context7
Context7 is a library documentation lookup server that pulls up-to-date, version-specific docs for the packages you are actually using. If the agent writes code against a stale Next.js API, that is your fault for not having this server installed.
claude mcp add context7 -- npx -y @upstash/context7-mcpReal use case. Writing a new Tailwind v4 theme. The agent needed the v4 syntax, not the v3 one it learned during training. Context7 hands it the current docs, the output actually compiles. Gotcha: coverage is uneven. Popular libraries are well-indexed. Your obscure internal fork of a six-year-old Python package is not.
13. notion
The Notion MCP server turns your team's workspace into queryable context. Specs, design docs, meeting notes, runbooks. All searchable without the agent hallucinating.
claude mcp add notion -- npx -y @notionhq/mcp-server --token $NOTION_TOKENReal use case. "Find the design doc for the billing migration and summarize the open questions." Thirty seconds, as opposed to thirty minutes of me scrolling. Gotcha: permissions. The integration sees exactly what the token sees. Grant it to a top-level page that holds only what the agent should touch, not to the entire workspace.
Enterprise and Ops
14. slack
Slack's MCP server is the one Marcus will talk more about below. The short version: it reads channels, searches history, posts messages, and pulls threads. Treat it as a careful peer, not a free-wheeling poster.
claude mcp add slack -- npx -y @slack/mcp-server --token $SLACK_BOT_TOKENReal use case. "Find the thread where we discussed the auth refactor and summarize the decisions." It used to take ten minutes of Slack scrolling. Now it takes ten seconds. Gotcha: posting. Disable write scopes unless you really mean it. An agent that can post to #general is a fun demo and a bad idea.
15. chroma
Vector-database-as-MCP-server, so the agent can remember. Chroma is the one I land on most often because it is dead simple to run locally, but memory-bank, qdrant-mcp, and similar servers solve the same problem.
claude mcp add chroma -- npx -y chroma-mcp --path ./chroma-storeReal use case. I keep an index of every architectural decision I have written down over the last three years. The agent pulls the relevant ones when it is about to make a similar decision. Fewer repeated mistakes, which is the only real learning there is. Gotcha: embeddings drift. Re-index on a schedule, or your "memory" becomes a museum of ideas that no longer match your codebase.
Marcus here: how we run MCP across a 12-person team
Marcus here. Kai is allergic to process, which is charming. I run a 12-person engineering team at a fintech where "charming" is not on the compliance checklist. So let me tell you how we actually deploy claude code MCP servers without getting paged at 3am or called into a conference room with Legal.
Three rules we live by.
Rule one, a central registry. We maintain a single repo with a claude-mcp.json equivalent that defines the exact set of MCP servers every engineer runs, pinned to specific versions. New engineers clone it, run one script, and their Claude Code config matches everyone else's. The register is source-controlled and reviewed. When someone wants to add a new server, they open a PR. Two approvers required, one of whom is security. This sounds heavy. It is not. It takes about a week of grumbling, then nobody thinks about it again.
Rule two, scoped credentials for every server. No engineer gets a personal token with production database privileges attached to an MCP server. We issue per-developer, per-service tokens with expiry dates and the narrowest possible scopes. Postgres MCP connects through a read-only replica. Sentry MCP uses a token limited to a single project. GitHub MCP cannot touch protected branches. Napkin math on this. A single engineer on our team makes roughly 80 MCP tool calls per day on average. With 12 engineers, that is close to 1,000 tool calls per working day hitting production-adjacent systems. If any one of those calls writes where it should read, we notice. More importantly, we can explain it.
Rule three, audit logs on everything. Every MCP server we allow either ships with its own audit log or writes through a local proxy we wrote that logs every request and response to a central store. When Legal or Security asks "what did this engineer's agent do on the night of March 14," we have an answer within ninety seconds. This is less about mistrust and more about sleep. A team that can answer that question sleeps better.
We allow exactly nine of Kai's fifteen. We block the filesystem server entirely in favor of scoped project roots. We run Postgres and Supabase through an internal gateway. We do not allow the Slack server to post, only to read. Chroma we replaced with an internal vector store that shares embeddings across the team so one engineer's learnings help everyone else.
The payoff is real. Our PR cycle time dropped from around four days to under two once MCP was standard across the team. Our on-call load dropped too, because Sentry MCP plus Linear MCP plus GitHub MCP together mean that by the time a human looks at a page, the agent has already pulled the relevant ticket, stack trace, and recent PRs. The human now spends minutes, not hours, getting oriented.
For teams thinking about this, the mistake I see most often is treating MCP servers like IDE plugins. They are not. They are pieces of infrastructure with credentials attached. Govern them like infrastructure. Log them like infrastructure. Revoke them like infrastructure.
If you are building the muscle for this, my other two reads are our best claude code plugins for 2026 post for the plugin side of the tooling story, and the 50 Claude Code tips guide for the day-to-day habits that keep a team from drowning in its own agent output.
When NOT to install an MCP server
This is the section I wish I had read a year ago. MCP is not free.
Context cost. I mentioned the napkin math earlier. Every server adds tokens to your window before you type. For a dense coding session on a smaller model, that difference is real and painful.
Security surface. Every MCP server is a new piece of software with a new set of credentials and a new API to attack. If you do not understand what a server does, do not install it. Read the source. It is almost always under 2,000 lines.
Cognitive cost. The model, like you, does better with fewer choices. Give it twenty tools and it will occasionally pick the wrong one. Give it six and it will pick right. I am not sure I believe the research yet, but anecdotally I can tell you that a lean config makes the agent sharper.
Fragility. Third-party MCP servers die. They stop getting maintained, they break on new Claude Code versions, they silently return empty results. Each one is a small relationship you are maintaining. Make sure it is worth it. The official ones are well-maintained. Some community ones are weekend projects that may or may not survive the winter.
A heuristic I use. If the task the MCP server solves is something I do less than once a week, I uninstall it. I can reinstall in thirty seconds when I need it again. My config stays lean, my window stays roomy, and my agent stays sharp.
Where this leaves us
I started with a story about a database query at 1am, but the real story is about plumbing. The first year of MCP was loud. Everybody was building a server for everything. The second year, which we are in now, is quieter and more interesting. The servers that survived are the ones that made engineers a little faster, a little calmer, a little less likely to lose an evening to a context switch.
You do not need all fifteen. Start with three. Pick one from Files, one from Data, one from Dev Tools. Live with them for a week. Add a fourth only when you catch yourself missing something specific. That is the honest playbook.
If you want to push further, our Claude Code tutorial for beginners walks through the first-day setup including MCP basics, and the 50 Claude Code tips and best Claude Code plugins for 2026 posts each go deeper on the tooling side.
What are the MCP servers on your board that you would defend with your life? The ones that survived your cleanup? Drop us a note. Marcus and I are still figuring ours out, same as you, and the good picks travel best by word of mouth.