There's a growing pile of tools that claim to "monitor MCP servers," and they range from generic uptime checkers with an MCP label bolted on to purpose-built tools that actually parse the protocol. The difference matters, because a server can be reachable and still be broken in a way only an MCP-aware check would catch. Here's what to actually evaluate.
Does it speak MCP, or just HTTP?
The baseline question: does the tool run the real protocol exchange, or does it just confirm a port answers? Generic uptime monitors — the UptimeRobot/Pingdom/BetterStack category — check whether an endpoint returns a 200 or a TCP port accepts a connection. That's necessary but nowhere near sufficient for MCP, because a server can be up at the transport level while failing to negotiate capabilities correctly, returning a broken tool schema, or hanging mid-handshake. An MCP-aware check speaks JSON-RPC, completes the actual handshake, and confirms the server exposes the tools it claims to.
Concretely, ask any candidate tool: does it parse the JSON-RPC envelope and check for an error field even when the transport status is 200? A "successful" HTTP response can still carry a JSON-RPC error in the body, and a tool that only checks status codes will miss it every time.
Schema drift detection
This is the single biggest differentiator between a generic monitor and a real MCP monitoring tool. MCP has no built-in versioning enforcement — a server can rename a tool parameter, tighten a type, change an enum, or drop a tool entirely, and nothing in the protocol announces it. The only way to catch it is to store a baseline tools/list response and diff every subsequent one against it.
Look for a tool that:
- Stores tool-schema history, not just the latest snapshot.
- Flags the specific field that changed (not just "something changed").
- Alerts on drift separately from availability, so you're not stuck reading through generic status noise to find the change that could actually break a client.
Protocol-version awareness
The 2026-07-28 MCP spec is a genuine dividing line: it drops the initialize/initialized handshake in favor of server/discover and moves version negotiation into _meta on every request. For a while, you'll have servers on both sides of that line. A monitoring tool that hardcodes the old handshake will start reporting false failures against newer servers, and one that assumes the new flow will break against anything not yet migrated. Ask whether the tool tracks which protocol version a server is actually running and adapts its checks accordingly — this is exactly the kind of detail that separates tools built by people paying attention to the spec from ones that shipped once and stopped.
Auth-aware checks
The same spec update makes MCP servers formal OAuth 2.1 resource servers, with mandatory Protected Resource Metadata (RFC 9728) and token binding via Resource Indicators (RFC 8707). A monitoring tool doesn't need to be an auth testing suite, but it's worth checking whether it can at least confirm your metadata endpoint is reachable and correctly formed — misconfigured auth metadata is an easy thing to ship by accident, and it's the kind of failure that only shows up when a new client tries to connect, not when you eyeball the server yourself.
Alerting that doesn't create noise
A tool that pages you for every transient blip trains your team to ignore it. Look for configurable thresholds, a clear split between "the server is down" and "the server responded but its contract changed," and enough context in a drift alert to triage without manually re-diffing the schema yourself (old value, new value, which tool, which field).
A public status signal
If other teams or external integrators depend on your server, a public health badge is worth more than it sounds like it should be — it lets people self-serve the answer to "is this broken, or is it just my client?" without opening a ticket. Not every monitoring tool offers this; it's worth checking for explicitly if your server has any external consumers.
Historical data, not just a current snapshot
A single point-in-time check tells you almost nothing about whether a P95 latency spike this week is normal or new. Favor tools that retain history and let you look at trends — percentile latency over time, error-rate trends, and a timeline of schema changes — over ones that only show you the current state.
The short checklist
- Runs the actual MCP handshake, not just a port or HTTP check
- Diffs
tools/listagainst a stored baseline and flags specific field changes - Tracks protocol version per server and adapts checks for the 2026-07-28 transition
- Surfaces auth-metadata issues, not just tool-call failures
- Separates availability alerts from schema-drift alerts
- Offers a public status badge for external consumers
- Keeps history, not just current status
MCP Vitals was built around this checklist specifically — real handshake checks, schema-drift diffing, and a public badge — rather than as a generic monitor with MCP support added on. Whichever tool you pick, make sure it's actually checking the protocol, not just the port.