# The MCP ecosystem map

URL: https://www.thedeepfeed.ai/posts/2026-04-30-mcp-ecosystem-map/
Category: Agents
Published: 2026-03-19
Author: the-deep-feed
Tags: mcp, anthropic, agents, infrastructure, protocols
Kind: deep

> Twelve months in, MCP is 97M SDK downloads, 20,000+ servers, six framework attempts, and one unsolved auth problem. Here is who is actually shipping and where the protocol breaks at scale.

## TL;DR

- MCP went from Anthropic spec (Nov 2024) to **97M monthly SDK downloads**, **20,000+ servers**, and Linux Foundation governance in sixteen months.
- **Forty reference servers** in the official repo break into four buckets. Roughly **two-thirds** are thin API wrappers around services that already had OpenAPI specs.
- **Six framework attempts**. FastMCP and the official Anthropic SDKs are converging on production. Cloudflare Agents owns remote hosting. The other three are losing oxygen.
- The protocol breaks at auth, multi-tenant, and token cost. MCP tool calls burn **4–35x more tokens** than equivalent CLI commands.
- The shortlist worth caring about is small. Filesystem, github, postgres, fetch, playwright, context7, and a handful of database connectors. Everything else is noise.

![MCP protocol stack — one client, many servers](/post-images/mcp-ecosystem-map/hero.jpg)

