Most MCP server outages don't look like outages. The process is running, the port is open, and a basic health check would say everything's fine — while agents connected to it are quietly failing or misbehaving. Here are the failure modes that actually show up in practice, roughly ordered by how often they slip past standard monitoring.
1. Tool schema drift
This is the big one, and it's specific to MCP in a way that generic API monitoring doesn't cover. A tool's input schema changes — a parameter gets renamed, a previously optional field becomes required, a type changes from string to enum — and the server keeps working perfectly for any client that happens to send the new shape. Clients that cached the old schema, or that build tool calls from an older spec, start getting rejected calls or, worse, calls that succeed with the wrong semantics.
How to catch it: snapshot the tools/list response on a schedule and diff it against the previous known-good version. Flag any change to required fields, types, or removed tools — not just any change at all, since descriptions and cosmetic wording shift more often and don't need to page anyone.
2. Handshake failures under load or config drift
The initialize handshake is the first thing any client does, and it's also one of the more fragile points — a bad deploy, a misconfigured environment variable, or a capability negotiation mismatch can break it while leaving other parts of the server (like a plain HTTP health endpoint) still responding fine.
How to catch it: don't just ping the port — actually run the handshake. A check that opens a connection and completes initialize end to end catches a category of failure a basic uptime ping never will.
3. Silent tool removal
A refactor drops a tool, or a feature flag disables it in production but not in staging, and tools/list quietly returns one fewer tool than before. Nothing errors. Any client relying on that tool starts failing at the point it tries to call something that no longer exists.
How to catch it: the same schema-diffing approach that catches drift catches removal — track the full list of tool names over time, not just the shape of each one.
4. Transport-level flakiness
MCP servers running over long-lived connections (rather than simple request/response) can develop connection stability issues that don't show up in a quick synthetic check but do show up under sustained real traffic — timeouts, dropped streams, or reconnect storms.
How to catch it: track handshake success rate over a rolling window, not just a single point-in-time check. A server that passes a check every five minutes but drops connections in between will look healthy on a dashboard while actually failing users constantly.
5. Slow degradation instead of hard failure
Sometimes nothing is technically broken — the handshake succeeds, tools/list returns correctly — but response latency has crept up to the point where clients start timing out on their own side. This is easy to miss because every individual check "passes."
How to catch it: track response time trends over time, not just pass/fail. A latency graph trending upward over a week is an early warning a binary health check will never give you.
6. Version/config mismatches across environments
Staging looks fine, production is running an older build with a different tool schema, and nobody notices until a client built against the newer schema hits production and fails. This isn't a code bug so much as a process gap.
How to catch it: run the same handshake-and-schema check against every environment you actually expect clients to hit, not just the one you remember to check manually.
The common thread
Every failure on this list shares the same property: a generic HTTP health check would miss it, because the server is technically "up" the whole time. Catching them requires actually speaking MCP — running the real initialize → tools/list sequence and paying attention to what comes back, not just whether something comes back.
That's the specific gap tools like MCP Vitals are built for: running the real handshake on a schedule, diffing schemas automatically to catch drift and silent removals, and alerting before your users find out the hard way. Whether you build that checking yourself or use something purpose-built for it, the underlying discipline is the same — monitor the protocol, not just the process.