MCP Server Monitoring: Uptime, Drift and Tool Poisoning Checks

Monitor an MCP server by running the real handshake on a schedule: initialize, then notifications/initialized, then tools/list, confirming tools are returned. Add a hash of each tool definition to catch drift, scan new or changed descriptions for injection, and alert on state changes rather than every failed check.

Four failure modes

BusinessMCP’s monitoring guide names four ways an MCP server fails:

Failure	Type	How you notice
Server down or not speaking MCP	Availability	Handshake fails
Broken auth	Availability	Valid credentials refused
Changed tool definitions	Integrity	Hash differs from the approved one
Poisoned descriptions	Integrity	Scan flags new or changed text

The first two are what ordinary uptime monitors partly catch. The last two are specific to MCP and are usually missed entirely. A server can return HTTP 200 on its health route while serving tools that changed overnight.

Check the protocol, not just the port

A TCP or HTTP ping proves a web server is there. It does not prove an MCP server works. A useful check:

1. Send initialize.
2. Send notifications/initialized.
3. Send tools/list and confirm you get tools.
4. Follow nextCursor pagination, or tools on later pages look removed.

Treat a 401 as alive: the server wants credentials. The failure is a 401 when you present valid credentials. Include a monitoring credential with read-only scope so the check can go all the way to tools/list. For consumer assistants that use OAuth, also check that your metadata endpoints respond, since a broken one stops new sign-ins even while existing tokens work.

Detect drift with fingerprints

Models pick tools from their names, descriptions and schemas, so a quiet change to any of them changes behaviour. The fix is simple: hash each tool definition at the moment you approve it, store the hash, and compare it on every check.

Pin at least the name, description and input schema, using a canonical form with sorted keys so equivalent JSON hashes identically. One caveat from the guide: its own monitor hashes only name and description, reads up to 60 tools and uses the first 240 characters of each description, so it does not catch schema-only changes. If schema drift matters to you, pin full definitions in your CI pipeline.

Key takeaway: an approved tool list is a contract. Monitoring should tell you when the other side changes it.

Scan for poisoned descriptions

Descriptions can hide instructions: fake system tags, requests to send data elsewhere, tool shadowing, or credential reads. Scan only new or changed tools, to avoid repeated alerts about something you already reviewed. And keep expectations honest: a clean scan is a text screen, not a safety certificate. Pair it with least privilege and approval gates, as described in MCP server security best practices.

Alerting without noise

Alert fatigue kills monitoring. The guide’s pattern is sensible:

• Mark a server down after 2 consecutive failures.
• Send one recovery message after a down alert.
• Alert on each tool change once.
• Auto-pause a failing monitor after a threshold, such as 168 consecutive failures at hourly cadence, so dead monitors do not run forever.

Route alerts to the owner of the integration, not a general channel nobody reads.

Cadence and cost

BusinessMCP’s pricing for its monitor is $0.002 per scheduled check plus a $0.05 baseline scan at creation, with up to 25 monitors per workspace and free listing, pausing and deleting.

Interval	Checks per 30-day month	Cost
Hourly	720	$1.44
Every 6 hours	120	$0.24
Daily	30	$0.06

Choose hourly for customer-facing servers or automated workflows, and daily or six-hourly for tools used occasionally. New accounts get a one-time $5 trial for 7 days on first-party tools, per the guide. These are one vendor’s prices; if you build your own, the cost is mostly your own scheduler and alert routing.

Build your own versus use a hosted monitor

A simple self-built monitor is a script on a schedule: perform the handshake, hash definitions, compare, post to your alert channel. It takes an afternoon and costs nearly nothing. The downside is that someone must keep the script alive, which is exactly the kind of invisible chore that fails silently. A hosted monitor removes that chore. If you already use BusinessMCP’s MCP hosting, its monitoring is part of the same platform, though you should check how it fits your own servers.

A starting setup

1. Run a one-off handshake test before scheduling anything.
2. Create a read-only monitoring credential.
3. Approve your current tool list and store hashes.
4. Schedule hourly checks for important servers.
5. Alert after two consecutive failures and on any tool change.
6. Review alerts weekly and prune noise.

Monitoring is a line in the hosting requirements checklist, and its cost is small beside a silent outage, as the cost article shows.

What a good monitoring record looks like

Whatever tool you use, keep a record per server so alerts mean something:

Field	Why
Server URL and owner	Who gets the alert
Approved tool list with hashes	Baseline for drift
Last successful handshake	Quick health read
Spec revision implemented	Prompts upgrade reviews
Monitoring credential and scope	Read-only, rotated
Escalation route	What happens at 2 a.m.

Link the record to your runbook. When an alert fires on drift, the first question is always “did we change it?”, and a record answers it in seconds. When the answer is no, treat it as an incident: pause the affected agents’ write access, review the changed definitions, and read MCP server security best practices for containment steps. For third-party servers you do not control, drift alerts are your only warning that the vendor has changed what your agents see, so do not skip monitoring on them.

One last practical point: monitor the dependencies your server relies on as well. If your server calls an upstream API that is down, the handshake will pass while every real tool call fails. A synthetic call to one safe, read-only tool catches this. Read the full vendor description of its approach at BusinessMCP’s monitoring guide, and decide which parts you will copy.