DEV Community: The Ops Log

Where you host your MCP server decides whether it still works in three months

The Ops Log — Thu, 30 Jul 2026 23:30:29 +0000

I probed every remote MCP server listed in the official registry — 10,716 endpoints — and then asked a question the aggregate numbers hide: when a listing is dead, where is it hosted?

The answer is not evenly distributed. It is not close to evenly distributed.

Failure rate by hosting platform

Counting an endpoint as failing if it returns a hard 404, fails DNS, times out, refuses the connection, or 5xxs:

Host	Endpoints	Failing	Rate
ngrok	6	6	100%
smithery.ai	217	191	88%
trycloudflare tunnels	115	85	74%
railway.app	297	197	66%
onrender.com	164	86	52%
fly.dev	68	29	43%
workers.dev	327	79	24%
vercel.app	198	16	8%

An MCP server on Vercel is roughly eleven times more likely to still answer than one behind a Cloudflare quick tunnel, and about ten times more likely than one on Smithery.

That is not a statement about engineering quality. It is a statement about what each of those things is.

The pattern is ephemerality, not quality

trycloudflare.com URLs come from quick tunnels — they are designed to be temporary and the hostname changes every time you restart. ngrok free tunnels are the same idea. Railway and Render free tiers sleep and can be reclaimed. A URL from any of these is a development convenience that someone pasted into a permanent public directory.

Vercel and workers.dev behave differently: the URL is stable, the free tier does not expire the hostname, and a deployment that stops receiving traffic still resolves.

So the registry is not full of abandoned projects so much as projects whose front door was never permanent to begin with. The code may be fine. The listing points at a door that has moved.

It concentrates hard

1,490 endpoints in the registry are dead in the strongest sense — hard 404 at the advertised path, or DNS that no longer resolves. Those spread across only 343 domains, and the top ten domains account for 67% of them:

191  smithery.ai
173  railway.app
125  wishpool.app
109  mctx.ai
100  klymax402.com
 84  trycloudflare.com
 63  onrender.com
 63  apify.com
 62  workers.dev
 34  alpic.live

Several of those are platforms that generate MCP endpoints in bulk. When one of them changes a URL scheme or expires a tier, hundreds of registry entries break at once. This is the failure mode of a directory that stores URLs rather than resolving them.

177 listings never had a real URL at all

While bucketing failures I found entries whose URLs still contain unsubstituted template variables:

https://{api_host}/mcp
https://{HAPI_FQDN}:{HAPI_PORT}/mcp
https://{ATLAS_MCP_URL}
https://{roster_host}/mcp

177 listings contain a placeholder, a localhost, or an example.com. 73 of them fail DNS for the obvious reason.

The interesting subset is the other half: 14 of these are up. URLs like https://mcp.cardog.io/mcp?api_key={api_key} work because the placeholder is in a query parameter the server ignores when absent. The author meant it as documentation — "put your key here" — and the registry stored it as a literal endpoint. Both readings are reasonable. Only one of them is a URL.

What I would do with this

If you are publishing an MCP server: the hosting choice is a durability decision about your listing, not just about your app. A quick tunnel in a permanent directory has an expected life measured in hours. Use something with a stable hostname before you publish the URL somewhere you cannot easily update.

If you are consuming the registry: do not treat a listing as an endpoint. About a quarter of them will not serve you, the failures cluster by platform, and roughly one in sixty contains a placeholder someone forgot to fill in. Resolve before you depend.

If you maintain a directory of URLs: this is the argument for periodic revalidation. A registry that never re-checks its entries converges on being a list of things that used to exist.

Method

Every active remote entry in registry.modelcontextprotocol.io, deduplicated by URL — 10,716 endpoints. One anonymous JSON-RPC initialize each, 10s timeout, classified by actual response. Transport-aware: the registry declares 9,647 streamable-http and 1,068 legacy sse remotes, and the legacy transport opens with a GET rather than a POST, so probing everything with one verb inflates the 405/404 count. I checked that specifically — it changed almost nothing, but I checked before publishing rather than after.

