uptimepage MCP
Monitoring and status page service with an MCP server: an agent reads check state and manages incidents.
- 55 ★ on the repository
- Last commit
- AGPL-3.0
Extended access
Why this level
- A token with write scopes lets the agent change monitors and publish text on the public status page.
- The connection lifetime is chosen on the consent screen: 90 days by default, 365 at most.
Install
- Works in
Manual install
{
"mcpServers": {
"uptimepage": {
"command": "npx",
"args": [
"-y", "mcp-remote",
"https://mcp.uptimepage.dev/mcp",
"--header", "Authorization: Bearer sm_live_YOUR_TOKEN"
]
}
}
}Config from the docs with a manual token. Issue the token in the API token settings.
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- A token with write scopes lets the agent change monitors and publish text on the public status page.
- The connection lifetime is chosen on the consent screen: 90 days by default, 365 at most.
This is third-party code. Review the repository files before installing.
What it does
uptimepage combines uptime monitoring, public status pages and on-call. Checks run as often as every 30 seconds from several regions across eight check types, including browser login flows and cron heartbeats. The service runs in the cloud, and the AGPL-3.0 source can be self-hosted. The MCP server is available at `https://mcp.uptimepage.dev/mcp` and is bound to one organization. It exposes 20 read tools and 21 write tools covering checks, incidents, maintenance windows and status pages. Writes need token scopes and, where the client can ask, confirmation for every action. Each call is recorded in the audit log.
Who it is for. SRE engineers and service owners who watch availability and want to ask an agent about checks, incidents and status.
Good fit when
- An alert fired overnight and the agent should show which checks failed and when.
- Monitors have to be added to a status page as public components.
- A maintenance window is created before work so alerts stay quiet.
- A dozen checks are created in a batch under one confirmation.
Not a fit when
- Monitoring runs in another service: the server knows only uptimepage data.
- A token with write scopes was issued to a client with no confirmation prompt.
- There are several organizations: a token is bound to one and cannot switch.
Example request
Show checks that failed in the last 24 hours and the incidents open on the public status page.MCP
- Transport
- http
- Authentication
- OAuth
Limitations
A token is bound to one organization and expires. The connector grants read-only scopes by default and write access is switched on at the consent screen. A client without confirmation prompts writes silently on token scope. Notification channels and variables are created in the app and the tools only read them. For a self-hosted server MCP is enabled with `UPTIMEPAGE_MCP_ENABLED=true` and is off by default.
How to disable. Revoke the connector or the token in the uptimepage API token settings and delete the `uptimepage` entry from the client config. On a self-hosted server remove the `UPTIMEPAGE_MCP_ENABLED` flag.
FAQ
How do I connect uptimepage to Claude Desktop?
Create a token in the API token settings and add an entry running `npx -y mcp-remote https://mcp.uptimepage.dev/mcp --header "Authorization: Bearer sm_live_YOUR_TOKEN"`. Keep the token minimal: three scopes cover reading, `targets:read`, `status_page:read` and `incidents:read`.
How do I connect through Cursor or VS Code?
Enter `https://mcp.uptimepage.dev/mcp` in the editor's MCP settings. The editor registers itself, opens the sign-in with a consent screen in the browser and returns. No token needs pasting.
Can the agent change monitors and publish incidents?
Yes, if the consent screen grants the Manage monitors or Full access level. Each write needs token scopes and confirmation where the client can ask. Read only is preselected by default.
Can I self-host the service?
Yes. The source is AGPL-3.0, and MCP on your own server is enabled with `UPTIMEPAGE_MCP_ENABLED=true`. The OAuth connector adds its own flag.
What will the agent not see?
Values of variables and secrets, webhook URLs and bot tokens of notification channels. The server returns only names and state flags.
Discussion
No questions or reviews yet.
Related
MCP serversThe built-in OneUptime MCP: an agent works incidents, reads logs and traces, acknowledges alerts and sets up monitors.
A skill that teaches an agent to create monitors, run incidents and build public status pages in OpenUptime over MCP
mcp-uptime-kuma: MCP server for Uptime Kuma 2
mcp-uptime-kuma
An MCP server for agents: read Uptime Kuma 2 monitors and checks, create or edit monitors and maintenance windows
Datadog MCP Server (winor30)
Datadog MCP Server
Independent Datadog MCP server: an agent reads incidents, monitors, logs, metrics, traces and RUM and schedules downtimes.
The cronstable job scheduler exposes its jobs, run history and schedule debugging to an agent through MCP.
maintenant monitoring MCP server: an agent reads container logs, check history and alerts but never touches the containers
README in short
The README presents the service as monitoring, status pages and on-call in one product. It then covers the REST API, the Terraform provider, the MCP server, a self-hosting quick start and a documentation table.