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

Official7 toolsLive

by cyanheads · TypeScript

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

This MCP server provides access to vendor status pages, SSL/TLS certificate inspection, DNS propagation checks, and incident-response playbooks. It exposes functionality via MCP over STDIO or Streamable HTTP and includes a tool set count of 7 tools.

🛠️ Key Features

Vendor status pages access
SSL/TLS certificate inspection
DNS propagation verification
Incident-response playbooks delivery
MCP transport via STDIO or Streamable HTTP
7 tools available

🚀 Use Cases

Check third-party vendor service status
Validate TLS certificates for target endpoints
Confirm DNS changes have propagated
Retrieve incident-response playbooks during incidents

⚡ Developer Benefits

Uses Model Context Protocol (MCP) tooling for SRE/DevOps workflows
Built around devops, monitoring, and statuspage use in TypeScript ecosystems
Topic-aligned tooling for status checks and operational readiness

⚠️ Limitations

Only the capabilities listed (status pages, TLS inspection, DNS checks, incident playbooks) are described; no other tools are specified.

📌 Tags

ai-agents, ai-tools, cyanheads, devops, mcp, mcp-server, model-context-protocol, monitoring, sre, status, statuspage, typescript

Topics

ai-agentsai-toolscyanheadsdevopsmcpmcp-servermodel-context-protocolmonitoringsrestatusstatuspagetypescript

Captured live from the server via tools/list.

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.

Parameters2

query	string	optional	Free-text search against vendor name and slug. Case-insensitive. E.g., "cloud", "auth", "slack".
category	string	optional	Filter to one category: cloud, cdn-edge, dev-platform, data, comms, auth, monitoring, or ai.

Raw schema

{
  "type": "object",
  "properties": {
    "query": {
      "description": "Free-text search against vendor name and slug. Case-insensitive. E.g., \"cloud\", \"auth\", \"slack\".",
      "type": "string"
    },
    "category": {
      "description": "Filter to one category: cloud, cdn-edge, dev-platform, data, comms, auth, monitoring, or ai.",
      "type": "string",
      "enum": [
        "cloud",
        "cdn-edge",
        "dev-platform",
        "data",
        "comms",
        "auth",
        "monitoring",
        "ai"
      ]
    }
  },
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "additionalProperties": false
}

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 Health, Azure status, Firehydrant) and normalized to one shape. Returns per-vendor operational indicator (none = all clear, minor, major, critical, maintenance = scheduled window), degraded components, and active incidents. Use mode: "detailed" for component lists and maintenance windows, narrowed with component_filter and bounded by component_limit. Batch-friendly — pass a list to check your full stack in one call; a vendor that cannot be resolved or reached is reported in its own result row, so one bad entry never discards the rest. Every vendor with an active problem gets a pre-filled devops_suggest_action call in nextToolSuggestions.

Parameters4

vendors	array	required	Vendor slugs from the built-in registry (e.g., "github", "aws") or raw Atlassian Statuspage base URLs (non-Statuspage backends are supported via registry slugs only). Mix freely. Use devops_list_vendors to discover available slugs.
mode	string	optional	summary: indicator + degraded components + active incidents only. detailed: adds the component list and scheduled maintenance windows.
component_filter	string	optional	Case-insensitive substring matched against component names in detailed mode (e.g., "api" to check just the API components). Applied before component_limit, so it is the way to reach a component that the cap would otherwise omit. Ignored in summary mode.
component_limit	integer	optional	Maximum components returned per vendor in detailed mode (1-500). Large status pages publish hundreds of components, so a multi-vendor batch at a high limit returns a very large response; narrow with component_filter instead where possible.

Raw schema

