Best MCP Servers in 2026: What Actually Earns a Slot

The best MCP servers are the ones that do something your command line cannot, or cannot do without a detour. An MCP server is a small program that hands an AI agent a set of tools, so Claude Code can reach a service like Google Drive or a browser directly instead of you copying things back and forth. Most of the servers on a typical list fail that test, because the thing they connect to already ships a command line tool, a CLI, that the agent knows how to use.

That test used to have a second half about cost, and this is the part that has changed. Tool definitions used to load into the context window before any work started, and Anthropic's own documentation puts a five server setup, GitHub with Slack, Sentry, Grafana and Splunk, at around 55,000 tokens of definitions before a single question is asked. On a fixed plan that is not a bill, it is context you no longer have. That is no longer how Claude Code behaves. Its own docs say tool search is enabled by default, that MCP tools are held back until the agent reaches for them rather than loaded upfront, and that only tool names and server instructions load at the start of a session. It matches what I see in my own sessions: the names arrive, the descriptions do not.

So the old reason to keep the list short is mostly gone, and what survived it is not what people argue about. Below is what I run, what I cut, and the five minute audit that tells you which of yours is doing real work.

Key takeaways

• An MCP server earns its place when it reaches something your command line cannot, or would need re authorizing to match: access you already granted, a browser, or a tool with no command line at all.
• The token cost of connecting one has dropped. Claude Code holds most of the detail back until it is needed.
• What survived is the skills. Every skill you have installed still lists itself each session, used or not, inside a budget that trims the ones you never touch.
• Anthropic has floated an alternative to dropping MCP: have the agent write code that calls those tools, so only the answer comes back.
• Servers pile up once the token cost stops enforcing a limit for you, and the plugins you no longer use cost more than the servers do.

In a hurry? Jump to the five minute audit and run it on your own setup.

What actually loads at the start of a session

A tool schema is the full instruction sheet for one tool: what it is called, what it does, and every argument it takes. That sheet is the expensive part, and where it loads is the whole question.

The middle two rows are where the surprise sits. Anthropic's answer to the tool definition problem is a mechanism called the tool search tool, which marks tools as deferred so only the few needed in a given turn get loaded. The same documentation reports this typically cutting that baseline by more than 85 percent, loading the three to five tools needed for a request instead of the whole catalogue. In Claude Code this is on by default and you do not have to do anything. Two exceptions are worth knowing: if your Claude Code runs through an employer's own gateway rather than connecting to Anthropic directly, or you are on a model older than the 4.5 generation, tools still load upfront the old way. If someone else set Claude Code up for you, ask them; on a normal direct setup with a current model, neither applies.

That page names a second cost, and it is worth reading in full rather than in half. A model's ability to pick the right tool does degrade once it has more than thirty to fifty available. Anthropic's point is that tool search is the fix for that, not a casualty of it: because only a focused set loads on demand, accuracy holds up across thousands of tools. So my seventy odd are not the problem the raw number makes them sound. What is left is narrower, and it is worth saying plainly. A search can surface the wrong five. A server you stopped using stays authenticated and connected. Neither costs much context now, and neither cleans itself up.

Skills work the other way around. Every skill you have installed puts its name in context at the start of every session, and its description with it, up to a budget of about one percent of the context window. Past that, Claude Code starts dropping descriptions, least used first, so the skills you never touch are the ones that lose their text. Only the full body waits until the skill is invoked. The cost is bounded, then, but you pay it every session, and a plugin that ships twenty skills is twenty more entries in that listing.

Here is my own setup as of today. I run seven MCP servers across Claude Code: Google Drive, Gmail, Canva, Clay, Context7, Excalidraw and Resend. Between them they expose about 73 tools. One of those servers, Canva, accounts for 33 of the 73 on its own, and I use maybe two of them. On the old model that server alone would have been a real tax. Today it costs me a list of names and one short block of instructions.

Three of those seven pass my own test. The other four are there because I connected them once, and they are on my own list to cut, which is the useful thing to notice: deferred loading took away the pressure that used to keep the list honest. Of the four plugin bundles I have installed, the ones I no longer use are the line item to look at first.

The test: does it do something the command line cannot

A CLI, short for command line interface, is a program you run by typing its name rather than by clicking around a website. Most services you would want to connect already ship one, and if a service has a good CLI, the agent can just use it.

GitHub is the example to hold onto. It ships one, called gh, and Claude Code can use it to do the things you would otherwise do on the GitHub website, with no server sitting in between. That one pattern covers a surprising amount of what the popular lists recommend.

What a CLI cannot easily do falls into three buckets, and those three buckets are where the servers worth keeping live.

Access that is already granted. I have the Google Workspace CLI installed and authenticated, and it looked like the obvious replacement for a Drive connection. The permission it holds only covers files it created itself, so the moment I pointed it at a document I had uploaded in the browser, it returned a not found error. The file was right there. The tool simply could not see it. The Drive connection reads the same file without complaint, because the permission it asked for when I connected it was wider.