Anthropic announced [the Model Context Protocol on November 25, 2024](https://www.anthropic.com/news/model-context-protocol). Sixteen months later it is governed by the [Linux Foundation under the Agentic AI Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation), Anthropic's Python and TypeScript SDKs do [97 million combined downloads a month](https://digitalapplied.com/), and crawlers find somewhere between 20,000 and 36,000 servers across public GitHub. The official `modelcontextprotocol/servers` repo carries 82,200 stars. Twenty-eight percent of the Fortune 500 has at least one production deployment. Cursor, ChatGPT, Claude Desktop, Claude Code, Windsurf, Zed, Cline, and goose all speak it natively. Google DeepMind adopted it. Microsoft hired Den Delimarsky to work on it.

That is the headline. The texture underneath is messier.

> **97M** SDK downloads per month
>
> **20,000+** servers indexed across public GitHub
>
> **82,200** stars on the reference repo
>
> **28%** of Fortune 500 with at least one production deployment
>
> **0** working auth standards at the protocol level

Most of the 20,000 are weekend projects that wrap an API which already had an OpenAPI spec. Six framework attempts are competing to be the way you build a server, and three of them are losing oxygen. Authentication is unsolved at the protocol level. Token costs run 4–35x higher than the equivalent CLI command. There are at least a dozen marketplace directories, none dominant. The list of MCP servers that solve a problem nothing else solved well is short. Maybe ten.

This is the field map.

## What MCP is, and isn't

The protocol is a JSON-RPC transport with three primitives. Tools are functions a client can call. Resources are read-only blobs the client can fetch. Prompts are templated text the client can render. Servers expose any combination of the three. Clients (Claude Desktop, Cursor, ChatGPT, anything else) discover them, present them to the model, and shuttle calls back and forth. The wire format is JSON-RPC 2.0 over either stdio or Streamable HTTP. Server-Sent Events were the original transport and got [deprecated in May 2025](https://auth0.com/blog/mcp-streamable-http/) after Anthropic concluded the SSE flow was both harder to secure and harder to scale.

The promise is clean. One client, many tools, no per-vendor integration. If you ship an MCP server for your product, you get distribution into every MCP-aware application without per-app work. If you build a client, you get every server.

The limitation is also clean. MCP defines a transport. It does not define semantics. There is no standard schema for "search," no canonical "database query" tool, no agreed shape for streaming partial results. A server author picks tool names, parameter shapes, return formats, and error conventions. Two filesystem servers in the wild expose `read_file` and `readFile` with different argument names. A model trying to use both has to learn both.

This is the same gap that haunted REST in 2010. The transport is solved. The vocabulary is not. Most of the production friction in MCP today traces back to that single fact.

## The taxonomy of forty servers

The reference list is the [`modelcontextprotocol/servers` repo](https://github.com/modelcontextprotocol/servers). It carries roughly forty active reference and partner servers, plus pointers to community ones. The wider ecosystem is much larger. The reference list is what anyone integrating MCP looks at first, and the shape of that list tells you where the protocol's weight actually sits.

Four buckets, with rough distribution from a manual sweep of the reference set:

| Bucket | Share | Example servers | What they do |
|---|---|---|---|
| Thin API wrappers | ~60% | `slack`, `github`, `gdrive`, `google-maps`, `linear`, `notion`, `sentry`, `stripe` | Translate REST endpoints into MCP tools |
| Database / data-source connectors | ~20% | `postgres`, `sqlite`, `redis`, `mongodb`, `supabase` | Expose query interfaces over a data store |
| Tooling and workflow | ~12% | `playwright`, `puppeteer`, `git`, `docker`, `kubernetes`, `sequential-thinking` | Drive a tool the agent does not own |
| Novel integrations | ~8% | `filesystem`, `fetch`, `memory`, `time`, `everything`, `context7` | Solve something the agent could not do otherwise |

The thin-wrappers bucket is the largest and the least interesting. A `slack` MCP server with `send_message`, `list_channels`, and `read_history` is a six-hour project that mirrors three Slack REST endpoints. The same is true of `linear`, `notion`, `sentry`, and most of the SaaS-vendor servers. These exist because the model needs structured tool descriptions to call them, but the underlying integration was already a one-liner with the vendor's SDK. MCP did not enable the integration. It standardised the wrapper.

The database connectors are more useful in practice. A `postgres` MCP server with read-only mode and schema introspection lets an agent answer "what is in the orders table" without a developer pre-writing the query. That capability did not exist before in a form a chat model could discover at runtime. `supabase`, `redis`, and `sqlite` get similar mileage.

The tooling bucket is where MCP starts to matter. `playwright` lets an agent drive a browser. `puppeteer` does the same. `git` lets it commit. `docker` lets it run containers. None of these were possible from a chat client without a wrapper, and the wrappers are non-trivial because they mediate stateful, long-running, sometimes-dangerous processes. The protocol earns its keep here.

Novel integrations are the rare end. `filesystem` exposes the local disk safely. `fetch` is an HTTP client with content extraction. `memory` is a knowledge graph the model writes to across sessions. `context7` (from Upstash) pulls live, version-specific docs into prompts. These are five to ten servers that solve problems no one else had solved well in a model-callable form. They are why the protocol exists.

The honest read of the reference list is that the bottom 60% would be unnecessary if any client supported OpenAPI imports natively. The top 20% justifies the entire protocol.

![Distribution of 20,000+ MCP servers across four buckets](/post-images/mcp-ecosystem-map/server-distribution.jpg)

## Where the frameworks converge

Six framework attempts compete for the right to be how you build a server. Three are converging on production. Three are losing.

| Framework | Language | Transport | Hosted target | Status |
|---|---|---|---|---|
| Anthropic SDKs ([python-sdk](https://github.com/modelcontextprotocol/python-sdk), [typescript-sdk](https://github.com/modelcontextprotocol/typescript-sdk)) | Python, TS | stdio + Streamable HTTP | Anywhere | Reference |
| [FastMCP](https://github.com/jlowin/fastmcp) | Python | stdio + Streamable HTTP | Anywhere | Production default for Python |
| [Cloudflare Agents](https://blog.cloudflare.com/remote-model-context-protocol-servers-mcp/) | TypeScript | Streamable HTTP | Workers | Production for remote |
| [mcp-go](https://github.com/mark3labs/mcp-go) | Go | stdio + HTTP | Anywhere | Niche but solid |
| [mcp-framework](https://github.com/QuantGeekDev/mcp-framework) | TypeScript | stdio | Local | Fading |
| [LiteMCP](https://github.com/wong2/litemcp) | TypeScript | stdio | Local | Fading |

The Anthropic SDKs are the floor. They implement the spec, they ship updates the same week the spec changes, and they are what every other framework ends up wrapping. Most production servers do not use them directly because the ergonomics are low-level. You write JSON-RPC handlers and hand-roll the schema for every tool.

FastMCP is what Python servers actually ship on. The decorator-driven API (`@mcp.tool` over a function with type hints, schema generated from the signature) collapses the boilerplate by an order of magnitude. It carries 12K+ stars and most of the reference Python servers in the official repo are migrating to it. When Anthropic upstreamed parts of FastMCP into the Python SDK in mid-2025, the result was that the two are now nearly the same library at the API layer. The convergence is real.

Cloudflare's Agents SDK owns the remote-hosted slice. Local stdio servers are easy. Hosted multi-tenant MCP servers behind OAuth are not, and the [Workers integration](https://blog.cloudflare.com/remote-model-context-protocol-servers-mcp/) handles the parts (Streamable HTTP, Durable Objects for session state, OAuth via Cloudflare Access) that nobody else wants to build. If a vendor ships a remote MCP server in 2026, the odds are it runs on Workers.

mcp-go covers the Go niche. It exists because tooling-bucket servers that wrap CLIs (`docker`, `kubernetes`, `terraform`) are usually written in Go and embedding a Python or Node runtime is overkill. It is not converging on anything because the niche does not need to converge.

The two losing frameworks are mcp-framework and LiteMCP. Both bet on local-only TypeScript with their own decorator APIs. Both got squeezed when the official TypeScript SDK absorbed similar ergonomics and Cloudflare absorbed the remote story. There is no remaining wedge.

If you are starting today the rule is short. Python: FastMCP. TypeScript local: official SDK. TypeScript remote: Cloudflare Agents. Go: mcp-go. Anything else is a research project.

![Six framework attempts — three converging, three losing oxygen](/post-images/mcp-ecosystem-map/framework-stack.jpg)

## Where the protocol breaks

The number-one finding in the [Zuplo State of MCP report](https://zuplo.com/mcp-report) is that security is the top blocker to adoption. The protocol does not define authentication. Every server author solves it differently. The result is a long list of failure modes that compound at scale.

![The unsolved auth gap — broken handshake at the transport seam](/post-images/mcp-ecosystem-map/auth-gap.jpg)

The counter-take, posted by Bindu Reddy at Abacus, is louder than most:

> RIP MCP!
>
> MCP is dying and we are back to using OAuth and APIs
>
> MCP servers are unreliable, very limited and don't handle auth well
>
> Overall LLMs still struggle with connectors and operations on 3rd party systems
>
> — [@bindureddy](https://x.com/bindureddy/status/2038442206894416312), Mar 30, 2026

[Astrix Security analysed 5,200+ open-source MCP servers in 2025](https://astrix.security/learn/blog/state-of-mcp-server-security-2025/). The finding was that the vast majority store credentials insecurely, often as plaintext API keys in JSON config files that get checked into git. The standard install flow for Claude Desktop is to edit `claude_desktop_config.json` and paste your secrets in. There is no secret manager hook in the spec. There is no per-session token issuance. A leaked config is a permanent compromise.

The OAuth story is in flux. The spec added an OAuth 2.1 profile in mid-2025, but adoption is uneven and most servers still ship API-key auth. Multi-tenant servers that need per-user OAuth flows have to build the entire dance themselves, which is why Cloudflare Access has become the de facto fix.

The SSE-to-Streamable-HTTP migration in May 2025 broke the previous generation of remote servers. Servers that shipped on the old transport had to be rewritten. Clients had to support both for a transition window. [Auth0's writeup](https://auth0.com/blog/mcp-streamable-http/) on why the move happened is the cleanest record of the failure cases SSE had at scale: connection state in the wrong place, session resumption that did not work behind load balancers, auth headers that could not be revoked mid-stream.

Token cost is the other quiet failure. [MyClaw.ai measured](https://myclaw.ai/) MCP tool calls against equivalent CLI commands and found a 4–35x token premium, with three concurrent MCP servers consuming over 70% of the context window before any work began. The protocol forces the model to read every tool description on every turn. A server with 30 tools and verbose descriptions is a permanent context tax. The widely-shared rule of thumb for Claude Code is a five-MCP cap, and most production deployments prefer raw CLI tools when one exists.

Anthropic shipped three API features in November to bend that cost curve. Alex Albert announcing them:

> Alongside the model, today we're launching three very useful API features for building agents that scale to hundreds of tools without context bloat.
>
> - Tool Search Tool
> - Programmatic Tool Calling
> - Tool Use Examples
>
> Here's how they work:
>
> — [@alexalbert__](https://x.com/alexalbert__/status/1993038631901315549), Nov 24, 2025

Programmatic Tool Calling is the one most worth understanding for MCP authors:

> Programmatic Tool Calling
>
> Claude orchestrates tools through code instead of individual round-trips. It writes Python, processes outputs in a sandbox, and controls what enters context.
>
> — [@alexalbert__](https://x.com/alexalbert__/status/1993038668018467013), Nov 24, 2025

![Token cost — MCP calls vs CLI equivalents](/post-images/mcp-ecosystem-map/token-tax.jpg)

> **4-35x** token premium per MCP call vs CLI equivalent
>
> **70%+** of context burned by three concurrent MCP servers before any work begins
>
> **5** MCP server cap recommended for Claude Code

Quality is its own problem. Glama indexes 20,000+ servers. A surprising fraction of them do not work. Tools throw on edge cases. Schemas drift from the docstrings. Error messages are model-confusing. There is no test suite the spec mandates and no certification mark.

Then there are the actual exploits. In 2025 a CVSS 8.9 RCE chain in Claude Desktop's Chrome, iMessage, and Apple Notes connectors hit roughly 10,000 active users. The bug was in the connectors, not the protocol, but the protocol shape (a JSON config that runs arbitrary local processes with full user privilege) made the blast radius worse than it had to be. [Anthropic's Desktop Extensions (`.mcpb`)](https://www.anthropic.com/engineering/desktop-extensions) launched in June 2025 to fix the install UX and got hit with the same class of bug a few months later.

The pattern is consistent. The transport works. The semantics, the auth, and the install pipeline do not.

## The vocabulary problem

The reason "MCP works" and "MCP feels janky" are both true at once is the same fact: the spec defines the wire format and almost nothing else. There is no canonical schema for `search`, no standard shape for `database_query`, no agreed convention for paginated results, no standard error envelope. Two filesystem servers in the wild expose `read_file` and `readFile` with different argument names. A coding agent connected to both has to learn both at runtime.

This is the same gap that haunted REST in 2010 and the same gap OpenAPI was built to close. MCP is at the pre-OpenAPI moment of its protocol life cycle. The transport is solved. The vocabulary is not, and most of the day-to-day friction in MCP today traces back to this single fact. The missing piece is not auth — it is a registry of canonical tool shapes. `search`, `list`, `get`, `create`, `update` should not have fifty different signatures across servers.

A few proposals are circulating. Anthropic's Skills format pushes in the right direction by packaging tool descriptions as reusable, model-readable workflow units. The 2026 spec roadmap includes a "tool semantics" working group that is trying to define canonical shapes for the dozen most common verbs. The Linux Foundation governance gives this effort a credible home that no single vendor could provide. Whether it lands inside twelve months will determine whether the protocol stays clean or splits into incompatible dialects.

## The shortlist that matters

Most of the 20,000 servers are noise. Here is the short list of MCP servers that earn their context tax. Specific repos, specific reasons.

- **`filesystem`** ([repo](https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem)). Sandboxed disk access with allow-listed roots. The reference for how to expose a stateful resource without giving the agent the keys to the machine. Every other filesystem-shaped server should match this contract.
- **`github`** ([github.com/github/github-mcp-server](https://github.com/github/github-mcp-server)). GitHub's own server, hosted at `api.githubcopilot.com/mcp/`. Read-write across issues, PRs, code search, and Actions. The thin-wrapper bucket has one entry that justifies itself, and this is it, because the alternative (`gh` CLI plus a wrapper) doubles your tool count.
- **`postgres`** ([repo](https://github.com/modelcontextprotocol/servers-archived/tree/main/src/postgres)). Read-only by default, schema introspection on connect. The cleanest example of what a database connector should look like. Pair it with read-only credentials and an agent can answer questions about your data without a human writing the query.
- **`playwright`** ([github.com/microsoft/playwright-mcp](https://github.com/microsoft/playwright-mcp)). Microsoft's official server. Drives a real browser with snapshot accessibility trees rather than screenshots, which is why it is cheaper than the alternatives. The right choice for any agent that needs to see the web.
- **`fetch`** ([repo](https://github.com/modelcontextprotocol/servers/tree/main/src/fetch)). HTTP client with Markdown extraction. Solves the "I need this URL's contents" tool that every research agent reinvents.
- **`context7`** ([github.com/upstash/context7](https://github.com/upstash/context7)). Live, version-pinned library docs. Replaces the loop where the model hallucinates an API that changed two versions ago. The single highest-impact server for code agents.
- **`memory`** ([repo](https://github.com/modelcontextprotocol/servers/tree/main/src/memory)). A persistent knowledge graph the model writes to. Imperfect, under-used, and the right shape for anything that needs cross-session state.
- **`supabase`** ([github.com/supabase-community/supabase-mcp](https://github.com/supabase-community/supabase-mcp)). Database, storage, and auth in one server. The reference for how a SaaS vendor should ship an MCP integration when the product has more than one resource type.
- **`sequential-thinking`** ([repo](https://github.com/modelcontextprotocol/servers/tree/main/src/sequentialthinking)). A tool that asks the model to write its plan into structured steps. Looks like prompt engineering until you watch a weaker model use it and the failure rate halves.
- **`anthropic-skills`** ([github.com/anthropics/skills](https://github.com/anthropics/skills)). Not strictly an MCP server. The Skills repo packages reusable workflows that load on demand and is the model the rest of the ecosystem is converging toward. Worth tracking because the Skills format is what MCP tool descriptions probably become next.

That is the list. Ten servers. Add three more for your specific stack (your error tracker, your data warehouse, your design tool) and the rest of the 20,000 is decoration.

### The shortlist, ranked by what it enables

| Server | Hosted by | Why it earns its context tax |
|---|---|---|
| `filesystem` | Anthropic / official | Sandboxed disk access with allow-listed roots |
| `github` | GitHub | Read-write across issues, PRs, code search, Actions |
| `postgres` | Anthropic / official | Read-only by default with schema introspection |
| `playwright` | Microsoft | Snapshot accessibility tree for real browser automation |
| `fetch` | Anthropic / official | HTTP client with content extraction |
| `memory` | Anthropic / official | Cross-session knowledge graph the model writes to |
| `context7` | Upstash | Live, version-specific docs into prompts |
| `sequential-thinking` | Anthropic / official | Forces structured plan-write; halves failure rate on weaker models |
| `linear` | Linear | Multi-resource SaaS done right |
| `stripe` | Stripe | The reference for how a payments vendor should ship MCP |

The 10-server shortlist is the actual product. The other 19,990 are README clutter, and registries that do not curate make discovery worse, not better.

## What happens next

The forecast is that MCP becomes the LSP of the agent stack. Boring infrastructure that everyone speaks and nobody markets. The Linux Foundation governance, the Anthropic+OpenAI+Google joint backing, the SDK download curve, and the lack of a serious competitor all point the same way. There is no second standard with momentum. There is no faction making the case for an alternative wire format. Even the people who hate the auth story are working inside MCP rather than around it.

The risk is that auth fragments the ecosystem before the standardisation completes. If multi-tenant remote MCP needs three or four incompatible OAuth profiles by the end of 2026, the install pipeline gets worse rather than better, and the friction tax pushes vendors back to bespoke chat-client integrations. The Linux Foundation has the right people to prevent this but no track record on protocol auth specifically. The 2026 spec roadmap has an OAuth 2.1 dynamic-client-registration profile that is supposed to fix it. Watch that one closely.

The other thing to watch is what happens to the 19,000 weekend-project servers. Three things can happen. They get garbage-collected by registries that start enforcing quality. They get absorbed by a smaller number of canonical servers per category. Or they sit there, ranked by stars, polluting discovery. The bet is on the first two, because Anthropic, Microsoft, and GitHub all have an interest in a clean catalog and the registries that serve them.

The category is past its hype phase and into its consolidation phase. The architecture has won. The shortlist is small and stabilising. The remaining work is the unglamorous middle of any protocol's life: schemas, auth, certification, and the slow death of the wrappers that should not have been written.

Three or four reference frameworks. A few hundred servers worth using. One unsolved auth problem. That is what the field looks like in twelve months.

> **3-4** reference frameworks worth tracking
>
> **~200** servers worth using out of 20,000
>
> **1** unsolved auth problem blocking the next phase

## Sources

- [Anthropic — Introducing the Model Context Protocol](https://www.anthropic.com/news/model-context-protocol)
- [GitHub — modelcontextprotocol/servers](https://github.com/modelcontextprotocol/servers)
- [GitHub — modelcontextprotocol/python-sdk](https://github.com/modelcontextprotocol/python-sdk)
- [Anthropic — Desktop Extensions (.mcpb)](https://www.anthropic.com/engineering/desktop-extensions)
- [Linux Foundation — Agentic AI Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation)
- [Cloudflare — Build remote MCP servers on Workers](https://blog.cloudflare.com/remote-model-context-protocol-servers-mcp/)
- [jlowin/fastmcp](https://github.com/jlowin/fastmcp)
- [Zuplo — State of MCP 2025](https://zuplo.com/mcp-report)
- [Auth0 — MCP moves away from SSE](https://auth0.com/blog/mcp-streamable-http/)
- [Astrix Security — MCP security analysis](https://astrix.security/learn/blog/state-of-mcp-server-security-2025/)
- [PulseMCP directory](https://www.pulsemcp.com/)
- [GitHub MCP Registry](https://github.com/mcp)
- [GitHub — github/github-mcp-server](https://github.com/github/github-mcp-server)
- [GitHub — microsoft/playwright-mcp](https://github.com/microsoft/playwright-mcp)
- [GitHub — anthropics/skills](https://github.com/anthropics/skills)
- [MyClaw.ai — MCP token cost analysis](https://myclaw.ai/)

---

Canonical: https://www.thedeepfeed.ai/posts/2026-04-30-mcp-ecosystem-map/
Site: https://www.thedeepfeed.ai
Full corpus: https://www.thedeepfeed.ai/llms-full.txt