{
  "type": "object",
  "properties": {
    "vendors": {
      "minItems": 1,
      "maxItems": 20,
      "type": "array",
      "items": {
        "type": "string",
        "minLength": 1,
        "description": "A vendor slug (e.g., \"github\") or raw Atlassian Statuspage base URL."
      },
      "description": "Vendor slugs from the built-in registry (e.g., \"github\", \"aws\") or raw Atlassian Statuspage base URLs (non-Statuspage backends are supported via registry slugs only). Mix freely. Use devops_list_vendors to discover available slugs."
    },
    "mode": {
      "default": "summary",
      "description": "summary: indicator + degraded components + active incidents only. detailed: adds the component list and scheduled maintenance windows.",
      "type": "string",
      "enum": [
        "summary",
        "detailed"
      ]
    },
    "component_filter": {
      "description": "Case-insensitive substring matched against component names in detailed mode (e.g., \"api\" to check just the API components). Applied before component_limit, so it is the way to reach a component that the cap would otherwise omit. Ignored in summary mode.",
      "type": "string"
    },
    "component_limit": {
      "default": 50,
      "description": "Maximum components returned per vendor in detailed mode (1-500). Large status pages publish hundreds of components, so a multi-vendor batch at a high limit returns a very large response; narrow with component_filter instead where possible.",
      "type": "integer",
      "minimum": 1,
      "maximum": 500
    }
  },
  "required": [
    "vendors"
  ],
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "additionalProperties": false
}

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. Page through long histories with limit + offset — a truncated result discloses the total and returns the value to page with in nextOffset. Some vendor feeds cap their own history: when upstreamCeiling is present the vendor API returned everything it will serve, and older incidents are not reachable at a higher offset. On Atlassian Statuspage vendors, since (a date up to 24 months back) also reads the status page's quarterly history archive back to that date where the page publishes one; those records are marked source: "history" and carry the title, impact, start and end times, and final update message only. An empty result, or a history read that stopped short of since, explains itself in notice.

Parameters5

vendor	string	required	Vendor slug (e.g., "github", "aws") or raw Atlassian Statuspage base URL. Use devops_list_vendors to find slugs.
filter	string	optional	all: incidents plus scheduled maintenances. active: only incidents with status investigating/identified/monitoring. resolved: only fully resolved incidents. scheduled: only scheduled maintenance windows. Not every vendor backend serves every filter — "aws" lists a resolved event only until it drops off its feed, "azure" lists open items only (never resolved), and "aws", "azure", "gcp", and "slack" publish no maintenance windows. An empty result names which case applied.
limit	integer	optional	Maximum incidents to return per call (1–50). Page through longer history with offset rather than raising this.
offset	integer	optional	Number of matching incidents to skip before applying limit, for paging through history. 0 (default) returns the most recent page; a truncated result returns the value to use next in the nextOffset field. Raising offset past the number of matches returns an empty list and says so.
since	any	optional	Earliest start date to include, as YYYY-MM-DD (UTC), at most 24 months back. Accepted with filter "all" or "resolved". Incidents that started before it are left out, and limit/offset page the rest. On Atlassian Statuspage vendors it also reads the status page's quarterly history archive back to this date, reaching incidents older than the 50 the status API serves. Omit to read only the status API.

Raw schema

