MCPatrol is live: because a dead MCP server doesn't tell anyone

An MCP server that goes down doesn't announce it. No error on your screen, no bounced email. It just stops answering, and the first person to notice is whoever asked their AI assistant to do something and got a failure back. If that person is you, fine. It's usually not you.

I ship MCP servers — GitEasy's git commands run as MCP tools, WikiMint generates wiki documentation over MCP. I got tired of the version of monitoring where the user is the alarm. MCPatrol is what I built instead, and as of this week it's all public. The Android app is on Google Play, and the web console is live at app.mcpatrol.com. Same account, same list of servers.

What the prober actually does

You register your servers. A cloud prober checks each one every few minutes, from outside your network. Outside matters: a monitor that lives next to the server goes down with it.

The probe isn't a ping, either. It runs the MCP handshake, and a server that accepts the TCP connection but times out on initialize counts as down, because that's what your users would experience. The port being open isn't the same thing as the server working.

When a check fails, an incident opens and a push notification lands on your phone. When the server comes back, you get a recovery notice with how long it was out. Open incidents stay on the front page until they resolve. Resolved ones get out of the way.

Every check is on the record

MCPatrol records every probe: state, latency, timestamp. Server pages chart the history, p95 and average latency included, so when a server feels slow lately you can check whether it actually is. And when one is failing, the history shows when that started.

The tool-list problem

This is where MCP monitoring is different from ordinary uptime monitoring. An MCP server advertises its tools, and that list changes — a deploy renames one, drops one, adds three. Nothing is down. But a client built around the old list is now broken, and nothing anywhere said so.

MCPatrol watches the tool list too, and alerts when it changes. The drift shows up the day it happens, not a week later while you're debugging someone's automation that "just stopped working."

The phone and the browser

The Android app is the half that follows you around: push notifications, the estate at a glance, incident detail when something needs attention. The web console at app.mcpatrol.com is the same account and the same servers from any browser, no install. I wanted both from the start. An incident should be able to find me on the couch, and the follow-up shouldn't have to happen on a phone keyboard.

On the quiet parts: MCPatrol encrypts data at rest and moves it over TLS, and the app carries no ads and no analytics SDKs.

Where to get it

The tour at mcpatrol.com walks through the whole flow. The app is on Google Play, and the web console signs you in at app.mcpatrol.com.

---

How do you find out when one of your MCP servers stops answering? For a long time my answer was "when something downstream breaks," and I never liked it. If you have a better system — or you put your servers on patrol and it changes your answer — I'd like to hear about it.