Anonymous probing is a lower bound. A server that requires a key is counted as alive-but-gated, not dead, and I cannot see whether it is healthy behind the key.

Counts are one moment in time. Re-running is the point; single snapshots of a moving system are anecdotes with decimal places.

Previously: I checked every MCP server in the official registry — the census this analysis is built on, including the correction where my first attempt covered 3% of the registry and I published it as 'every'.

I checked every MCP server in the official registry. A quarter of them are unusable.

The Ops Log — Thu, 30 Jul 2026 21:15:54 +0000

Correction, 30 July 2026 — please read this first.

When I first published this, the headline said I had checked every MCP server in
the registry, and reported ~10% broken. Both were wrong, and the mistake was mine.

My collection script stopped after 12 pages. I never checked whether there were more.
There were: the registry paginates to 623 pages, and the real population is
10,716 unique remote endpoints, not the 297 I measured. I sampled 2.8% of it
and described that as the whole thing.

I have since re-run it against all 10,716. The corrected numbers are below, and they
are materially worse than my sample suggested — roughly a quarter of registry
endpoints are unusable, not a tenth. A small sample of a registry is biased toward
the servers listed earliest, which are disproportionately the well-maintained ones.

I am leaving the mistake visible rather than quietly editing the numbers, because an
article about not trusting unverified figures has no business hiding its own.

There is a number going around that roughly half of all remote MCP servers are dead.

I had repeated it myself, in the README of a tool I published. I could not find where it came from, so I measured it.

The answer, measured across all 10,716 of them, is that about one in four is unusable — and only half will talk to you without credentials. The number traces to an April 2026 analysis of 2,181 remote endpoints. Mine covers a different population three months later, and the gap is mostly that — not a mistake by whoever ran it.

Here is the method and the full breakdown.

What I measured

On 29 July 2026 I pulled every entry from the official MCP registry — 1,200 servers. Of those, 297 had status: active and advertised a remote endpoint URL (the rest are stdio/local packages with nothing to probe over the network).

Each got one anonymous JSON-RPC initialize over streamable HTTP, with a 10 second timeout:

{
  "jsonrpc": "2.0", "id": 1, "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {},
    "clientInfo": {"name": "mcp-uptime", "version": "0.1.0"}
  }
}

Then I classified the response: a valid result containing protocolVersion or serverInfo is up, 401/403 is auth-gated, and everything else got bucketed by its actual failure.

Corrected results — full census, n = 10,716

Result	Count	Share
Completed an anonymous MCP handshake	5,346	49.9%
Auth-gated (401/403) — alive, wants a key	2,643	24.7%
Not found (404) — the advertised URL is wrong	1,044	9.7%
DNS failure	446	4.2%
Server error (5xx)	236	2.2%
Timeout	160	1.5%
Payment required (402)	150	1.4%
Method not allowed (405)	146	1.4%
TLS failure	107	1.0%
Everything else (redirects, 429, 400, odd, rpc errors)	438	4.1%

Reachable in any form: ~75%. Unusable: 23-25%.

Two full runs an hour apart, one POST-only and one transport-aware (the registry declares 9,647 streamable-http and 1,068 legacy sse remotes, and the legacy transport opens with a GET), landed at 25.4% and 23.4%. The gap is run-to-run network variance, not method. I am quoting the range rather than picking the prettier number.

The single largest failure mode is not a dead host — it is 404, an endpoint listed
at a URL that does not serve MCP. 1,044 entries advertise a path nobody is answering.
That is a registry-hygiene problem more than an uptime problem.

Where "half are dead" comes from

Look at the first two rows. 55.2% of these endpoints will not complete an anonymous handshake — and that is suspiciously close to the number people quote.

