Best MCP Servers in 2026 (And the Ones You Should Delete)

Almost every "best MCP servers" roundup you will read today is built on two claims that are no longer true. The first: that @modelcontextprotocol/server-postgres, server-github, server-puppeteer, server-slack and their siblings are the canonical picks. They were archived on 2025-05-29 into a repository whose README states, in capitals, that no security guarantees are provided for them. They still npx cleanly, which is exactly why the recommendation keeps propagating. The second: that every tool definition you add eats your context window, so you should install as few servers as possible. In Claude Code, tool search is on by default and defers tool definitions — the docs say plainly that adding more MCP servers has minimal impact on your context window and that there is no fixed per-server tool cap. Definitions got cheap. Output and trust did not. This article rebuilds the list from primary sources, gives you a four-gate rule for deciding what earns a slot, and tells you exactly which readers still pay full freight for every tool definition.

The list everyone is still copying is archived

Open any current roundup of the best MCP servers and count how many of these appear: @modelcontextprotocol/server-postgres, server-puppeteer, server-github, server-brave-search, server-slack, server-sqlite, server-gdrive. In most lists, all seven. Usually near the top, usually with an install command you can paste.

Fourteen server directories sit in modelcontextprotocol/servers-archived, a repository that was archived on 2025-05-29. The full list: AWS KB Retrieval, Brave Search, EverArt, Git, GitHub, GitLab, Google Drive, Google Maps, PostgreSQL, Puppeteer, Redis, Sentry, Slack and SQLite. The README of that repository says, in capitals, that no security guarantees are provided for these archived servers, that they are no longer maintained, and that no security updates or bug fixes will be provided.

Thirteen of those fourteen have no maintained reference successor. The fourteenth is a trap for anyone reading carelessly: Git appears on both lists. An archived copy sits in servers-archived, and Git is also one of the seven servers still active in the main repo. If you go looking for "the Git MCP server" and land in the archive, you will conclude it is dead. It is not. Check which repo you are standing in — this is the whole failure mode of the genre, compressed into one package name.

They still install. They still run. That is the trap, and it is the whole reason the recommendation keeps reproducing itself: a writer tests the install command, it works, the server returns rows, and it goes in the list. Nothing in the install path tells you that the code has been unmaintained for over a year and explicitly carries no security commitment. You have to go look at the repo, and the repo you land on from an old blog link is the archived one.

There is a second, subtler error in the same neighborhood — the same shape as the Git confusion, one layer out. The archived "GitHub server" was Anthropic's reference implementation. GitHub's own server — github/github-mcp-server — is a different piece of software, maintained, with a remote endpoint at https://api.githubcopilot.com/mcp/. Same for Sentry and Slack: the old reference implementations are archived, but first-party remote servers exist at https://mcp.sentry.dev/mcp and https://mcp.slack.com/mcp. Conflating the two — writing "the GitHub MCP server is archived, avoid it" — would be worse than saying nothing. The reference implementation is dead; the vendor's own server is the replacement.

The seven servers that survived

Exactly seven reference servers remain active: Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, and Time. Their README is careful about what they are — reference implementations that demonstrate MCP features and SDK usage — and it points discovery elsewhere: if you are looking for a list of MCP servers, browse published servers on the MCP Registry.

That framing matters. These seven are not a curated best-of. They are teaching material that happens to be useful. Filesystem is the one most people actually run day to day: npx -y @modelcontextprotocol/server-filesystem [directories], with all operations restricted to allowed directories — set either by CLI args or, as the docs recommend, dynamically via the Roots protocol, using roots/list plus roots/list_changed so the allowed set can change at runtime without a restart. Note that Roots is one of the three features the 2026-07-28 release candidate deprecates. Deprecates, not removes: the RC's lifecycle policy keeps a deprecated feature in the spec for at least twelve months before it is eligible for removal, so this is a thing to track, not a fire to put out.

As for the MCP Registry itself: it is still in preview, not generally available, and says so — breaking changes or data resets may occur before general availability. It hosts server.json metadata pointing at packages, and uses reverse-DNS namespaces with DNS or GitHub verification. Treat it as a directory with a verification story, not as a safety guarantee.

