How Many Official MCP Servers Are There? 59,506 Latest Records on November 8, 2026

The official MCP registry listed 59,506 latest server records between 13:43:33 and 13:45:25 UTC on November 8, 2026. Of those, 58,565 were marked active and 941 were marked deprecated. A second pass through the same API, from 13:45:47 to 13:47:43 UTC, counted 59,508. Two records appeared while the first count was being written up. That is the size of the list. It is not a count of servers worth connecting.

MCP is the protocol a host uses to reach tools and data. The registry is the public metadata catalog for servers that speak it. This page counted that catalog. It did not rank the servers, and it did not copy a star list from anywhere else.

How many official MCP servers are there?

59,506, if you ask the official API for the latest version of each server and you finish the walk that started at 13:43 UTC. 59,508, if you start again two minutes later.

Both numbers come from GET https://registry.modelcontextprotocol.io/v0.1/servers with version=latest and limit=100, following metadata.nextCursor until the cursor was gone. The OpenAPI text for that parameter says version=latest returns only the latest version of each matching server. Without it, the same endpoint returns older versions as separate rows. This count used the filter. Each pass took 596 pages.

58,565 + 941 = 59,506. The second pass is the one that supports the namespace and repository figures further down. Its total is two higher. The count of records with no repository URL stayed at 20,434, so the net addition was two records that have a repository URL. The top ten namespaces had the same counts on both passes.

The about page, read at 13:48 UTC the same day, calls this "the official centralized metadata repository for publicly accessible MCP servers" and says it is backed by Anthropic, GitHub, PulseMCP, and Microsoft. The same page says the registry is in preview, and that breaking changes or a data reset can still happen. A count from a preview catalog is a snapshot of that catalog. It is the wrong number to engrave.

What does the registry actually list?

A record is a server.json document. The about page says it carries a reverse-DNS name such as io.github.user/server-name, a place to get the server (a package, or a remote URL), and discovery text. Package registries such as npm host the code. The MCP registry hosts the pointer.

The page also says the metadata is "deliberately unopinionated." Ratings and curation are left to downstream marketplaces, which are expected to pull the API on a slow cadence, the example given being once an hour. Host applications are told not to consume the official registry directly.

Two records from the same hour show the range of what "listed" means. At 13:48:44 UTC, io.github.github/github-mcp-server was active, with the description "Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language." In the same minute, com.microsoft/azure was active, described as Azure MCP tools for agents. Both sit in the same latest-version list as the bulk namespaces below. The API flag on all of them, in pass A, was active or deprecated. Nothing in the response is a quality score.

The status enum in the OpenAPI file is active, deprecated, and deleted. Pass A returned no latest row with status deleted. Deprecated means the publisher or the registry has marked that entry retired. It does not mean the other 58,565 were reviewed by a person.

Spam controls, from the same about page, are namespace authentication (GitHub, DNS, or an HTTP challenge), character limits on free-form fields, and manual takedown. The page says stricter rate limits, automated detection, and community reporting are under consideration. Authentication stops a stranger from publishing under your name. It does not stop you from publishing thousands of servers under a name you do own.

Why can one namespace hold thousands of servers?

Because the list is metadata, and a verified namespace can attach that metadata to as many names as it likes. Pass B found 36,737 namespaces across 59,508 latest records. 33,307 of those namespaces, 90.7%, had exactly one server. The crowd is real. So is the pile at the top.

Twenty-one namespaces had 100 or more latest records. Together they held 11,211 records, 18.8% of pass B. The top ten held 9,821.

These ten counts matched on pass A and pass B. 2,366 / 59,506 is 4.0% of the first snapshot in a single namespace.

The records inside a large namespace are not copies of one another, and they are not all the same kind of product. At 13:45:35 UTC the first five latest rows for sadri-dridi were aba-ok, abnf-ok, abs-ok, acah-ok, and acam-ok. Each description said the value is discarded (an ABA routing-number shape, an ABNF rule count, an absolute-value sign, and two header counters). Each repository URL was https://github.com/sadri-dridi/named-mcp-utilities. Each remote URL was a path under agent-observatory-sensor.nolimit-observatory.workers.dev. That is five rows. The namespace has 2,366. This page did not open the other 2,361.

The same search-and-read on the next two namespaces, at 13:47:56 UTC, looked different. The first pipeworx-io rows were 19hz and 42matters, each with its own GitHub repository and a remote under gateway.pipeworx.io. The first mrfentmen rows were 1c-enterprise-mcp and 4d-mcp. Both pointed at https://github.com/mrfentmen/awesome-servers, both had no remote URL in the record, and both descriptions claimed "20 real tools" for a named programming stack. Two rows are not a description of all 1,804.

Search on this API is a substring match, and a short query returns names outside the namespace you typed. The counts in the table come from splitting the name field on the first slash during a full walk, not from the search box.

How many records point at a code repository?

On pass A, 39,072 latest records included a repository URL. 38,980 had source: github and 92 had source: gitlab. 38,980 + 92 = 39,072. The other 20,434 records had no repository URL in that pass, and pass B found the same 20,434 without one.

Pass B collapsed the repository URLs to 30,687 distinct strings. 39,074 records in that pass had a URL (59,508 − 20,434), so thousands of server names share a repository. The sadri-dridi sample is the plain version of that pattern: many names, one repo. A star count on that one repository would still be one number. The registry count would still be thousands. Anyone adding those two numbers together is adding a catalog to a popularity vote.

Other fields from pass A, which are easy to misread as "servers":

39,519 + 1,139 = 40,658 remote entries, which is more than 39,709 servers. The extra entries are second remotes on a server that already had one. They are not 40,658 extra products.

What should you count instead?

Count the thing the decision needs.

If the question is "how large is the official catalog right now," the answer on November 8, 2026 is 59,506 latest records at 13:45 UTC, or 59,508 at 13:47 UTC, with the preview warning attached. If the question is "how many publishers used the catalog," pass B's namespace count is 36,737, and 33,307 of them published a single server. If the question is "how many code repositories are named," the distinct URL count is 30,687, and 20,434 latest records name none.

If the question is "what should an agent be allowed to call," none of those totals is the answer. The about page hands that job to a marketplace. A harness still decides which servers are connected and what the agent may do with them. The tool JSON for a server is billed on every turn whether or not the model calls it, so connecting a namespace of 2,366 counters is a cost decision, not a completeness decision. MCPHallu, posted November 5 and broken down on this site on November 8, scores a different question again: when an agent does have a tool list, which failures show up. Its 36 servers were a benchmark set. They are not a sample of these 59,506 records.

The registry will not stay at 59,506. It gained two records in the two minutes between these passes, and the about page says a preview catalog can still be reset. The useful habit is to store the window with the count. The number without the window is already a different list.