The State of Public MCP Servers in 2026: What 500+ Listings Tell Us

Most MCP server statistics online are headcounts: how many servers a catalog lists. This piece asks how the servers a client can actually reach are built, how they authenticate and what they expose, using the 536 approved listings on mcp.tc on 4 October 2026, each probed by our own checker.

Where the numbers come from#

Every mcp.tc listing points at the vendor's own endpoint or package, and before it is approved our checker connects to it: an MCP request with no credentials for a remote server, then a look at the OAuth metadata if the answer is 401; the package on npm, PyPI, OCI or NuGet, plus its server.json or manifest, for a local one. The docs for server owners describe what the checker reads.

The dataset is the 536 listings with status approved on 4 October 2026: 427 from our curated seed list, 107 from the official MCP Registry, 2 added by hand. One of the two is our own directory server (mcp.tc/i/mcp-tc, remote, no sign-in). It counts in the catalog totals (536 listings, 366 remote, 58 remote with no sign-in) and is left out of every figure that comes from probing a server: anonymous tool lists, protocol versions, tools and annotations, health. Those figures cover only what we could read: remote servers that answered, and the tool lists in MCPB bundle manifests. All counts come from the database on that day; the kind and auth split, for example:

SELECT kind, auth, COUNT(*) FROM servers
WHERE status = 'approved'
GROUP BY kind, auth;

Percentages are rounded to the nearest whole number, so some rows do not sum to exactly 100.

Remote vs local: two thirds live on a URL#

The split matches the direction of the protocol itself. The transports section defines two standard transports, stdio and Streamable HTTP, and Streamable HTTP replaced the older HTTP+SSE transport back in the 2025-03-26 revision. We found no listing that still depends on the legacy SSE transport. The single local listing recorded with an HTTP transport is Playwright, whose package can listen on a port you choose instead of using stdio.

Where do the remote endpoints live? 299 of 366 (82%) end in /mcp, the path the spec uses in its own example, and another 40 sit at the root of their host. Google Cloud runs the most remote endpoints (14), then Cloudflare (11). Across the whole catalog, remote and local, Google Cloud is also the largest vendor with 15 listings, then Microsoft (12), Cloudflare (11) and Google (8).

