Check vendor status pages, inspect SSL/TLS certificates, verify DNS propagation, and get incident-response playbooks via MCP. STDIO or Streamable HTTP.
- ✓Open-source license (Apache-2.0)
- ✓Actively maintained (<30d)
- ✓Clear description
- ✓Topics declared
- ✓Documented (README)
git clone https://github.com/cyanheads/devops-status-mcp-server{
"mcpServers": {
"devops-status": {
"command": "node",
"args": ["/path/to/devops-status-mcp-server/dist/index.js"]
}
}
}MCP Servers overview
<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">
[](./CHANGELOG.md) [](./LICENSE) [](https://github.com/users/cyanheads/packages/container/package/devops-status-mcp-server) [](https://modelcontextprotocol.io/) [](https://www.npmjs.com/package/@cyanheads/devops-status-mcp-server) [](https://www.typescriptlang.org/) [](https://bun.sh/)
</div>
<div align="center">
[](https://github.com/cyanheads/devops-status-mcp-server/releases/latest/download/devops-status-mcp-server.mcpb) [](https://cursor.com/en/install-mcp?name=devops-status-mcp-server&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIkBjeWFuaGVhZHMvZGV2b3BzLXN0YXR1cy1tY3Atc2VydmVyIl19) [](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)
[](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>
---
## Overview
Vendor status pages, SSL/TLS certificates, and DNS propagation — normalized across Atlassian Statuspage, Status.io, Slack, AWS Health, Google Cloud Service Health, and Firehydrant backends, plus direct TLS/DNS checks for any domain. List and check 51 built-in vendors, fetch incident timelines, watch a persisted stack, and get a tailored incident-response playbook, all without API keys. Runs as a stdio process, a local Streamable HTTP server, or the public hosted endpoint above.
### Tools
| 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` / `maintenance`), 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. |
### Resources
| Resource | Description |
|:-----|:------------|
| `devops-status://vendors/{name}` | Full registry entry for a vendor by slug — status page URL, category, and API type. |
All resource data is also reachable via tools. Tool-only agents are fully supported.
---
## Capability reference
### `devops_list_vendors` <sub>tool</sub>
- 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, most on Atlassian Statuspage; `aws`, `gcp`, `gitlab`, `neon`, `slack`, and `redis-cloud` route through native-API adapters normalized to the same shape
- Azure is excluded — its status feed is RSS with no severity/lifecycle field, so the normalized shape can't be filled without inventing values
- Statuspage-compatible pages not in the registry are still reachable by passing a raw base URL to other tools
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 |
---
### `devops_status_check` <sub>tool</sub>
- Accepts registered vendor slugs (e.g., `github`, `aws`) or raw Atlassian Statuspage base URLs, mixed freely — up to 20 per call
- `mode: "summary"` (default): indicator + degraded components + active incidents; `mode: "detailed"` adds the full component list (capped at `component_limit`, default 50, max 500) and scheduled maintenance windows
- `Promise.allSettled` fan-out — one failing vendor never blocks the rest; failures surface as a per-vendor `error` field
- Results served from a 60-second in-memory cache; `cached: true` on each result
- `summary` partitions the batch into `operational` / `degraded` / `down` / `maintenance` / `unavailable` counts
---
### `devops_get_incidents` <sub>tool</sub>
- `filter`: `all` (default, incidents + scheduled maintenances), `active` (investigating/identified/monitoring), `resolved` (fully resolved), or `scheduled` (maintenance windows only)
- Returns per-update bodies in chronological order, affected component names, duration in minutes for resolved incidents, and a direct shortlink to the incident page
- `limit` (1–50) with `offset` for paging; a truncated result discloses the total and the next `offset` to fetch
- Some vendor feeds cap their own history (`upstreamCeiling`) — incidents older than that ceiling are reachable only on the vendor's own status page
- AWS exposes only currently-open events — `filter: "resolved"` and `filter: "scheduled"` are always empty for it
---
### `devops_watch_stack` <sub>tool</sub>
- 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"`) — letters, digits, hyphens, and underscores, optionally separated by single dots or slashes, 1-64 characters
- Aggregate `health` rollup: `all_operational` / `maintenance` (a vendor in a scheduled window, nothing worse open) / `degraded` / `partial_outage` / `major_outage` / `unknown` (a vendor could not be reached) — never `all_operational` when any vendor errored or is in a window
- Note: stack state is in-memory; it does not persist across server restarts
---
### `devops_check_certs` <sub>tool</sub>
- 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
- `status: "critical"` distinguishes a hostname mismatch (`hostname_verification_error`) from an untrusted chain (`authorization_error`) — both would be rejected by ordinary clients
- 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` <sub>tool</sub>
- 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, and human-readable flags
- Discrepancies are typed: `partial_resolution` (some resolvers answered, others didn't) signals a real problem; `value_variation` (all answered, different values) is normal for anycast/geo-steered domains
- Custom resolver list supported — pass any IP addresses to test internal DNS or resolver-specific behavior
- Up to 10 domWhat people ask about devops-status-mcp-server
What is cyanheads/devops-status-mcp-server?
+
cyanheads/devops-status-mcp-server is mcp servers for the Claude AI ecosystem. Check vendor status pages, inspect SSL/TLS certificates, verify DNS propagation, and get incident-response playbooks via MCP. STDIO or Streamable HTTP. It has 2 GitHub stars and its last recorded update is dated 2026-09-20.
How do I install devops-status-mcp-server?
+
You can install devops-status-mcp-server by cloning the repository (https://github.com/cyanheads/devops-status-mcp-server) or following the README instructions on GitHub. ClaudeWave also provides quick install blocks on this page.
Is cyanheads/devops-status-mcp-server safe to use?
+
Our security agent has analyzed cyanheads/devops-status-mcp-server and assigned a Trust Score of 95/100 (tier: Verified). See the full breakdown of passed checks and flags on this page.
Who maintains cyanheads/devops-status-mcp-server?
+
cyanheads/devops-status-mcp-server is maintained by cyanheads. The last recorded GitHub activity is dated 2026-09-20, with 3 open issues.
Are there alternatives to devops-status-mcp-server?
+
Yes. On ClaudeWave you can browse similar mcp servers at /categories/mcp, sorted by popularity or recent activity.
Deploy devops-status-mcp-server to your cloud
Ship this repo to production in minutes. Each platform spins up its own environment with editable env vars.
Maintain this repo? Add a badge to your README
Drop the badge into your GitHub README to show it's tracked on ClaudeWave. Each badge links back to this page and reflects the live Trust Score.
[](https://claudewave.com/repo/cyanheads-devops-status-mcp-server)<a href="https://claudewave.com/repo/cyanheads-devops-status-mcp-server"><img src="https://claudewave.com/api/badge/cyanheads-devops-status-mcp-server" alt="Featured on ClaudeWave: cyanheads/devops-status-mcp-server" width="320" height="64" /></a>More MCP Servers
Fair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400+ integrations.
User-friendly AI Interface (Supports Ollama, OpenAI API, ...)
An open-source AI agent that brings the power of Gemini directly into your terminal.
Real-time global intelligence dashboard. AI-powered news aggregation, geopolitical monitoring, and infrastructure tracking in a unified situational awareness interface
🕷️ An adaptive Web Scraping framework that handles everything from a single request to a full-scale crawl! Don't be shy, join here: https://discord.gg/EMgGbDceNQ
The fastest path to AI-powered full stack observability, even for lean teams.