The token argument points at the wrong thing

Here is the line that appears in nearly every article in this genre: every tool definition you add is consumed on every request, so install fewer servers. It was true. It is the reason people believe MCP has a hard scaling ceiling.

Anthropic's own numbers make the historical case well. In their advanced tool use writeup, as of their November 2025 measurements, a five-server example came out at roughly: GitHub, 35 tools, about 26K tokens; Slack, 11 tools, about 21K tokens; Sentry, 5 tools, about 3K; Grafana, 5 tools, about 3K; Splunk, 2 tools, about 2K. Fifty-eight tools, roughly 55K tokens, before you have said anything. (These are vendor-published approximations from Anthropic measuring its own harness, and they will have drifted since.) You may also have seen a widely-recycled "67,300 tokens / 33.7% of context" figure — that one is from a third-party blog, not from Anthropic. Anthropic's numbers are better and citable; use theirs.

But the Claude Code docs now say something that invalidates the advice as a present-tense universal: tool search keeps MCP context usage low by deferring tool definitions until Claude needs them; only tool names and server instructions load at session start, so adding more MCP servers has minimal impact on your context window; and Claude Code does not impose a fixed per-server tool cap — the practical limit is your context window budget. Tool search is enabled by default.

Anthropic's published figures for the mechanism: about 77K tokens of tool definitions reduced to about 8.7K, described as an 85% reduction in token usage while maintaining access to the full tool library, and preserving 95% of the context window. On accuracy, they report Opus 4 improving from 49% to 74% and Opus 4.5 from 79.5% to 88.1%. A separate piece on code execution with MCP reports a two-server task (read a meeting transcript from Google Drive, attach it to a Salesforce prospect record) going from 150,000 tokens to 2,000 — a 98.7% saving. All of these are Anthropic measuring Anthropic's own features on their own harness. No independent replication exists that I could find. They are the best numbers available and they are worth citing; they are not neutral benchmarks.

So the honest 2026 version of the advice is a reversal: definitions got cheap; output and trust did not.

Where the costs actually land

The single most useful thing you can hold in your head is a map of which part of an MCP connection charges you, and when.

Read it left to right. At session start, only tool names and server instructions enter the window. Definitions sit at the server until tool search pulls one in. Then the model calls a tool, and the result comes back — and that is uncapped by anything except the output limit. Claude Code displays a warning when MCP tool output exceeds 10,000 tokens and limits output to 25,000 tokens by default; MAX_MCP_OUTPUT_TOKENS=50000 raises the ceiling, but the warning threshold is fixed.

Sit with the arithmetic for a second. Ten servers' worth of deferred definitions cost you a list of names. One badly-scoped query against a database server — SELECT * against a wide table, no limit — can hit the 25,000-token truncation in a single call, and the truncation itself is a failure mode: the model now reasons over a partial result and does not necessarily know it. This is a context engineering problem, not a server-count problem, and it is why "how do I stop this thing from returning everything" is the question that should drive your picks.

The four-gate rule

Here is the decision rule this article is really about. Install a server only if it clears all four gates. Each one is defensible from a primary source.

Gate 1 — MAINTAINED. First-party, or demonstrably actively maintained. If it lives in servers-archived, it is disqualified regardless of how well it works today — with the one caveat established above, that Git lives in both repos and the active copy is fine. "It still runs" is not a maintenance status; it is the absence of one.

Gate 2 — SCOPABLE. The server must ship a read-only mode, toolset filtering, or both, so you can shrink privilege and output at the same time. github/github-mcp-server is the reference standard here: toolsets are configurable via the GITHUB_TOOLSETS environment variable (the default set is context, repos, issues, pull_requests, users), and a --read-only flag means write tools are skipped entirely. Supabase's server expresses the same idea at a different layer — its read-only mode executes queries as a read-only Postgres user, which is a database-enforced boundary rather than a politely-omitted tool.

Gate 3 — BOUNDED OUTPUT. Will its typical call routinely blow past 25,000 tokens? If the honest answer is yes and there is no pagination, no field selection, and no limit parameter, you are installing a context bomb with a nice logo.

