Back to Browse

Exit1 MCP Server

by Mopra
Developer ToolsLow Risk8.2MCP RegistryLocalRemote
Free

Server data from the Official MCP Registry

Set up uptime monitoring from your editor: create checks, configure alerts, query uptime history.

About

Set up uptime monitoring from your editor: create checks, configure alerts, query uptime history.

Remote endpoints: streamable-http: https://app.exit1.dev/mcp/v1

Security Report

8.2
Low Risk8.2Low Risk

Exit1 MCP server is well-architected with proper authentication, sensible authorization scopes, and clean code practices. The server requires API keys for the stdio path and uses OAuth for the hosted path, both appropriately enforced. Input validation is present via JSON schema, and dangerous operations are properly scoped. Minor code quality observations exist (broad error handling, environment variable validation) but do not create security vulnerabilities. Package verification found 1 issue.

7 files analyzed · 4 issues found

Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.

Permissions Required

This plugin requests these system permissions. Most are normal for its category.

HTTP Network Access

Connects to external APIs or services over the internet.

env_vars

Check that this permission is expected for this type of plugin.

What You'll Need

Set these up before or after installing:

Exit1 Public API key (ek_live_…), created at https://app.exit1.dev/api-keys. Requires an Indie plan or higher.Required

Environment variable: EXIT1_API_KEY

Override the Exit1 API base URL. Development only.Optional

Environment variable: EXIT1_API_URL

How to Install & Connect

Available as Local & Remote

This plugin can run on your machine or connect to a hosted endpoint. during install.

Documentation

View on GitHub

From the project's GitHub README.

exit1-mcp

MCP server for Exit1 uptime monitoring. Let your AI assistant set up monitoring for the project you just shipped — read your repo, create the checks, configure alerts, and send a real test alert to prove it works — then ask it about uptime in plain language afterwards.

Two ways to connect

Hosted (recommended). No API key, no npm install, no plan requirement to get started. Your assistant opens a browser, you sign in (or sign up) with Clerk, approve, and you're connected.

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

Local stdio. This npm package. Uses a Public API key from your dashboard. Use it when your client doesn't support remote MCP servers with OAuth.

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

Both expose the same tools. The hosted server is easier; the stdio one has no browser step, which some CI-ish setups prefer.

Zero to monitored

Paste this into Claude Code, Cursor, Codex or any MCP-capable assistant, from inside your project:

Set up uptime monitoring for this project with Exit1.

1. Add the MCP server: claude mcp add --transport http exit1 https://app.exit1.dev/mcp/v1
2. Call get_account to see my plan limits.
3. Read this repo to find what should be monitored — deployed URLs in vercel.json /
   next.config / wrangler.toml / .env.production / README, and any /health or
   /api/status route handlers.
4. Show me the checks you plan to create before creating them.
5. Configure email alerts, then send a test alert so I can confirm delivery works.

Once connected, the server also ships a setup_monitoring prompt containing the full playbook — in Claude Code, /exit1:setup_monitoring.

Requirements

  • Hosted: an Exit1 account. Sign-up happens inline during the OAuth flow.
  • Local stdio: Node.js 18+, and an API key from your dashboard. Every plan can mint a key, Free included.

Supported clients

ClientHosted (OAuth)Local stdio
Claude Code
Claude Desktop
Cursor
VS Code (Copilot)
Windsurf⚠️ check version
Codex CLI⚠️ check version
Gemini CLI⚠️ check version
Goose⚠️ check version
ChatGPTvia connectorvia mcp-remote bridge

Remote MCP with OAuth is still rolling out across clients. Where it isn't supported yet, the stdio path below works everywhere.

Local stdio setup

Claude Code

claude mcp add exit1 -- npx -y exit1-mcp

export EXIT1_API_KEY="ek_live_your_key_here"
claude

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "exit1": {
      "command": "npx",
      "args": ["-y", "exit1-mcp"],
      "env": {
        "EXIT1_API_KEY": "ek_live_your_key_here"
      }
    }
  }
}

Cursor

Add to .cursor/mcp.json in your project (or ~/.cursor/mcp.json globally). Same shape as Claude Desktop above.

VS Code with Copilot

Run MCP: Add Server from the Command Palette, choose Command (stdio), enter npx -y exit1-mcp. VS Code uses a servers key rather than mcpServers:

{
  "servers": {
    "exit1": {
      "command": "npx",
      "args": ["-y", "exit1-mcp"],
      "env": {
        "EXIT1_API_KEY": "ek_live_your_key_here"
      }
    }
  }
}