{
  "type": "object",
  "properties": {
    "vendor": {
      "type": "string",
      "minLength": 1,
      "description": "Vendor slug (e.g., \"github\", \"aws\") or raw Atlassian Statuspage base URL. Use devops_list_vendors to find slugs."
    },
    "filter": {
      "default": "all",
      "description": "all: incidents plus scheduled maintenances. active: only incidents with status investigating/identified/monitoring. resolved: only fully resolved incidents. scheduled: only scheduled maintenance windows. Not every vendor backend serves every filter — \"aws\" lists a resolved event only until it drops off its feed, \"azure\" lists open items only (never resolved), and \"aws\", \"azure\", \"gcp\", and \"slack\" publish no maintenance windows. An empty result names which case applied.",
      "type": "string",
      "enum": [
        "all",
        "active",
        "resolved",
        "scheduled"
      ]
    },
    "limit": {
      "default": 20,
      "description": "Maximum incidents to return per call (1–50). Page through longer history with offset rather than raising this.",
      "type": "integer",
      "minimum": 1,
      "maximum": 50
    },
    "offset": {
      "default": 0,
      "description": "Number of matching incidents to skip before applying limit, for paging through history. 0 (default) returns the most recent page; a truncated result returns the value to use next in the nextOffset field. Raising offset past the number of matches returns an empty list and says so.",
      "type": "integer",
      "minimum": 0,
      "maximum": 9007199254740991
    },
    "since": {
      "description": "Earliest start date to include, as YYYY-MM-DD (UTC), at most 24 months back. Accepted with filter \"all\" or \"resolved\". Incidents that started before it are left out, and limit/offset page the rest. On Atlassian Statuspage vendors it also reads the status page's quarterly history archive back to this date, reaching incidents older than the 50 the status API serves. Omit to read only the status API.",
      "anyOf": [
        {
          "type": "string",
          "const": ""
        },
        {
          "type": "string",
          "format": "date",
          "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
          "description": "Earliest start date to include, as YYYY-MM-DD (UTC), e.g. \"2025-10-01\"."
        }
      ]
    }
  },
  "required": [
    "vendor"
  ],
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "additionalProperties": false
}

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 persisted list. Returns a unified health snapshot with an aggregate rollup plus per-vendor detail. A vendor that cannot be resolved or reached is reported in its own row and left out of the saved stack, so one bad entry never discards the sweep. Every vendor with an active problem gets a pre-filled devops_suggest_action call in nextToolSuggestions. Ideal for morning status checks or pre-deploy sweeps. Multiple stacks can coexist (e.g., "production", "staging").

Parameters5

vendors	array	optional	Vendor slugs (e.g., "github", "aws") or raw Atlassian Statuspage base URLs. When provided, saves this list as the stack. When omitted, uses the previously saved list for stack_name.
stack_name	string	optional	Name for this vendor stack. Defaults to "default". Use distinct names to manage multiple stacks (e.g., "production", "data-layer"). Letters, digits, hyphens, and underscores, optionally separated by single dots or slashes ("prod.eu", "team/prod"); 1-64 characters. No spaces or colons.
mode	string	optional	summary: indicator + degraded components + active incidents. detailed: adds component lists and maintenance windows.
component_filter	string	optional	Case-insensitive substring matched against component names in detailed mode (e.g., "api" to check just the API components). Applied before component_limit, so it is the way to reach a component that the cap would otherwise omit. Ignored in summary mode.
component_limit	integer	optional	Maximum components returned per vendor in detailed mode (1-500). Large status pages publish hundreds of components, so a full stack at a high limit returns a very large response; narrow with component_filter instead where possible.

Raw schema

{
  "type": "object",
  "properties": {
    "vendors": {
      "description": "Vendor slugs (e.g., \"github\", \"aws\") or raw Atlassian Statuspage base URLs. When provided, saves this list as the stack. When omitted, uses the previously saved list for stack_name.",
      "type": "array",
      "items": {
        "type": "string",
        "description": "A vendor slug (e.g., \"github\") or raw Atlassian Statuspage base URL."
      }
    },
    "stack_name": {
      "default": "default",
      "description": "Name for this vendor stack. Defaults to \"default\". Use distinct names to manage multiple stacks (e.g., \"production\", \"data-layer\"). Letters, digits, hyphens, and underscores, optionally separated by single dots or slashes (\"prod.eu\", \"team/prod\"); 1-64 characters. No spaces or colons.",
      "type": "string",
      "minLength": 1,
      "maxLength": 64,
      "pattern": "^[a-zA-Z0-9_-]+([./][a-zA-Z0-9_-]+)*$"
    },
    "mode": {
      "default": "summary",
      "description": "summary: indicator + degraded components + active incidents. detailed: adds component lists and maintenance windows.",
      "type": "string",
      "enum": [
        "summary",
        "detailed"
      ]
    },
    "component_filter": {
      "description": "Case-insensitive substring matched against component names in detailed mode (e.g., \"api\" to check just the API components). Applied before component_limit, so it is the way to reach a component that the cap would otherwise omit. Ignored in summary mode.",
      "type": "string"
    },
    "component_limit": {
      "default": 50,
      "description": "Maximum components returned per vendor in detailed mode (1-500). Large status pages publish hundreds of components, so a full stack at a high limit returns a very large response; narrow with component_filter instead where possible.",
      "type": "integer",
      "minimum": 1,
      "maximum": 500
    }
  },
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "additionalProperties": false
}

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, chain-trust verification, TLS protocol version negotiated (flags TLS 1.0/1.1 as insecure), cipher suite, and HSTS presence. The handshake completes even for a certificate clients would reject, so a broken certificate is reported rather than hidden behind a connection error: a hostname mismatch surfaces in cert.hostname_verification_error and a chain-trust failure (self-signed, untrusted root) in cert.authorization_error, both status "critical". If a domain fails to connect at all, check devops_check_dns first — the name may not resolve.

