MCP in 2026: 475M SDK Downloads a Month, 39,492 Servers in a Registry Still in Preview, and 12 Gateways Selling the Same 3 Features

The way most agents reach my sandboxes now is an MCP tool call: a client lists my tools, a model picks one, a microVM boots. (I run PandaStack, a Firecracker microVM cloud for agent code execution; that is the affiliation.) A month ago I wrote about MCP's security and concluded the protocol was fine and the ecosystem was not. This post is the operating half of that picture: who governs it, how many servers exist and where, which SDK speaks which spec, what the clients and the twelve gateways selling "MCP governance" actually do and charge, why a fully loaded agent burns 55,000 tokens before its first word, and what a stateless, authenticated, traceable server looks like on the current SDK. Every number is from a package registry API, a spec page or a vendor's own documentation, fetched this week, and where I ran something I say so.

Who owns the protocol now

Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation on 9 December 2025, alongside Block's goose runtime and OpenAI's AGENTS.md; the platinum members were AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI, and the press release counted "more than 10,000 published MCP servers". Google's A2A, already a Linux Foundation project since June 2025, joined the foundation on 17 August 2026, and Solo.io's agentgateway is listed as a hosted project too. I covered the A2A side separately.

The governance that came with the move is the more useful part. The 2025-11-25 revision formalised a governance structure, working groups, and an SDK tiering system with maintenance commitments (SEP-932, SEP-1302, SEP-1730). The 2026-07-28 revision added a feature lifecycle: anything deprecated stays in the spec for at least twelve months, with a public registry of deprecated features (SEP-2596). The maintainers published a roadmap in March (transport scalability, agent communication, governance, enterprise readiness) and a second one in August adding server-initiated events, an HTTP-native transport for local servers, DPoP, workload identity federation and "progressive tool discovery". None of it is glamorous; all of it is what a protocol needs before a bank will build on it.

Three revisions in sixteen months, and the one that did not exist

I went looking for a 2026-03-26 revision because I had seen it quoted. It does not exist: the dated revisions are 2025-03-26, 2025-06-18, 2025-11-25 and 2026-07-28, and the March 2026 items people remember are blog posts about extensions and tool annotations. The authorization changes I covered in the security post; here is what the two most recent revisions did to the operating model.

Revision	What changed for operators	Source
2025-06-18	Structured tool output, elicitation, servers become OAuth resource servers, resource indicators mandatory	changelog
2025-11-25	Experimental tasks (SEP-1686), URL-mode elicitation (SEP-1036), Client ID Metadata Documents (SEP-991), OIDC discovery, icons, sampling with tools, JSON Schema 2020-12 default, SDK tiers	changelog
2026-07-28	Sessions and Mcp-Session-Id removed (SEP-2567); initialize handshake removed, every request carries version and capabilities in _meta (SEP-2575); mandatory Mcp-Method and Mcp-Name headers (SEP-2243); ttlMs and cacheScope on list results (SEP-2549); tasks moved to an official extension (SEP-2663); server-initiated requests replaced by multi round-trip results (SEP-2322); SSE resumability removed; OpenTelemetry _meta keys (SEP-414); Roots, Sampling and Logging deprecated (SEP-2577)	changelog

The July revision is the one that matters for operators. The transport page now describes a single POST endpoint where "each request is its own POST", answered with JSON or a request-scoped SSE stream: no GET stream, no session header, no Last-Event-ID. The release post states the motivation: requests "can now land on any server instance behind plain round-robin load balancers without shared storage". The server-card idea from the March roadmap, capabilities discoverable without a live connection, landed as a mandatory server/discover RPC returning versions, capabilities and identity in one cacheable call. The headers are what gateway vendors wanted: a proxy can read Mcp-Method: tools/call and Mcp-Name: delete_repository and enforce policy without parsing JSON, and the server must reject any request whose headers disagree with its body with error -32020.

The SDKs are not all where the spec is

