How many MCP servers are there? The numbers, November 2026
The official MCP registry lists 53,553 active servers, and our directory shows 47,703. Here is how fast that grew, who publishes them, how they are built, and how few have much evidence behind them.

As of early November 2026, the official MCP registry lists 53,553 active servers. Our directory, which reads the registry plus GitHub, npm and PyPI, shows 47,703 listings, and 99.7% of those are registry records.
A year ago it held under a thousand names. So this post counts what is there now and describes it: how fast it grew, who publishes, how the servers are packaged, and how many have enough public evidence behind them for us to rate them well. Everything comes from public sources, and the last section says how to check each number yourself.
The count, and what counts
The registry's API returns one record per version of a server, not one per server. We pulled all 202,828 version records and grouped them by server name. That gives 54,396 distinct names: 53,553 active and 843 deprecated. The average name has 3.7 versions on record, though the median is one, and the most-released name has 1,179.
Our directory has fewer listings than the registry has active servers. Records have to pass a publish check before they appear (an install path and a short summary, at minimum), deprecated records are handled separately, and the sync runs on a schedule rather than continuously. The total even moved while we were counting, from 47,688 to 47,703.
One caution about the word "server". A registry entry is a record that someone published. It isn't a promise that the server runs, is maintained or is safe. Keep that in mind for every figure below.
How fast it grew

Distinct server names in the official MCP registry, by month of first publication, through 31 October 2026. Source: the registry's public API.
The registry's first month, September 2025, brought 456 names. By the end of January 2026 the running total was 1,592. Then the curve bent upward. February added 1,155, April 2,547, July 5,077 and September 11,858. October added 16,307, which is about 30% of every name ever published there. Monthly first publications went from 389 in January to 16,307 in October, roughly 42 times as many in nine months. A further 522 had appeared on 1 November by the time we pulled the data.
Is that a handful of bulk publishers? Partly, not mostly. Eighteen namespaces have 100 or more servers each, and together they hold 9,337 servers, 17.4% of the active total. The largest single namespace has 2,366. But leave all eighteen out and October still brings 14,980 new names. The growth is broad.
Who publishes them
There are 33,621 distinct namespaces (the part of a name before the slash). 30,538 of them, 90.8%, publish exactly one server. The median namespace has one.
58.2% of active servers sit under a GitHub namespace, the io.github. kind that is tied to a GitHub account. The other 41.8% use a domain name, such as a company's own. A namespace is tied either to a GitHub account or to a domain the publisher controls, so neither kind is a quality signal on its own.
Most servers are published once and left alone. 56.2% of names have a single version on record. About 44% of active servers have a registry record updated in the last 30 days, and 75% in the last 90, though an update to a record is not the same as new code.
Remote, local, or both

