Check If Your Site Is Down From Claude, Cursor or VS Code (MCP)

You can check whether your site is down without leaving your editor or chat window by connecting your uptime monitor to your AI assistant over MCP. Add the monitoring service's MCP server URL and an API key to Claude Code, Claude Desktop, Cursor or VS Code, then ask "which of my monitors are down, and since when?" The assistant calls a tool such as list_monitors, reads the answer and replies in plain language. With a read-and-write key it can also add monitors, schedule maintenance and post status-page updates, so start with a read-only key and only upgrade when you need changes.

What MCP is

The Model Context Protocol (MCP) is an open standard for connecting AI applications to outside tools and data. A service runs an MCP server that describes a set of tools, each with a name, a description and the inputs it accepts. Your AI client connects to that server and lets the model call those tools when they help answer your question, the same way it might read a file or run a command.

For monitoring, that means the assistant can look at real monitor status, incident history and uptime instead of guessing or telling you to open a dashboard.

What you need

The examples here use PingRobot's remote MCP server at https://pingrobot.io/mcp, which speaks Streamable HTTP, is available on every plan, and uses the same API keys as the REST API. Create a key in the app under Settings, API keys, and pick its access level:

• Read only if the assistant should only answer questions. This is the right default for a chat assistant.
• Read & write if it should also create, change or delete monitors and maintenance windows.

The key is shown once, so copy it before closing the dialog. Each snippet below uses pr_live_… as a placeholder for it.

Connect your client

Claude Code

One command adds the server:

claude mcp add --transport http pingrobot https://pingrobot.io/mcp \
  --header "Authorization: Bearer pr_live_…"

Claude Desktop

Open Settings, Developer, Edit config, and add the server to claude_desktop_config.json. Claude Desktop connects through mcp-remote, which needs Node.js installed:

{
  "mcpServers": {
    "pingrobot": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://pingrobot.io/mcp", "--header", "Authorization:${PINGROBOT_AUTH}"],
      "env": { "PINGROBOT_AUTH": "Bearer pr_live_…" }
    }
  }
}

Restart Claude Desktop afterwards so it picks up the change.

Cursor

Add the server to ~/.cursor/mcp.json, or to .cursor/mcp.json inside a project:

{
  "mcpServers": {
    "pingrobot": {
      "url": "https://pingrobot.io/mcp",
      "headers": { "Authorization": "Bearer pr_live_…" }
    }
  }
}

If you use the project file, keep it out of version control, because it contains the key.

VS Code

Add the server to .vscode/mcp.json. The inputs entry makes VS Code ask for the key once and store it securely, so the file itself holds no secret:

{
  "inputs": [{ "type": "promptString", "id": "pingrobot-key", "description": "PingRobot API key", "password": true }],
  "servers": {
    "pingrobot": {
      "type": "http",
      "url": "https://pingrobot.io/mcp",
      "headers": { "Authorization": "Bearer ${input:pingrobot-key}" }
    }
  }
}

Other clients

Any client that supports remote MCP servers over Streamable HTTP with a custom header works with the same URL and an Authorization: Bearer <your key> header. Clients that only run local (stdio) servers can use mcp-remote, as in the Claude Desktop example.

What does not work yet: connectors that sign in with OAuth, such as custom connectors on claude.ai. The server accepts API keys only, so those clients have no way to authenticate today.

Example prompts and what happens

Here is what the assistant does with typical requests. The tool names are the ones the server exposes; the client decides which to call based on your question.

"Which of my monitors are down, and since when?" The assistant calls list_monitors, which returns every monitor with its status, when that status started, the last failure reason and 30-day uptime. The tool can filter by status, so it may ask only for monitors that are down.

"Why did the checkout monitor fail last night?" It finds the monitor with list_monitors, then calls get_monitor for the full record, including uptime stats and recent incidents with their reasons. A good answer quotes the actual reason and times rather than speculating. If you need to dig into the server side, the website down checklist is the next step.

"Add a monitor for https://api.example.com/health that checks $.status equals ok every minute." With a read-and-write key, it calls create_monitor with a JSON rule on $.status. A one-minute interval needs a plan that allows it; otherwise the call fails with the plan's limit in the error message and the assistant should tell you so. It may run test_monitor first to try the check without saving it.

"Create a heartbeat for my nightly backup and give me the curl command for the end of the script." It calls create_monitor with type heartbeat and a daily interval, then reads the heartbeatUrl from the reply and writes the line for your script. See cron job monitoring with heartbeats for why the ping should run only on success.

"Pause all checks for the shop from 02:00 to 03:00 Istanbul time every Sunday." It calls create_maintenance_window with a weekly repeat, the shop's monitors and the Europe/Istanbul time zone. list_maintenance_windows shows whether it is set up as you expected.

"Post on the status page that we're investigating slow logins." It calls list_status_pages to find the page and post_announcement to publish an incident. This one is public, so it should show you the wording before posting. Later, add_announcement_update can mark it resolved.

An exchange might look like this. This is an illustrative example, not real output:

You: Anything down right now?
Assistant: One monitor is down. "Checkout API" has been down since 14:02 UTC
with the reason "HTTP 503". Everything else is up; 30-day uptime across your
monitors is above 99.9%.

Use it safely

An assistant with tools can act quickly, which is the point and also the risk. A few habits keep it under control.

Use a read-only key for chat. Most questions, such as what is down, why something failed and how uptime looked last week, need only read access. The assistant can do only what its key allows, so a read-only key rules out accidental deletes entirely.

Confirm destructive actions. Each tool carries MCP hints that mark it as read-only or destructive, so clients can ask you before the assistant deletes a monitor, a contact or a maintenance window. Leave those confirmations on. delete_monitor removes the monitor and its history, and that cannot be undone.

Review public announcements. Anything posted with post_announcement is visible to everyone who opens the status page, and with notify on Pro, confirmed email subscribers get it too. Read the wording before approving it. Incident communication templates help if you want consistent phrasing.

Keep keys out of shared files. Use VS Code's input prompt or environment variables where you can, and do not commit config files that contain a key.

Revoke when in doubt. If a key ends up somewhere it should not, revoke it in Settings. It stops working at once, in every client, and you can create a new one in seconds.

Mind the rate limit. MCP calls count toward the same 120 requests a minute per key as the API. Normal conversation stays far below that, but an agent looping over dozens of monitors can reach it.

When to use the API instead

MCP is good for questions and one-off changes in a conversation. For anything that should happen the same way every time, such as creating a monitor on customer signup or opening a maintenance window during each deploy, write code against the REST API instead. See uptime monitoring API for those patterns, and the MCP docs for the full tool list.

Start monitoring free — 10 monitors, no credit card.