# devops-status-mcp-server [Health: Active]
**Category:** 💻 Developer Tools
**Repository:** https://github.com/cyanheads/devops-status-mcp-server
**GitHub Stars:** 1
**Views:** 0
**Installs:** 0
**Upvotes:** 0
**Directory Page:** https://allmcps.com/mcp/devops-status-mcp-server
## Description
Vendor status pages, TLS cert inspection, DNS propagation checks, and incident-response playbooks.
## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `bunx` (confidence: high):
```json
"mcpServers": {
"devops-status-mcp-server": {
"command": "bunx",
"args": ["@cyanheads/devops-status-mcp-server@latest"]
}
}
```
## Documentation & README
@cyanheads/devops-status-mcp-server
Check vendor status pages, inspect SSL/TLS certificates, verify DNS propagation, and get incident-response playbooks via MCP. STDIO or Streamable HTTP.
7 Tools • 1 Resource
[](./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/)
[](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)
**Public Hosted Server:** [https://devops-status.caseyjhand.com/mcp](https://devops-status.caseyjhand.com/mcp)
---
## 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` / `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. |
### `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), `gcp` (Google Cloud Service Health), `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. Azure remains out of the registry: its status feed is RSS with no severity or lifecycle field, so the normalized shapes cannot be filled from it without inventing values. Statuspage-compatible pages not listed here 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"`) — letters, digits, hyphens, and underscores, optionally separated by single dots or slashes, 1-64 characters
- 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 automatically
- Optional `incident_summary` / `affected_components` prepend a targeted section to the playbook and add a component re-check when they identify a subsystem (e.g. GitHub `Actions` → CI/CD-prioritized steps; Cloudflare `DNS` → DNS/TTL guidance)
- Optional `vendor_indicator` — pass the `indicator` from `devops_status_check` to lead the playbook with severity-tailored urgency guidance (`none` / `minor` / `major` / `critical` / `maintenance`)
- Falls back to generic guidance for unrecognized vendors
- When `DEVOPS_STATUS_DISABLE_ACTIVE_PROBES=true`, suggestions and playbook text replace the unregistered probe tools with equivalent manual commands (`dig`, `openssl s_client`)
---
## Resources and prompts
| Type | Name | Description |
|:-----|:-----|:------------|
| Resource | `devops-status://vendors/{name}` | Full registry entry for a vendor by slug — status page URL, category, API type. |
All resource data is also reachable via tools. Tool-only agents are fully supported.
---
## Features
Built on [`@cyanheads/mcp-ts-core`](https://www.npmjs.com/package/@cyanheads/mcp-ts-core):
- Declarative tool and resource definitions — single file per primitive, framework handles registration and validation
- Unified error handling — handlers throw, framework catches, classifies, and formats
- Pluggable auth: `none`, `jwt`, `oauth`
- Swappable storage backends: `in-memory`, `filesystem`, `Supabase`, `Cloudflare KV/R2/D1`
- Structured logging with optional OpenTelemetry tracing
- STDIO and Streamable HTTP transports
DevOps-status-specific:
- **No API keys required** — every status backend is a public API; TLS and DNS use Node.js stdlib (`node:tls`, `node:dns`)
- 51-vendor built-in registry covering cloud, CDN, dev-platform, data, comms, auth, monitoring, and AI categories; adapter layer normalizes Status.io, Slack, AWS Health, Google Cloud Service Health, and Firehydrant backends into the Statuspage shapes; extendable via raw Statuspage URL passthrough
- 60-second in-memory cache on status reads shared across all tenants — prevents thundering-herd on batch calls
- `devops_watch_stack` persists named vendor lists in tenant-scoped state for repeat morning checks or pre-deploy sweeps
- `devops_suggest_action` dispatches category-specific playbooks deterministically — no LLM sampling dependency, works in all clients
Agent-friendly output:
- Batch tools (`devops_status_check`, `devops_watch_stack`, `devops_check_certs`, `devops_check_dns`) use `Promise.allSettled` — one failing target never blocks the rest; errors surface as inline `error` fields
- `cached: true` / `checked_at` on every status result — agents know when data was fetched
- Discriminated indicator and status enums (`none` / `minor` / `major` / `critical` / `maintenance`; `operational` / `degraded_performance` / `partial_outage` / `major_outage` / `under_maintenance`) — callers branch on data, not string parsing
- `nextToolSuggestions` in `devops_suggest_action` pre-fills tool arguments from incident context — agents can execute the playbook mechanically
---
## Getting started
### Public Hosted Instance
A public instance is available at `https://devops-status.caseyjhand.com/mcp` — no installation required. Point any MCP client at it via Streamable HTTP:
```json
{
"mcpServers": {
"devops-status-mcp-server": {
"type": "streamable-http",
"url": "https://devops-status.caseyjhand.com/mcp"
}
}
}
```
### Self-Hosted / Local
No API key required. Add the following to your MCP client configuration file:
```json
{
"mcpServers": {
"devops-status-mcp-server": {
"type": "stdio",
"command": "bunx",
"args": ["@cyanheads/devops-status-mcp-server@latest"],
"env": {
"MCP_TRANSPORT_TYPE": "stdio",
"MCP_LOG_LEVEL": "info"
}
}
}
}
```
Or with npx (no Bun required):
```json
{
"mcpServers": {
"devops-status-mcp-server": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@cyanheads/devops-status-mcp-server@latest"],
"env": {
"MCP_TRANSPORT_TYPE": "stdio",
"MCP_LOG_LEVEL": "info"
}
}
}
}
```
Or with Docker:
```json
{
"mcpServers": {
"devops-status-mcp-server": {
"type": "stdio",
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "MCP_TRANSPORT_TYPE=stdio",
"ghcr.io/cyanheads/devops-status-mcp-server:latest"
]
}
}
}
```
For Streamable HTTP, set the transport and start the server:
```sh
MCP_TRANSPORT_TYPE=http MCP_HTTP_PORT=3010 bun run start:http
# Server listens at http://localhost:3010/mcp
```
### Prerequisites
- [Bun v1.3.0](https://bun.sh/) or higher (or Node.js v24+).
- No API keys or external accounts required.
### Installation
1. **Clone the repository:**
```sh
git clone https://github.com/cyanheads/devops-status-mcp-server.git
```
2. **Navigate into the directory:**
```sh
cd devops-status-mcp-server
```
3. **Install dependencies:**
```sh
bun install
```
4. **Configure environment:**
```sh
cp .env.example .env
# edit .env if you want to override defaults
```
---
## Configuration
No API keys required. All environment variables are optional.
| Variable | Description | Default |
|:---------|:------------|:--------|
| `DEVOPS_STATUS_CACHE_TTL_MS` | In-memory cache TTL for vendor status reads (all backends) in milliseconds. | `60000` |
| `DEVOPS_STATUS_FETCH_TIMEOUT_MS` | Per-request timeout for vendor status API calls (all backends) in milliseconds. | `8000` |
| `DEVOPS_STATUS_CERT_TIMEOUT_MS` | Default `timeout_ms` for `devops_check_certs` (per-domain TLS handshake, milliseconds). A caller-passed `timeout_ms` overrides it. | `5000` |
| `DEVOPS_STATUS_DNS_TIMEOUT_MS` | Default `timeout_ms` for `devops_check_dns` (per domain+resolver query, milliseconds). A caller-passed `timeout_ms` overrides it. | `3000` |
| `DEVOPS_STATUS_ALLOW_PRIVATE_TARGETS` | When `true`, disables SSRF guards for user-supplied URLs and domains. For trusted local/intranet deployments only. | `false` |
| `DEVOPS_STATUS_DISABLE_ACTIVE_PROBES` | When `true`, omits the arbitrary-target probe tools (`devops_check_dns`, `devops_check_certs`) from the registered tool surface; the five vendor-registry/incident tools remain. For shared/public multi-tenant instances. | `false` |
| `MCP_TRANSPORT_TYPE` | Transport: `stdio` or `http`. | `stdio` |
| `MCP_HTTP_PORT` | Port for HTTP server. | `3010` |
| `MCP_SESSION_MODE` | HTTP session handling: `stateless`, `stateful`, or `auto`. This server holds no per-session state, and the published container sets `stateless`. | `auto` (resolves to `stateful`) |
| `MCP_AUTH_MODE` | Auth mode: `none`, `jwt`, or `oauth`. | `none` |
| `MCP_LOG_LEVEL` | Log level (RFC 5424). | `info` |
| `LOGS_DIR` | Directory for log files (Node.js only). | `/logs` |
| `OTEL_ENABLED` | Enable [OpenTelemetry instrumentation](https://github.com/cyanheads/mcp-ts-core/tree/main/docs/telemetry). | `false` |
See [`.env.example`](https://github.com/cyanheads/devops-status-mcp-server/blob/HEAD/.env.example) for the full list of optional overrides.
---
## Running the server
### Local development
- **Build and run:**
```sh
bun run rebuild
bun run start:stdio
# or
bun run start:http
```
- **Run checks and tests:**
```sh
bun run devcheck # Lint, format, typecheck, security
bun run test # Vitest test suite
bun run lint:mcp # Validate MCP definitions against spec
```
### Docker
```sh
docker build -t devops-status-mcp-server .
docker run --rm -p 3010:3010 devops-status-mcp-server
```
The Dockerfile defaults to HTTP transport, stateless session mode, and logs to `/var/log/devops-status-mcp-server`. OpenTelemetry peer dependencies are installed by default — build with `--build-arg OTEL_ENABLED=false` to omit them.
---
## Project structure
| Path | Purpose |
|:-----|:--------|
| `src/index.ts` | `createApp()` entry point — registers tools, resources, and inits services. |
| `src/config/` | Server-specific environment variable parsing and validation with Zod. |
| `src/mcp-server/tools/` | Tool definitions (`*.tool.ts`). |
| `src/mcp-server/resources/` | Resource definitions (`*.resource.ts`). |
| `src/services/cert/` | `node:tls` — TLS handshake, X.509 parsing, expiry and protocol flagging. |
| `src/services/dns/` | `node:dns` — multi-resolver DNS fan-out, propagation discrepancy detection. |
| `src/services/statuspage/` | Statuspage public API client with 60-second in-memory cache. |
| `src/services/status-adapters/` | Native-API adapters (Status.io, Slack, AWS Health, Google Cloud Service Health, Firehydrant) + `api_type` dispatch, normalizing into the Statuspage shapes. |
| `src/services/vendor-registry/` | In-memory vendor registry loaded from `src/data/vendor-registry.ts`. |
| `src/data/` | Static vendor registry data file (`vendor-registry.ts`). |
| `tests/` | Vitest tests mirroring `src/`. |
---
## Development guide
See [`CLAUDE.md`](https://github.com/cyanheads/devops-status-mcp-server/blob/HEAD/CLAUDE.md) for development guidelines and architectural rules. The short version:
- Handlers throw, framework catches — no `try/catch` in tool logic
- Use `ctx.log` for request-scoped logging, `ctx.state` for tenant-scoped storage
- Register new tools and resources via the barrels in `src/mcp-server/*/definitions/index.ts`
- `devops_check_certs` and `devops_check_dns` use only Node.js stdlib — add no external deps for these paths
---
## Contributing
Issues and pull requests are welcome. Run checks and tests before submitting:
```sh
bun run devcheck
bun run test
```
---
## License
Apache-2.0 — see [LICENSE](https://github.com/cyanheads/devops-status-mcp-server/blob/HEAD/LICENSE) for details.