All servers · Build & deploy · Monitoring & logs · Cloud & networking

io.github.cyanheads/devops-status-mcp-server

io.github.cyanheads/devops-status-mcp-server · v0.10.0

Measured by MCP Station

Description written by the publisher, not verified

Vendor status pages, TLS cert inspection, DNS propagation checks, and incident-response playbooks.

Connect

claude mcp add --transport http devops-status-mcp-server https://devops-status.caseyjhand.com/mcp

{
  "mcpServers": {
    "devops-status-mcp-server": {
      "url": "https://devops-status.caseyjhand.com/mcp"
    }
  }
}

Tools as reported by the server

• devops_list_vendors
  List vendors in the built-in registry, optionally filtered by category or name search. Returns slug, display name, category, and status page URL for each entry. Use to discover the correct slug to pass to other tools, or to see which vendors are available before configuring a stack.
• devops_status_check
  Check the current health status for one or more vendors. Accepts registered vendor slugs (e.g., "github", "aws", "gcp", "gitlab") or raw Atlassian Statuspage base URLs. Registry entries are served by each vendor's native status API (Statuspage, Status.io, Slack, AWS Health, Google Cloud Service Heal
• devops_get_incidents
  Fetch incident history and scheduled maintenance windows for a vendor. Returns full incident timeline — each investigator update, affected components, and resolution. Filter by status to focus on active incidents (use before deploy), resolved history (for postmortem), or upcoming maintenance windows
• devops_watch_stack
  Check the health of a named vendor stack — a saved list of vendors representing your infrastructure dependencies. On the first call, provide vendors to define the stack; subsequent calls can omit vendors to reuse the saved list. Stacks are saved per authenticated caller, or per local server process;
• devops_check_certs
  Inspect SSL/TLS certificate health for one or more domains by performing a real TLS handshake. Works for any internet-accessible domain — no vendor registry required. Reports days to expiry (flagged at < 30 days warning and < 7 days critical), certificate subject and SANs, issuer, hostname coverage,
• devops_check_dns
  Resolve DNS records for one or more domains across multiple public resolvers and compare what each resolver returned. Works for any domain — no vendor registry required. Reports records found (A/AAAA/CNAME/MX/TXT/NS/CAA/SOA), resolution latency per resolver, and a typed outcome per resolver and reco
• devops_suggest_action
  Return an incident-response playbook tailored to a vendor degradation, with pre-filled follow-up tool calls. Synthesizes category-specific guidance (cloud, CDN, dev-platform, auth, etc.) from built-in incident knowledge and the provided context. Use after devops_status_check or devops_get_incidents

Repository · JSON · Text for agents · Registry updated 2026-10-14