This is the finding I did not expect. On 2 October both flagship SDKs cut releases, and they speak different protocols. The Python package mcp 2.3.0 declares LATEST_PROTOCOL_VERSION = "2026-07-28"; the npm package @modelcontextprotocol/sdk at its latest tag, 1.32.0, declares 2025-11-25. I installed both and checked. The 2026-07-28 TypeScript implementation lives in new split packages, @modelcontextprotocol/server, client, node, express, versioned 2.x, ESM-only, Node 20 or later; the monolithic package gets critical updates "for at least six months". Download counts from the npm API and pypistats on 5 October show where the installed base is.

Package	Version, date	Protocol	Downloads, week to 3 Oct	Source
@modelcontextprotocol/sdk (TS, v1)	1.32.0, 2 Oct 2026	2025-11-25	74,981,440 (243.99M in the month)	npm API
@modelcontextprotocol/server (TS, v2)	2.3.0, 2 Oct 2026	2026-07-28	10,001,814	npm API
@modelcontextprotocol/client (TS, v2)	2.x	2026-07-28	7,269,221	npm API
mcp (Python)	2.3.0, 2 Oct 2026	2026-07-28	59,791,459 (231.33M in the month)	pypistats
fastmcp (Python, third party)			13,513,790	pypistats
mcp-remote (npm bridge, CVE-2025-6514 in 2025)			716,048	npm API
Go / C# / Rust / Ruby / Java SDKs	v1.8.0 / v2.2.0 / rmcp 3.5.0 / v1.6.1 / v2.0.1	TS, Python, Go, C# support 2026-07-28; Rust in beta		GitHub releases, release post

The maintainers' claim of "close to half-a-billion downloads a month" checks out: npm and PyPI alone sum to 475 million. And the v1 TypeScript package outnumbers the v2 server package seven to one, so most JavaScript MCP servers in the wild still negotiate sessions and your gateway will handle both protocol eras for a year. Python's 2.x renamed FastMCP to MCPServer; Go made statelessness an opt-in. Note also mcp-remote at 716,000 weekly downloads fifteen months after its critical RCE: the installation habit has not changed.

Registries: one official and still in preview, three unofficial and much larger

The official registry launched in preview on 8 September 2025, and the about page still carries the preview notice this week: breaking changes or data resets may occur before general availability. The API is frozen at v0.1, the codebase tagged v1.8.1 in August, the working group led by Stacklok with PulseMCP, TeamSpark and Ravenmail. It is deliberately narrow: server.json metadata, namespaces verified by GitHub account or DNS, pointers to npm, PyPI, Docker Hub or a remote URL, no private servers, security scanning delegated to package registries and aggregators, a codebase "not designed for self-hosting". A feed for marketplaces, not a marketplace. It is also much bigger than its label suggests. I paged the whole /v0/servers API on 5 October, 395 pages filtered to latest versions, and counted 39,492 distinct servers, 39,015 active and 477 deprecated, up from the "more than 10,000" the foundation quoted in December. 24,731 publish a remote endpoint, 24,242 as Streamable HTTP and 1,105 still on the deprecated SSE transport; the rest point at packages, 10,742 on npm, 4,218 on PyPI, 1,445 .mcpb bundles and 1,056 OCI images. The curve is steep: 14,724 of those latest versions were published in September 2026 alone, against 347 in the registry's first month. The walk took most of an hour; the API is built for aggregators syncing hourly, not for me.

The unofficial directories are larger still because they index GitHub rather than publications. Glama showed 96,340 servers on 5 October, Smithery, now part of Arcade.dev, "25,098+", and PulseMCP 21,747. Docker's curated MCP Catalog is at the other end with "300+ verified servers" as container images. The gap between 96,340 and 300 is the gap between "someone pushed a repo" and "someone is accountable for it", and the official registry's 39,492 sits in between: namespace-verified, so you know who published it, and otherwise unvetted, so you know nothing else. That gap is the reason the enterprise gateways exist.

