The uptime monitoring MCP server

What MCP is, briefly

The Model Context Protocol is a JSON-RPC convention for handing an LLM client a typed set of callable tools. The client asks the server what it offers (tools/list), the server answers with names, descriptions, and a JSON Schema for every argument, and the model makes structured calls instead of guessing its way around a web UI. Undownable speaks it over the streamable HTTP transport at undownable.com/mcp, authenticated with an Authorization: Bearer header and rate limited to 60 requests a minute per token. Nothing to install: the server is part of the application, so what the agent reads is what the check engine wrote a moment ago.

What the server exposes

Fifteen tools, all team scoped. Each defaults to the token's team and accepts an optional team argument naming any other team the owner belongs to. Monitor and window IDs are the ULIDs the list tools return.

create-monitor covers all eight check types: http, keyword, json, ssl, tcp, dns, ping, and heartbeat. get-monitor returns 24 hour, 7 day, and 30 day uptime alongside the five most recent incidents, usually everything an agent needs before it starts theorising about a cause. There is no update-status-page tool yet, so an agent creates a page with its monitors already attached.

Setting it up in Claude Code

Create the token first: log in, open API tokens in the dashboard sidebar, name it after the agent that will hold it, and copy the value immediately because it is shown exactly once. Then one command:

claude mcp add --transport http undownable https://undownable.com/mcp \
  --header "Authorization: Bearer YOUR_TOKEN"

That is the whole setup. The agent discovers the tools by itself; you never name one.

Setting it up in Claude Desktop

Claude Desktop reaches a remote HTTP server through mcp-remote. Add this to the mcpServers section of claude_desktop_config.json (Settings, then Developer, then Edit Config) and restart the app:

"undownable": {
  "command": "npx",
  "args": [
    "mcp-remote", "https://undownable.com/mcp",
    "--header", "Authorization: Bearer YOUR_TOKEN"
  ]
}

Any other MCP client

Point it at the same URL over the HTTP (streamable) transport and send the bearer header with every request. Most clients take a config shaped like this:

{
  "url": "https://undownable.com/mcp",
  "headers": { "Authorization": "Bearer YOUR_TOKEN" }
}

Underneath it is plain JSON-RPC over HTTP, so you can prove a token works before wiring up any client at all:

curl -s https://undownable.com/mcp \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

The full setup reference, including the current tool table, lives at undownable.com/docs/mcp.

Scope the token before you hand it over

A token is a personal access token that acts as you. The token page narrows it in two independent ways, and both are worth using:

• Abilities. Pick only what the agent needs from user:read, teams:read, fleet-status:read, monitors:read, monitors:write, incidents:read, status-pages:read, status-pages:write, maintenance-windows:read, maintenance-windows:write, and mcp. Full access is a wildcard satisfying every gate including anything added later, which is convenient and also the thing you are trying to avoid.
• Team pin. If you belong to more than one team, pin the token to one at creation. A pinned token cannot see the others, and it can omit the team argument because there is nothing left to guess.
• Revocation. Revoking a token cuts the agent off instantly and changes nothing else. Mint one per agent so revoking is a decision about that agent alone.

One honest caveat: there is no read-only MCP token. The mcp ability opens the whole server and every tool there can write, so a token that lists monitors over MCP can also delete them. For an agent that cannot change anything, use monitors:read and incidents:read on the REST API and leave mcp off.

Things worth saying out loud

You talk to the agent, not to the tools. Prompts that land cleanly:

• Create an HTTP monitor for example.com checking every minute, tagged production.
• Open a 2 hour maintenance window for the api tag before tonight's deploy, then end it when I say we are done.
• Is anything down? Pull last week's incidents and tell me which monitor is the repeat offender.
• Create a heartbeat monitor for the nightly backup job with a 15 minute grace period and give me the ping URL.

Why this beats screen-scraping a dashboard

The alternative pattern (point a browser-driving agent at a monitoring dashboard and let it click) fails in ways this does not:

• Nothing is ambiguous. The agent gets typed arguments and enumerated values, so a bad interval is a validation error naming the five valid ones rather than a dropdown it misread.
• Errors are instructions. Hit the plan monitor cap and the message names the limit, the plan, and where to change it. Send an unknown config key and the error lists the valid keys for that type, which is enough for the agent to fix its own call and retry.
• Permissions are real. Every tool runs the dashboard's policies, so an agent cannot exceed the role of the person whose token it holds.
• It survives a redesign, because a tool contract does not move when a button does. And it is auditable: one named token per agent, revocable in a click.

Plan limits apply to agents exactly as they do to you: 10 monitors and 5 minute checks on the free plan, 50 monitors and 1 minute checks on Pro, with every alert channel (email, ntfy, Telegram, Slack, Discord, webhooks) on both.