MCP Server Statistics That Matter to Software Developers

The Model Context Protocol went from an Anthropic blog post to a de facto integration layer in roughly eighteen months. That is a short enough window that most of the ecosystem numbers you read are already stale, and long enough that the honest ones are starting to tell a consistent story. This piece is for engineers and buyers trying to size MCP before committing a roadmap to it: how many servers actually exist, which transports and SDKs are winning, what tool calls cost in milliseconds, and where the security debt is piling up.

None of what follows argues for or against MCP. It argues for knowing the numbers before you decide.

Registry Growth Has Outrun the Spec

Anthropic published MCP as an open standard on November 25, 2024, with Python and TypeScript SDKs and a handful of reference servers for Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer. The adoption curve bent sharply once OpenAI announced support on March 26, 2025 across its Agents SDK, Responses API, and ChatGPT desktop app.

By late 2025, the ecosystem was no longer a side project. Anthropic's own ecosystem update put monthly SDK downloads past 97 million and active public servers above 10,000. The reference monorepo on GitHub carries more than 91,000 stars and 11,800 forks, which is engagement at the scale of a popular framework rather than a nascent protocol.

Server counts diverge wildly by directory. The Glama registry, which indexes and scores servers automatically, reports 97,619 servers and 29,561 remote connectors as of October 11, 2026. That is a superset of the official registry and includes a long tail of community wrappers. Any single figure here is a lower bound at best.

Where the Servers Actually Live

The published counts flatter the ecosystem more than they should. A production survey summarized in community coverage found that 86% of MCP servers run on developer laptops and only about 5% in production environments. That matches what buyers encounter: a huge library of local prototypes, a much smaller set of servers hardened for multi-tenant hosting. If you are shortlisting third-party servers, assume you will be the first team to deploy most of them remotely.

Transport Breakdown: stdio, SSE, and Streamable HTTP

MCP's transport story has moved faster than most docs. The original spec defined two transports: stdio for local subprocess communication and HTTP+SSE for remote. The standalone HTTP+SSE transport was deprecated in the 2025-03-26 revision and replaced by Streamable HTTP, a single-endpoint design that accepts POST and GET and can respond with either plain JSON or a text/event-stream body. SSE as a mechanism survived inside the new transport. SSE as a transport did not.

Two years in, stdio still dominates local use for the reason it always has: no network layer, no auth to configure, no port to open. Streamable HTTP is where every new remote server is going, because stdio tops out at one client per process and provides no transport-layer authentication. If you are evaluating a server for a shared agent, Streamable HTTP is effectively the only answer, and session management via the Mcp-Session-Id header is the piece most implementations get wrong first.

Latency and Tool-Call Overhead

Per-call overhead is small enough that transport choice is rarely the bottleneck, but it is not zero. A published benchmark on real tool calls reports p50 of roughly 0.3 to 1 ms for a warm stdio call and 5 to 10 ms for Streamable HTTP in the same datacenter, with p95 tails of 2 to 3 ms and 15 to 25 ms respectively. Stdio cold starts, which happen once per IDE session when the subprocess is spawned, land in the 250 to 400 ms range.

For most agent workflows the LLM round-trip dominates, so Streamable HTTP's extra few milliseconds per call vanishes into the noise. The place latency bites is sequential tool chains: twenty calls at 20 ms each is 400 ms of pure transport. If your agent planner likes to decompose work, batch or parallelize at the client.

SDK Language Share and Client Support

The two SDKs Anthropic shipped at launch, Python and TypeScript, still account for essentially all of the download volume behind the 97M monthly figure. Community SDKs now cover Go, Rust, C#, Java, Kotlin, Swift, and others, but their combined share is a rounding error against the two originals. Teams building production servers tend to default to TypeScript for anything that will run in Node alongside a Next.js or Nest app, and Python for anything that will sit next to existing data or model code. If you are planning a long-lived server, that split still looks right. For a view on when to pick a stricter type system instead, our write-up on TypeScript template literal types argues the case for making the compiler enforce the contract.

Client support consolidated faster than most people expected. Claude Desktop and Claude Code remain the reference hosts. Cursor, Windsurf, and VS Code with GitHub Copilot all treat MCP as a first-class feature rather than an extension. VS Code enforces a 128-tool-per-request cap and introduces "virtual tools" above a threshold, which is a detail worth knowing before you install a dozen servers in the same workspace. ChatGPT added MCP behind a Developer Mode toggle. The practical rule: wire a server once, and the same binary runs in every major host without changes.

Security Is Where the Numbers Get Uncomfortable

Three independent studies converge on the same conclusion: the median community server was not written with a threat model. An offensive-security assessment by Equixly, cited in the MCP Guardian paper, found that 43% of tested MCP server implementations were susceptible to command injection. A larger survey of 2,614 servers by Endor Labs reported 82% exposed to path traversal, 67% to code injection, and 34% to command injection. The same report documents CVE-2025-6514 in the mcp-remote package: CVSS 9.6, OS command injection, in a package downloaded more than 437,000 times.

Transport-layer authentication is worse. A dynamic assessment of internet-facing MCP servers found 380 of 414 audited servers with at least one authentication weakness, consistent with roughly a 92% OAuth absence rate at discovery time. Translation: most of what is publicly reachable right now has either no auth or a token scheme that will not survive a review.

None of this makes MCP uniquely dangerous. It makes it an API surface that inherited the usual sins of fast-moving ecosystems with none of the usual guardrails yet. Before you expose an MCP server to an agent that can act on behalf of users, the controls that matter are familiar: input validation at the tool handler, allow-listed shell commands or no shell at all, OAuth 2.1 with scoped tokens, request-level audit, and the same prompt-injection defenses we outlined in our agentic AI SOW guidance. For teams that would rather own the full stack than inherit community servers, our note on in-house AI rollouts covers the tradeoffs. If you are weighing a dedicated pod against piecing it together, the dedicated team cost numbers are the place to start.

What the Numbers Mean for a Buyer

Three things fall out of the data if you are deciding whether to adopt MCP this quarter. First, the standard itself has effectively won. Every host that matters speaks it, both frontier labs ship SDKs for it, and the spec is on a predictable revision cadence. Second, the server ecosystem is wide but shallow: tens of thousands of listings, a few hundred that are production-ready, and a very small set with any kind of independent security review. Third, remote serving is still the frontier. Streamable HTTP is the right transport, OAuth is the right auth, and both are young enough that most community implementations get the details wrong.

If you are a buyer, the sensible posture is to treat MCP as the integration layer, not the implementation. Use it to connect agents to your systems, write the servers that touch your data yourself, and vet any third-party server you host as carefully as you would a dependency on your production path. The protocol is boring in the way standards are supposed to be boring. The code behind it is not boring yet. Our AI development services page is the right starting point if you want that work done against a scope rather than a vibe.