Your MCP server can stay perfectly reachable and still break every agent using it.
A renamed tool or a changed input schema returns a normal 200 with different JSON inside — nothing about that looks like an outage to a plain uptime check. It looks like a working server that happens to confuse every agent calling it.
"Schema drift" is already a named problem in the MCP ecosystem.
Practitioners have started writing about tool definitions changing on the server side with nothing corresponding on the client — silent enough that an observability dashboard catches the symptom (degraded output, a confused agent) without ever showing the cause.
"My MCP Tools Broke Silently" →
It's specific enough that dedicated tooling already exists for exactly this one signal — a real, if early, monitoring category on its own, not a feature anyone's invented from scratch.
Reachable the whole time. Broken the whole time, too.
-
A tool's input schema changes — a field renamed, a type tightened.
-
The server stays reachable. Every uptime check keeps passing.
-
Agents calling the old shape get malformed results or silent failures.
-
Someone notices degraded output days later — and has to guess why.
-
Same schema change happens.
-
The server stays reachable, same as before.
-
HeimPulse's next scheduled check re-fingerprints the tool list and catches the change.
-
A private alert names it before an agent's bad output does.
Two situations, same underlying check
Where HeimPulse sits doesn't change — only whose server it's watching.
You ship the MCP server.
You expose tools to agents — your own internal ones, or customers integrating against you. HeimPulse checks your production endpoint from the outside, exactly like it would check any API: reachability and latency continuously, tool-schema drift on its own schedule. An alert means your own deploy (or a dependency inside it) changed the contract without anyone flagging it in review.
You depend on someone else's.
Your agent calls out to a vendor's MCP server as part of its toolset. You have no visibility into their deploys and no service of your own to attach a check to. HeimPulse polls their public endpoint independently, on the same schedule your agent would hit it, and flags a change before your agent does something wrong with it in production.
The second case is newer and, today, the rougher edge: alert routing is org-wide by event type, not per-server, so tracking several unrelated dependencies means their alerts currently share one inbox. See the FAQ below before relying on this for more than a couple of dependencies at once.
How it works
-
1
Point HeimPulse at the server's URL. Your own, or a third-party one — no service or endpoint has to exist first.
-
2
It runs the real handshake. A JSON-RPC
initialize, thentools/list— the same calls an agent would make, on a recurring schedule. -
3
Each response is fingerprinted. Tool names and input schemas only — description text is excluded on purpose, so a prose edit never counts as drift.
-
4
A real change fires a private alert. Webhook, Slack, or email — never a public status page. Want uptime and latency too? Add the same URL as a regular monitored endpoint, on any plan including Free.
mcp.example.com
protocol 2025-06-18 · 6 tools
tools.vendor-api.com
protocol 2025-06-18 · 4 tools
Frequently asked questions
Is this the same as regular uptime monitoring?
Only half of it is. Reachability and latency for an MCP server work exactly like any other endpoint — that part is on every plan, including Free. Schema-drift tracking is a separate, standalone resource (Pro and Business): you point it at an MCP server's URL independently of any uptime check, and it fingerprints the tool schema on its own recurring schedule.
What exactly counts as "drift"?
A change to a tool's name or its input schema — a renamed tool, a changed parameter, one quietly dropped. A tool's description text is deliberately excluded from the fingerprint, so a copy edit on the server side never triggers a false alarm. Tool order and JSON key order are normalized away for the same reason — only a real structural change counts.
Do I need to run the MCP server myself to monitor it?
No. Schema-drift monitoring is a plain URL-based resource, independent of any service you've configured — the same reasoning HeimPulse's SSL certificate monitoring already uses (a certificate can back a host you don't run checks against either). You can track a third-party MCP server you depend on but don't control the deploys of, with nothing else configured.
Where do drift alerts show up?
Through whichever notification channels you've configured — webhook, Slack, or email — never on a public status page. It's a private change signal for whoever owns the integration, not a customer-facing status. One honest limitation worth knowing: routing today is by event type across your whole org, not per monitored server. If you're tracking several independent MCP servers, drift on any of them currently reaches the same configured channels — routing a specific server's alerts to a specific channel isn't built yet.
Which plans include this?
MCP reachability/latency monitoring is available on every plan, including Free. Schema-drift monitoring requires Pro or Business, and is currently in beta - the fingerprinting approach and the one-hour recheck interval are both still being tuned against real-world usage. See the pricing page for the full breakdown.
The same "watch a URL you don't run checks against" pattern, for TLS certificates → · All solutions →
Don't let a schema change be your agent's problem to discover.
Free plan, no credit card, set up in a few minutes.