An MCP server is up when a client can complete the initialize handshake, agree a protocol version, list its tools and get answers fast enough. Monitor a remote server over Streamable HTTP by running that handshake on a schedule with a monitoring token, asserting the tools you depend on exist, and alerting when the tool list changes unexpectedly.
What is an MCP server?
The Model Context Protocol (MCP) is an open protocol for connecting AI applications to tools and data. An MCP client, built into an assistant, an IDE or an agent framework, connects to an MCP server, which exposes capabilities: tools the model can call, resources it can read and prompts it can use. Messages between them are JSON-RPC 2.0 requests, responses and notifications.
Once an agent relies on a server for real work, such as searching tickets, querying a database or creating a deploy, that server becomes production infrastructure. When it breaks, the failure is often quiet: the agent stops seeing a tool, or tells the user it cannot help, and nobody gets an error page.
MCP transports: stdio vs Streamable HTTP
How you monitor a server depends first on how clients reach it. The specification defines two standard transports, and older servers may still use a third.
- stdioThe client starts the server as a local subprocess and exchanges JSON-RPC messages over its standard input and output. Nothing listens on the network, so there is nothing for an external monitor to reach. Its health is the health of the machine and the process it runs on.
- Streamable HTTPThe server is a remote service with a single HTTP endpoint, often ending in /mcp. The client sends each JSON-RPC message as an HTTP POST; the server answers with a JSON body or opens a Server-Sent Events (SSE) stream for that response. Servers may assign a session ID in the Mcp-Session-Id header, which the client sends back on later requests. This is the transport for hosted, shared servers, and the one you can monitor from outside.
- HTTP+SSE (legacy)The original remote transport, from the 2024-11-05 version of the spec, used a long-lived SSE connection for server messages and a separate endpoint for client POSTs. Streamable HTTP replaced it in the 2025-03-26 version. Some servers still offer it for older clients.
A stdio server cannot be checked over the network. Test it in CI instead: start it, run the handshake and list its tools, for example with the open-source MCP Inspector or a short script using an official SDK. If the same code is also deployed behind Streamable HTTP, monitor that deployment.
What does "up" mean for an MCP server?
A TCP connection or a 200 on the base URL tells you a web server is running. An agent needs more than that. A useful definition of up has five parts.
- 1. The handshake completesEvery MCP session starts with initialize. The client sends the protocol version it wants, its capabilities and its name; the server answers with the version it will use, its own capabilities and serverInfo. The client then sends a notifications/initialized notification. If initialize fails or returns something that is not valid JSON-RPC, no client can use the server.
- 2. A protocol version is agreedProtocol versions are dates, such as 2025-06-18. If the server cannot speak a version the client supports, the session fails even though the server is running. Version problems usually appear after an SDK upgrade on one side.
- 3. The tools are thereA server that advertises the tools capability answers tools/list with each tool's name, description and JSON Schema for its input. If the tools an agent relies on are missing, the server is up in name only.
- 4. Authentication worksRemote servers usually need a token. An expired or revoked credential, or a broken authorization server, locks out every client. A 401 is an outage for your users even if it is correct behaviour for an anonymous request.
- 5. It answers in timeAgents call tools in a loop, and many clients time out slow requests. A handshake that used to take 300 ms and now takes 8 seconds is a real regression.
Tool-list drift: the failure HTTP checks miss
Tool drift is a change in the tools a server exposes: a tool renamed, removed or added, or its input schema changed. It is usually caused by a deploy, a feature flag or a dependency upgrade, and it rarely produces an error on the server.
- A renamed or removed tool breaks prompts, agent configurations and evaluation suites that refer to it by name.
- A new required parameter in an input schema makes existing calls fail validation.
- A changed description can change how a model chooses between tools, which alters agent behaviour without any code change on the client.
- An unexpected new tool may be a deploy going out in the wrong order, or a capability you did not intend to expose.
Servers can announce changes during a session with a notifications/tools/list_changed notification, if they declare that capability, but that only helps a client that is connected at the time. To catch drift reliably, record a baseline of the tool list and compare each check against it.
If other teams or customers build agents on your server, its tool names and schemas are a public API. Version them, announce breaking changes, and alert when they change without a release.
How to check an MCP server by hand
You can run the handshake against a Streamable HTTP server with curl. Send initialize as a POST with the headers Content-Type: application/json and Accept: application/json, text/event-stream, plus Authorization if the server needs it, and a body like {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"manual-check","version":"1.0.0"}}}.
A healthy server answers with a result containing protocolVersion, capabilities and serverInfo, either as plain JSON or as an SSE event whose data line holds the JSON. Note any Mcp-Session-Id response header. Then send notifications/initialized and a tools/list request, passing the session ID back in the Mcp-Session-Id header and the negotiated version in the MCP-Protocol-Version header, and read the tools array.
- A 404 or 405 on the POST usually means the URL is not a Streamable HTTP endpoint: the path is wrong, or the server only offers the legacy SSE transport.
- A 401 means the server wants credentials; for OAuth-protected servers the response normally points the client at the authorization metadata it needs.
- An error object in place of result means the server rejected the request, for example because of the protocol version you offered.
- For an interactive view of the same steps, the MCP Inspector connects to a server and lists its tools, resources and prompts.
Monitoring an MCP server in production
Turning the manual check into monitoring means running it on a schedule from outside your infrastructure, grading the result and alerting the right person. A good MCP check:
- Speaks the protocolRuns initialize and tools/list like a real client, rather than requesting the URL and accepting any 200.
- Never calls toolstools/call can send email, write data or spend money. A health check must stay on the read-only handshake and listing.
- Uses its own credentialIssue a dedicated, read-only token for monitoring, so a revoked user token does not look like an outage, and rotation is tracked.
- Asserts the tools you needLists the tool names agents depend on, and fails when one disappears.
- Tracks driftCompares the tool list, and optionally schemas, with an accepted baseline, and lets you accept intended changes.
- Confirms before pagingChecks from more than one location before alerting, like any other uptime monitor, so a single network blip does not wake anyone.
Also keep an ordinary HTTP or API monitor on anything the MCP server depends on, such as the backend API it wraps and the authorization server that issues tokens, so an alert can tell you which part failed.
MCP server monitors in SutramX
SutramX MCP server monitors check a remote server the way a client connects to it. Each check sends initialize to the server's HTTPS endpoint over Streamable HTTP, negotiates a protocol version and calls tools/list. It never calls a tool. MCP server monitors are available on every plan, Free included.
- Protocol versionsSutramX offers 2025-11-25 by default, or 2025-06-18, 2025-03-26 or 2024-11-05. Turn on "Require exactly this version" to fail when the server negotiates anything else.
- AuthenticationAdd the headers the server expects, most often Authorization: Bearer with a token. SutramX cannot complete an interactive OAuth sign-in, so issue a token for monitoring, ideally read-only, and add it as a bearer header.
- Expected toolsList the tool names you rely on. A missing one marks the monitor down.
- DriftThe first successful check records the tool list as a baseline. Compare tool names and input schemas, or names only, and mark a change as degraded (the default) or down. Click "Accept current tools" when the change was intended.
- Clear errorsFailures are reported as protocol errors, version mismatches, missing tools or tool changes. A 404 or 405 on initialize is reported as "not a Streamable HTTP MCP endpoint", and redirects are never followed.
Only Streamable HTTP servers are supported. Local stdio servers and the older HTTP+SSE transport cannot be monitored. The setup steps and every setting are in the MCP server monitor docs.
MCP monitoring FAQ
Is a /health endpoint enough for an MCP server?
It tells you the process is running, not that clients can use it. A health route stays green when the handshake breaks after an SDK upgrade, when a tool disappears in a deploy, or when the token clients use has been revoked. Check the protocol itself.
Will monitoring an MCP server run my tools?
It should not. Initialize and tools/list only describe the server; they do not perform actions. A monitor that calls tools could create data or spend money on every check. SutramX never calls a tool.
How often should I check an MCP server?
Treat it like an API with the same users. If agents in production depend on it, check every minute or faster; for an internal or experimental server, every few minutes is fine. The guide to choosing check intervals covers the trade-off.