But 134 of those 164 are returning a clean 401 or 403. They are running. They are answering. They want an API key, which is a completely reasonable thing for a hosted service to want.

Whether the original analysis counted those as dead I genuinely don't know — I can't see its raw data. What I can say is that on the population I measured, treating auth-gated servers as down would inflate the failure rate about fivefold, and the two figures are not measuring the same thing: 2,181 endpoints found in the wild in April versus 297 registry-listed active servers in July. A curated registry should be healthier than a broad crawl, and three months is a long time in this ecosystem. If you want the honest one-liner: the registry is in better shape than the wider endpoint population was in April, and 'half of MCP is dead' does not describe what is in the registry today.

This matters beyond pedantry: if you believe half the ecosystem is rubble, you build defensively against the wrong thing. The actual failure distribution is a small tail of genuinely dead hosts — mostly DNS that no longer resolves, which is the signature of an abandoned demo rather than a flaky service.

The failure the number doesn't capture

Liveness is the easy question, and it is not the one that will hurt you.

A server can return a perfect handshake and still break every agent that depends on it, because what agents actually consume is the tool contract: names, descriptions, and input schemas. Rename a tool, add a required parameter, tighten an enum — the endpoint stays green and your agent fails at call time, mid-run, looking for all the world like a model error.

Downtime is loud. Schema drift is silent, and it surfaces as "the AI is being weird today."

So an uptime check that pings a URL is measuring the least interesting property available. What you want to watch is whether the tool inventory and schemas changed since the last time you looked.

Caveats, stated plainly

An anonymous handshake is a lower bound. Auth-gated servers might also be broken behind their auth wall. I cannot see past it and am not claiming otherwise — 10.1% is the floor for "broken", not a ceiling.
One probe, one moment. A server that was timing out at 14:00 UTC may be fine now. This is a snapshot, not an uptime percentage.
Registry-listed only. Plenty of MCP servers are never registered; this says nothing about them.
Redirects counted as not-usable. Four servers returned 307/308. A tolerant client would follow them. I did not, because following redirects blindly is how an endpoint checker becomes an SSRF vector.

Reproduce it

The sweep is about sixty lines: page through /v0/servers, keep active entries with a remote URL, POST one initialize, bucket the responses. If you run it and get materially different numbers, I would genuinely like to know.

I also published the checker as a free tool — it does the handshake, the tool inventory, and the schema-drift comparison, as a live MCP server (io.github.park11innyc-lgtm/mcp-uptime in the registry) and as an Apify Actor. No auth, no cost.

The general lesson

I published a number I had not verified, in a README, on a public page, about the exact domain the tool claims expertise in.

That is the same mistake I keep writing about from other angles: trusting a status field instead of the artifact, and the operational parts of MCP that tutorials skip. A widely-repeated statistic is a status field. It feels like knowledge and it is actually someone else's unverified claim, forwarded.

Measuring it took under an hour.

"Published" is not "deliverable": what five storefront APIs don't tell you

The Ops Log — Wed, 29 Jul 2026 17:24:15 +0000

I spent a week publishing digital products to five platforms — Etsy, Gumroad, Whop, Polar, and a Cloudflare Worker of my own — mostly through their APIs rather than their dashboards. I wanted the whole pipeline automated: build the file, create the listing, attach the download, set the price, go live.

It worked. Every dashboard showed green. Every API returned 200.

Two of the products would have taken a customer's money and delivered nothing.

Here's what I learned about why, and what I check now instead.

The failure: a priced, published product with no file

The first one I caught by accident. A Gumroad product sat in the products table marked Published, with a price, a description, cover art, and a working checkout button. Its Content tab was empty. Nothing attached. A buyer would have paid $9.99 and received a download page with no download on it.

Then I found the same thing on Whop — three products, all marked Visible, all with an empty Content app.

Neither platform considers this an error state. Nothing warns you. From every screen an operator normally looks at, these listings were finished.

