--- title: MCP Server Monitoring & Tool Drift Alerts description: MCP server monitoring: a real initialize handshake and tools/list on every check, timed per phase, and an alert when a tool's description or schema changes. canonical: https://watchfor.io/mcp-monitoring --- New AI # MCP Server Monitoring That Runs the Real Handshake An MCP server can return 200 and still fail every agent. WatchFor connects like an agent does and alerts when tools vanish or their descriptions change. [Get started for free](/auth/sign-up)[View pricing](/pricing) ## What Each MCP Check Does An HTTP check sees a status code. An MCP check sees the session, the negotiated version and the tools ### Real Initialize Handshake Each check sends a JSON-RPC initialize over Streamable HTTP, accepts JSON or SSE responses, handles Mcp-Session-Id and MCP-Protocol-Version as the spec describes, sends notifications/initialized and records the protocol version the server negotiates. ### Full Tool Inventory tools/list is walked through every page of results. Tool names, descriptions and input schemas are hashed into one fingerprint, and the monitor shows how many tools, resources and prompts the server exposes. ### Drift and Rug-Pull Detection Tool descriptions go straight into an agent's context, so a changed description changes what the agent does. When a tool is added, removed or rewritten, the Tool Inventory Changed rule (on by default) fires, and the monitor's Inventory changes timeline shows which tools changed. ### Protocol Version Pinning Enter the version your clients depend on, such as 2025-11-25, on the Protocol Version Mismatch rule. The check offers exactly that version, so the rule fires when a deploy or an SDK upgrade stops speaking it. ### Phase-Level Latency DNS, TCP, TLS, initialize and tools/list are timed separately. A serverless cold start shows up as a slow initialize; a network problem shows up in DNS or TCP. The Slow Handshake rule alerts past a threshold you set. ### Auth-Aware Checks Add a bearer token in the monitor settings, or extra headers such as X-API-Key through the API. A rejected or expired token is reported as an auth failure with the HTTP status and the phase it happened in, not as a timeout. ### Empty-Server Detection A server that completes the handshake but exposes zero tools is useless to every agent. The No Tools Exposed rule is on by default and opens an incident when the list comes back empty. ### Alerts After Consecutive Failures The availability rule opens an incident after 3 consecutive failed checks, so one dropped connection does not page anyone. Incidents go to the same channels as every other monitor: email, Slack, Discord, PagerDuty, webhooks and the rest. ## A closer look Server version, protocol, handshake timings and the full tool inventory. Alert on tool changes, on zero tools or on a protocol version mismatch. Each check stores the reply: protocol, capabilities and every tool. ## Why MCP Servers Need Their Own Monitor Claude and ChatGPT connectors, IDE agents like Cursor and internal copilots all depend on two things: a completed handshake and an accurate tool list. An ordinary uptime check sees neither. The port answers while initialize fails behind a proxy that buffers SSE. The process starts while tool registration fails. A compromised dependency rewrites a tool description into a prompt injection, and every response is still 200 OK. An MCP monitor checks the protocol itself, so these turn into incidents instead of bug reports from confused agent users. [Start monitoring now](/auth/sign-up) Catches 'HTTP up, MCP down', which a health endpoint cannot see The tool inventory is recorded on every check, with a timeline of changes A changed tool description raises an alert instead of going unnoticed The negotiated protocol version is watched across deploys and SDK upgrades Rejected tokens are named as auth failures, with the HTTP status Cold starts and proxy buffering show up in their own phase timing Certificate expiry and TLS version come from the same handshake A regular monitor on every plan, Free included ## How MCP Monitoring Works A full protocol session on every check 1 ### Point It at Your Endpoint Create an MCP Server monitor with your endpoint URL, for example https://mcp.example.com/mcp. Add a bearer token if the server requires one. 2 ### Each Check Runs a Full Session initialize, notifications/initialized, tools/list with pagination, resources/list and prompts/list when the server advertises them, then a DELETE to end the session. tools/call is never sent. 3 ### The Inventory Is Fingerprinted Tool names, descriptions and input schemas are hashed into a fingerprint. The first check records the baseline; every later check compares with the inventory it saw last. 4 ### Each Failure Has Its Own Rule A failed handshake, an empty tool list, a slow handshake, a version mismatch and inventory drift are separate rules with separate incidents. Pin a protocol version on the Alerting tab if you want that rule too. ## Who Monitors Their MCP Servers If agents depend on it, it is production ### Teams Shipping Public MCP Servers Your MCP server is the API agents use. A broken handshake or a missing tool is an outage for your customers, even while HTTP still answers and your status page is green. ### Companies Running Internal Agent Infrastructure Internal copilots wired to company MCP servers fail quietly: the agent stops using a tool and nobody files a ticket. A protocol check opens an incident after three failed checks in a row. ### Security-Conscious Platform Teams Every MCP server your organization connects to is a prompt-injection surface. Point monitors at third-party servers too: drift detection tells you on the next check that a tool description changed, before an agent acts on it. ### Framework & SDK Maintainers Reference servers and hosted demos break with spec revisions. A pinned protocol version plus a handshake check catches the upgrade that negotiates a version your clients do not expect. ## Frequently asked questions Everything you need to know about MCP server monitoring [All questions→](/faq)[Ask us directly](/contact) What is MCP server monitoring? It is uptime monitoring that speaks the Model Context Protocol instead of only HTTP. Every check performs the JSON-RPC initialize handshake over Streamable HTTP, records the negotiated protocol version, discovers capabilities and walks the full tool inventory. It verifies that the server works the way an AI agent needs it to, not just that the port answers. Why isn't a normal HTTP check enough for an MCP server? What is tool drift detection? What is an MCP rug-pull? Which MCP transports are supported? Does monitoring call my tools? Can I monitor an authenticated MCP server? How often is an MCP server checked? Can my own AI agents use WatchFor over MCP? How much does MCP monitoring cost? ## From our blog Guides, deep-dives, and best practices from the WatchFor team [Monitoring ### The agentic supply chain: monitoring MCP servers you host — and the ones you only consume Aug 23, 2026·5 min readRead article](/blog/mcp-agentic-supply-chain)[Monitoring ### MCP Server Monitoring: Why "HTTP 200" Means Nothing to an AI Agent Jul 30, 2026·5 min readRead article](/blog/mcp-server-monitoring)[Engineering ### What it actually took to make a monitoring platform agent-ready Aug 28, 2026·7 min readRead article](/blog/what-it-took-to-make-monitoring-agent-ready) ## Find Out Before Your Agents Do Add your MCP endpoint and the first check records the tool inventory. From then on, a broken handshake, an empty tool list or a changed tool description opens an incident. Start on the free plan, no credit card required. [Get started for free](/auth/sign-up)[View documentation](/docs/monitors/mcp) --- Canonical page: https://watchfor.io/mcp-monitoring · Site guide: https://watchfor.io/llms.txt