For most of MCP’s short life, stdio has been the default answer. It is simple, local, and easy to reason about: start a process, pipe JSON messages through standard input and output, and let the agent call tools. That model still matters.
But the directory data is shifting. AgentNDX now tracks 1,077 curated MCP servers. Of those, 549 use stdio and 524 use HTTP. That puts HTTP at 48.7% of the index, close enough that the old mental model of “MCP equals local stdio server” no longer holds.
The current split
Here is the transport breakdown in the AgentNDX directory:
| Transport | Servers | Share |
|---|---|---|
| stdio | 549 | 51.0% |
| HTTP | 524 | 48.7% |
| SSE | 4 | 0.4% |
The headline is not that stdio is dead. It is not. The headline is that HTTP has almost caught it.
That matters because transport choice says a lot about where MCP is being used. stdio is the local development path. HTTP is the hosted, production, multi-user path. When the split moves toward HTTP, it usually means teams are wiring MCP into services, dashboards, cloud environments, and internal platforms instead of keeping agents boxed inside one developer’s laptop.
The monthly pattern is sharper
The overall count hides the speed of the shift. New listings by month show HTTP taking over recent intake:
| Month | HTTP | stdio | SSE |
|---|---|---|---|
| April 2026 | 7 | 215 | 0 |
| May 2026 | 81 | 142 | 2 |
| June 2026 | 154 | 92 | 0 |
| July 2026 | 175 | 51 | 2 |
| August 2026 | 107 | 49 | 0 |
April was still overwhelmingly local. By June, HTTP had flipped the ratio. July widened the gap. August is partial, but it is following the same direction.
That is the real story. The installed base still shows stdio slightly ahead because early MCP servers were built for local tools like Claude Desktop, coding assistants, database clients, and one-user automation. Newer servers are arriving with HTTP first because their use cases are different.
Where HTTP is showing up
HTTP is strongest in categories that already look like production infrastructure:
| Category | HTTP servers |
|---|---|
| Data | 224 |
| Infrastructure | 111 |
| Productivity | 90 |
| Code | 22 |
| Media | 20 |
| Payments | 20 |
Data leads by a lot. That includes hosted database services, analytics platforms, warehouses, search systems, and APIs that agents need to query from somewhere other than a local shell. Infrastructure is next, which fits the pattern: cloud control planes, deployment tools, observability systems, and internal developer platforms are rarely single-user local processes.
You can see the same direction in examples from the directory. AgentNDX, Microsoft Fabric, Google Cloud Spanner, Axiom MCP, Backstage MCP, and Google Cloud Run all use HTTP. These are not toy integrations. They are services that make more sense as remote endpoints.
stdio still owns local agent work
There is a reason stdio remains at 51% of the index. It is the fastest way to ship an MCP server for a developer tool. No hosted endpoint. No deploy pipeline. No public URL. No account system unless the underlying API needs one.
That is why stdio remains common in code, AI, media, and local web automation. Playwright MCP, Firecrawl MCP, and GitHub MCP all fit the local-first pattern in different ways. Some call remote APIs behind the scenes, but the MCP surface itself runs as a local process that the agent can start and manage.
For individual developers, stdio is still hard to beat. If you are testing a server locally or giving a coding agent access to a narrow tool, stdio keeps the integration small. The tradeoff comes later, when more than one user or agent needs the same capability.
Why HTTP keeps gaining ground
HTTP solves the problems that appear once MCP leaves the laptop.
A hosted server can be shared across teams. It can sit behind normal auth. It can log requests, rate limit traffic, expose health checks, and fit into existing cloud operations. It can also serve agents that cannot spawn local processes, which matters for browser-based agents, server-side agents, and workflow runners.
The auth data points the same way. In the current index, 643 servers use API keys and 245 use OAuth. OAuth is only 22.7% of the directory, but it maps naturally to HTTP-based services where an agent acts on behalf of a user inside Slack, Google Workspace, GitHub, Salesforce, or another account-bound platform.
None of this makes stdio obsolete. It just means MCP is splitting into two normal deployment modes: local connectors for developer machines and HTTP services for shared systems.
What builders should do
If you are building an MCP server for a local tool, start with stdio. It is easier to install, easier to debug, and easier for developers to trust because it runs under their own permissions.
If you are building for a SaaS product, cloud platform, internal service, or paid API, start with HTTP. You will probably need user accounts, logs, health checks, rate limits, and a deploy target anyway. In that world, wrapping the capability as a local process first can create more work than it saves.
The best servers may support both. stdio gives developers a low-friction local path. HTTP gives teams a production path. But if you only have time for one, pick the transport that matches where the agent will actually run.
FAQ
Q: Is stdio going away for MCP servers? A: No. stdio is still the simplest transport for local tools, coding agents, and single-user workflows. It remains slightly ahead in the full AgentNDX index.
Q: Why are newer MCP servers using HTTP more often? A: Newer servers are more likely to be hosted services, cloud tools, internal platforms, or SaaS integrations. Those need deployment, auth, monitoring, and shared access, which fit HTTP better than a local process.
Q: What happened to SSE? A: SSE is nearly absent in the current directory. AgentNDX tracks only 4 SSE servers out of 1,077. For most builders, the choice is now stdio or HTTP.
Q: Which transport should I choose for a new MCP server? A: Choose stdio for local developer tooling. Choose HTTP for hosted products, team use, production agents, and services that need account-based access.