Exit1 Uptime Monitoring

What Exit1 Uptime Monitoring MCP server does

Exit1 Uptime Monitoring MCP server exposes Exit1 monitoring operations as MCP tools. An assistant can inspect the account plan, limits, and current usage before creating monitors. It can list existing checks, retrieve individual check details including SSL state, review historical results, calculate uptime and response-time statistics, and read a public status page snapshot.

The write operations cover the full check lifecycle. Agents can create monitors for websites, APIs, ping targets, TCP services, DNS, domains, and heartbeats. Existing checks can be updated, paused, resumed, or permanently deleted. Alert tools show current destinations, configure email recipients and event types, add Slack, Discord, Teams, or generic webhook destinations, and send a real test alert.

How it works

The project provides two connection paths with the same tool surface. The hosted option uses the HTTP endpoint at https://app.exit1.dev/mcp/v1 and authenticates through a browser-based OAuth flow. An Exit1 account is required, and sign-up can happen during authentication. The local option runs the exit1-mcp npm package over stdio and sends requests to Exit1 using an API key.

MCP clients load servers when a session starts, so a newly added connection may require a client or assistant restart. The hosted server requests read and write scopes for checks and alerts by default; deletion access must be requested separately. For local use, the scopes are selected when the API key is created.

A bundled setup_monitoring prompt provides a project-monitoring workflow. It instructs the assistant to inspect repository files for deployed URLs and health endpoints, show proposed checks before creating them, configure email alerts, and send a test notification.

Setup and configuration

For the hosted route, add the HTTP server and authenticate with the MCP client. The README gives this Claude Code command:

claude mcp add --transport http exit1 https://app.exit1.dev/mcp/v1 && claude mcp login exit1

For local stdio, use Node.js 18 or newer and an Exit1 API key:

claude mcp add exit1 -- npx -y exit1-mcp
export EXIT1_API_KEY="ek_live_your_key_here"

EXIT1_API_KEY is required for stdio operation. EXIT1_API_URL is optional and can override the API base URL, primarily for development. The README documents configuration examples for Claude Code, Claude Desktop, Cursor, VS Code with Copilot, Windsurf, Gemini CLI, Goose, Codex CLI, and ChatGPT through an mcp-remote bridge.

Tools and capabilities

Read operations include account information, check lists and details, check history, uptime and response-time statistics, alert settings, and public status pages. Write operations create and modify checks, toggle monitoring, remove checks, configure email or webhook alerts, and issue test alerts.

The tools support natural-language requests such as checking which monitors are down, finding recent production failures, comparing response times between periods, or adding a staging check with Slack notifications. Destructive check deletion is separately permissioned from the other hosted scopes.

Limitations and notes

The hosted OAuth path depends on client support for remote MCP and OAuth; the README marks support for Windsurf, Codex CLI, Gemini CLI, and Goose as version-dependent. The stdio path is available for clients that do not support remote OAuth. ChatGPT requires a connector or an mcp-remote bridge. Hosted connections can be revoked from the Exit1 application, which immediately invalidates tokens issued to that client.