devops-status-mcp-server

<div align="center">
  <h1>@cyanheads/devops-status-mcp-server</h1>
  <p><b>Check vendor status pages, inspect SSL/TLS certificates, verify DNS propagation, and get incident-response playbooks via MCP. STDIO or Streamable HTTP.</b>
  <div>7 Tools • 1 Resource</div>
  </p>
</div>

<div align="center">

[![Version](https://img.shields.io/badge/Version-0.7.0-blue.svg?style=flat-square)](./CHANGELOG.md) [![License](https://img.shields.io/badge/License-Apache%202.0-orange.svg?style=flat-square)](./LICENSE) [![Docker](https://img.shields.io/badge/Docker-ghcr.io-2496ED?style=flat-square&logo=docker&logoColor=white)](https://github.com/users/cyanheads/packages/container/package/devops-status-mcp-server) [![MCP SDK](https://img.shields.io/badge/MCP%20SDK-^1.29.0-green.svg?style=flat-square)](https://modelcontextprotocol.io/) [![npm](https://img.shields.io/npm/v/@cyanheads/devops-status-mcp-server?style=flat-square&logo=npm&logoColor=white)](https://www.npmjs.com/package/@cyanheads/devops-status-mcp-server) [![TypeScript](https://img.shields.io/badge/TypeScript-^7.0.2-3178C6.svg?style=flat-square)](https://www.typescriptlang.org/) [![Bun](https://img.shields.io/badge/Bun-v1.3.0-blueviolet.svg?style=flat-square)](https://bun.sh/)

</div>

<div align="center">

[![Install in Claude Desktop](https://img.shields.io/badge/Install_in-Claude_Desktop-D97757?style=for-the-badge&logo=anthropic&logoColor=white)](https://github.com/cyanheads/devops-status-mcp-server/releases/latest/download/devops-status-mcp-server.mcpb) [![Install in Cursor](https://cursor.com/deeplink/mcp-install-dark.svg)](https://cursor.com/en/install-mcp?name=devops-status-mcp-server&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIkBjeWFuaGVhZHMvZGV2b3BzLXN0YXR1cy1tY3Atc2VydmVyIl19) [![Install in VS Code](https://img.shields.io/badge/VS_Code-Install_Server-0098FF?style=for-the-badge&logo=visualstudiocode&logoColor=white)](https://vscode.dev/redirect?url=vscode:mcp/install?%7B%22name%22%3A%22devops-status-mcp-server%22%2C%22command%22%3A%22npx%22%2C%22args%22%3A%5B%22-y%22%2C%22%40cyanheads%2Fdevops-status-mcp-server%22%5D%7D)

[![Framework](https://img.shields.io/badge/Built%20on-@cyanheads/mcp--ts--core-67E8F9?style=flat-square)](https://www.npmjs.com/package/@cyanheads/mcp-ts-core)

</div>

<div align="center">

**Public Hosted Server:** [https://devops-status.caseyjhand.com/mcp](https://devops-status.caseyjhand.com/mcp)

</div>

---

## Tools

Seven tools in three capability groups — vendor status (51 built-in vendors across Atlassian Statuspage, Status.io, Slack, AWS Health, Google Cloud Service Health, and Firehydrant backends, normalized to one shape, + raw Statuspage URL passthrough), pure-TypeScript cert/DNS checks (any domain), and incident-response guidance:

| Tool | Description |
|:-----|:------------|
| `devops_list_vendors` | List vendors in the built-in registry, optionally filtered by name or category. Returns slug, display name, category, and status page URL. |
| `devops_status_check` | Check the current health status for one or more vendors. Returns per-vendor indicator (`none` / `minor` / `major` / `critical`), degraded components, and active incident summaries. |
| `devops_get_incidents` | Fetch incident history for a vendor — active, resolved, or scheduled maintenance. Returns the full incident timeline with per-update bodies and affected components. |
| `devops_watch_stack` | Check the health of a named vendor stack persisted in session state. Pass `vendors` once to save the list; subsequent calls reuse it. Returns an aggregate health rollup plus per-vendor detail. |
| `devops_check_certs` | Inspect SSL/TLS certificate health for one or more domains via a real TLS handshake. Reports expiry, chain depth, protocol version, cipher suite, and HSTS presence. Pure TypeScript — no external API. |
| `devops_check_dns` | Resolve DNS records and verify propagation for one or more domains across Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). Reports per-resolver latency and resolver discrepancies. Pure TypeScript — no external API. |
| `devops_suggest_action` | Instruction tool — returns a tailored incident-response playbook and pre-filled follow-up tool calls given a vendor name and optional incident context. No external calls; fully deterministic. |

### `devops_list_vendors`

Discover available vendors before running status checks or configuring a stack.

- Accepts an optional free-text `query` (matches name and slug, case-insensitive) and an optional `category` filter
- Eight categories: `cloud`, `cdn-edge`, `dev-platform`, `data`, `comms`, `auth`, `monitoring`, `ai`
- Returns slug (what to pass to other tools), display name, category, and status page URL
- 51 built-in entries — well-known public vendors with verified status endpoints (most on Atlassian Statuspage; `aws`, `gcp`, `gitlab`, `neon`, `slack`, and `redis-cloud` served through native-API adapters)

Built-in vendor registry:

| Category | Vendors |
|:---------|:--------|
| `cloud` | digitalocean, linode, aws, gcp |
| `cdn-edge` | cloudflare, akamai |
| `dev-platform` | gitlab, github, npm, vercel, netlify, render, fly-io, circleci, travis-ci, snyk, atlassian, figma, launchdarkly |
| `data` | mongodb-atlas, planetscale, supabase, neon, redis-cloud, elastic, influxdb, upstash, cloudinary, segment |
| `comms` | slack, discord, twilio, sendgrid, mailgun, hubspot, brevo, courier, loops |
| `auth` | auth0, clerk, workos |
| `monitoring` | datadog, sentry, new-relic, grafana-cloud, honeycomb |
| `ai` | openai, anthropic, elevenlabs, pinecone, cohere |

Most registry entries are Atlassian Statuspage endpoints; `aws` (AWS Health Dashboard), `gitlab` / `neon` (Status.io), `slack` (Slack's own status API), and `redis-cloud` (Firehydrant) are served through adapters that normalize into the same shapes, so every tool works identically for them. GCP and Azure publish no keyless machine-readable feed and remain out of the registry — Statuspage-compatible pages can still be reached by passing a raw base URL.

---

### `devops_status_check`

Batch health snapshot across one or more vendors in a single call.

- Accepts registered vendor slugs (e.g., `"github"`, `"aws"`) or raw Atlassian Statuspage base URLs (e.g., `"https://www.githubstatus.com"`) — mix freely
- `mode: "summary"` (default): indicator + degraded components + active incidents
- `mode: "detailed"`: adds full component list and scheduled maintenance windows
- `Promise.allSettled` fan-out — one failing vendor does not block the rest; errors surface inline
- Results served from a 60-second in-memory cache; `cached: true` flag on each result

---

### `devops_get_incidents`

Full incident timeline for a vendor with filter support.

- `filter: "all"` (default): incidents plus scheduled maintenances
- `filter: "active"`: only incidents with status `investigating` / `identified` / `monitoring`
- `filter: "resolved"`: only fully resolved incidents
- `filter: "scheduled"`: only scheduled maintenance windows
- Returns per-update bodies in chronological order, affected component names, duration in minutes (resolved incidents), and a direct shortlink to the incident page
- Configurable `limit` (1–50) with `offset` for paging through longer history; a truncated result discloses the total and names the next `offset` to fetch
- AWS exposes only currently-open events (no history feed) — `filter: "resolved"` and `filter: "scheduled"` are always empty for `aws`

---

### `devops_watch_stack`

Named, persisted vendor stack for recurring health sweeps.

- On the first call, provide `vendors` to define the stack — it is saved to tenant-scoped session state under `stack_name`
- Subsequent calls can omit `vendors`; the saved list is reused automatically
- Multiple stacks coexist via distinct `stack_name` values (e.g., `"production"`, `"data-layer"`)
- Aggregate health output: `all_operational` / `degraded` / `partial_outage` / `major_outage` / `unknown` (a vendor could not be reached — errored vendors count as `unavailable` and never roll up as `all_operational`)
- Note: stack state is in-memory; it does not persist across server restarts

---

### `devops_check_certs`

Direct TLS handshake inspection — no external API required.

- Accepts bare hostnames (no `https://` prefix) — up to 10 per call
- Reports: days to expiry (flagged `warning` at < 30 days, `critical` at < 7), certificate subject and SANs, issuer common name, chain depth, negotiated TLS version (flags 1.0 and 1.1 as insecure), cipher suite
- HSTS detection: sends a minimal HTTP/1.1 GET over the same TLS socket, reads the `Strict-Transport-Security` response header
- Per-domain failures are reported inline (status: `"error"`) rather than throwing — useful partial results when checking multiple domains
- Configurable port (default 443) and timeout per domain

---

### `devops_check_dns`

Multi-resolver DNS propagation check — no external API required.

- Queries Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9) in parallel per domain
- Supported record types: A, AAAA, CNAME, MX, TXT, NS (defaults to A, AAAA, MX, TXT)
- Reports per-resolver latency, propagation discrepancies (where resolvers disagree), and human-readable flags
- Custom resolver list supported — pass any IP addresses to test internal DNS or resolver-specific behavior
- Up to 10 domains per call; per-domain timeouts configurable

---

### `devops_suggest_action`

Deterministic incident-response guidance, no external calls.

- Returns a markdown playbook tailored to the vendor's category (CDN outage vs. CI/CD outage vs. auth provider outage vs. AI service outage)
- Accepts a vendor slug or display name (`aws` or `Amazon Web Services`) — resolved to the canonical slug so the pre-filled follow-up arguments stay valid
- `nextToolSuggestions` pre-populated with arguments from the provided context — execute in sequence to gather diagnostic data
- Optional `your_domain` populates cert and DNS check arguments automatica