78trust / 100

Stackpulse

by stackpulse.app in Developer tools

MCP serverPassing, checked 9 h ago

8,900+ services' status, and your Stackpulse dashboards and URL monitors. Needs Pro.

https://stackpulse.app/mcp
Tools
16
open to any client
Uptime
100%
last 30 days
Response time
308 ms
520 ms slowest 5%
Last check
Passed
9 h ago, next any minute now

Scan it nowHow to connect

Reliability

All checks passedSome failedAll failedNot checked

Status and outage history · Atom feed · Watch with other listings

How to connect

Add it to any MCP client that supports remote servers.

{
  "mcpServers": {
    "stackpulse": {
      "type": "http",
      "url": "https://stackpulse.app/mcp"
    }
  }
}

16 tools

  • search_services

    Finds services in the catalog of 9,700+ status pages by name, with their status now. Use it to find a service’s slug.

  • get_service

    One service’s status from its official status page: what’s wrong, the components with a problem, 90 days of history and recent incidents.

  • list_outages

    Services reporting a problem right now, the newest first: the 25 best-known, unless all is true or a limit is given.

  • list_dashboards

    The 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_status

    What’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_history

    Incidents 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_monitor

    One 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_reliability

    How 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…

  • create_dashboard

    Makes 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_dashboard

    Renames a dashboard. Its status page shares the name.

  • add_services

    Adds services to a dashboard by slug (search_services finds them), within the plan’s limit.

  • remove_services

    Takes services off a dashboard. Their history stays; adding one back shows it again.

  • add_monitor

    Watches 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_monitor

    Checks one of the account’s URL monitors now, as Check now does in the app, and says what it got.

  • pause_monitor

    Pauses a URL monitor, e.g. during a deploy: an open incident ends, and no alerts go out until it’s resumed.

  • resume_monitor

    Resumes a paused URL monitor: it’s checked at once and starts fresh.

Security scan

No findings

We scan names, descriptions and tool definitions for hidden instructions and other prompt-injection patterns.

Recent checks

WhenResultHTTPTime
9 h agoPassed200328 ms
18 h agoPassed200337 ms
28 h agoPassed200520 ms
38 h agoPassed200271 ms
2 days agoPassed200453 ms
Show 8 older checks
2 days agoPassed200272 ms
3 days agoPassed200257 ms
3 days agoPassed200297 ms
4 days agoPassed200326 ms
4 days agoPassed200392 ms
4 days agoPassed200241 ms
5 days agoPassed200308 ms
5 days agoPassed200295 ms