Parameters3

domains	array	required	Domains to inspect. Do not include "https://" — pass the bare hostname. Up to 10 per call.
port	integer	optional	TLS port. Defaults to 443. Use 8443 or custom ports for non-standard HTTPS endpoints.
timeout_ms	integer	optional	Connection timeout per domain in milliseconds. Defaults to the DEVOPS_STATUS_CERT_TIMEOUT_MS env var (5000 when unset). Increase for slow or geographically distant endpoints.

Raw schema

{
  "type": "object",
  "properties": {
    "domains": {
      "minItems": 1,
      "maxItems": 10,
      "type": "array",
      "items": {
        "type": "string",
        "minLength": 1,
        "description": "Domain name without protocol (e.g., \"api.github.com\", \"example.com\")."
      },
      "description": "Domains to inspect. Do not include \"https://\" — pass the bare hostname. Up to 10 per call."
    },
    "port": {
      "default": 443,
      "description": "TLS port. Defaults to 443. Use 8443 or custom ports for non-standard HTTPS endpoints.",
      "type": "integer",
      "minimum": 1,
      "maximum": 65535
    },
    "timeout_ms": {
      "default": 5000,
      "description": "Connection timeout per domain in milliseconds. Defaults to the DEVOPS_STATUS_CERT_TIMEOUT_MS env var (5000 when unset). Increase for slow or geographically distant endpoints.",
      "type": "integer",
      "minimum": 1000,
      "maximum": 15000
    }
  },
  "required": [
    "domains"
  ],
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "additionalProperties": false
}

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), resolution latency per resolver, and a typed outcome per resolver and record type so "the domain does not exist" (nxdomain), "the resolver could not answer" (servfail), and "no record of this type" (nodata) stay distinguishable. Resolver disagreements are reported without asserting a cause: partial_resolution (some resolvers answered, others returned nothing) points at a real propagation or resolver problem, while value_variation (every resolver answered with different values) is the normal steady state for anycast and geo-steered domains. Pair with devops_check_certs when a domain resolves but TLS to it is failing.

Parameters4

domains	array	required	Domain names to query. Up to 10 per call.
record_types	array	optional	DNS record types to resolve. Defaults to A, AAAA, MX, and TXT. An empty array uses the same defaults. Add NS to check nameserver delegation. Add CNAME when investigating redirect chains.
resolvers	array	optional	Resolver IP addresses to query. Defaults to Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). An empty array uses the same defaults. Add custom resolvers to test resolver-specific behavior. Each must be an IP literal, not a hostname; resolvers in private, loopback, or cloud-metadata ranges are rejected unless DEVOPS_STATUS_ALLOW_PRIVATE_TARGETS=true.
timeout_ms	integer	optional	Query timeout per domain+resolver combination in milliseconds. Defaults to the DEVOPS_STATUS_DNS_TIMEOUT_MS env var (3000 when unset).

