“Up” for an MCP server means one specific thing: it answers a real initialize request and returns a usable tool list. A GitHub repository with a green README badge tells you none of that — it tells you code exists, not that an endpoint is listening, authenticating correctly, and handing back the tools your client expects. Most directories only check the former. Here is what actually checking the latter looks like, and why the difference matters before you wire a server into something your team depends on.

Why “listed” is not “live”

A typical MCP directory is a curated list: someone found a repo, read its README, and added an entry. That tells you a server existed at some point. It does not tell you whether the endpoint still resolves, whether the maintainer changed the auth flow last month, or whether the process behind the URL has been down for a week. Repos do not go offline when their servers do — the listing just quietly goes stale.

The only way to know a server is live right now is to talk to it right now: send it a real MCP handshake and see what comes back.

What an actual check looks like

A real liveness check for an MCP server has a few concrete parts:

  • A real handshake. Not a ping to the domain — an actual MCP initialize call, the same request your AI client would send. If that round-trip fails, nothing downstream matters.
  • Auth behavior, observed. Does it accept a fresh client with no prior relationship, does it want an API key, or does it reject unknown clients outright? That last case is common enough to have its own failure mode — see the “unauthorized client” error for what it looks like from the client side.
  • A tool inventory from the source. What tools/list actually returns, not what the vendor’s marketing page says it returns.
  • A timestamp. A check without a “last verified” date is a claim, not evidence. Yesterday’s probe says nothing about today.

None of this requires special access. You can run the same initialize call yourself with the MCP Inspector — we walked through that in how to debug an MCP server with the MCP Inspector. The only thing a directory adds is doing it on a schedule, for every server, so you do not have to.

Connectivity is not binary

“Up” and “down” is also the wrong frame. In practice a server lands in one of three states: it connects cleanly for any new client, it requires an API key instead of OAuth, or it has a working OAuth endpoint that still rejects a client it has not pre-approved — a deliberate allow-list, not a bug. All three show up as failures to someone who only checks “does it respond,” but they call for completely different next steps. Knowing which one you are looking at before you build on top of a server saves a lot of debugging time later.

What reliability does not tell you

A server that answers every handshake correctly can still be a bad idea to connect. Tool descriptions can carry hidden instructions, a vendor can change what a tool does after you have already approved it, and an open endpoint says nothing about who else can read its code. Those are separate questions from uptime, covered in MCP prompt injection and tool poisoning and MCP rug pulls and drift detection. Liveness is the floor. It is not a security review, and treating a server that “just connects” as a server that is safe to connect is how teams end up trusting tools they never actually looked at.

Where gate fits: gate publishes a live reliability index for the remote servers in its directory — real handshakes run on a rolling schedule, with connectivity labels (connects cleanly, API key, or vendor-restricted), tool counts from each server’s own tools/list, and a last-checked timestamp per entry. We also ran the same question at registry scale in our probe of 516 MCP registry servers. Liveness and security are tracked separately: every server in gate’s directory also passes a free security scan before it is listed, and connecting through the gateway adds drift detection on top — you hear about it if a server’s tools change after you have already approved them.

The bottom line

Before you depend on an MCP server — for yourself, and especially for a team — check that it is actually live, not just listed: a real handshake, honest auth behavior, a tool list from the source, and a timestamp you can trust. Then, separately, check whether it is safe to use at all. The two questions look similar from the outside. They are not the same question, and a server can pass one and fail the other.