MCP Server Health Checks

Check an MCP server the way an assistant connects to it: start a session, then list its tools.

Overview

An MCP check connects to a Model Context Protocol server over the Streamable HTTP transport, the way Claude, ChatGPT or Cursor do, from every region your plan allows. It catches what an HTTP check of a health endpoint misses: an endpoint that answers but no longer speaks MCP, a sign-in that assistants can't discover, or a deploy that dropped a tool.

Each run makes the same requests an assistant makes:

initialize, asking for protocol version 2025-11-25 and accepting the version the server answers with
notifications/initialized
tools/list, following nextCursor for up to 10 pages

The check handles JSON and event-stream answers, keeps the Mcp-Session-Id a server assigns and sends MCP-Protocol-Version, and ends the session with a DELETE afterwards. It never calls a tool.

With or without a key

Server	Without a key	With a key in the headers
Open (no sign-in)	Up when it answers; its tools are listed and checked	Same, sending your headers
OAuth sign-in	Up when it answers `401` and its sign-in can be discovered (below). Tools aren't listed.	Up when it accepts the key; its tools are listed and checked. A `401` or `403` is down: the server refused the key.

Discoverable sign-in means what a client follows after a 401 works: the protected resource metadata (named in the WWW-Authenticate header, or at the RFC 9728 /.well-known/oauth-protected-resource paths) names an authorization server, and that server's RFC 8414 or OpenID metadata loads, lists its authorization and token endpoints, and names itself as the issuer. A 401 without that is down, because assistants couldn't sign in either.

💡 No key needed to watch a sign-in server

A keyless check of a server that uses OAuth tells you it's up and that assistants can start signing in to it. Add a key only to check its tools, and use one with the least access the server offers: listing tools needs no more.

Configuration

Setting	Description	Default
Server URL	The Streamable HTTP endpoint, often ending in `/mcp`	Required
Request headers	Sent with every request; where the server's key goes, e.g. `Authorization: Bearer …`	None
Required tools	Tool names, one per line. The check fails when the server stops listing one of them, and names the missing ones.	None
At least this many tools	The check fails when the server lists fewer tools	None
Timeout	The whole exchange shares it	10 seconds in the app

The headers, required tools and minimum are under Advanced settings in the app. Rechecks, the down/degraded rules, alerts, status pages and reports work as for every other check.

What each result shows

Field	Description
Server	The name and version from the server's `serverInfo`
Protocol	The protocol version the server chose
Access	How the check got in: Open, OAuth sign-in (keyless, sign-in discovered) or Key
Sign-in server	The authorization server a keyless check discovered
Tools	How many tools the server listed
Missing tools	Required tools the server didn't list
Request breakdown	DNS, TCP, TLS and time to first byte of the `initialize` request

The response time covers the whole exchange: three or four requests in a row, so expect it to be a few times an HTTP check's.

Why a check fails

What happened	What the check says
`404` or `405`	No MCP endpoint at this URL (it often ends in /mcp)
An HTML page or another non-JSON answer	Not an MCP endpoint
A JSON-RPC error from `initialize` or `tools/list`	The server's error message and code
`401` without a key and no discoverable sign-in	Sign-in isn't discoverable, with the step that failed
`401` or `403` with a key	The server refused the key
Required tools missing, or too few tools	The missing names, or the count
No answer in time, DNS, TLS or connection errors	The same as for HTTP checks

Setting it up

In the app

Create a healthcheck, pick the MCP tab and paste the server URL. Open Advanced settings to add a key, required tools or a minimum.

From an assistant

Connected to the Uptimy MCP server, ask something like “monitor our MCP server at https://mcp.example.com/mcp”. add_monitors adds it with type: mcp, without a key: keys are added in the app, so they never pass through a chat.

With uptimyctl

type: mcp takes the URL as its target (uptimyctl 1.11.0 and later). Required tools, a minimum or headers go in config:

uptimy.yaml

monitors:
  - name: Docs MCP
    type: mcp
    target: https://mcp.example.com/mcp
  - name: Docs MCP tools
    type: mcp
    target: https://mcp.example.com/mcp
    config:
      requiredTools: [search_docs, read_page]
      minTools: 2

Through the API

MCP is healthcheck type 13. Its config:

MCP check config

{
  "uri": "https://mcp.example.com/mcp",
  "headers": { "Authorization": "Bearer your-key" },
  "requiredTools": ["search_docs", "read_page"],
  "minTools": 2
}

Limits

Streamable HTTP only: not the older HTTP+SSE transport (GET /sse, protocol 2024-11-05), and not local stdio servers.
The server must be reachable from the internet; checks don't connect to private addresses.
Tools are listed, never called.

ℹ️ On every plan

MCP checks are available on every plan, Free included, and count toward your plan's checks like any other monitor.