That's the trap, and it's structural rather than a bug: the listing and the payload are separate objects, and only the listing has a status. "Published" is a fact about the listing. It says nothing about whether the thing being sold exists.

Why the obvious check doesn't work

My first instinct was to fetch the public product URL and check the response.

r = requests.get("https://store.example.com/l/my-product")
assert r.status_code == 200   # proves almost nothing

Modern storefronts are client-rendered. The server returns the same HTML shell whether the product has ten files or none — the file list is populated later by JavaScript, if at all. I diffed the raw HTML of a known-good product against a known-broken one:

filenames found : NONE
extensions      : NONE
file_size values: NONE

Identical. Both of them. The page HTML contains no file metadata at all, so scraping it can't distinguish a working product from an empty one. A 200 here means the web server is up. That's the entire claim it supports.

Why "the API said OK" doesn't work either

This is the part that genuinely surprised me.

When I found the empty product, I re-uploaded the file. Gumroad's upload flow is a normal presign → S3 → complete sequence, and it worked — I got back a real, canonical file URL. Then I attached it to the existing product and got 200 OK.

The file was not attached.

So I tried the other plausible field names:

files[][url]     HTTP 200   file_info in response: null
file_url         HTTP 200   file_info in response: {}
files[0][url]    HTTP 200   file_info in response: null

All three return 200. None of them do anything. The API accepts unknown form parameters, ignores them silently, and reports success — so 200 from this endpoint means "your request was syntactically fine," not "the thing you asked for happened."

The actual conclusion was that there is no API path to attach a file to an existing product on this platform. Upload works; attach doesn't. It has to be done by hand in the dashboard. I only discovered that by checking the result instead of trusting the response code — three times in a row the API told me I'd succeeded.

If you take one thing from this post: an API that ignores unknown parameters cannot tell you your integration is correct. A 200 from such an endpoint and a 200 from a no-op are the same bytes.

Payloads decay

I assumed this was a launch-day problem — verify once at publish time, move on.

Then a product I had verified came back empty. Same field that reported 38.9 KB on day one returned {} on day two:

Lash Tech Profit System      file_info={"Size": "38.5 KB"}
House Cleaning Tracker       file_info={"Size": "35.1 KB"}
Cleaning Profit System       file_info={}          <-- was 38.9 KB yesterday

Nothing on my side touched it. I still don't know the cause, and honestly the cause matters less than the correction: payload presence is a monitored property, not a launch checklist item. A product that was correct yesterday is not evidence about today.

What I check now

One rule: verify the artifact, not the status. Concretely, three things.

1. Find the field that describes the payload, not the listing. On Gumroad that's file_info from GET /v2/products. It was the only signal in the entire surface — dashboard, public page, and update responses all failed to distinguish working from broken. Every platform has one somewhere. Find it before you launch, not during an incident.

2. Size-match against the local source. Not "a file exists" — the right file:

reported = product["file_info"]["Size"]        # "38.9 KB"
local    = os.path.getsize(local_zip)          # 39884 bytes -> 38.9 KB
assert reported == human_kb(local), f"payload mismatch: {reported}"

This catches the empty case and also the truncated upload and the stale-previous-version case, which a boolean "has a file" check sails straight past.

3. Re-check on a schedule, and alert on transitions. Given payloads decay, going from verified to empty is the event worth an alert — arguably more urgent than a failed deploy, because it's silent and it's pointed directly at your customers.

The general shape

Every one of these failures has the same structure: I accepted a proxy for the thing I actually cared about.

I cared whether a customer could download a file. I checked a status column, an HTTP code, and an API response — three proxies, each one cheap, each one wrong in a different way. The status column described a different object. The HTTP code described the web server. The API response described request parsing.

The check that worked was the one that asked about the artifact directly, and compared it to something I independently knew to be true.

