AI assistants (MCP)
Statuswerk has an MCP server (Model Context Protocol). With it, an AI assistant can run your status page: "Set the checkout API to partial outage and open an incident" — and the assistant does it, exactly as if you had done it in the dashboard. Subscribers are notified, the affected components show the disruption, and four-eyes approval applies here too.
What the assistant can do
| Tool | What it does |
|---|---|
get-status |
The page at a glance: overall status, open incidents, uptime, disrupted components |
list-components |
List components with their ID and current status |
set-component-status |
Set a component's status |
list-incidents |
List open incidents with their IDs, resolved ones on request |
create-incident |
Open an incident, with the affected components |
post-incident-update |
Post an update, also to resolve |
list-incident-templates |
Incident templates with their ID and placeholders |
apply-incident-template |
Open an incident from a template, placeholders filled |
list-maintenances |
Scheduled and running maintenance |
create-maintenance |
Announce a maintenance window, with the affected components |
start-maintenance / complete-maintenance |
Start or complete a maintenance by hand |
list-monitors |
Your HTTP checks with their state and last result (read-only) |
If a new incident waits for four-eyes approval, the tool says so explicitly, and the assistant does not report it as published.
If your workspace has several status pages, the assistant names the one it means with statuspage_id; otherwise it uses the first.
Subscribers are notified by default. With notify_subscribers: false an incident, an update or a maintenance stays quiet — for an interim note, say. create-incident and create-maintenance also take is_unlisted: the entry then stays off the status page, and the assistant hands you the link to share (public_url). See Unlisted entries.
Setting it up
You need an API token. Read-only is enough to look; for the assistant to change anything it needs read & write. The token is bound to your workspace.
The server's address:
https://statuswerk.eu/mcp/statuswerk
The token goes along as a header: Authorization: Bearer YOUR_TOKEN.
Claude Code
claude mcp add --transport http statuswerk https://statuswerk.eu/mcp/statuswerk \
--header "Authorization: Bearer YOUR_TOKEN"
Cursor (.cursor/mcp.json)
{
"mcpServers": {
"statuswerk": {
"url": "https://statuswerk.eu/mcp/statuswerk",
"headers": { "Authorization": "Bearer YOUR_TOKEN" }
}
}
}
Other clients that speak MCP over HTTP with a custom header are set up the same way.
What applies
- The same rights as the API: a read-only token can only list; on the Starter plan everything is read-only. If your access to single status pages is restricted, that applies here too.
- The same limits: your plan's incident allowance and 120 requests per minute per token.
- The assistant sees only what the token may see — your workspace, no other.
- With four-eyes approval switched on for incidents, an incident the assistant opens waits in the queue until someone approves it in the dashboard.
Give a token with write access only to an assistant you would also trust with the dashboard — and revoke it under Account → API Tokens when you no longer need it.