MCP server for uptime monitoring

Your monitors, in your agent's hands.

• Five tools, the whole surface

  The server exposes five tools and they cover everything the dashboard does: list_monitors for current status and 24h stats, create_monitor with only a URL required, test_monitor to run one check against a draft without saving, update_monitor for edits and for enabled: false to pause, and delete_monitor.

  Say "monitor my site" and the agent drives the rest. Say "is checkout slow because of us or the network?" and it reads connect time against time to first byte and tells you.

• Agents that register what they ship

  The interesting flow isn't you asking an agent to make a monitor. It's the agent doing it unprompted: it deploys a service, calls test_monitor to confirm the endpoint answers, then create_monitor to put it under watch, and the thing it just shipped is being checked before the deploy log scrolls away.

  Because create returns the first check's result, the agent knows immediately whether it pointed the monitor at the right URL, and corrects itself without a human in the loop.

• Dry-run before it commits

  test_monitor runs one real check against a config that doesn't exist yet and returns the latency breakdown a scheduled check would log. An agent can try a URL, a header, or a content rule, read the result, and only then create the monitor.

  It's the difference between an agent that guesses and one that checks its work, and it costs one call.

• One project, by construction

  Authentication is a Bearer project API key, created in your project's Settings under Access tokens. A key binds to one project, so a connected agent can only touch that project's monitors; it can never create more keys or reach account settings.

  Give it an expiry for a throwaway experiment, and revoke it any time from the same list. The blast radius of a confused agent is one project's monitors, and nothing it does there is irreversible except delete.