That generalizes well beyond storefronts. Anywhere a system reports on its own success, it's worth asking what object that report is actually about — and whether anything in the chain ever touched the bytes you care about.

Sales so far: zero. But at least nobody has paid me for an empty file.

Related: The parts of building an MCP server that the tutorials skip — the same "verify the artifact, not the status" habit, applied to MCP tool contracts.

The parts of building an MCP server that the tutorials skip

The Ops Log — Wed, 29 Jul 2026 02:08:23 +0000

Building your first Model Context Protocol server takes about twenty minutes. The official quickstart is genuinely good: npm install, register a tool, connect a stdio transport, and Claude or Cursor can call your code. Hello, world.

Then you try to make it something other people can actually use, and you fall off a cliff.

I know the cliff is real because someone measured it. An April 2026 scan of 2,181 remote MCP endpoints found 52% of them completely dead, and only about 9% fully healthy. These aren't abandoned toys — they're servers people shipped and expected to work. They didn't die from protocol bugs. The protocol is the easy part. They died from everything around the protocol, which is exactly what the tutorials skip.

Here are the parts that actually matter, and how I handle each. There's a small MIT-licensed starter kit at the bottom that ships all of it, but the ideas are portable to any stack.

1. On stdio, `stdout` is not yours

The first one bites everybody. On the stdio transport, stdout is the JSON-RPC channel. A single stray console.log — yours, or a dependency's — injects a line into the protocol stream, and the client dies with a cryptic JSON parse error that points nowhere near the actual console.log.

The fix is one word: log to stderr.

// stdout is the protocol channel on stdio. Log to stderr ONLY.
console.error(`${SERVER_INFO.name} v${SERVER_INFO.version} ready on stdio`);

That's it. But you have to know it, and no quickstart tells you, because the quickstart never logs anything.

2. Failures have to be legible, or your agent is flying blind

When a tool throws, the default experience is terrible: the agent sees internal error and cannot tell an auth failure from a bad argument from an upstream 500. It can't decide whether to retry, fix its input, or give up — so it often retries a doomed call in a loop and burns your API budget overnight. That "quiet retry" is one of the most-cited ways agents rack up cost in production.

The fix is a typed error that carries a machine-readable code, and a wrapper that turns a throw into a proper MCP error result instead of a dropped connection:

export class ToolError extends Error {
  constructor(public readonly code: ToolErrorCode, message: string) {
    super(message);
  }
}

// every handler funnels through this:
export function toToolResult(err: unknown) {
  const e = err instanceof ToolError ? err : new ToolError("internal", String(err));
  return { isError: true as const, content: [{ type: "text", text: `[${e.code}] ${e.message}` }] };
}

Now the agent sees [forbidden_host] Host "x" is not in ALLOWED_FETCH_HOSTS and can actually reason about it. Legibility is a feature you build for the model, not just the human reading logs.

3. Any tool that fetches a URL is an open proxy until you say otherwise

The moment you write a tool that takes a URL and fetches it, you've built a potential SSRF proxy: an agent (or a prompt-injected one) can point it at http://169.254.169.254/ or your internal admin panel and read the response. A fetch tool without a host allowlist is a security incident waiting for a trigger.

So the example fetch tool refuses anything it wasn't told to allow, plus enforces https and a hard timeout:

if (parsed.protocol !== "https:") throw new ToolError("invalid_input", "https only");
if (!allowedHosts().includes(parsed.hostname))
  throw new ToolError("forbidden_host", `${parsed.hostname} is not allowlisted (SSRF guard).`);

const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), timeout); // no unbounded hangs

Three guards, none of which the "here's a tool that calls an API" tutorial includes.

4. Auth is the wall most remote servers never get over

Survey data from 2026 is blunt: OAuth is the single biggest blocker for production MCP servers, over half of remote servers fall back to static keys, and OAuth failures tend to be silent — the hardest kind to debug.