Raw schema

{
  "type": "object",
  "properties": {
    "domains": {
      "minItems": 1,
      "maxItems": 10,
      "type": "array",
      "items": {
        "type": "string",
        "minLength": 1,
        "description": "A domain name to query (e.g., \"github.com\", \"api.example.com\")."
      },
      "description": "Domain names to query. Up to 10 per call."
    },
    "record_types": {
      "default": [
        "A",
        "AAAA",
        "MX",
        "TXT"
      ],
      "description": "DNS record types to resolve. Defaults to A, AAAA, MX, and TXT. An empty array uses the same defaults. Add NS to check nameserver delegation. Add CNAME when investigating redirect chains.",
      "type": "array",
      "items": {
        "type": "string",
        "enum": [
          "A",
          "AAAA",
          "CNAME",
          "MX",
          "TXT",
          "NS"
        ]
      }
    },
    "resolvers": {
      "default": [
        "8.8.8.8",
        "1.1.1.1",
        "9.9.9.9"
      ],
      "description": "Resolver IP addresses to query. Defaults to Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). An empty array uses the same defaults. Add custom resolvers to test resolver-specific behavior. Each must be an IP literal, not a hostname; resolvers in private, loopback, or cloud-metadata ranges are rejected unless DEVOPS_STATUS_ALLOW_PRIVATE_TARGETS=true.",
      "type": "array",
      "items": {
        "type": "string",
        "minLength": 1,
        "description": "A resolver IP literal — IPv4 (\"8.8.8.8\"), IPv6 (\"2001:4860:4860::8888\"), or either with a port (\"1.1.1.1:53\", \"[2001:4860:4860::8888]:53\"). A hostname is rejected."
      }
    },
    "timeout_ms": {
      "default": 3000,
      "description": "Query timeout per domain+resolver combination in milliseconds. Defaults to the DEVOPS_STATUS_DNS_TIMEOUT_MS env var (3000 when unset).",
      "type": "integer",
      "minimum": 1000,
      "maximum": 10000
    }
  },
  "required": [
    "domains"
  ],
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "additionalProperties": false
}

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 surfaces a problem to determine what to investigate next.

Parameters5

vendor	string	required	Vendor slug or display name (e.g., "cloudflare", "github"). Used to tailor category-specific guidance (CDN outage vs. CI/CD outage vs. auth provider outage).
incident_summary	string	optional	Latest incident description or update body from devops_get_incidents. Paste the most recent update to get more targeted advice.
affected_components	array	optional	Component names affected (from devops_status_check degraded_components or devops_get_incidents affected_components). Used to tailor suggestions to the impacted subsystem.
your_domain	string	optional	Your own domain or service URL. When provided, nextToolSuggestions will be pre-filled with your domain for cert and DNS checks.
vendor_indicator	string	optional	Overall vendor status indicator from a prior devops_status_check call (its indicator field). When provided, the playbook leads with severity-tailored urgency guidance. Omit if status has not been checked yet.

Raw schema

