How to Monitor an MCP Server and Get Alerted When Your Agents Lose a Tool

If you run a Model Context Protocol (MCP) server, you have a new kind of user: an AI agent. It does not read your changelog, it does not retry politely, and it does not file a bug report. When your server stops answering or a tool it relied on gets renamed, the agent quietly fails the task, and the person who asked for that task blames the agent, not your deploy.

Classic uptime monitoring does not catch this. A ping to your MCP endpoint can return HTTP 200 while the server fails the MCP handshake, rejects the token your agents use, or advertises half the tools it did yesterday. This guide explains what actually breaks between an agent and an MCP server, what a useful monitor checks, and how to set one up in a few minutes with AlertsDown MCP alerts.

Why an HTTP check is not enough for MCP

An MCP server is a small protocol on top of HTTP. Before an agent can call anything, it has to complete an initialize exchange, then list the tools, resources, and prompts the server advertises. Each of those steps can fail while the HTTP layer looks fine:

• The process is up, the protocol is down. A bad deploy can leave the endpoint answering requests but returning malformed JSON-RPC responses or rejecting initialization. HTTP says 200, agents say nothing works.
• Authentication drifted. A rotated bearer token or a renamed header turns every agent request into a 401 or 403. A monitor that pings without credentials never sees it.
• A tool went missing. You renamed list_orders to orders_list, or a feature flag hid a tool in production. The server is healthy by every infrastructure metric, but the agent prompt that depends on that tool now fails.
• Capabilities shrank silently. Resources and prompts are part of the contract too. Removing one rarely triggers an error on your side, only on the agent's.

None of these show up on a status page built from TCP or HTTP checks. They show up in a user's chat window as "I couldn't complete that".

What a good MCP monitor checks, in order

Think of an MCP check as a short conversation that mirrors what a real agent does on connect. Each stage can fail on its own, and knowing which stage failed is most of the diagnosis.

1. Reachability. Can the endpoint be reached at all within the timeout? A network error or a DNS failure here means the host is down, not the protocol.
2. Authentication. With the same credentials your agents use, does the server accept the request? A 401 or 403 at this stage means auth is broken, even if the server would work for someone else.
3. Initialize. Does the server complete the MCP initialize handshake over the Streamable HTTP transport? This is the step a plain uptime check skips entirely.
4. Capability discovery. Does the server still advertise the tools, resources, and prompts you expect, by exact name? This is where renamed or removed tools are caught.

AlertsDown maps these stages to three outcomes. A failure in reachability, authentication, or initialization marks the monitor down. A successful handshake with missing expected capabilities marks it degraded, because agents can still connect but some prompts will fail. Everything present means up. The distinction matters for your alert routing: a degraded server at 3 a.m. may wait until morning, a down one may not.

Set up an MCP monitor in AlertsDown

MCP Server Monitoring is available on Indie Builders and above. You need the endpoint URL your agents connect to and, if the server is protected, a credential with read access.

1. Add a monitor. Sign in, open My URLs, choose Add URL, and switch Monitor Type from HTTP / Website to MCP Server.
2. Enter the endpoint. Paste the Streamable HTTP URL agents use, for example https://your-app.com/mcp. Pick a check interval allowed by your plan, down to every minute on paid plans, and a timeout. The default timeout is 15 seconds, which is generous for a handshake and a capability listing.
3. Add authentication. Choose no auth, a bearer token, or a custom header. Use a dedicated read-only credential for monitoring rather than a production agent's token, so you can rotate it independently. AlertsDown stores the secret encrypted and never returns it in full after you save it.
4. List expected capabilities. Type the exact names of the tools, resources, and prompts your agents depend on. Start with the two or three that matter most. Leave alert on missing capabilities enabled so a deploy that drops one of them raises an alert even though the server is technically up.
5. Choose alert channels. Route failures to the contacts you already use for website monitoring: email, the Chrome extension, SMS, Signal, Telegram, WhatsApp, or a webhook, depending on your plan. Recovery notifications are off by default for MCP monitors, so turn them on if you want a message when the server comes back.
6. Check the first result. The monitor's logs show which stage ran and which one failed. Fix anything the first check surfaces, such as a wrong transport URL or a token without permission to list tools.

From then on, each scheduled check repeats the same handshake from outside your infrastructure, the way an agent would.

Which expected capabilities to list

Listing every tool is tempting, but it makes the monitor noisy every time you add or rename something minor. A better approach:

• Tools your production prompts call by name. If a prompt template or an agent workflow references create_ticket, that name is part of your public contract. Monitor it.
• Tools that other teams or customers depend on. Anything documented for external use.
• One resource and one prompt, if you expose them. This confirms the server advertises more than tools and catches a partial registration bug.

Skip internal or experimental tools. If you rename a monitored tool on purpose, update the monitor in the same change, the same way you would update an API client.

Common MCP failures and what the alert tells you

What you see	Likely cause	Where to look
Down at the reachability stage	Host, DNS, or load balancer problem	Hosting provider, DNS records
Down with HTTP 401 or 403	Rotated or expired token, header renamed	Secret store, reverse proxy auth rules
Down at initialize	Deploy broke JSON-RPC handling or the transport path	Latest deploy, server logs around the initialize request
Degraded with missing tools	Tool renamed, removed, or hidden behind a flag	Tool registration code, feature flags
Degraded with missing resources or prompts	Partial registration or a startup error in one module	Server startup logs

Because each alert names the failed stage and the missing capability names, you usually know whether to page an infrastructure person or a developer before you open a terminal.

Monitoring vendor MCP servers you rely on

The same monitor works for MCP servers you do not operate. If your product's agent depends on a vendor's hosted MCP endpoint, add it with the credentials you use in production and list the tools your workflows call. When the vendor ships a breaking rename, you learn about it from an alert instead of from a customer, and you have a timestamped log to share with their support team.

Keep probes polite on third-party servers: use the longest check interval that still gives you useful warning, and never configure anything that writes data.

MCP alerts versus the AlertsDown hosted MCP

The two are easy to confuse, so one line on each. MCP alerts are monitors that AlertsDown runs against MCP servers you add, which is what this article covers. The hosted MCP is AlertsDown's own MCP endpoint that your coding agent or assistant connects to in order to create monitors, read status, and manage your account. You can use both: let an agent create and adjust your monitors through the hosted MCP, and let MCP alerts watch the servers that agent depends on.

Start with the server your agents hit most

Pick the MCP server whose failure would break the most conversations, create a monitor for it, list its two or three critical tools, and send alerts to the channel you check first. It takes a few minutes, and the next time a deploy drops a tool, you will know before your agents' users do. For the full feature overview and FAQ, see the MCP alerts page.