The Model Context Protocol, or MCP for short, is “an open-source standard for connecting AI applications to external systems”.

In this post, I briefly try to understand how open such an ecosystem is. I’ll use a very simple definition: as a client, does a server require me to log in, does it have a login facility, or is it completely open?

The result is that authentication is common in the part of the MCP ecosystem I measured. About 28% of remote endpoints required it to list tools, while another 23% advertised it. I do not have a good comparison with the Web, even though this seems quite high.

AI Disclosure: through this post, I use visualisations for data I’ve gathered. The code that sustains them has been generated by interacting with AI systems. It has been manually reviewed (thanks, SQL). Words are mine.

Short background on MCP Link to heading

When browsing the Web, the most usual interaction medium is a browser. I use Firefox, which I like even more since Mozilla redesigned its fox mascot, but Chrome, Safari, Brave, Edge, and others are equally popular options.

In the past few years, AI assistants such as Claude and ChatGPT have become another way to find information. Unlike browsers, the systems and sources they can reach are usually built into the application.

MCP aims to help close that gap by allowing assistants to be “connected to the systems where the data lives directly”.

The experiment Link to heading

I ran my experiment from France on August 13, 2026. The data I’ve captured is available in a DuckDB database in the GitHub repository.

The MCP ecosystem has an official MCP registry. In August 2026, it contained 21,423 servers, with 10,950 listing a remote endpoint. The others are servers you can run locally, or entries without a deployable remote URL.

A client can connect to one of these remote endpoints, initialize an MCP session, and ask for its list of tools. At least, this is how the discovery process is supposed to work.

This is the process that I ran: make a request to each endpoint without an account or token, and record how far the exchange gets.

How far an anonymous client gets across the MCP registryOne hundred marks represent the 11,121 probed remote endpoints. They separate into endpoints that did not answer, require authentication, advertise authentication, or are simply open through tools/list.CONNECTINITIALIZETOOLS / LISTanonymous client15.4%did not answer1,718 endpoints27.8%auth required3,092 endpoints23.1%auth advertised2,566 endpoints31.6%simply open3,511 endpoints
One mark ≈ 1% of the 11,121 remote endpoints probed.
Anonymous access outcomes across the MCP registryOne hundred marks represent the 11,121 remote endpoints. Scroll steps highlight endpoints that did not answer, require authentication, advertise authentication, or are simply open.
  1. 15%no answer
  2. 28%auth required
  3. 23%auth advertised
  4. 31%simply open

Start without an identity.

For each listed remote endpoint, send only the two requests needed to learn what is there: initialize, then tools/list. No credentials and no tool calls.

About one in six never answers.

1,718 endpoints were broken or unreachable. They are unknown, not closed: a failed connection cannot establish an access policy.

More than a quarter require credentials.

3,092 endpoints answered with an authentication challenge before an anonymous client could inspect their tools.

Another quarter introduces identity.

2,566 endpoints advertised OAuth while allowing some anonymous progress. That is not the same as forcing authentication, but it makes identity part of the protocol surface.

Only one in three is simply open.

3,511 endpoints (about 31%) let an anonymous client initialize and inspect the tool list without advertising OAuth.

These labels appeared while probing. I did not actually call the tools to confirm that they could be used anonymously. “Simply open” means that initialization and tools/list worked without OAuth being advertised.

It is worth noting that 118 endpoints also returned the reserved HTTP status 402 Payment Required. Another 92 only completed part of the exchange, 24 throttled the probe, and 1,718 timed out, were broken, or simply did not reply. A server that did not reply tells us nothing about whether it is open or closed.

So all in all, we can assess that about 28% of endpoints require authentication to list tools, and 23% have the capability advertised. Authentication appeared in the discovery path for about 51% of the endpoints I probed. This does not mean they are all private or paywalled.

Endpoints versus hosts Link to heading

One thing we would like to clear up is that MCP is not restricted to one endpoint per domain. For instance, Cloudflare hosts a remote MCP server at https://mcp.cloudflare.com/mcp, but nothing would prevent it from hosting https://mcp.cloudflare.com/staging/mcp. The way operators decide to shape their URLs and expose MCP servers has the potential to bias our analysis. Therefore, the graph below compares distinct endpoints with unique hosts.

Auth posture, by endpoint and by hostThe two units disagree because a few operators register many endpoints.endpointshosts3,5113,201open3,0922,783required2,5661,065optional1,7181,344broken118117paywalled9285partial2424throttled
Auth posture, by endpoint and by hostThe two units disagree because a few operators register many endpoints.endpointshostsopen3,5113,201required3,0922,783optional2,5661,065broken1,7181,344paywalled118117partial9285throttled2424
Endpoint and host counts use the same axis. Some hosts publish many endpoints, so the two counting units do not always agree.