84 remote servers also ship a package you can run yourself. Among the 170 local servers, 89 come from npm, 62 from PyPI, 9 as OCI container images, 2 from NuGet and 1 as an MCPB bundle; the other 7 start from a tool you install first (the Docker, Fly.io and Dart command lines, Laravel's artisan, a macOS app, a Burp Suite extension) or from a repository you clone and build. Those are the registry types the server.json format supports, minus Cargo, which no approved listing uses.

Authentication: OAuth won on the remote side#

Three quarters of hosted servers require an OAuth sign-in. The spec makes authorization optional but, when an HTTP server does protect itself, it should use the OAuth 2.1 flow described there, and stdio servers should take credentials from the environment instead. The data follows that advice: 64% of local servers need no credentials at all, 27% read an API key from an environment variable, and the OAuth share among local servers is the 11 packages that open a browser to sign you in.

"Optional" is a category we had to add. These servers answer an anonymous request but also take a key or sign-in, so you get a basic service without one and a better one with it. Some say so with a WWW-Authenticate header on the anonymous answer (Context7 is the best known example); others list an optional key header in their registry entry.

How well do OAuth servers implement discovery?#

The authorization spec requires a protected MCP server to publish OAuth 2.0 Protected Resource Metadata (RFC 9728) so the client can find the authorization server. We checked the 275 remote OAuth servers:

So 35 OAuth servers (13%) answer 401 without protected resource metadata. Three of them publish authorization server metadata on their own origin, the fallback of the 2025-03-26 revision; for the other 32, a client that follows the current spec has no standard way to find their authorization server.

The registration rows catch a transition in progress. Dynamic client registration was the original way an unknown client got a client ID. The 2025-11-25 revision added client ID metadata documents as the recommended mechanism, and 2026-07-28 deprecated dynamic registration in its favor. Today 81% of the 275 OAuth servers (94% of the 238 whose authorization metadata we could read) still offer the deprecated path, and 22% the new one. 61 is respectable for a feature under a year old; the long tail has not moved.

Who answers without a key?#

92 remote servers (25% of remote, 17% of the catalog) return their tool list to an anonymous request: 57 need no sign-in, 10 make it optional, and 25 gate tool calls behind OAuth (16, mostly Google Cloud's managed servers) or an API key (9) but publish the list openly. Our own directory server is left out of these counts. Of the 67 that work without a required sign-in, 27 are documentation servers, 11 finance and market data and 5 search. DeepWiki, Microsoft Learn, Astro Docs, Cloudflare Docs, AWS Knowledge and Svelte all fall in this group, and so do a few reference services such as Kiwi.com Flights and Wolfram.

Most of them serve public data, so open access is reasonable. It does mean the tool list you see on an mcp.tc page is the same one anyone, including an attacker, can enumerate.

Protocol versions in the wild#

The protocol is versioned by date, and the versioning page lists 2026-07-28 as current. A server only reveals its version when it answers our request, which 94 of the 365 third-party remote servers did; most of the rest need a sign-in first, and we do not launch local packages.

The 2026-07-28 revision is a bigger change than its predecessors: it removes the initialize handshake and sessions and adds a mandatory server/discover call. Our checker tries that call first; 17 servers answered it and 77 still needed the old initialize exchange. Two months after release, nearly one in five reachable servers has moved, while four still speak a version that predates Streamable HTTP.

What the tools look like#

We have a tool list for 113 listings: 92 read live from remote servers and 21 taken from an MCPB bundle manifest. Together they expose 1,567 tools. The median server has 8 tools, the mean is 13.9, and the largest (Mailtrap) exposes 125.

The most common tool types#

Tool names follow the verb_object convention closely enough that the first word tells you what the tool does:

The only first word outside this list that would rank is web (48 tools, as in web_search and web_fetch), which is not a verb. Read-style verbs (get, list, search) account for 38% of all tools; write-style verbs (create, update, delete) for 11%. The most repeated exact names are create_instance and list_instances (6 tools each), search and get_instance (5) and execute_sql (4). The instance and SQL tools all come from Google Cloud's managed database and compute servers, which share one naming scheme.

Annotations#

The tools section of the spec lets a server annotate each tool with hints such as readOnlyHint and destructiveHint, and tells clients to treat those hints as untrusted unless the server is. 775 of the 1,567 tools (49%) carry at least one annotation: 629 (40%) are marked read-only and 77 (5%) destructive. The other 51% say nothing, and since destructiveHint defaults to true, a careful client will ask for confirmation before calling them.

Prompts and resources remain rare in this set: 16 listings expose prompts and 31 report at least one resource.

Categories#

The six smaller categories (e-commerce, CRM, travel, browser automation, utilities, automation) hold 56 listings between them, none above 12.

Finance comes third. 36 of its 41 listings are hosted servers, 23 of them behind OAuth, which points to payment, banking and market-data companies publishing their own endpoints.

Verified vendors#

162 listings (30%) carry the verified checkmark. All of them were marked by hand as the official server of a well-known vendor; the self-service route, a DNS TXT record on the vendor's domain requested from the verify page, has not produced its first checkmark yet. The checkmark says who a listing belongs to. It is not a security review of the server.

Health#

At the last daily check, 271 remote endpoints answered with a sign-in challenge (they work, you need to sign in), 92 answered an anonymous request and 2 were down; the 366th is our own directory server. The daily check does not launch the 170 local packages.

Limitations#

• This is a curated directory, not a census. The official registry launched in preview in September 2025 and held 39,045 entries (the latest version of each) when our sync last read all of it, early on 4 October 2026. We only take entries from known vendors and from reputable publishers whose endpoint or package works; much of the rest is test projects, duplicates or spam.
• Protocol version, tool lists and annotations are only visible when a server answers without credentials or ships a manifest. Most of the 271 servers that require sign-in first are invisible on those metrics, and we can't tell whether they adopt new revisions faster or slower than the open ones.
• Auth classification is what the endpoint told our checker when the listing was built. The daily check refreshes health, protocol version and tools, not auth, so a server that moves from an API key to OAuth keeps its old label until the listing is checked again.
• Tool verb counts take the first token of the name, so tools with a vendor prefix (auth0_, aws___) or a camelCase name (getCoins) are not counted as reads or writes.
• Categories are assigned by our evaluator and corrected by hand when we notice a bad one; some servers could sit in two.