Worth being precise about what that proves. It is a scope I chose, and I could re authorize the CLI with broader permissions tomorrow. What the server saved me was the trip, and that is a smaller claim than "a CLI cannot reach your files."

Driving a browser. An agent that opens a browser, clicks through a page and reads back what happened, one step at a time, is working differently from one that writes an entire script and runs it blind. Both are possible from a command line. The server is what makes it interactive, which matters when you do not know what the page will do next.

Services with no CLI at all. Some things only exist as a hosted product, with nothing to install and nothing to pipe. Your own internal systems usually qualify, since nobody has published a tool for them.

Everything else is a judgment call, and it usually goes to the command line: no server to start, one sign in you already did once, and the agent can see exactly what it ran.

The best MCP servers for Claude Code right now

Grouped by the reason they earn a slot rather than by popularity.

The ones I have stopped reaching for are the ones with a good CLI behind them, GitHub above all. Reading and writing files on your own machine is another, since Claude Code does that directly. A general purpose memory server tends to fill up with things I would not have chosen to keep.

The last row of that table is the one I would take most seriously. The servers people report actually using every day are usually the ones they wrote for their own systems, because nothing off the shelf knows what their internal tools are called.

Anthropic's own answer is a third thing

The popular conclusion right now is to skip MCP and let the agent use the command line. Anthropic has floated a different idea, and it is worth knowing about before you settle the question either way.

Their engineering write up on code execution with MCP, published back in November 2025, identifies two places tokens drain: the definitions loading up front, and every intermediate result passing back through the context on its way to the answer. What they put forward is not removing the servers. It is presenting them to the agent as code it can call, so it writes a short program, runs it, processes the results, and returns only what matters. On their worked example that took a task from about 150,000 tokens down to about 2,000. That figure covers both drains together, not the definitions alone.

They offer it as one pattern rather than settled advice, and close by asking people who try it to report back, so treat it as a direction and not an instruction.

The practical version for anyone not building their own agent platform: when a job involves pulling a lot of data through a tool, ask for a script rather than a sequence of tool calls. The agent runs it, and you get the summary instead of the raw pull.

Audit your setup in 5 minutes

Four checks and one habit, and you will know exactly what you are carrying. Run these in your terminal or in a Claude Code session. If you have never changed anything in there, the settings worth changing are a good five minutes to spend first.

claude mcp list

This lists every server you have configured along with whether it is actually connected. Anything showing a failure or asking for authentication has been doing nothing for you since it broke. Then run the test down the list: could the agent get there with a command line tool instead? Every yes is a candidate to cut.

/context

Run this inside a session. It breaks down what is occupying your context window right now, line by line: the system prompt, your instruction files, your skills, your tools, and the conversation itself. Ignore the conversation, which is your actual work. Compare the rest to each other rather than to any number I could give you, and go after the biggest. On my own setup that is the skills line rather than the servers, and yours may land somewhere else, which is the reason to look. Codex has a comparable lever if you split your work across tools, and raising the Codex context window trades against the same allowance this command is protecting.

claude mcp get <name>

Before you remove anything, this tells you where that server was added from, and for one you added yourself it prints the removal command ready to copy. Servers that came with a plugin, or that you connected through your Claude account, you turn off where they came from instead.

/plugin

Opens the plugin manager. Go to the Installed tab and look for the Not used recently header near the bottom. Claude Code puts a plugin there once you have gone at least two weeks and ten sessions without using it, and the documentation says exactly what that list is for: plugins that still add startup and context cost even though you no longer use them. That is the list, already made for you. It skips plugins your employer manages and ones that only ship a theme, output style, monitor or workflow, so it is most of the list rather than all of it.

Disable anything on it. Disabling is enough, and it is reversible:

/plugin disable plugin-name@marketplace-name

If you want a number before you decide, open the plugin in the Discover tab. Its details pane shows a context cost estimate next to a list of everything the plugin will add, so you can see what it costs before you install it rather than after. Not every plugin supplies that figure. From the shell, claude plugin details <name> gives you the same list of contents.

If you want to work out which bundles are worth keeping rather than guessing, Claude can audit your setup and tell you which plugins you need. A second command goes at it from the other side and audits your habits rather than your config, so you see what you actually reach for before you decide what to cut.

One last habit worth picking up while you are in there. Look at which tools you reach for most, then ask whether they are servers at all. The two I use most in Claude Code are gh and the Playwright command line tool, not the Playwright server, and neither runs through a server. One is the GitHub tool from earlier, which the agent calls directly. The other runs my automated tests, and the agent starts it by typing a command like anyone else would.

The heaviest tools in a setup are often not on the list you think you are maintaining, which is why the list is not the only place to look.

If you want a hand mapping this to your own work, that is a large part of what I cover in the AI workshop.