Private registries are where the enterprise story is. Microsoft positions Azure API Center as "a private, enterprise-ready MCP server registry", Kong's is in tech preview, and Windows has an On-device Agent Registry with an odr.exe tool, per-agent consent, Intune control and a File Explorer connector, still marked prerelease in June 2026 documentation. The official registry's OpenAPI spec is meant to be the interface these implement: one schema, many catalogues, each with its own curation.

Every client, and the twelve gateways behind them

MCP support is table stakes in clients; the differences are in the enterprise knobs. VS Code declared MCP generally available in version 1.102 on 9 July 2025 with a curated gallery and organisation-wide control through GitHub Copilot policies. Cursor supports stdio, SSE and Streamable HTTP, uses fixed OAuth redirect URLs, and lets team admins distribute servers through a team marketplace and enforce allowlists by command pattern for local servers and URL pattern for remote ones. Gemini CLI does all three transports, OAuth with RFC 9207 issuer validation, includeTools and excludeTools filters and a per-server trust flag that bypasses confirmations. Copilot Studio supports tools and resources only and requires generative orchestration. Claude's connectors directory opened on 14 July 2025, and Claude Code ships managedMcpServers, allowedMcpServers and deniedMcpServers for administrators plus a warning when a single tool result exceeds 10,000 tokens and a 25,000-token default cap. OpenAI's Apps SDK is built on MCP servers: its documentation requires a Streamable HTTP endpoint, typically at /mcp, built with the official TypeScript or Python SDK, with authorization enforced in the server on every request; the examples repository is MIT-licensed. One protocol, six vendors, six policy models. If you administer more than one of these, the only place to enforce a single policy is a gateway.

Every product below does some combination of three things: terminate authentication and inject credentials, apply per-tool access policy and rate limits, and emit logs and traces. Several add a catalogue. Prices from each vendor's page this week; "quote" means no public price.

Product	What it does for MCP	Licence or price	Source
Azure API Management	Expose REST APIs as MCP tools or front existing MCP servers; JWT, rate limits, IP filters; tools only, no resources or prompts; API Center as registry	All tiers Developer to Premium v2; per-tier pricing	Microsoft Learn
AWS AgentCore Gateway	Lambda, OpenAPI and Smithy targets become MCP tools; passthrough to MCP and A2A; inbound OAuth, outbound credential injection; semantic tool search	$0.005 per 1,000 invocations; $0.025 per 1,000 searches; $0.02 per 100 tools indexed per month	AWS pricing
Kong AI Gateway	AI MCP Proxy plugin: passthrough or REST-to-MCP conversion, OIDC and key auth, tool ACLs, logging	Kong Gateway 3.12+, Enterprise only; Konnect Plus from $25 per month plus usage, 1M AI requests included, $200 per extra million	Kong docs, pricing
Cloudflare	createMcpHandler stateless servers on Workers (the stateful McpAgent is deprecated); MCP Server Portals aggregate servers behind Access with per-user policy, open beta since 26 Aug 2025	Workers free 100,000 requests per day; paid $5 per month for 10M, $0.30 per extra million; Portals free up to 50 seats	Workers pricing, Portals
agentgateway (Solo.io, Linux Foundation)	Rust data plane for MCP, A2A and LLM traffic; JWT and OAuth, RBAC per tool, OpenTelemetry	Apache-2.0; v1.6.0 on 2 Oct 2026; 5,172 stars	GitHub
Docker MCP Gateway and Toolkit	Runs catalogue servers as containers, secrets via Docker Desktop, OAuth flows, profiles per client	MIT; v0.44.1; needs Docker Desktop 4.59+ or DOCKER_MCP_IN_CONTAINER=1; catalogue 300+	GitHub
Obot	Gateway plus catalogue with SSO/OIDC, RBAC, audit export, shadow-agent discovery	MIT Community edition free; Cloud and Enterprise by quote; 1,089 stars	obot.ai
Lasso MCP Gateway	Python proxy reading mcp.json; PII and secret masking plugins (Presidio)	MIT; 391 stars; last commit 22 Jan 2026	GitHub
Zuplo	Hosted MCP gateway: auth, routing, virtual servers	Free tier for development; Builder $25 per month with 5 MCP users and 10,000 tool invocations; Enterprise from $1,000 per month	Zuplo pricing
Composio	Hosted tool catalogue, "1,500+ toolkits", bring your own MCP servers	Hobby free with 100,000 tool calls per month; Pro $29 per month, $0.0003 per call over	Composio pricing
IBM ContextForge	Gateway, registry and proxy for MCP, A2A, REST and gRPC with plugins	Apache-2.0; v1.0.11; 4,571 stars	GitHub
Microsoft MCP Gateway	Reverse proxy for "session-aware stateful routing" of MCP servers on Kubernetes	MIT; C#; 859 stars	GitHub