{
  "type": "object",
  "properties": {
    "vendor": {
      "type": "string",
      "minLength": 1,
      "description": "Vendor slug or display name (e.g., \"cloudflare\", \"github\"). Used to tailor category-specific guidance (CDN outage vs. CI/CD outage vs. auth provider outage)."
    },
    "incident_summary": {
      "description": "Latest incident description or update body from devops_get_incidents. Paste the most recent update to get more targeted advice.",
      "type": "string"
    },
    "affected_components": {
      "description": "Component names affected (from devops_status_check degraded_components or devops_get_incidents affected_components). Used to tailor suggestions to the impacted subsystem.",
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "your_domain": {
      "description": "Your own domain or service URL. When provided, nextToolSuggestions will be pre-filled with your domain for cert and DNS checks.",
      "type": "string"
    },
    "vendor_indicator": {
      "description": "Overall vendor status indicator from a prior devops_status_check call (its indicator field). When provided, the playbook leads with severity-tailored urgency guidance. Omit if status has not been checked yet.",
      "type": "string",
      "enum": [
        "none",
        "minor",
        "major",
        "critical",
        "maintenance"
      ]
    }
  },
  "required": [
    "vendor"
  ],
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "additionalProperties": false
}

README.md21 KBView on GitHub

@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

MCP SDK TypeScript

Public Hosted Server: https://devops-status.caseyjhand.com/mcp

Overview

Vendor status pages, SSL/TLS certificates, and DNS propagation — normalized across Atlassian Statuspage, Status.io, Slack, AWS Health, Google Cloud Service Health, Azure status, and Firehydrant backends, plus direct TLS/DNS checks for any domain. List and check 52 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` _tool

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
52 built-in entries, most on Atlassian Statuspage; aws, gcp, azure, gitlab, neon, slack, and redis-cloud route through native-API adapters normalized to the same shape
azure reads Microsoft's Azure status RSS feed, which carries no severity or lifecycle: each posted item is an open minor incident with its services and regions as affected components, and the feed is empty while nothing is posted
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, azure
`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` _tool

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
nextToolSuggestions carries one pre-filled devops_suggest_action call per vendor with an active problem — indicator minor/major/critical, or an open incident of that impact — with the vendor slug (or normalized URL), indicator, affected components, and latest incident title filled in; a vendor that could not be checked never gets one, so the list is empty when no checked vendor has a problem

`devops_get_incidents` _tool

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). Atlassian Statuspage's API stops at the newest 50 incidents, which on a busy page is about a week
since (YYYY-MM-DD, up to 24 months back, with filter: "all" or "resolved") leaves out incidents that started before that date. On Statuspage vendors it also reads the status page's quarterly history archive back to that date, reaching past the 50-record ceiling
Every incident carries source: api for the status API, or history for an archive record, which has the title, impact, start and end times, and final update message but no components or update timeline. When a record is in both, the API version is kept
If the archive can't be read (the page doesn't publish one, it times out, or it comes back in an unexpected shape), the call still returns the status API result, with a notice saying how far history reached
AWS keeps a resolved event listed for hours after it ends, so filter: "resolved" returns only those still listed; Azure's feed lists open items only, so filter: "resolved" is always empty for it; AWS, Azure, Google Cloud, and Slack publish no maintenance windows, so filter: "scheduled" is always empty for them

`devops_watch_stack` _tool

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
nextToolSuggestions pre-fills a devops_suggest_action call for each vendor with an active problem, same as devops_status_check
Note: stack state is in-memory; it does not persist across server restarts

`devops_check_certs` _tool

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", reason in error) rather than throwing — useful partial results when checking multiple domains. flags is empty unless a handshake completed; a server that completes one without presenting a certificate still reports its TLS session
Configurable port (default 443) and timeout per domain

`devops_check_dns` _tool

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 public resolver IP literals to test resolver-specific behavior (private and loopback resolvers need DEVOPS_STATUS_ALLOW_PRIVATE_TARGETS=true); an empty resolvers or record_types array uses the defaults
Up to 10 domains per call; per-domain timeouts configurable

`devops_suggest_action` _tool

Category-tailored markdown playbook (cloud, CDN, dev-platform, data, comms, auth, monitoring, AI); falls back to generic guidance for unrecognized vendors
Accepts a vendor slug or display name, resolved to the canonical slug so pre-filled follow-up arguments stay valid
Optional incident_summary / affected_components prepend a targeted subsystem section (e.g. GitHub Actions → CI/CD steps, Cloudflare DNS → DNS/TTL guidance); optional vendor_indicator leads with severity-tailored urgency framing
nextToolSuggestions pre-fills follow-up tool calls, including cert/DNS checks when your_domain is given — execute in sequence
When DEVOPS_STATUS_DISABLE_ACTIVE_PROBES=true, guidance swaps the unregistered probe tools for equivalent manual commands (dig, openssl s_client)

`devops-status://vendors/{name}` _resource

Returns the full registry entry for a vendor slug — status page URL, category, and API type (statuspage, statusio, slack, aws, gcp, azure, firehydrant)
Cached publicly for 1 hour — the registry is compiled in and identical for every caller
Same data is reachable via devops_list_vendors — tool-only agents are fully supported

Features

Built on @cyanheads/mcp-ts-core: stdio and Streamable HTTP transports, pluggable auth (none / jwt / oauth), swappable storage (in-memory, filesystem, Supabase, Cloudflare KV/R2/D1), structured logging with optional OpenTelemetry tracing.

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)
52-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, Azure status, 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:

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

