I have fourteen Claude Code MCP servers connected and I use five of them. An MCP server is a standard way to hand Claude a set of tools it can call, like reading a Notion database or opening a GitHub pull request, without you writing the integration yourself. Adding one is a single command, and the part nobody warns you about is scope, because get that wrong and your server quietly vanishes the next time you open a different project. The real cost is that every connected server loads its tool definitions before you type a single word, and past a certain count Claude starts reaching for the wrong one. Fewer servers, picked per tool, beats a long list every time.
I asked Claude for a design canvas and it went for Canva.
Not the design tool I meant. Canva, which I have connected for something else entirely, because the word “canvas” was sitting right there in the server’s name and Claude took the bait.
That’s the moment I stopped thinking about Claude Code MCP servers as a collection to grow and started thinking about them as a budget to spend.
What an MCP Server Actually Is
Model Context Protocol is a standard for handing a model tools. That’s the whole idea. Somebody writes a server that exposes a handful of functions, Claude Code connects to it, and now Claude can call those functions the same way it calls its built-in ability to read a file or run a command.
Before MCP, connecting Claude to Notion meant you wrote the glue yourself. Now Notion ships a server, you run one command, and Claude can query your databases. Same for GitHub, Figma, your Postgres instance, whatever.
The useful mental model: built-in tools are what Claude can do with your computer. MCP servers are what Claude can do with everything else.
If you’re not set up with Claude Code at all yet, start with my getting started guide and come back. This post assumes you’ve got it running.
How to Add MCP Servers to Claude Code
One command. The shape depends on whether the server runs locally as a process or lives at a URL.
For a remote server over HTTP:
claude mcp add --transport http notion https://mcp.notion.com/mcpFor a local server that runs as a process, everything after the -- is the command to launch it:
claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable -- npx -y airtable-mcp-serverThen claude mcp list to see what’s connected, claude mcp get <name> for details on one, and claude mcp remove <name> to drop it. Inside a session, /mcp opens a panel showing every server, its status, its tool count, and an authentication option for the ones that need you to sign in.
If a server needs OAuth, you don’t paste a token anywhere. Run /mcp, pick the server, and it opens a browser login. There’s also claude mcp login <name> if you’d rather stay in the terminal.
One thing worth knowing if you’re copying setup instructions off a blog: a lot of them show you a claude_desktop_config.json file. That’s Claude Desktop, not Claude Code. Different app, different file. If the instructions you’re following name that file, they weren’t written for the tool you’re using.
Scope Is the Thing Everyone Gets Wrong
This is the part that cost me the most confusion, and the official docs explain it fine, but only if you go looking.
There are three scopes:
- Local is the default. The server works in the project you added it from and nowhere else. It’s private to you.
- Project writes to a
.mcp.jsonfile in the project root. That file goes in git, so everyone on the team gets the server. - User makes the server available in every project on your machine, and stays private to you.
You pick it with --scope:
claude mcp add --transport http hubspot --scope user https://mcp.hubspot.com/anthropicDefault is local. Which means if you add a server without thinking about it, open a different project the next day, and wonder where it went, that’s why. It never left the first project. Most of the servers you’d actually want everywhere belong at user scope, and most of the ones tied to a specific codebase belong at project scope so your team gets them too.
If you’re the kind of person who likes their project setup pinned down and reproducible, project scope pairs naturally with how I handle the .claude directory on every repo.
The 5 Claude Code MCP Servers I Actually Use
Fourteen connected. Five I reach for.
Context7 pulls current documentation for libraries and frameworks straight into the session. The failure mode it fixes is the expensive one. A model confidently writing against an API that changed two versions ago costs you an hour of debugging. Looking it up costs a round trip.
GitHub for repository work. Issues, pull requests, reading code in a repo I don’t have checked out locally. I’m on the hook for anything I put in a PR, so having Claude able to read the actual state of the repo instead of guessing at it matters.
Notion because my entire content system lives there. Ideas, rules, templates, all of it. If Claude can’t read Notion, it’s working from whatever I remember to paste into the chat, which is always less than what’s actually written down.
Figma for pulling design context into code. Getting the real variables and the real layout rather than eyeballing a screenshot.
Higgsfield for generating images. Every image on this site comes from it, including the ones in this post.
That’s the list. Five servers, and the only thing they have in common is that each one gives Claude access to something that genuinely lives outside my codebase and that I need while I’m in the middle of writing code.
The 9 I Have Connected That Don’t Belong Here
WordPress. Dropbox. Gmail. Buffer. AllTrails. Audible. Canva. Spotify. OpenSEO.
I use almost all of those. I just don’t use them in Claude Code.
They’re for the other side of my week, the writing and publishing and scheduling work I run in Cowork instead, which I wrote about in Claude Code vs Cowork. The split turns out to be pretty clean: if the work touches code, it’s Claude Code, and the servers it needs are the five above. If the work is everything else, it’s the other nine.
Nothing on that second list is a bad server. They’re just sitting in the wrong room. AllTrails is a genuinely good server. It has never once helped me ship anything.
The honest question to ask about any server you’ve connected isn’t “is this useful?” It’s “is this useful here, in this tool, while I’m doing this kind of work?” Those are different questions and the second one prunes a lot harder.
What Nobody Tells You: Every Server Costs You Context
Here’s the number that reframed this for me. Anthropic’s own engineering team published what a five-server setup costs: 58 tools consuming roughly 55,000 tokens before the conversation even starts. In the same post they mention seeing tool definitions hit 134,000 tokens internally before they optimized it.
Fifty-five thousand tokens. For five servers. I had fourteen connected.
The Claude Code docs put it more plainly: 50 tools can use 10,000 to 20,000 tokens, and tool selection accuracy starts degrading past roughly 30 to 50 tools loaded at once.
That second half is the one that actually bit me. It’s not just that a long server list is expensive. It’s that a long server list makes Claude worse at picking. The design canvas thing wasn’t a fluke or a bad prompt. It’s the documented behavior of a model choosing from too many options with similar names.
The good news is this is being fixed at the platform level. Claude Code now has tool search, which holds tool definitions out of the context window and loads only the handful it needs when it needs them. Anthropic measured it preserving 191,300 tokens of context versus 122,800 with the old approach, and tool selection accuracy on Opus 4.5 going from 79.5% to 88.1%. It’s on by default.
That helps with the token cost. It does not fully solve the naming collision problem, because the search still matches on tool names and descriptions, and “Canva” still looks a lot like “canvas.”
The Other Failure Mode: Servers That Don’t Do What You Think
The second thing that goes wrong isn’t overload, it’s capability gaps, and you only find them mid-task.
The WordPress server is my standing example. It accepts my Yoast SEO fields on pages without complaining and then silently doesn’t save them. No error. The write looks like it worked. I only caught it by reading the post back afterward and finding the fields empty. Its media upload only accepts base64, which is useless for an image that already lives at a URL, so I fall back to the browser for that step.
Neither of those is documented anywhere I could find. I found them by hitting them.
So the rule I’d give anyone: after the first time you use a server for something that matters, verify the result independently. Read the thing back. Check the field actually saved. MCP servers report success for the call, not for the outcome, and those are not the same thing.
What I Actually Do About It
Honest answer, and it’s less disciplined than the advice above deserves.
When Claude grabs the wrong server, I correct it in the moment and then rephrase going forward. I’ve started naming the server explicitly in the prompt, which works and which I should have been doing from the start. “Use the Figma MCP to get the layout” never picks Canva.
What I keep meaning to do and keep forgetting is turning servers off per project in the /mcp panel. You can toggle a server off without removing it, which is exactly the right tool for this, and I never remember it exists until something breaks. If you’re better at housekeeping than me, that panel is where the real fix lives.
The version of this I’d recommend, and am slowly moving toward: user scope for the two or three servers you genuinely need everywhere, project scope for anything tied to a specific codebase, and nothing else installed by default. Start empty and add on demand rather than adding everything and hoping the model sorts it out.
Where to Start
If you’re setting up Claude Code MCP servers for the first time, don’t build a collection. Install Context7 and stop. Use it for a week. Add the second one only when you catch yourself wanting something Claude can’t reach.
Every guide out there, including the ones ranking above this post, is structured as a list of ten servers you should install. That framing is the problem. The right number is the smallest one that does your actual work, and for most people writing code that’s three or four, not fourteen.
Go run claude mcp list right now and count what’s connected. Then, for each one, answer the harder question: have you used it in Claude Code in the last two weeks? Whatever fails that test, toggle it off in /mcp and see if you miss it. My bet is you won’t. If you want to see the kind of thing that survives a prune like that, it’s mostly the servers doing the unglamorous work, the same category as the small tools I build with Claude Code and forget I’m relying on.