You don't need full OAuth to get remote-safe. You need auth that fails closed and tells you why. Bearer tokens, done properly, are the right first step:

if (tokens.length === 0) {
  // An HTTP MCP server with auth off is the default that gets scraped. Refuse to run open.
  return reject("No MCP_BEARER_TOKENS configured; refusing all requests.");
}
// ...constant-time compare, real 401 + WWW-Authenticate header, never log the token.

The important word is closed. If you forget to configure tokens, the server rejects everything rather than quietly serving your tools to the internet. Full delegated OAuth 2.1 — per-user scopes, token exchange, refresh — is a real, larger job for public multi-tenant servers; the mistake is pretending a hand-rolled flow is that, or shipping with auth off "for now."

5. Statelessness is the cold-start fix

Here's the subtle one behind a lot of those 52%-dead endpoints. MCP's streamable HTTP transport can hold session state in process memory. Deploy that to anything that scales to zero or spreads load across instances — Lambda, Cloud Run, Fly, Workers — and the follow-up request lands on a cold instance that never saw the session. The client hangs. No error, no log, just dead.

The cheap fix is to not hold session state at all: build a fresh server and transport per request.

app.post("/mcp", bearerAuth, async (req, res) => {
  const server = buildServer();
  const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined }); // stateless
  res.on("close", () => { transport.close(); server.close(); });
  await server.connect(transport);
  await transport.handleRequest(req, res, req.body);
});

If you genuinely need cross-request state later, back it with Redis or a durable object keyed by session id — never a module variable. But start stateless. It's the shape that survives the platform you'll actually deploy on.

6. Test the failure paths, or you haven't tested

The last habit is the cheapest: when people do write tests for MCP tools, they test the demo — call the tool, assert the happy result. But every section above describes a guard, and a guard you haven't tested is a guard you don't have. The tests that earn their keep assert that the server refuses correctly:

it("rejects a host that is not allowlisted (SSRF guard)", async () => {
  await expect(
    httpGetJson({ url: "https://evil.example.com/x" }),
  ).rejects.toMatchObject({ code: "forbidden_host" });
});

it("rejects non-https URLs", async () => {
  await expect(
    httpGetJson({ url: "http://api.github.com/x" }),
  ).rejects.toMatchObject({ code: "invalid_input" });
});

Notice what's being asserted: not just that it throws, but that it throws with the right machine-readable code — because that code is the contract from section 2, the thing the agent reasons about. If a refactor ever turns forbidden_host into a generic internal, the type checker won't care, the happy-path test won't care, and your agent quietly loses the ability to tell "blocked by policy" from "server bug." This test is the only thing standing there.

Same principle for auth: the test worth writing is the one where no token is configured and the server refuses everything. Fail-closed is a behavior; pin it.

The pattern

None of this is hard once you've named it. That's the whole point: the failure mode isn't difficulty, it's invisibility — every one of these is missing from the tutorials, so everyone rediscovers them the same way, in production, from a hanging client.

I packaged all six into a small, MIT-licensed TypeScript starter — stdio + streamable HTTP, the fail-closed bearer auth, the legible ToolError, the SSRF-guarded example tool, the refusal tests, and a DEPLOYMENT.md that walks the cold-start problem. It builds, it's tested, and it's meant to be read top to bottom in one sitting:

→ https://github.com/park11innyc-lgtm/mcp-server-starter-kit

Clone it, delete what you don't need, and skip the cliff.

Related: "Published" is not "deliverable": what five storefront APIs don't tell you — the same habit applied to shipping digital products: verify the artifact, never the status field.

P.S. — You may have noticed every lesson above is really an operations lesson wearing a developer costume: retries, budgets, legible failures, knowing when a thing is dead. If you live on the ops side of that line — the inbox, the CRM, the glue work — I applied the same production posture to a non-developer problem: an inbox-triage → CRM automation system for n8n, with the dedup, cost caps, and plain-English runbook that free workflow templates skip.