What Is an MCP Server?
A definition, and then the part documentation cannot give you: what 34 696 real MCP servers actually expose, which transport they really use, and how often each way of failing happens. Every number here comes from our own handshake with every registered endpoint, repeated every 15 minutes.
The short answer
An MCP server is a program that exposes tools, data or workflows to an AI application through the Model Context Protocol, so the application can use them without anyone writing a custom integration for that particular pair of products.
“Server” describes its role in the protocol, not where it runs. It can be a command on your laptop that reads one folder, or a hosted service behind an OAuth login. Both answer the same handshake and describe themselves the same way — which is exactly why they can be compared at all, and why 34 696 of them fit in one list.
How many MCP servers exist
34 696 servers are published in the official registry, but only 17 707 of them — 51% — answer when something actually connects.
The gap matters more than the headline number. 3 696 servers are still marked active by the registry and respond to nothing at all: the registry stores what an author submitted once, it never rechecks. Catalogues that copy the registry inherit that error and present dead endpoints as working ones.
Another 12 294 servers flip between answering and failing within a single day, and 623 point at domains that no longer resolve — the project is gone, the listing remains.
What a server actually exposes
The protocol defines three things a server can offer — tools, resources and prompts — and a
server may implement any combination. In practice tools dominate: we have read
261 687 of them straight off servers via tools/list.
Half expose fewer, half more. 2 574 servers expose three or fewer — often a single function wrapped as a server.
396 servers expose fifty or more. A large surface is not automatically better — it is more to review before you connect it.
Of the tools whose names are unambiguous, 85% read or search and 15% change something — create, update, delete or execute.
Descriptions and input schemas come with the list. That is what lets a model pick a tool on its own: it reads what is available before it makes a request, instead of being told in advance.
Local and remote servers
The split is almost even: 13 379 registered servers have no network address at all, while 21 317 are reachable over HTTP.
Launched by your client as a child process and spoken to over stdio. Installed from npm or PyPI, runs with your own permissions, sees your files.
Uptime cannot be measured for these by anyone, including us — the server only exists while your client is running it. What can be measured is adoption: weekly installs from the package registry.
Runs on someone else's infrastructure at an HTTPS address. Nothing to install; the client connects to a URL. 23% of them ask who you are first, and 7 in 10 of those sign you in through the browser rather than taking a key.
These can be checked, and we check every one of them every 15 minutes. A server that answers an authorization challenge counts as alive — it is running, it just will not talk to strangers.
What happens when a model calls a tool
Four steps, and the first two are exactly what we run against every endpoint every 15 minutes — which is how everything else on this page gets measured.
- Initialize. The client opens a connection and sends protocol version, its own identity and the capabilities it supports. The server answers with its own. This single exchange is enough to tell a working server from a dead one.
-
List capabilities. The client asks for
tools/listand gets names, descriptions and input schemas. A server behind auth stops here and returns a challenge instead — that is the 23% above. - Call. The model picks a tool and the client sends arguments matching its schema. The server validates them, checks authorization and runs the underlying operation.
- Return. A structured result goes back to the host, which shows it to the user or feeds it to the model as context for the next reply.
Which transport is actually used
Streamable HTTP has won outright: 95% of the 22 148 endpoints we track use it, and only 5% still use SSE.
The specification describes both, so documentation says “commonly” and leaves it there. This is the count. If you are writing a client today, SSE is a compatibility path, not a choice.
What goes wrong, and how often
Every guide lists what can fail. Here is how often each thing actually fails, measured across 1 996 359 handshakes in the last 24 hours.
Two of these are worth reading twice. Asks who you are is not a failure: the server is running and refusing anonymous clients, which is correct behaviour. Most of these sign you in through the browser, so there is no key to hunt for. Wrong reply is the nastiest case: the address responds with a normal HTTP page, so anything that only checks for a status code will call it healthy. It is not an MCP server at that address any more.
How to tell a working server from a dead one
A listing in a catalogue proves nothing: 3 696 servers are listed as active and answer nothing. Four checks that take a minute each.
- Does it answer right now? Not “was it added recently” — send a handshake, or look at a site that does. 12 294 servers answer and fail within the same day.
- Does the domain still exist? 623 registered servers point at hostnames that no longer resolve.
- Is anyone installing it? Weekly installs from npm or PyPI are work someone did. GitHub stars are bookmarks and never expire.
- What does it expose? Read the tool list before connecting, not the README. The README
describes intentions;
tools/listdescribes the server.
Playwright Tools for MCP
Gives AI development tools Firebase-specific capabilities and expertise.
Up-to-date code docs for any prompt
Control a real Chrome browser to complete any task: fill forms, extract data, book flights.
Help agents automatically write and test stories for your UI components.
MCP server for Chrome DevTools
What connecting a server actually grants
The protocol standardises how a server is described. It says nothing about whether that server deserves what you are about to hand it.
A local server runs as your user. It sees the files your account sees, uses the credentials in your environment, and can do anything the command it wraps can do. Scoping it to one directory is a decision you make in the config, not a guarantee the protocol provides.
A remote server sees whatever you authorise it to see on the other side of the login, and every argument the model sends it. 14 413 servers list their tools to an anonymous client — useful for us, and a reminder that a tool list is public information you can read before connecting anything.
Practical order: read the tool list, check which of them write rather than read, give the narrowest credentials that work, and require confirmation for anything that sends, pays, deletes or deploys.
MCP compared to APIs, plugins and function calling
These are not competitors — an MCP server usually wraps an API and describes it in a way a model can discover.
MCP server FAQ
Every answer below uses our own measurements, not the specification text.