All servers · Monitoring & logs
Stackpulse
app.stackpulse/mcp · v1.0.0
Has write/delete tools
Measured by MCP Station
| Last check | Reachable |
|---|---|
| Checked at | — |
| Check success 7 / 30 days | — |
| First-try success 30 days | — |
| Median response | — |
| Lookups 30 days | — |
| Authentication | No auth |
| MCP version | 2025-06-18 |
| Rank score | — |
| Declared risk | Has destructive tools (destructiveHint) |
| Capabilities declared | tools |
| Tool definitions | 16 tools · with description 100% · input schema is an object 100% · read/destructive hints 100% |
Description written by the publisher, not verified
8,900+ services' status, and your Stackpulse dashboards and URL monitors. Needs Pro.
Connect
streamable-http · https://stackpulse.app/mcp
claude mcp add --transport http mcp https://stackpulse.app/mcp{
"mcpServers": {
"mcp": {
"url": "https://stackpulse.app/mcp"
}
}
}Tools as reported by the server
search_servicesFinds services in the catalog of 9,700+ status pages by name, with their status now. Use it to find a service’s slug.get_serviceOne service’s status from its official status page: what’s wrong, the components with a problem, 90 days of history and recent incidents.list_outagesServices reporting a problem right now, the newest first: the 25 best-known, unless all is true or a limit is given.list_dashboardsThe account’s dashboards (the ones this connection can see), with how many services and URL monitors each has and its worst status now.get_stack_statusWhat’s going on now on a dashboard: a summary, then every service and URL monitor with a problem, with when the problem began and when its current status did. A URL monitor that’s down lists what started around then. Without a dashboard, every dashboard.get_incident_historyIncidents on a dashboard in a window: the ones that started in it (with what else started at the same time) and the ones already going on. As far back as the plan’s history goes.get_monitorOne of the account’s URL monitors: its status, its uptime over the last 30 days (or since it started) with the failed checks apart, response times, its certificate and its latest checks.get_reliabilityHow reliable a dashboard’s services and URL monitors were over 7, 30 or 90 days: the least reliable first, with the share of time without a reported problem (minor issues count, so one long minor issue makes it low), time in each severity, incidents and recovery, and what tends to break together.create_dashboardMakes a dashboard with a name and, optionally, services by slug (search_services finds them), within the plan’s dashboards and services. Answers with its address.rename_dashboardRenames a dashboard. Its status page shares the name.add_servicesAdds services to a dashboard by slug (search_services finds them), within the plan’s limit.remove_serviceswrite/deleteTakes services off a dashboard. Their history stays; adding one back shows it again.add_monitorWatches a website or API endpoint on a dashboard: checks the address once first, and refuses what the app refuses (private addresses, other ports, past the plan). Without a name, the page’s title names it. Headers and request bodies stay in the app.check_monitorChecks one of the account’s URL monitors now, as Check now does in the app, and says what it got.pause_monitorPauses a URL monitor, e.g. during a deploy: an open incident ends, and no alerts go out until it’s resumed.resume_monitorResumes a paused URL monitor: it’s checked at once and starts fresh.
Website · JSON · Text for agents · Registry updated 2026-10-10