Uptime isn't the whole story: monitoring MCP inventory drift
Classic monitoring asks one question: is it up? For a website that's most of the story. For an MCP server it's barely half, because the thing your users depend on isn't the process — it's the contract: the list of tools, resources, and prompts the server advertises, and the schemas behind them.
That contract moves. A dependency update adds a tool. A refactor renames one. A hosting
migration drops three and nobody notices, because the server still answers
initialize perfectly. Every uptime check stays green while every agent wired to
the missing tool starts failing in ways that look like the agent's fault.
Down is loud. Drift is silent.
When a server dies, you find out — users tell you, if nothing else does. Drift has no such
feedback loop. An agent that can no longer find export_repo_csv doesn't page
anyone; it hallucinates an alternative, or errors in a retry loop, or silently degrades. The
people debugging it usually start from the wrong end, because the server dashboard says
everything is fine.
What MCPatrol does about it
Alongside the health probe, MCPatrol periodically examines each server: a full MCP handshake that pulls the complete inventory — every tool, resource, and prompt. Each examination is stored as a snapshot, and each new snapshot is diffed against the previous one. A difference becomes a change event:
giteasy · tools · 3 h ago
+ delete_branch (new tool)
+ merge_queue_status
− export_repo_csv (removed)
22 tools → 23 toolsChange events get their own feed in the app and their own push notification, exactly like an incident — because operationally, that's what they are. A new tool appearing on a server your agents trust is a security-relevant event, not trivia: it changes what an agent connected to that server is able to do.
Three details that turned out to matter
- Diff against the last snapshot, not the last hour. Servers restart, probes miss, networks flake. Diffing consecutive successful examinations means a flaky window can't fake a "removed then re-added" pair of events.
- Record what was seen, not what was inferred. Every change event stores the actual added/removed names. When the answer isn't known — the examine failed — the app says UNKNOWN rather than guessing the inventory is unchanged.
- Both directions matter. Removals break agents today; additions are the ones worth reading carefully. A tool nobody reviewed showing up on a production MCP server deserves the same attention as a new SSH key.
Uptime tells you the server answered. Inventory tracking tells you what it answered with. For servers that AI agents act through, the second question is the one that bites.