How many MCP servers are there?

The official Model Context Protocol (MCP) Registry listed 26,837 active servers on 2026-09-05, when we enumerated the whole thing. 15,219 of those publish a remote HTTPS endpoint. We picked 1,500 of them at random and tried to connect, and 862 answered.

That is the easy half. The harder half is what those 862 servers actually expose once you are talking to them. Between them they publish 13,644 tools. 8,739 of those tools take at least one required argument, and 97.6% of them name no value in the schema that could fill even one. If you write MCP clients, that number decides how much of the work you can do for your user before you have to stop and ask.

How we measured the MCP registry

Every number here was measured on 2026-09-05 against the official MCP Registry at version=latest. There are two strata, measured with two unrelated instruments, both sampled at seed 1671 so the draw is reproducible.

• The census is not a sample. We enumerated all 27,146 registry records, deduped by name, and kept the 26,837 that were active.
• For servers with a remote endpoint, we opened an MCP handshake over HTTPS and called tools/list. That is the entire interaction. No third-party code was executed.
• For package-only servers, we fetched the published npm tarball and read it statically: gzip and tar in process, then a TypeScript AST walk that accepts only literal values. npm install was never run and nothing was evaluated.
• The two random samples are 1,500 of the 15,219 remote records, and 400 of the package-only records that carry an npm identifier.

What do MCP servers publish to connect with?

Every registry record has to tell a client how to reach the server. There are two ways to do that: hand over a remote HTTPS endpoint, or name a package the client can launch locally over stdio. A surprising number of records do neither.

what the record publishes        count    share
-------------------------------  ------  ------
a remote HTTPS endpoint          15,219   56.7%
package only (stdio)             11,228   41.8%
nothing, no launch option           390    1.5%
-------------------------------  ------  ------
total active records             26,837    100%

The 390 at the bottom are worth naming. They are published, listed and searchable, and there is no documented way for any client to start them. A user who finds one has reached a dead end through no fault of their own.

There is one more thing a registry cannot tell you, and it shaped this whole survey: no MCP registry publishes tool schemas. Not the official one, not Smithery. Tool schemas exist only behind a live tools/list call. That is why answering "what do these servers expose" meant connecting to them rather than reading metadata.

How many MCP servers can you actually connect to?

57.5%. Of the 1,500 randomly sampled remote servers, 862 completed an MCP handshake and returned a tool list. The other 638 did not, and the reasons matter more than the total does.

why it did not answer            count   share of 1,500
-------------------------------  -----  ---------------
auth wall (401, 402, 403)          388            25.9%
HTTP error                         120             8.0%
other transport failure             62             4.1%
DNS does not resolve                56             3.7%
timeout                              9             0.6%
JSON-RPC refused the handshake       3             0.2%
-------------------------------  -----  ---------------
total unreachable                  638            42.5%

The largest group is not broken. 388 servers are commercial and want an account before they will say anything. Roughly a quarter of the remote registry is a login screen, and for a client that is a first-run experience to design rather than an error to handle.

The next three groups are closer to rot. 238 servers between them returned an HTTP error, failed at the transport, or pointed at a hostname that no longer resolves. The 56 dead hostnames are the sharpest case: the record is still listed, still searchable, and the domain is gone. Nothing in the registry marks them.

What do the reachable MCP servers expose?

862 servers, 13,644 tools. The median server publishes 7 tools and the mean is 15.8, which tells you the distribution has a long tail: a handful of very large servers pull the average well above the middle. The most common band is 4 to 10 tools, where 377 of the 862 sit. At the other end, 39 servers, 4.5%, publish exactly one tool.

The number that matters to a client is not how many tools a server has, but how many arguments those tools demand before they will run.

required args on a tool   tools
-----------------------  ------
0                         4,905
1                         5,855
2                         2,005
3                           609
4                           171
5                            54
6                            29
7                             9
8                             2
9                             2
10                            1
11                            2
-----------------------  ------
total                    13,644

4,905 tools take no required argument at all. A client can call those with an empty object and get a result. The remaining 8,739 need something from the user first, and the rest of this post is about whether the schema gives a client any way to supply it.

Almost no MCP tool names a value for its own required arguments

This is the finding. We counted a required argument as fillable when the tool's own JSON Schema names a value for it. Four keywords can do that: const, default, an enum with exactly one member, and an examples array with exactly one element. Any of the four hands a client an unambiguous value. Anything else, including a two-member enum or a bare type, does not.

Across the 8,739 tools that take at least one required argument:

                                           tools   share
----------------------------------------  ------  ------
FULL: every required argument named           73   0.84%
PARTIAL: some named, some not                136    1.6%
NONE: not one required argument named      8,530   97.6%

Counting arguments instead of tools gives the same answer. Those 8,739 tools carry 12,949 required arguments between them, and 245 have a value named in the schema. That is 1.9%.

