exit1-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@exit1-mcp Set up uptime monitoring for this project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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. Run this in your terminal before starting a session: the login opens your 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 && claude mcp login exit1One line on purpose: pasting the two commands as separate lines is unreliable in some terminals (cmd.exe drops the second line). In old Windows PowerShell (5.1), where && doesn't parse, run the two halves one at a time. Connect before you start the session: MCP clients load servers at startup, so a server added mid-conversation isn't usable until a restart. On Claude Code versions without claude mcp login, start claude and authenticate via /mcp instead.
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.
Related MCP server: mcp-uptime-kuma
No account yet? Let the agent create one
Started without EXIT1_API_KEY, the stdio server doesn't exit. It starts in setup mode and offers one extra tool, create_account. Your agent calls it with your email address, and exit1 creates a free account and connects the server to it on the spot. Every other tool works straight away, and monitors start running.
claude mcp add exit1 -- npx -y exit1-mcp
# then, in the session: "Set up uptime monitoring for this project with exit1. My email is you@example.com."Or from a terminal, before the session:
npx exit1-mcp signup --email you@example.comEither way exit1 emails you a link to claim the account. Alerts are only delivered once you claim it, so nobody can point exit1's alerts at an address they don't own. On the claim page you decide whether the agent keeps access. Unclaimed accounts are paused after 7 days and deleted after 30.
The tokens are saved to ~/.exit1/credentials.json and refreshed automatically, so later sessions connect without any setup. EXIT1_API_KEY, when set, always wins. Agents that don't use MCP can do the same with one HTTP call: see Agent signup.
Zero to monitored
Connect the server (above), then 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. Call get_account to see my plan limits. If you have a create_account tool
instead, I have no account yet: ask for my email and call it. If the Exit1
tools aren't available to you at all, don't try to connect from inside this
session; tell me to add the HTTP MCP server https://app.exit1.dev/mcp/v1 in
my tool, restart it, and paste this prompt again.
2. 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.
3. Show me the checks you plan to create before creating them.
4. 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 either an API key from your dashboard (every plan can mint one, Free included) or no account at all: see No account yet?.
Supported clients
Client | Hosted (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 | ✅ |
ChatGPT | via connector | via |
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"
claudeClaude 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"
codexChatGPT
Bridge the stdio server with mcp-remote, then add it under Settings › Connectors.
Tools
Tool | Scope | Description |
|
| Plan, limits and current usage. Call this first when setting things up. |
|
| List checks with current status. |
|
| Detail for one check, including SSL state. |
|
| Individual results over time. |
|
| Uptime % and response times across ranges. |
|
| Snapshot of a public status page. |
|
| Create a monitor (website, API, ping, TCP, DNS, domain, heartbeat). |
|
| Change an existing check's settings. |
|
| Pause or resume a check. |
|
| Permanently remove a check. |
|
| See where alerts currently go. |
|
| Set email recipients and events. |
|
| Connect Slack, Discord, Teams or a generic webhook. |
|
| Fire 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 variable | Required | Description |
| No | Your Exit1 API key ( |
| No | Where signup credentials are saved (default |
| No | Override 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 servernpm 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. A second run starts it with no key
and no saved credentials and checks setup mode (create_account listed, other tools explain how
to get an account). 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:catalogReleasing
npm version patch # or minor
npm publish # prepublishOnly runs the build + smoke test
git push --follow-tagsBump 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 publishnpm ownership is proven by the mcpName field in package.json, which must stay equal to name
in server.json.
Quick Links
Website | exit1.dev — Learn about the platform | |
Monitor App | app.exit1.dev — Sign in and manage your checks | |
Documentation | docs.exit1.dev — Guides, API reference, and setup instructions | |
MCP Server |
|
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.
Available Tools
15 toolsadd_webhook_alertAdd webhook alertAInspect
Send alerts to Slack, Discord, Microsoft Teams or any HTTPS endpoint. Paste the incoming-webhook URL the user gives you; the platform is detected from the URL if you do not pass webhook_type.
Inputs: url (required), name (required), events, secret, +1 more.
create_accountCreate an exit1 accountAInspect
Create a free exit1 account for the user and connect this server to it, so the other tools work right away. Use the user's own email address: exit1 emails it a link to claim the account, and alerts are only delivered once they claim it. Monitors you create before then start running immediately. Fails if the email already has an account; then ask the user for an API key instead.
Inputs: email (required), agent_name.
create_checkCreate checkAInspect
Create a new monitor. Use 'website' for a page that should return 200, 'rest_endpoint' for an API endpoint (supports JSONPath assertions on the response body), 'ping' for ICMP, 'tcp' for a raw port, 'dns' for record drift, 'domain' for registration expiry, and 'heartbeat' for cron jobs that call in. Check the plan's minCheckIntervalMinutes via get_account before setting check_frequency_minutes.
Inputs: url, name, type, http_method, +7 more.
delete_checkDelete checkADestructiveInspect
Permanently delete a check and stop monitoring it. This cannot be undone. Prefer toggle_check unless the user explicitly wants it gone.
Inputs: check_id (required).
get_accountGet accountARead-onlyIdempotentInspect
Get the current plan, its limits, and how much of them is already used. Call this FIRST when setting up monitoring — it tells you how many checks you can create and the fastest check interval the plan allows, so you can plan within the plan instead of hitting errors halfway through.
Inputs: no named parameters.
get_alert_settingsGet alert settingsARead-onlyIdempotentInspect
Show where alerts currently go — email recipients and connected webhooks. Call this before configuring alerts so you do not duplicate a channel the user already has.
Inputs: no named parameters.
get_checkGet checkARead-onlyIdempotentInspect
Get full detail for one check: status, response time, SSL certificate state and maintenance mode.
Inputs: check_id (required).
get_check_historyGet check historyARead-onlyIdempotentInspect
Get individual check results over time — timestamps, status codes, response times and errors. Use when investigating an incident or confirming a fix held.
Inputs: check_id (required), to, from, page, +2 more.
get_check_statsGet check statsARead-onlyIdempotentInspect
Get aggregate uptime percentage and response-time statistics for a check across one or more time ranges. Good for 'how has this been doing' questions and week-over-week comparisons.
Inputs: check_id (required), ranges.
get_status_pageGet status pageARead-onlyIdempotentInspect
Get the current snapshot of a public status page, with each check's status and uptime percentage.
Inputs: status_page_id (required).
list_checksList checksARead-onlyIdempotentInspect
List monitored checks with their current status and folder. Use for an overview, to find offline checks, or to see what is already monitored before creating duplicates. Pass folder to list one folder; add recursive to include its subfolders. Pass include="uptime" to add 24h and 30d uptime percentages and the 24h average response time to each check.
Inputs: page, limit, folder, status, +2 more.
send_test_alertSend test alertAInspect
Fire a real test alert so the user can confirm delivery works. ALWAYS finish a monitoring setup with this — a channel that was configured but never tested is the most common way monitoring silently fails. Pass channel='email' or channel='webhook' with a webhook_id.
Inputs: channel (required), webhook_id.
set_email_alertsConfigure email alertsAInspect
Set which email addresses receive alerts and which events trigger them. Events: website_down, website_up, website_error, ssl_error, ssl_warning, domain_expiring, domain_expired, domain_renewed. Defaults to website_down + website_up, which is the right pair for most people.
Inputs: events, format, enabled, recipients.
toggle_checkEnable or disable checkAIdempotentInspect
Enable or disable a check without deleting it. Disabled checks stop probing and stop alerting — use this rather than delete_check for a temporary pause.
Inputs: check_id (required), disabled (required).
update_checkUpdate checkAIdempotentInspect
Change an existing check's settings. Only the fields you pass are modified.
Inputs: check_id (required), url, name, http_method, +4 more.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 15 tools
Most tools target a distinct resource+action, and descriptions explicitly steer between look-alikes (toggle_check vs delete_check, send_test_alert vs alert config). The one fuzzy cluster is the three read tools on a single check (get_check, get_check_history, get_check_stats), whose boundaries are clarified only by description text rather than by name.
Every tool follows the same snake_case verb_noun pattern (create_check, get_check_stats, toggle_check, add_webhook_alert). Verb variety (get/set/add/send/toggle) is semantically meaningful rather than arbitrary.
15 tools is well within a healthy range for a monitoring service, and each maps to a real task: account setup, check CRUD, alert channel configuration, and read/investigation queries. No obvious filler or duplicate tooling.
Core lifecycle is covered for checks (create/update/toggle/delete/read), which is the heart of the domain. But there are notable gaps: webhooks can be added but never listed or removed, status pages are read-only (no create/update), folders are referenced in list_checks/create_check but have no management tools, and maintenance mode is exposed in get_check yet cannot be set.
Related MCP Connectors
MCP server for Uptrack uptime monitoring. Manage monitors and incidents from AI agents.
Uptime, SSL, DNS and domain monitoring you can talk to from Claude or any MCP client.
Pingstack monitors cron jobs and scheduled tasks with heartbeat checks, and checks websites, TCP ports, DNS records, SSL certificates and domain expiry. This MCP server lets your agent create, update, pause and delete checks, build dashboards and publish them as status pages, manage notification groups, and read incidents with their causes, uptime, run history and latency. Pause, delete and unpublish stay off until you turn them on. Browser sign-in, no API key needed.
Manage uptime monitors, incidents and status pages from any MCP client.
Related MCP Servers
AlicenseNot gradedqualityCmaintenanceMCP server for Uptrack uptime monitoring. Manage monitors and incidents from AI agents like Claude, ChatGPT, and Cursor.13 npmMIT- AlicenseAqualityAmaintenanceMCP server for Uptime Kuma that enables monitoring and management of uptime monitors, heartbeats, notifications, tags, and maintenance windows via natural language.35619 npm64MIT
- FlicenseBqualityBmaintenanceMCP server for managing self-hosted Uptime Kuma monitors and querying uptime statistics from Claude.15-
- AlicenseAqualityDmaintenanceMCP server for StillOnline uptime monitoring, enabling management of projects, checks, incidents, and public status pages through natural language.1058 npm1MIT