Windsurf / Gemini CLI / Goose

Same mcpServers block as Claude Desktop, in mcp_config.json (Windsurf settings › MCP), ~/.gemini/settings.json, or via goose mcp add exit1 -- npx -y exit1-mcp. Restart the IDE or CLI afterwards.

Codex CLI

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

ChatGPT

Bridge the stdio server with mcp-remote, then add it under Settings › Connectors.

Tools

ToolScopeDescription
get_accountchecks:readPlan, limits and current usage. Call this first when setting things up.
list_checkschecks:readList checks with current status.
get_checkchecks:readDetail for one check, including SSL state.
get_check_historychecks:readIndividual results over time.
get_check_statschecks:readUptime % and response times across ranges.
get_status_pagechecks:readSnapshot of a public status page.
create_checkchecks:writeCreate a monitor (website, API, ping, TCP, DNS, domain, heartbeat).
update_checkchecks:writeChange an existing check's settings.
toggle_checkchecks:writePause or resume a check.
delete_checkchecks:deletePermanently remove a check.
get_alert_settingsalerts:readSee where alerts currently go.
set_email_alertsalerts:writeSet email recipients and events.
add_webhook_alertalerts:writeConnect Slack, Discord, Teams or a generic webhook.
send_test_alertalerts:writeFire a real test alert.

The hosted server requests checks:read, checks:write, alerts:read and alerts:write by default — not checks:delete, which has to be asked for explicitly. For the stdio path, tick the scopes you want when creating the API key.

Example prompts

  • "Set up monitoring for this project."
  • "Are any of my monitors down right now?"
  • "What's the uptime for my API check over the last 30 days?"
  • "Show me the last 10 failures for production."
  • "Add a check on staging.example.com and send alerts to #ops in Slack."
  • "Compare response times this week vs last week."

Configuration

Environment variableRequiredDescription
EXIT1_API_KEYstdio onlyYour Exit1 API key (ek_live_…)
EXIT1_API_URLNoOverride the API base URL (for development)

Managing connections

Hosted connections are listed at app.exit1.dev/mcp and can be revoked there at any time. Revoking kills every token issued to that client immediately.

Development

npm install
npm run build          # tsc -> dist/
npm test               # build, then drive a real MCP handshake over stdio
npm run check:catalog  # compare the tool catalog against the hosted server

npm test spawns the built server and asserts the surface a client actually sees — the tool count, readOnlyHint / destructiveHint annotations, the setup_monitoring prompt, and that an unknown tool returns isError rather than a protocol error. It needs no API key and makes no network calls.

Why check:catalog exists

The tool catalog is deliberately duplicated between this package and the hosted OAuth server, which lives in Mopra/exit1.dev at functions/src/mcp-tools.ts. Two separate builds, no shared package, nothing at compile time tying them together. npm run check:catalog fails if they drift on tool names or input schemas, and warns on wording differences. CI runs it on every push and once a day.

Change a tool here, change it there — and run the check before releasing.

To run it against a local checkout instead of GitHub:

CATALOG_REMOTE_PATH=../exit1.dev/functions/src/mcp-tools.ts npm run check:catalog

Releasing

npm version patch          # or minor
npm publish                # prepublishOnly runs the build + smoke test
git push --follow-tags

Bump version in server.json to match, then re-publish the registry entry (see below). The version string in src/index.ts is what clients see in serverInfo — keep it in step with package.json.

MCP registry

server.json describes both distribution paths (the npm package and the hosted endpoint) for the official MCP registry. The registry name is dev.exit1/exit1-mcp, which requires proving control of exit1.dev:

mcp-publisher login dns --domain=exit1.dev --private-key=HEX_KEY
mcp-publisher publish

npm ownership is proven by the mcpName field in package.json, which must stay equal to name in server.json.

Quick Links

Websiteexit1.dev — Learn about the platformRepo
Monitor Appapp.exit1.dev — Sign in and manage your checksRepo
Documentationdocs.exit1.dev — Guides, API reference, and setup instructionsRepo
MCP Serverexit1-mcp — this repoRepo

Also listed on the official MCP registry as dev.exit1/exit1-mcp.

License

MIT — see LICENSE.

The rest of exit1 is source-available rather than open source; this package is the exception, so it can be vendored and inspected freely by MCP clients.

Reviews

No reviews yet

Be the first to review this server!

Exit1 MCP Server - Set up uptime monitoring from your editor: create checks, | MCP Marketplace