Gate 4 — EARNS alwaysLoad, OR ACCEPTS DEFERRAL. Setting alwaysLoad: true on a server loads every one of its tools into context at session start regardless of ENABLE_TOOL_SEARCH. The docs are direct about the tradeoff: use this for a small number of tools that Claude needs on every turn, since each upfront tool consumes context that would otherwise be available for your conversation. It also blocks startup until the server connects, capped at a 5-second connect timeout. A server can mark individual tools as always-loaded via "anthropic/alwaysLoad": true in the tool's _meta. Requires Claude Code v2.1.121 or later. So: if you cannot justify a server loading every single turn, it must be fine behind tool search — and if it is fine behind tool search, you have no reason not to install it.

Gate 4 is the one that dissolves the old anxiety. The question stopped being "how many servers can I afford?" and became "which of these earns a permanent seat, and which is happy to be summoned?" Most are happy to be summoned.

One extra preference on top of the gates: prefer a maintained first-party remote server with OAuth over a local stdio process holding a long-lived personal access token. The spec's own guidance is that stdio implementations should not follow the authorization spec and should retrieve credentials from the environment instead — which in practice means a token sitting in a config file on disk, unscoped, with no revocation story. Remote plus OAuth is a better shape for the same capability.

Migration table: archived pick to maintained pick

This is the table the genre owes you. Left column is what you will see recommended; right columns are what to run instead, with the knobs that satisfy Gate 2 and the deferral verdict for Gate 4.

A note on the last row, because it is the most interesting one: Cloudflare's Code Mode server provides broad API access through code execution rather than typed tools. That is a vendor implementation of the same thesis Anthropic published in its code-execution-with-MCP writeup — the one reporting 150,000 tokens down to 2,000 on a two-server task. If you want the general argument for when a tool call beats a plain HTTP call and when it does not, that is the subject of MCP vs API.

Two things deliberately absent from that table: star counts and tool counts. Star counts are noise and I have seen implausible ones circulating. Tool counts drift with every release — naming the mechanism (GITHUB_TOOLSETS, --read-only) tells you more than a number that will be stale by the next minor version. Also absent: a total count of MCP servers in existence. The registry is explicitly in preview with no durability guarantee, and any total you see quoted has no credible source behind it.

If you route Claude through a gateway, the old advice still applies

This section exists because our readers are disproportionately the exception, and nobody has written it down.

Tool search requires a model that supports tool_reference blocks — the docs name Claude Sonnet 4.5, Claude Haiku 4.5, and Claude Opus 4.5 and later models. And it is disabled by default on Google Cloud's Agent Platform, and when ANTHROPIC_BASE_URL points to a non-first-party host, because most proxies do not forward tool_reference blocks. CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS keeps it off outright, and ENABLE_TOOL_SEARCH cannot override that.

Read that again if you use a gateway or a router. If you have pointed ANTHROPIC_BASE_URL at anything that is not Anthropic — which is the entire premise of tools like Claude Code Router — you are very likely still paying the full 55K-for-58-tools that Anthropic measured in November 2025. The token-bloat article you read in 2025 is not stale for you. It is a live description of your bill.

Concretely, if that is your setup:

• Keep server count genuinely low, or split configs by project scope so each project only mounts what it needs.
• Use GITHUB_TOOLSETS and equivalents aggressively — a 5-tool GitHub is a fraction of a 35-tool GitHub.
• Check whether your gateway forwards tool_reference. If it does, ENABLE_TOOL_SEARCH can force the behavior on; unset means all MCP tools are deferred, true forces it, and auto is threshold mode — load definitions upfront if they fit within 10% of the context window, defer the overflow.

auto is the underrated setting for mixed fleets: it gives you upfront definitions when they are cheap and deferral when they are not, without you having to decide per server. If you are building agents where tool-call accuracy is the binding constraint, model choice interacts with all of this — see the best LLM for AI agents in 2026.

Trust does not defer

Tool search made definitions cheap. It did nothing to the thing that should actually cap your server count.