Prerequisites

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

Installation

Clone the repository:

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

Navigate into the directory:

cd devops-status-mcp-server

Install dependencies:

bun install

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 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`. The server declares `stateless` in source — it holds no per-session state — so setting this is only needed to override that.	`stateless`
`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/status-adapters/`	Native-API adapters (Status.io, Slack, AWS Health, Google Cloud Service Health, Azure status, 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 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 are welcome. Run checks and tests before submitting:

bun run devcheck
bun run test

License

Apache-2.0 — see LICENSE for details.

Install

Tools (7)

devops_list_vendorsdevops_status_checkdevops_get_incidentsdevops_watch_stackdevops_check_certsdevops_check_dnsdevops_suggest_action

Configuration

Environment variables

MCP_LOG_LEVELdefault info

Sets the minimum log level for output (e.g., 'debug', 'info', 'warn').

DEVOPS_STATUS_ALLOW_PRIVATE_TARGETSdefault false

When 'true', disables SSRF guards for user-supplied URLs and domains. For trusted local/intranet deployments only. Leave unset or 'false' for hosted/public deployments.

DEVOPS_STATUS_DISABLE_ACTIVE_PROBESdefault false

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. Leave unset or 'false' to register both tools.

MCP_HTTP_HOSTdefault 127.0.0.1

The hostname for the HTTP server.

MCP_HTTP_PORTdefault 3010

The port to run the HTTP server on.

MCP_HTTP_ENDPOINT_PATHdefault /mcp

The endpoint path for the MCP server.

MCP_AUTH_MODEdefault none

Authentication mode to use: 'none', 'jwt', or 'oauth'.

Add to VS Code Add to Cursor

claude_desktop_config.json

json

{
  "mcpServers": {
    "devops-status-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "@cyanheads/devops-status-mcp-server@0.9.0",
        "run",
        "start:stdio"
      ],
      "env": {
        "MCP_LOG_LEVEL": "info",
        "DEVOPS_STATUS_ALLOW_PRIVATE_TARGETS": "false",
        "DEVOPS_STATUS_DISABLE_ACTIVE_PROBES": "false"
      }
    }
  }
}

🛠️ Key Features

🚀 Use Cases

⚡ Developer Benefits

⚠️ Limitations

📌 Tags

Topics

devops_list_vendors

devops_status_check

devops_get_incidents

devops_watch_stack

devops_check_certs

devops_check_dns

devops_suggest_action

@cyanheads/devops-status-mcp-server

Overview

Tools

Resources

Capability reference

devops_list_vendors tool

devops_status_check tool

devops_get_incidents tool

devops_watch_stack tool

devops_check_certs tool

devops_check_dns tool

devops_suggest_action tool

devops-status://vendors/{name} resource

Features

Getting started

Public Hosted Instance

Self-Hosted / Local

Prerequisites

Installation

Configuration

Running the server

Local development

Docker

Project structure

Development guide

Contributing

License

Install

Configuration

Related servers

`devops_list_vendors` _tool

`devops_status_check` _tool

`devops_get_incidents` _tool

`devops_watch_stack` _tool

`devops_check_certs` _tool

`devops_check_dns` _tool

`devops_suggest_action` _tool

`devops-status://vendors/{name}` _resource