How to Monitor Your MCP Server (Step-by-Step Guide)

MCP servers have quietly become production infrastructure. If you have shipped a Model Context Protocol server so that Claude, an agent, or a connector can call your tools, that endpoint is now on the critical path. When it goes down, or starts returning errors, your users feel it the same way they would feel any API outage. The difference is that most teams are not watching it yet.

This guide shows you how to set up real monitoring for an MCP server in a few minutes, so you find out about problems before your users do.

Why a normal uptime check is not enough

The instinct is to point an uptime monitor at the host and call it done. The problem is that an MCP server can be reachable and still be broken. A few failure modes we have seen in the wild:

• Session and transport bugs. A server running multiple processes can hand a request to the wrong process and return a 400 on every call, while the host itself keeps answering pings. A plain uptime check stays green for days.
• Auth expiry. An OAuth token or API key rotates or lapses and every tool call starts returning 401. The port is open, but nothing works.
• Latency creep. Cold starts or a slow dependency push response times past what an agent will wait for, so calls time out even though nothing is technically “down”.

None of these show up if you only check whether the host answers. You have to speak the MCP server’s own language and confirm it gives a healthy answer.

What “healthy” means for an MCP server

An MCP server over streamable HTTP is a JSON-RPC endpoint. The simplest meaningful health check is to send it a tools/list request, with the same auth a real client would use, and confirm two things:

1. It returns HTTP 200.
2. It returns in a reasonable amount of time.

That single call exercises the transport, the auth layer, and the tool registry all at once. If any of them is broken, the check fails. This is exactly the check you want running around the clock.

How to monitor an MCP server, step by step

Here is how to set it up with LoadFocus API monitoring. The same shape works for any MCP server you run.

Step 1: Create an API monitor

Create a new API monitor and set the method to POST and the URL to your MCP endpoint, for example:

POST https://your-domain.com/mcp/api

Step 2: Add the headers a real client sends

MCP clients authenticate and negotiate the response format through headers. Add these:

Authorization: Bearer YOUR_TOKEN
Content-Type: application/json
Accept: application/json, text/event-stream

Use a token with the same access a normal client would have. The Accept header matters because streamable HTTP servers can reply with either JSON or an event stream.

Step 3: Send a tools/list request as the body

Set the request body to a JSON-RPC tools/list call:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

This asks the server to enumerate its tools, which is a lightweight, read-only operation that touches every layer you care about.

Step 4: Assert on status and response time

Add an assertion that the status code equals 200. A healthy MCP server answers a tools/list in well under a second, so a real endpoint might return in around 80 milliseconds. Add a response-time assertion with a threshold that fits your target, for example fail if the response takes longer than 2000 milliseconds. Now a slowdown pages you before it turns into timeouts.

Step 5: Set a schedule and pick locations

Run the check on a schedule that matches how quickly you want to know about a problem. Every five minutes is a good default. Choose one or more regions close to where your clients connect from, and add a second region if you want to catch location-specific network issues.

Step 6: Wire up alerts

Attach the alert channels your team already lives in, such as Slack, Microsoft Teams, a webhook, or email. Set them to fire when a check fails and again when it recovers, so an incident opens and closes on its own. This is the step that turns a monitor into an early warning system instead of a dashboard you have to remember to look at.

What this catches

With this one check running, you are covered against the failure modes that matter:

• Outage. The endpoint stops answering, the status is not 200, and you get paged.
• Auth breakage. A rotated or expired credential returns 401, and the assertion fails.
• Transport and session errors. The 400-on-every-call class of bug is caught immediately, because a real JSON-RPC call fails even though the host is up.
• Latency regressions. A slow deploy or cold-start problem trips the response-time assertion before agents start timing out.

A few tips to get more out of it

• Monitor from more than one region. A regional network problem or a misbehaving edge can break access for some users and not others.
• Set a latency budget, not just an uptime check. Agents give up on slow tools. Treat response time as a first-class signal.
• Always alert on failure. A monitor no one is notified about is just a chart. Route failures to a channel someone watches.
• Define your monitors as code. If you run several MCP servers, keeping the checks in a monitoring-as-code file makes them repeatable and reviewable alongside the rest of your infrastructure.

Start monitoring your MCP server

MCP servers are real production endpoints now, and they deserve the same monitoring you already give your APIs. A single scheduled tools/list check with status and latency assertions and a failure alert covers the outages, auth failures, and slowdowns that would otherwise reach your users first.

Set up MCP monitoring with LoadFocus and get an alert the moment your server stops answering the way it should.

monitor MCP server