A deferred tool definition is still a running process on your machine with your credentials and your privileges. The spec's security best practices section says it without euphemism: local MCP servers are binaries downloaded and executed on the same machine as the MCP client; the risks include arbitrary code execution, where attackers can execute any command with MCP client privileges, and no visibility, where users have no insight into what commands are being executed. The mitigation guidance tells clients to warn users that MCP servers run with the same privileges as the client, and to sandbox.

The spec is equally blunt about tools themselves: tools represent arbitrary code execution and must be treated with appropriate caution; descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server. And: hosts must obtain explicit user consent before invoking any tool. Anthropic's Claude Code docs carry the same warning right next to server discovery — verify you trust each server before connecting it, because servers that fetch external content can expose you to prompt injection risk — and point discovery at the Anthropic Directory for reviewed connectors.

Notice how those two facts interact with tool search. Tool poisoning — hiding malicious instructions in tool metadata that the user never sees but the model reads as ground truth — lives in the description. Tool search retrieves the description at the moment of use. Deferral does not sanitize anything; it just moves when the untrusted text arrives. The technique was named by Invariant Labs, which published the first public proof-of-concept during 2025; I have not verified the exact date against their primary source, so treat the timing loosely.

And then there is supply chain. The postmark-mcp case, disclosed by Koi Security in September 2025 and described as the first in-the-wild malicious MCP server, has a shape worth memorizing: the package published fifteen benign versions, and version 1.0.16 added a one-line BCC that forwarded every email sent through the server to an attacker address. Roughly 1,643 downloads were reported before removal from npm, though figures vary slightly between the vendor security blogs that covered it. The important framing: this was a supply-chain rug-pull, not a protocol vulnerability. No amount of MCP spec hardening prevents a maintainer from shipping a bad sixteenth version. What prevents it is not having installed a server you did not need.

Which is the real answer to "how many servers is too many?" Not a token number. Server count still scales risk linearly even when it no longer scales tokens. Every server is a process, a credential, a maintainer you are trusting, and a description your model reads as truth.

If you want a formal taxonomy to check yourself against, an OWASP MCP Top 10 project exists — though it is at Phase 3, beta release and pilot testing, not a ratified standard. Its 2025 entries: token mismanagement and secret exposure, privilege escalation via scope creep, tool poisoning, software supply chain attacks and dependency tampering, command injection and execution, intent flow subversion, insufficient authentication and authorization, lack of audit and telemetry, shadow MCP servers, and context injection and over-sharing. Useful as a checklist; not something to cite as a standard.

What changes on 2026-07-28

Two governance and timing facts that most roundups will get wrong.

MCP is not Anthropic's protocol anymore. Anthropic introduced and open-sourced it, but on 2025-12-09 it was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI. The founding project contributions were MCP, Block's goose, and OpenAI's AGENTS.md. Platinum members include AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI. Any sentence beginning "Anthropic's MCP" is describing December 2024, not July 2026.

And the spec is about to move. Revisions are dated YYYY-MM-DD and marked Draft, Current, or Final. The current revision is 2025-11-25. A release candidate for 2026-07-28 was locked on 2026-05-21, with final publication stated for that date — eleven days after this article was written. Its own announcement calls it the largest revision of the protocol since launch. What it does:

• Stateless protocol core — eliminates the initialize handshake and the Mcp-Session-Id header.
• Extensions framework — Tasks and MCP Apps become official extensions.
• Authorization hardening toward OAuth 2.0 / OIDC.
• A formal deprecation policy.
• Breaking changes, deprecating three features: Roots, Sampling, and Logging.

One nuance worth holding onto, because it is the part that will get flattened into panic: nothing is removed in 2026-07-28. Three features are deprecated with migration paths documented, and the new lifecycle policy keeps a deprecated feature in the spec for at least twelve months before it is eligible for removal. The methods, types and capability flags keep working in this release and in every spec version published inside that window.

The practical consequence for anything you read about MCP right now: descriptions of MCP as having stateful connections and sessions, and lists naming Sampling and Roots as client-offered features, are about to be revision-specific rather than wrong-in-general. Under 2025-11-25 they are accurate — servers offer Resources (context and data, for the user or the AI model to use), Prompts (templated messages and workflows for users), and Tools (functions for the AI model to execute); clients may offer Sampling, Roots, and Elicitation; the architecture is hosts, clients and servers over JSON-RPC 2.0 with stateful connections and capability negotiation, taking, as the spec puts it, some inspiration from the Language Server Protocol. Pin your claims to a dated revision, because two of those three client features are on the deprecation list. Do not treat the RC as shipped until it is.