Three observations. The hyperscalers price this as API management, which is what it is: AgentCore's $0.005 per thousand calls is a Lambda-shaped number, and Azure folds MCP into tiers you already pay for. The open-source field has sorted itself: agentgateway has a foundation home and a release cadence, Docker has distribution, and the smaller projects are pivoting to products (Obot) or going quiet (Lasso's last commit was January). And the 2026-07-28 revision quietly obsoleted a product category: Microsoft's gateway exists to do sticky, session-aware routing, and the current spec has no sessions to be sticky about. Any gateway whose value was holding the stream and the session for you has a year of deprecation window to find a new reason to exist; the survivors will be doing identity, policy and audit, the boring API-gateway job platform teams have done for fifteen years.

Tool overload is a context problem, and the fixes are converging

The ecosystem's growth created its own failure mode. Anthropic's tool search documentation states that a typical five-server setup (GitHub, Slack, Sentry, Grafana, Splunk) consumes about 55,000 tokens of tool definitions before the model does any work, and that selection accuracy "degrades once you exceed 30 to 50 available tools". Their November 2025 engineering post measured the fix: deferring tool definitions and loading them through a search tool cut a 77,000-token preamble to 8,700, and raised MCP-evaluation accuracy from 49 to 74 percent on Opus 4 and from 79.5 to 88.1 percent on Opus 4.5. A week earlier, code execution with MCP made the stronger version of the argument: present servers as a filesystem of typed functions, let the model write code against them in a sandbox, and a workflow that moved 150,000 tokens through the context drops to 2,000, a 98.7 percent reduction, because intermediate results never reach the model. Cloudflare had published the same idea as Code Mode on 26 September 2025, converting MCP schemas into a TypeScript API executed in a V8 isolate: "LLMs are better at writing code to call MCP, than at calling MCP directly."

By this autumn the pattern is everywhere. Claude Code enables MCP tool search by default once definitions pass a share of the context window; AgentCore Gateway meters semantic tool selection so "agents can use thousands of tools while minimizing prompt size"; the spec asks servers to return tools/list in deterministic order "to improve LLM prompt cache hit rates" and to attach a ttlMs; the August roadmap lists progressive tool discovery. The code-execution variant touches my business directly, because the code has to run somewhere isolated from the tools' credentials. I have written about that boundary before; a sandbox executing model-written code against a hundred MCP bindings is the most privileged process in the architecture.

Running one in production on the current SDK

Here is the shape of a server I would put behind a load balancer today, on the Python SDK that speaks 2026-07-28. It is stateless, so any replica can take any request; it verifies RS256 access tokens offline against the identity provider's JWKS and refuses tokens not issued for its own resource URL; it publishes protected-resource metadata so clients can discover the authorization server; it exposes an unauthenticated /healthz for the balancer; it tells clients and gateways that tools/list is cacheable for an hour; and it wraps every request in an OpenTelemetry span parented from the traceparent the client puts in _meta.

