Devops Status MCP Server

@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

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

---

Overview

Status pages for 71 vendors — AWS, Google Cloud, Azure, Slack, and more — in one normalized format. Check who's down, pull incident timelines, watch your stack, and get an incident-response playbook. Plus TLS certificate and DNS checks for any domain. No API keys required.

Tools

Resources

All resource data is also reachable via tools. Tool-only agents are fully supported.

---

Capability reference

devops_list_vendors tool

• Optional free-text query (name and slug, case-insensitive) and optional category: 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; an empty result carries a notice naming what missed
• 71 built-in entries, most on Atlassian Statuspage; aws, gcp, azure, azure-devops, gitlab, neon, slack, redis-cloud, and the nine Datadog site entries (datadog for US1, datadog-us3, datadog-us5, datadog-eu1, datadog-uk1, datadog-ap1, datadog-ap2, datadog-us1-fed, datadog-us2-fed) use native-API adapters. Statuspage-compatible pages not in the registry work by passing a raw base URL to other tools
• These Atlassian products have their own entry (jira, confluence, bitbucket, jira-service-management, atlassian-compass, atlassian-developer, trello, opsgenie, atlassian-statuspage, atlassian-guard). atlassian reads the umbrella page, which publishes no components and only cross-product incidents; any tool serving it says so in notice and names those slugs

Built-in vendor registry:

---

devops_status_check tool

• Accepts vendor slugs (e.g., github, aws) or raw Atlassian Statuspage base URLs, mixed freely. Up to 20 are checked per call; the rest come back in deferred_vendors with a notice to resend them. More than 100 entries is rejected (invalid_arguments)
• mode: "summary" (default) returns the indicator, degraded components, and active incidents; mode: "detailed" adds the full component list (component_limit, default 50, clamped to 500) and scheduled maintenance windows. component_filter matches component or group names
• A list longer than component_limit pages: each capped vendor returns next_component_offset, which you pass back as component_offset (applied after component_filter). degraded_components and active_incidents are complete on every page
• One failing vendor never blocks the rest (per-vendor error field). Results are cached for 60 seconds (cached: true), and summary counts operational / degraded / down / maintenance / unavailable
• indicator is the vendor's own rating, and a Statuspage page can keep it at none while an incident it rated minor or worse is open. summary counts each vendor at the worse of the two; incidents rated none or maintenance and scheduled windows never count as an outage
• nextToolSuggestions pre-fills a devops_suggest_action call for each vendor with an active problem — the vendors counted degraded or down

---

devops_get_incidents tool

• filter: all (default), active, resolved, or scheduled (maintenance windows only). limit (default 20, max 50) with offset for paging
• Returns per-update bodies as plain text in chronological order, affected component names, duration in minutes for resolved incidents, and a shortlink. Google Cloud and AWS incidents also carry affected_locations (region ID, name, and whether it is still affected; on AWS, the one region the event names, or global). Each incident carries source: api, or history for an archive record (title, impact, times, and final message only)
• since and until (YYYY-MM-DD, UTC) bound the start date and work with filter: "all" or "resolved"; since also reads the Statuspage history archive back up to 24 months, past the API's newest-50 limit; a call that hits that limit without since is told to set it. match keeps incidents whose title, component names, or (on Google Cloud and AWS) location names and IDs contain every space-separated term given (up to 200 characters); a term joined by punctuation, such as eu-central-1, must find its words together and in order within one of them
• Responses are capped at 64,000 bytes per surface; a cut page sets truncated: true and nextOffset. full_updates: true keeps every update on a single oversized incident
• Errors: invalid_since and invalid_until (filter: "active" or "scheduled", or until before since)
• Feeds with no data for a filter return empty: resolved for Azure, scheduled for AWS, Azure, Azure DevOps, Google Cloud, and Slack. History is short where a vendor reads no archive: AWS keeps resolved events for a few hours, and Status.io (gitlab, neon) lists current incidents only. On those feeds a since earlier than the oldest record returned, or an until without since, gets a notice naming the date the feed starts

---

devops_watch_stack tool

• Pass vendors (up to 20) once to save the stack under stack_name (1-64 characters; several stacks can coexist, e.g. "production"); later calls can omit vendors. Over 20 is rejected with stack_too_large. Saving works on stdio and on HTTP with MCP_AUTH_MODE=jwt|oauth; with the default in-memory storage, saved stacks do not survive a restart
• On HTTP with MCP_AUTH_MODE=none nothing is saved: a call with vendors runs the sweep and returns stack_persisted: false, and a call without vendors fails with vendors_required
• Aggregate health: all_operational / maintenance / degraded / partial_outage / major_outage / unknown (a vendor could not be reached), rolled up from the same per-vendor rating as summary. component_limit and nextToolSuggestions work as in devops_status_check; there is no component_offset, so a capped vendor's next_component_offset continues in devops_status_check

---

devops_check_certs tool

• Accepts hostnames, IP addresses, host:port, or URLs; a port on the entry overrides port (default 443). The first 10 entries are inspected (up to 100 accepted); the rest come back in deferred_domains to resend
• Reports days to expiry (warning under 30 days, critical under 7), subject and SANs, issuer, chain depth, TLS version (1.0 and 1.1 flagged insecure), cipher suite, and HSTS on HTTP ports
• status: "critical" separates a hostname mismatch (hostname_verification_error) from an untrusted chain (authorization_error). Per-domain failures come back inline as status: "error" with the reason in error
• timeout_ms is one deadline per domain (max 15000)

---

`dev