The State of MCP Servers: what 1,157 tools across 126 servers actually tell us

Everyone has an opinion about where the Model Context Protocol is going. Almost nobody has counted what's actually shipped. So I did.

This is based on the full dataset behind this directory: 126 servers, 1,157 individual tools — the real name and description of every capability each server exposes, not marketing copy. Here's what the numbers say, and what I think they mean.

MCP is still overwhelmingly local

84% of servers run locally over stdio. Only 14% are HTTP and a rounding-error 2% are SSE. If you read the conference talks, you'd think remote, hosted MCP was the present. It isn't — it's the future the ecosystem keeps talking itself into.

That matters because local-first is a feature, not a limitation. A stdio server runs on your machine, sees your filesystem, uses your already-authenticated CLIs, and sends nothing to a third party. The push to "remote everything" trades that away for convenience. Some of that trade is worth it (sharing, scaling). A lot of it isn't, and the data suggests builders quietly agree.

The "ecosystem" is really a CRUD layer

Count the verbs in those 1,157 tool names and the long tail collapses fast: get (240), list (167), create (116), search (92), delete (43), update (42). The overwhelming majority of MCP tools are thin CRUD wrappers over an existing API.

This is not a criticism — it's the correct first move. But it means the differentiation between two servers for the same product is usually not "what can it do." It's the boring stuff: which transport, what auth, whether writes are guarded, and whether it's still maintained. That's exactly the metadata most directories don't surface, and it's why "best X mcp server" is a harder question than it looks.

Tools-per-server is small — until you stack them

The median server exposes 10 tools; the average is 9.2; the most tool-heavy single server has 19. No single server we track exceeds 40 tools.

That sounds comfortable until you remember nobody runs one server. Install five and you're at ~46 active tools — past the point where Cursor's selection starts to degrade. The tool budget is a portfolio problem, not a per-server one, and almost no tooling treats it that way. (We built a Config Doctor precisely because of this number.)

"Official" is winning, but not the way you'd guess

Two-thirds of the servers we track (67%) are first-party — built by the vendor whose product they wrap. That share is climbing as Stripe, GitHub, Atlassian, Linear and the rest ship their own.

The naive read is "always use the official one." The real read is more interesting: official servers win on auth and maintenance, not on capability. A community server is often just as capable and sometimes more focused. Where the vendor server pulls ahead is the unglamorous half — OAuth done right, kept current, security reviewed. When you pick official, that's what you're actually buying.

What I'd watch next

• Auth is the real battleground. 63% of servers want an API key, 21% need nothing, 17% use OAuth. As MCP moves toward agents acting on your behalf, the no-auth/api-key majority is going to feel increasingly uncomfortable. OAuth-with-scopes is where this has to go.
• Remote will grow, slowly. Not because local is bad, but because sharing a working setup across a team is painful, and hosted servers solve that. Watch HTTP's share, not the keynotes.
• The shakeout hasn't happened. Multiple competing community servers for Postgres, GitHub, browsers — with no clear winner — is a sign of an early market, not a mature one.

If you take one thing from the numbers: MCP in mid-2026 is a young, local-first, CRUD-shaped ecosystem where the interesting decisions are about trust and maintenance, not features. Pick accordingly.

Figures are computed from the servers indexed in this directory and refresh as the data does. Want the raw breakdown? See the live data report.