---

Tools

Seven tools in three capability groups — vendor status (Atlassian Statuspage, 48 built-in vendors + raw-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 Statuspage base 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 Statuspage base URL
• 48 built-in entries — well-known public vendors with verified Statuspage /api/v2/status.json endpoints

Built-in vendor registry:

Category	Vendors
cloud	digitalocean, linode
cdn-edge	cloudflare, akamai
dev-platform	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

The registry covers verified public vendors on Atlassian Statuspage. Major cloud providers (AWS, GCP, Azure) use custom status pages and are not in the registry — they can still be reached by passing their raw Statuspage-compatible URL if one exists.

---

devops_status_check

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

• Accepts registered vendor slugs (e.g., "github") or raw 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); Statuspage returns at most 50 per call

---

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
• 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)
• 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
• Falls back to generic guidance for unrecognized vendors

---

Resources and prompts

Type	Name	Description
Resource	devops-status://vendors/{name}	Full registry entry for a vendor by slug — Statuspage base 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:

• 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 — Atlassian Statuspage is a public API; TLS and DNS use Node.js stdlib (node:tls, node:dns)
• 48-vendor built-in registry covering cloud, CDN, dev-platform, data, comms, auth, monitoring, and AI categories; extendable via raw Statuspage URL passthrough
• 60-second in-memory cache on Statuspage 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 Statuspage result — agents know when data was fetched
• Discriminated indicator and status enums (none / minor / major / critical; 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:

{
  "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:

{
  "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):

{
  "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:

{
  "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:

MCP_TRANSPORT_TYPE=http MCP_HTTP_PORT=3010 bun run start:http
# Server listens at http://localhost:3010/mcp

Prerequisites

• Bun v1.3.0 or higher (or Node.js v24+).
• No API keys or external accounts required.

Installation

1. Clone the repository:

git clone https://github.com/cyanheads/devops-status-mcp-server.git

2. Navigate into the directory:

cd devops-status-mcp-server

3. Install dependencies:

bun install

4. Configure environment:

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 Statuspage reads in milliseconds.	60000
DEVOPS_STATUS_FETCH_TIMEOUT_MS	Per-request timeout for Statuspage API calls in milliseconds.	8000
DEVOPS_STATUS_CERT_TIMEOUT_MS	Per-domain TLS handshake timeout for devops_check_certs in milliseconds.	5000
DEVOPS_STATUS_DNS_TIMEOUT_MS	Per-query DNS timeout for devops_check_dns in milliseconds.	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_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).	<project-root>/logs
OTEL_ENABLED	Enable OpenTelemetry instrumentation.	false

See .env.example for the full list of optional overrides.

---

Running the server

Local development

• Build and run:

  bun run rebuild
  bun run start:stdio
  # or
  bun run start:http
  

• Run checks and tests:

  bun run devcheck   # Lint, format, typecheck, security
  bun run test       # Vitest test suite
  bun run lint:mcp   # Validate MCP definitions against spec
  

Docker

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/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 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:

bun run devcheck
bun run test

---

License

Apache-2.0 — see LICENSE for details.