Directory listings by transport (left) and the share of each type that scores 60 or more on trust (right), 2 November 2026.
In our directory, a listing is remote if it only has a URL, local if it only has an install, and hybrid if it has both. Of 47,703 listings, 27,819 (58.3%) are remote, 15,612 (32.7%) are local and 4,272 (9.0%) are hybrid.
The registry's own entries look almost the same. Among active servers, 59.1% have a remote endpoint and no package, 31.7% have a package and no remote, 8.0% have both, and 1.2% have neither. That is expected, since the registry is where most of our listings come from, but it does show that the directory isn't skewing the picture.
Among servers that publish a remote endpoint, 97.0% use Streamable HTTP only. 2.0% use the older SSE transport only, and 1.0% offer both. SSE was deprecated in the spec in March 2025, and new registry entries have largely moved on. (Registry entries show what people publish, not what clients accept, which we cover in remote vs local MCP servers.)
What they are made of
Of the 21,259 servers that publish an installable package, 14,260 (67.1%) use npm and 4,768 (22.4%) use PyPI. MCPB bundles account for 1,530, container images (OCI) for 1,328, NuGet for 165 and Cargo for 108. A server can publish more than one. Almost all of them, 20,980, are stdio servers that a client starts as a local process.
For language we only know what GitHub reports, so the figure covers 10,579 listings, 22.2% of the directory. Of those, TypeScript has 4,261 (40.3%), Python 2,792 (26.4%) and JavaScript 2,548 (24.1%), which together make up 90.8%. Go has 285, Rust 234 and C# 118.
How many are well evidenced?
This is where the numbers get thin. Our trust score runs from 0 to 100 and is described on the methodology page. It weighs a registry record (up to 30 points), license (10), maintenance (20), popularity (20), documentation (10) and security basics (10). It is a heuristic of ours, not an independent audit.
Of 47,703 listings, 37,648 (78.9%) score 40 or more, the Fair band. 2,073 (4.3%) score 60 or more, the Good band. Two score 80 or more.
The reason for the shape is that the score measures evidence, and the registry record alone is worth 22 points. A listing with an active registry record, a summary and nothing else lands somewhere around 35 to 42. Getting past 60 takes the things a repository provides: a license, recent commits, stars or downloads.
That explains the split by transport. Only 0.7% of remote listings reach 60 (189 of 27,819), against 4.6% of local (725 of 15,612) and 27.1% of hybrid (1,159 of 4,272). Hybrid servers make up 9% of listings but 56% of the servers scoring 60 or more. In the registry the gap shows up in the raw data:
- 47.1% of remote-only entries link a repository. For package-only entries it is 95.5%, and for hybrid ones 93.4%.
- 30.9% of remote-only entries have more than one version. For package-only it is 57.1%, and for hybrid 87.7%.
Many remote-only entries are hosted services from companies whose code isn't public, so no repository is a reasonable choice. But our score can't see what it can't link to. Read the 0.7% as "little public evidence", not "bad servers". Licensing has the same gap. 77.5% of listings have no license we can read (36,976), and for remote listings that rises to 91.9%. Only 21.8% have an OSI-style license.
TypeScript listings reach 60 more often than the others: 25.7%, against 14.8% for JavaScript, 20.5% for Rust, 11.6% for Go, 10.5% for Python and 11.0% for C#. We haven't tested why. It could be the kind of projects people write in each language, or how much metadata a typical TypeScript project publishes.
What people build
The 20 category pages hold 26,285 listings between them, a little over half the directory. Search is the largest at 4,329, followed by Finance (3,323), AI and memory (3,143), Communication (2,053), Knowledge (1,690) and Security (1,587). Marketing is the smallest at 139.
If you are choosing a server
Four things follow from the numbers.
- Being listed is not an endorsement. With 54,000 names, and over half published once and never re-released, treat a listing as the start of your own checks.
- For a local server, check the license and look at the repository's recent activity before you run it. A local server runs with your privileges. Our vetting checklist goes through it.
- For a remote server, the evidence is somewhere else: who runs it, what it does with your data, what scopes it asks for. Our trust score can't answer that.
- If you publish a server, link your repository and add a license. Those two things are most of what the score can see. The claim guide shows how to take over a listing.
How we counted
The registry numbers come from its public API, read 100 records at a time by cursor (the /v0/servers endpoint on registry.modelcontextprotocol.io). We pulled everything on 2 November 2026, grouped records by server name, kept the record flagged as the latest version, and took each name's first publication date from its earliest version. Statuses are the registry's own. The registry itself is labelled as a preview, so its data can change shape.
The directory numbers come from the public filters on the servers page, read the same day. Counts there change as the sync runs, so yours will differ slightly from ours. Trust scores follow the formula on the methodology page. Language comes from GitHub and is missing for most listings. Our tool-description figures, which we use elsewhere, are covered in how to write MCP tool descriptions.
Two things this post can't tell you. First, how many of these servers work. We haven't run them. Second, how many people use them. Registry growth shows publishing, not adoption.
Servers in this post
Repowise
by repowise-dev · Python
Codebase intelligence for AI coding agents — graph, git history, docs, decisions, code health.
mirroir-mcp
by jfarcand · Swift
Drive a stock iPhone via iPhone Mirroring: no Developer Mode, Xcode or WDA. LLM-free skill replay.
mobile-mcp
by mobile-next · TypeScript
MCP server for iOS and Android Mobile Development, Automation and Testing
Firecrawl MCP Server
by firecrawl · JavaScript
Firecrawl, the context API for AI agents: search, scrape, interact with the web, plus paper search.
Zotero MCP
by 54yyyu · Python
Search, read, annotate, and add to your Zotero research library, local or web.