The 136 PARTIAL tools are the interesting failure, because they look like progress and save nothing. A client only avoids interrupting the user when the required set empties completely. Filling three of a tool's four required arguments still ends in a prompt, and the user still has to understand the whole call to answer it.

Why the default keyword almost never helps

The cause is structural, and it is the most portable sentence in the survey: default and required are near-disjoint by construction. An argument is required precisely because there is no sensible default for it. So authors put default on the optional arguments, which is exactly correct schema design and exactly no help to a client trying to skip a question.

Here is the same 245 attributed by keyword, across 44,335 properties in the reachable sample:

keyword                     on properties   fills a required arg
-------------------------  --------------  ---------------------
default                             7,300                      9
one-element examples                  309                     97
one-member enum                       139                    127
const                                  21                     12
-------------------------  --------------  ---------------------
total                                                        245

Read the two columns against each other. default appears on 7,300 properties and lands on 9 required ones. A single-member enum appears on 139 properties and lands on 127. The three rare keywords do 236 of the 245, which is 96% of all the seeding that happens on a required argument anywhere in the sample.

That inversion makes sense once you see it. An author who writes a one-member enum is describing a constraint, not a convenience, and a constraint on a required argument is the one case where the value is genuinely knowable from the schema alone.

A second instrument, on the servers a probe cannot see

A live probe is blind to 41.8% of the registry. Package-only servers run over stdio on the user's own machine, so there is no endpoint to call and no handshake to open. Measuring them needed a different instrument, and using a different instrument is the point: if two unrelated methods disagree, one of them is wrong.

We sampled 400 package-only records with an npm identifier at the same seed, pulled what we could from registry.npmjs.org, and read the published source statically. 8 could not be fetched. Of the 392 we did read, 105 yielded a literal tool schema. Those 105 packages carry 1,542 schemas and 1,182 tools with at least one required argument.

One of those tools had every required argument named. Across 1,807 required arguments, 13 carried a value. That is 0.7%, lower than the 1.9% the live probe found on remote servers. Two unrelated instruments, no disagreement.

What this survey did not measure

A percentage published without its population is not a measurement. Here is everything this survey could not see, with counts, in the body of the post where it belongs.

• 638 of the 1,500 sampled remote servers never answered. 388 of those are behind an authentication wall, so the unmeasured group skews commercial and hosted.
• 295 of the 400 sampled npm packages produced no measurement. 219 build their schemas with zod at runtime, so no literal exists in the published source to read. 48 had no inputSchema literal, 20 had one that was not a pure literal, and 8 could not be fetched at all.
• 390 registry records publish no launch option, so there was nothing to connect to and nothing to download.
• Smithery, a second registry carrying more than 11,000 servers, is out of frame entirely. Its listing endpoint publishes no transport, no launch detail and no tool list, so there is no address to probe and no source to read.

Those gaps do not point in a neutral direction, and it is worth saying which way they run. The 388 auth-walled servers are commercial products. If they differ from the servers that answered, they carry more required arguments and not fewer: API keys, account identifiers, tenant identifiers. That pushes the true figure below 1.9% rather than above it, so treat 1.9% as a ceiling.

The one covariate we can check on measured and unmeasured servers alike shows no hidden split. Records that also publish a package answered 58.4% of the time, and remote-only records answered 57.4%. Whatever separates the reachable from the unreachable, it is not that.

What this means if you build on MCP

If you are writing an MCP client

• Budget for the auth wall. About a quarter of remote servers in the registry will refuse you before you ever see a tool. Design that as a first-run path, not an error state.
• Do not build a feature on schema-supplied values. At 1.9% of required arguments, anything that pre-fills a call from the schema will fire on almost nothing.
• Handle the empty case well. 4,905 of 13,644 tools require no arguments, and those are the ones you can run without asking the user anything.
• Expect a median of 7 tools and plan for the tail. The mean is 15.8, more than twice the median, so a minority of servers publish far more tools than the typical one.
• Check that the endpoint still exists before you blame your own code. 56 of 1,500 sampled hostnames did not resolve, and the registry does not mark them.

If you are publishing an MCP server

• Name a value when you honestly can. A const or a one-member enum on a required argument is read by clients, and it is rare enough today to be a real difference.
• Do not reach for default on a required argument. It appears on 7,300 properties in this sample and names a value on 9 required ones. Spend the effort on a clear description instead.
• Publish a launch option. 390 records publish none, and no client can reach any of them.
• Keep the endpoint alive or take the record down. 56 dead hostnames in a 1,500 sample is a lot of dead ends for users to find.

Frequently asked questions

One note on where this came from. We build MCPOrbit, a desktop app for working with MCP servers, so the question of how much a client can work out on its own is not academic for us. We ran this survey to decide whether a feature was worth building. The answer was no, and the data was too useful to leave in a ticket.