There is a distinction if we count per host or per endpoint, although the broad picture remains the same. Simply open access represents about 32% of endpoints and 38% of hosts. Required authentication represents about 28% of endpoints and 33% of hosts. Optional authentication moves the other way: 23% of endpoints, but about 13% of hosts.

However, if we look at the largest contributors, we see that some hosts indeed contribute a lot of endpoints to the registry. gateway.pipeworx.io alone contributes about 12% of endpoints, with a total of 1,312. Each of them advertised authentication capabilities while allowing anonymous discovery.

Endpoint concentration by hostOne host accounts for about an eighth of every remote endpoint.gateway.pipeworx.io1,312server.smithery.ai216api.mcp.ai99mcp.apify.com65tooloracle.io57api.lazy-mac.com54mcp.olyport.com38api.meok.ai34
Endpoint concentration by hostOne host accounts for about an eighth of every remote endpoint.gateway.pipeworx.io1,312server.smithery.ai216api.mcp.ai99mcp.apify.com65tooloracle.io57api.lazy-mac.com54mcp.olyport.com38api.meok.ai34
The largest host contributes more endpoints than the next seven hosts combined.

To close this section, I’d say that both numbers are useful. There is no real way we can conclude whether a host provides services for multiple operators, or whether a given host has made some particular architectural choices. Unlike the Public Suffix List used for the Web, the registry does not provide a way to tell which endpoints belong to the same operator. With its minimal registration requirements, this is something left for future analysis.

Public data but with authentication Link to heading

We now have a good view of how authentication works per endpoint. There are sensible reasons to request authentication though. For instance, you might like your AI assistant to help you triage your email, or understand the last movies you’ve seen to provide suggestions. Notion’s MCP server requires authentication to access your workspace. And so do PayPal, Stripe, Cloudflare, or Vercel when accessing your account. These are not data that you expect would be public.

The analysis that we’ve conducted evaluates whether tool listing was open, meaning that an unauthenticated client could list the features provided by the MCP server. It does not evaluate whether a tool could then be called anonymously.

To get a rough view of what sits behind each result, I classified servers as public, user-private, financial, or infrastructure-control. I used tool names when they were available. For servers requiring authentication, I could only use the name and description from the registry. These labels were generated with an AI model and spot-checked manually, so this gives us a rough estimate.

We plot this data as follows:

What sits behind each postureServers by the highest-sensitivity capability inferred from their metadata. Required-auth servers never show a tool list, so their labels rest on name and description alone.publicuser-privatefinancialinfrastructure-controlrequired2,976 servers41%39%15%optional2,561 servers78%16%open3,490 servers73%13%10%
What sits behind each postureServers by the highest-sensitivity capability inferred from their metadata. Required-auth servers never show a tool list, so their labels rest on name and description alone.publicuser-privatefinancialinfrastructure-controlrequired2,976 servers41%39%15%optional2,561 servers78%16%open3,490 servers73%13%
Composition by authentication posture. For required authentication, this is inferred from registry descriptions because the tool list was inaccessible.

Some endpoints seem to require authentication for public data. About 41% of servers in the required-authentication group were classified as public information services. This number tells us what their descriptions look like, but not why authentication is required.

Pipeworx is a slightly different case. Its servers expose multiple public sources, such as Wikipedia or the Wayback Machine, but they did not require authentication for discovery in my snapshot. They advertised it. Pipeworx provides an anonymous tier, with authentication meant to unlock higher rate limits.

I want to point out that Wikipedia offers free copies of all its content, and that the Wayback Machine also provides an API. Both institutions have donation or support options. In a way, I believe that this is a transient problem due to the discovery of MCP servers, or of such APIs, more than a service users desire. This is a topic for another time though.

Conclusion Link to heading

I wanted to better understand how the openness story works in the MCP ecosystem. I’m still unsure, but we now have a bit more data to work with. Overall, it seems that authentication capabilities are widely deployed among the MCP ecosystem. This is inherent to accessing private data and agency, but also seems to be overkill when only rate limiting or denial-of-service considerations are at play.

Authentication may be the right choice for many servers, and the fact that they support it acknowledges that these primitives are accessible and in demand. The result from this analysis of the official MCP registry is that simply open tool discovery is not the majority experience for these remote servers. There is of course further analysis to conduct. Why do people use authentication? Why do they advertise it? Is what is being communicated actually enforced? Is authentication moving to Client ID Metadata Documents now that CIMD is recommended in the specification? Do different services make different choices? How do users discover content from websites that do not have MCP, and can they customise the search of such content?

If you want to rerun the experiment, or expand it, you can check thibmeu/are-mcps-open-yet. It contains a snapshot of the data I used to construct this blog, which you can inspect with SQL and the DuckDB CLI.

Thanks to Sven Sauleau for the early review and feedback.