# server.py: a minimal production-shaped MCP server on the 2026-07-28 protocol.
# Pinned: mcp==2.3.0 (speaks 2026-07-28), uvicorn==0.54.0, PyJWT==2.15.1 with the crypto extra.
# Stateless Streamable HTTP, bearer-token auth via the IdP's JWKS, a public /healthz, and
# OpenTelemetry spans per request. Any pod behind a round-robin load balancer can serve any call.
import os
import jwt                                   # PyJWT
from jwt import PyJWKClient
from starlette.requests import Request
from starlette.responses import JSONResponse
from mcp.server.mcpserver import MCPServer
from mcp.server.auth.provider import AccessToken, TokenVerifier
from mcp.server.auth.settings import AuthSettings
from mcp.server.caching import CacheHint
from mcp.server.transport_security import TransportSecuritySettings
from mcp.server._otel import OpenTelemetryMiddleware

ISSUER   = os.environ["MCP_OAUTH_ISSUER"]        # e.g. https://login.example.com/realms/agents
JWKS_URL = os.environ["MCP_OAUTH_JWKS_URL"]      # the issuer's jwks_uri
RESOURCE = os.environ["MCP_RESOURCE_URL"]        # this server's public URL, e.g. https://mcp.example.com/mcp
HOSTS    = os.environ.get("MCP_ALLOWED_HOSTS", "mcp.example.com").split(",")

class JwksTokenVerifier(TokenVerifier):
    """Verify RS256 access tokens offline against the IdP's JWKS. No network call per request
    after the key is cached; audience must equal this server's resource URL (RFC 8707)."""
    def __init__(self) -> None:
        self._jwks = PyJWKClient(JWKS_URL, cache_keys=True)

    async def verify_token(self, token: str) -> AccessToken | None:
        try:
            key = self._jwks.get_signing_key_from_jwt(token).key
            claims = jwt.decode(token, key, algorithms=["RS256"], issuer=ISSUER, audience=RESOURCE)
        except jwt.PyJWTError:
            return None                          # middleware answers 401 + WWW-Authenticate
        return AccessToken(
            token=token,
            client_id=claims.get("client_id") or claims.get("azp", "unknown"),
            scopes=claims.get("scope", "").split(),
            expires_at=claims.get("exp"),
            resource=RESOURCE,                   # we already checked aud == RESOURCE above
            subject=claims.get("sub"),
            claims={"iss": claims["iss"]},
        )

mcp = MCPServer(
    name="sandbox-tools",
    version="1.0.0",
    instructions="Tools for inspecting and controlling sandboxes.",
    token_verifier=JwksTokenVerifier(),
    auth=AuthSettings(
        issuer_url=ISSUER,
        resource_server_url=RESOURCE,            # served at /.well-known/oauth-protected-resource
        validate_token_resource=True,
        required_scopes=["mcp:tools"],
    ),
    # tools/list is identical for every caller, so let clients and gateways cache it for an hour.
    cache_hints={"tools/list": CacheHint(ttl_ms=3_600_000, scope="public")},
    middleware=[OpenTelemetryMiddleware()],     # mcp.method.name, gen_ai.tool.name, parent from _meta.traceparent
)

@mcp.tool(description="Return the lifecycle state of a sandbox by id.")
def sandbox_status(sandbox_id: str) -> dict[str, str]:
    return {"sandbox_id": sandbox_id, "state": "running"}   # replace with your control-plane lookup

@mcp.custom_route("/healthz", methods=["GET"])             # unauthenticated, for the load balancer
async def healthz(_: Request) -> JSONResponse:
    return JSONResponse({"ok": True, "protocol": "2026-07-28"})

app = mcp.streamable_http_app(
    stateless_http=True,                         # no sessions, no sticky routing, no shared store
    json_response=True,                          # plain JSON replies; SSE only when a tool streams
    host="0.0.0.0",
    transport_security=TransportSecuritySettings(
        enable_dns_rebinding_protection=True, allowed_hosts=HOSTS),
)
# run: uvicorn server:app --host 0.0.0.0 --port 8080 --workers 4