Wiring it up in Claude Code

The mechanics, current as of July 2026, and Claude Code behavior rather than protocol behavior.

Scopes. Three of them. local is the default — stored in ~/.claude.json, current project only, private to you. project lives in .mcp.json at the project root, is checked into version control, and is shared with the team. user is also in ~/.claude.json but applies across all your projects. The scope choice is a security decision as much as an ergonomic one: a project-scoped server is one every collaborator's agent will run.

Adding servers. claude mcp add --transport http <name> <url> for remote; claude mcp add [options] <name> -- <command> [args...] for stdio. OAuth for remote servers goes through the /mcp panel or claude mcp login <name> — and note that non-interactive runs cannot complete OAuth, which matters if you are wiring MCP into CI.

Transport naming. In .mcp.json, the type field accepts streamable-http as an alias for http, deliberately: the MCP specification uses the name streamable-http for this transport, so configurations copied from server documentation work without modification. SSE is deprecated in Claude Code too — use HTTP servers instead, where available.

Which brings up a distinction worth getting right. The spec defines exactly two standard transports: stdio and Streamable HTTP. Clients SHOULD support stdio whenever possible. Streamable HTTP replaced the HTTP+SSE transport from protocol version 2024-11-05, which the spec now calls the deprecated HTTP+SSE transport; it requires a single MCP endpoint supporting both POST and GET, with SSE optional within it. Custom transports are permitted. Claude Code additionally supports a ws WebSocket type — that is a host-specific extension, not an MCP standard transport. It supports neither OAuth nor the --transport flag and is header-auth only. Do not let anyone list it alongside stdio and Streamable HTTP as if it were part of the spec.

Auth, precisely. Authorization is OPTIONAL and applies to HTTP-based transports; implementations using stdio SHOULD NOT follow the authorization spec and should instead retrieve credentials from the environment. It is based on OAuth 2.1 (still an IETF draft, draft-ietf-oauth-v2-1-13) plus RFC 8414, RFC 7591, RFC 9728, and OAuth Client ID Metadata Documents. Servers MUST implement RFC 9728 Protected Resource Metadata; clients MUST implement RFC 8707 Resource Indicators and MUST use PKCE with S256. One update that most 2025 explainers missed: Dynamic Client Registration (RFC 7591) has been demoted to MAY and is included for backwards compatibility — Client ID Metadata Documents are now the recommended path for the common no-prior-relationship case. Expect this section to move again on 2026-07-28.

SDKs, if you are building rather than installing: ten official SDKs under a tiering system. Tier 1 is TypeScript, Python, C#, Go. Tier 2 is Java and Rust. Tier 3 is Swift, Ruby, PHP, Kotlin.

The starting config I would defend. Filesystem, scoped to the directories you actually work in, via Roots if your client supports it. Your code host's own server — github/github-mcp-server with --read-only and a trimmed GITHUB_TOOLSETS — and take the write tools off the table until you have a reason. One browser server, chosen by what you are actually doing: Playwright MCP for automation, Chrome DevTools MCP if you need performance traces or heap profiling. Your database platform's own server, in read-only mode, or nothing. Everything else: deferred, and justified individually against the four gates. Nothing gets alwaysLoad unless you can name the turn on which you would miss it.

That is a smaller list than most roundups give you, and the reason is not tokens. It is that each entry is a maintained thing with a scoping knob and a revocation story, and the entries that did not make it are mostly entries that could not clear Gate 1. If you are assembling a broader agent toolkit, MCP servers are one layer — Claude Code Skills cover a different one, and the Claude Code basics guide covers the rest of the surface.

One last discipline, and it is the article's own premise turned on itself: verify before you install. Not because MCP is dangerous, but because the specific failure mode of this ecosystem is that stale advice keeps working just well enough to look correct.

FAQ