# Stackpulse MCP server

Source: https://glimind.com/server/mcp-registry%2Fapp.stackpulse%2Fmcp
Registry id: `mcp-registry/app.stackpulse/mcp`
Status: live (checked 2026-10-27T03:14:33.550Z)

## Verdict

Stackpulse MCP server answered 100% of Glimind's liveness checks over 30 days, better than 42% of MCP servers, with 618 ms median handshake and 0 outages in 90 days. Its agent-readiness grade is A (100/100) across 16 tools, costing an agent about 2,078 tokens to load. Checked every few minutes; no tool is ever called.

## Measurements (30 days)

| Metric | Value | Better than |
|---|---|---|
| Uptime, 30 days | 100% | 42% of MCP servers |
| Median handshake latency | 618 ms | 40% of MCP servers |
| p95 handshake latency | 2862 ms | — |
| Checks in 30 days | 3,216 | — |
| Outages, 90 days | 0 | — |
| Median recovery | — | — |
| Agent-readiness score | 100/100 (A) | 94% of MCP servers |
| Tools | 16 | — |
| Tool-list size for an agent | ~2,078 tokens | 52% of MCP servers |
| Days observed | 15 | — |

## Install

```json
{
  "mcpServers": {
    "stackpulse-mcp-server": {
      "type": "http",
      "url": "https://stackpulse.app/mcp"
    }
  }
}
```

Claude Code:

```sh
claude mcp add --transport http stackpulse-mcp-server https://stackpulse.app/mcp
```

## Tools (16)

- `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
- `add_services`: Adds services to a dashboard by slug (search_services finds them), within the plan’s limit.
- `check_monitor`: Checks one of the account’s URL monitors now, as Check now does in the app, and says what it got.
- `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 addres
- `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 pl
- `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 certific
- `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 (mi
- `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.
- `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
- `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.
- `list_outages`: Services reporting a problem right now, the newest first: the 25 best-known, unless all is true or a limit is given.
- `pause_monitor`: Pauses a URL monitor, e.g. during a deploy: an open incident ends, and no alerts go out until it’s resumed.
- `remove_services`: Takes services off a dashboard. Their history stays; adding one back shows it again.
- `rename_dashboard`: Renames a dashboard. Its status page shares the name.
- `resume_monitor`: Resumes a paused URL monitor: it’s checked at once and starts fresh.
- `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.

Measured by Glimind (https://glimind.com): MCP handshake + tool list only, no tool is ever called. CC BY 4.0.