I ran this in a scratch directory against a JWKS I generated locally, with uvicorn 0.54.0, driving it with curl in the 2026-07-28 wire format (MCP-Protocol-Version and Mcp-Method headers, protocol version in _meta). Verbatim results: /healthz returned 200; tools/list with no token returned 401 with WWW-Authenticate: Bearer error="invalid_token" pointing at /.well-known/oauth-protected-resource/mcp; a token lacking the mcp:tools scope returned 403 insufficient_scope; a valid token returned the tool list with "ttlMs": 3600000, "cacheScope": "public" and "resultType": "complete"; a tools/call carrying a traceparent in _meta returned structuredContent; a request whose Mcp-Name header disagreed with the body got HTTP 400 and JSON-RPC -32020; and a legacy initialize from a 2025-11-25 client was answered with protocolVersion: 2025-11-25, so one binary serves both eras. The SDK's middleware sets the attributes the OpenTelemetry MCP semantic conventions define (mcp.method.name, mcp.protocol.version, gen_ai.tool.name); those conventions are still marked Development, the caveat I made about agent observability generally. Propagation itself is settled: SEP-414 was finalised on 26 February 2026 and the July spec reserves traceparent, tracestate and baggage in _meta.

Three notes the spec makes explicit and people miss. Set X-Accel-Buffering: no on SSE responses or nginx will hold your progress events. Bind local servers to 127.0.0.1 and return 403 on a bad Origin. And because resumability is gone, a client that loses a stream re-issues the request with a new id, so non-idempotent tool handlers need their own deduplication; for long work the answer is the tasks extension, where the server returns a handle and the client polls tasks/get.

The infrastructure servers I would actually connect

For the DevOps reader, the servers that matter touch clusters and cloud accounts, and the question for each is whether it has a read-only mode. GitHub's server (v1.14.0, MIT, 33,373 stars) is hosted at api.githubcopilot.com/mcp/, groups tools into selectable toolsets, and honours --read-only over any explicit tool request. The containers project's Kubernetes server (v0.0.67, Apache-2.0, 2,144 stars) talks to the API server natively rather than shelling out to kubectl, with a read-only mode, a denied-resources list for Secrets, and toolsets for core, Helm, Tekton and OpenShift. HashiCorp's Terraform server (v1.3.0, MPL-2.0, 1,543 stars) does registry lookups and HCP Terraform workspace and run operations over stdio or Streamable HTTP with token passthrough. AWS's monorepo (Apache-2.0, 9,754 stars) holds forty-plus servers including EKS, ECS and IaC, plus the remote AWS Knowledge server and an AWS MCP Server in preview routed through IAM and CloudTrail. Grafana's server reached v2.0.0 on 1 October (Apache-2.0, 3,524 stars) with Prometheus, Loki, incident and alerting tools and --disable-write. All five learned, mostly from the incidents in my security post, that a write-capable tool in a cluster needs a flag to turn it off. Whether your platform team sets it is a policy question, which brings you back to the gateway table.

What I take from the month. The protocol is finished in the sense that matters: stateless, header-routable, with a deprecation policy and a foundation behind it, and every client speaks it. The ecosystem is not, and where it is unfinished is exactly where platform engineering has always lived: the registry is still in preview, the SDKs straddle two protocol eras, twelve gateways are converging on three features, and tool overload is being solved by moving execution into sandboxes. This quarter I will move my own server to the 2.x SDK in stateless mode, put ttlMs on the list endpoints, pin tool definitions in CI, and run both protocol eras behind one gateway until the v1 downloads fall off. None of that is novel. That is rather the point.

---

Related: MCP Security in 2026: The Protocol Got Hardened. The Ecosystem Didn't., Agent-to-Agent Protocols in 2026: A2A Reached 1.0 and Agent Observability in 2026.