# Stackpulse [Health: Active]

**Category:** 📊 Monitoring  
**Repository:** https://stackpulse.app/mcp  
**Views:** 1  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/stackpulse

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

## Tools
Capabilities this server exposes over MCP:

- **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 to break together.
- **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.

## Claude Desktop Quick Installation
Remote MCP endpoint (confidence: medium). Install path inferred — verify against the README before running it. Add as a URL/SSE server in your client:

```json
"mcpServers": {
  "stackpulse": {
    "url": "https://stackpulse.app/mcp"
  }
}
```

## Documentation

## What Stackpulse MCP server does

The Stackpulse MCP server gives an MCP-compatible agent access to Stackpulse monitoring data and selected account-management actions. It covers two related sources: a catalog of thousands of public status pages and the dashboards configured in a Stackpulse account.

For public services, an agent can search by name, retrieve the current state of one service, inspect affected components, review recent incidents, and view up to 90 days of history. It can also list services currently reporting problems, with controls for the result set.

For account data, the Stackpulse MCP server exposes dashboard status, dashboard incident history, URL-monitor details, uptime measurements, failed checks, response times, certificate information, and recent checks. It also supports dashboard and monitor changes, including creating or renaming dashboards, adding or removing services, and adding, checking, pausing, or resuming URL monitors.

## How it works

The integration is exposed through the Stackpulse MCP endpoint at `https://stackpulse.app/mcp`. An MCP client invokes named tools and receives structured results about service status, dashboard state, incidents, or monitor checks.

Service-based dashboard actions use slugs rather than display names. The intended flow is to search the service catalog first, use the returned slug when creating a dashboard or adding services, and then query the dashboard’s status or reliability. Dashboard queries can target one dashboard; some status and history operations can also cover all dashboards visible to the connection.

A URL monitor is checked when it is added, and a manual check can be requested later. Pausing ends an open incident and suppresses alerts until the monitor is resumed. Resuming checks the endpoint immediately and starts a new monitoring period.

## Tools and capabilities

Available operations include:

- Search public status-page services and retrieve one service’s status and history.
- List current service outages, newest first.
- List visible dashboards and summarize their service and URL-monitor counts.
- Report dashboard problems, incident start times, and current-status changes.
- Analyze dashboard reliability over 7-, 30-, or 90-day periods.
- Inspect monitor uptime, failed checks, response times, certificate data, and latest results.
- Create and rename dashboards, or add and remove catalog services.
- Add, check, pause, and resume URL monitors.

Reliability results rank the least reliable items first and include time by severity, incidents, recovery information, and services or monitors that tend to fail together.

## Limitations and notes

The Stackpulse MCP server requires a Stackpulse Pro plan.

URL-monitor creation follows restrictions enforced by the Stackpulse application. Private addresses and unsupported ports are rejected, and plan limits apply to dashboards, services, and monitors. Monitor headers and request bodies remain managed in the Stackpulse application rather than being supplied through the described tool interface.

Removing a service from a dashboard does not delete its history; adding it again makes that history visible on the dashboard. Incident-history range is limited by the account plan’s available history. A dashboard query without a dashboard identifier returns information for every dashboard the connection can see.

_Full upstream README: https://allmcps.com/mcp/stackpulse/readme_