ZBS Index What actually exists in applied AI, with the source next to it

mcp server

devops-status-mcp-server

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

Description as published by the maintainer. Source

  • version 0.8.0
  • active

active — Most recent push to the repository was 2026-07-31.

What this server can do

7 functions, named and described by the server itself. Parameter names are shown because they say more about what a function does than its name usually does.

devops_check_certs(port, domains, timeout_ms)
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. Required: domains.
devops_check_dns(domains, resolvers, timeout_ms, record_types)
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. Required: domains.
devops_get_incidents(limit, filter, offset, vendor)
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 reachable only on the vendor status page, not at a higher offset. An empty result explains itself in notice. Required: vendor.
devops_list_vendors(query, category)
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(mode, vendors, component_limit, component_filter)
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, 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. Required: vendors.
devops_suggest_action(vendor, your_domain, incident_summary, vendor_indicator, affected_components)
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. Required: vendor.
devops_watch_stack(mode, vendors, stack_name, component_limit, component_filter)
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. Ideal for morning status checks or pre-deploy sweeps. Multiple stacks can coexist (e.g., "production", "staging").

Last successful function declaration observed on . Source: https://devops-status.caseyjhand.com/mcp. We list what the server declared; we do not call any of these functions.

Endpoint status observed on . Source: https://devops-status.caseyjhand.com/mcp.

Signals

These are separate measurements of different things. They are deliberately not combined into one score, because a popularity number that mixes website traffic with saves and stars cannot be checked or acted on.

Signal Value What it measures Window Observed Source
GitHub stars 1 Number of GitHub accounts that bookmarked this repository since it was created. It is a bookmark count, not installs, not active users and not quality. cumulative, all time GitHub
Last commit 2026-07-31 Date of the most recent push to any branch. This is the strongest cheap indicator of whether the project is still maintained. point in time GitHub
Open issues 2 Open issues plus open pull requests, as GitHub counts them together. A high number can mean an active project or an abandoned one. as of fetch GitHub
Latest published version 0.8.0 Latest version string the maintainer published to the registry. as of fetch Model Context Protocol
Registry record last updated 2026-07-31 When the registry record was last updated by its maintainer. point in time Model Context Protocol
License Apache-2.0 Licence GitHub detected in the repository. Detection can be wrong; the LICENSE file is authoritative. as of fetch GitHub
First listed in the MCP Registry 2026-07-31 Date this server was first published to the official MCP Registry. Not a usage or quality measure. point in time Model Context Protocol
repository status active The repository exists on GitHub and is not archived. This says nothing about how recently it was worked on. as of fetch GitHub
mcp tools declared 7 tools Number of functions the server itself declared when asked to list them. This is what the server offers an agent, not a measure of how well any of them work. as of probe devops-status.caseyjhand.com
mcp endpoint status ok The server listed 7 functions when asked. as of probe devops-status.caseyjhand.com

Where to get it

Related, by what their authors tagged them

  • com.hyperping/hyperping — last commit 2026-07-30, shares monitoring, sre
    Uptime, API and server monitoring with outages, reporting, on-call and status pages.
  • Servonaut — last commit 2026-08-05, shares devops, sre
    Manage AWS, Hetzner, OVH and SSH servers: status, logs, CloudWatch, IP bans, safe command exec.
  • io.github.Areso/safe-ssh-mcp — last commit 2026-06-04, shares sre
    A secured scoped SSH MCP server for executing safe read-only diagnostic DevOps / SysOps commands
  • LiteScope — last commit 2026-07-14, shares devops, monitoring
    Operations toolchain for SQLite, Cloudflare D1 & Turso: inspect, diff, migrate, monitor & repair.
  • World Monitor — last commit 2026-08-06, shares monitoring
    Live global intelligence: real-time markets, conflicts, country risk, chokepoints, energy. 39 tools.
  • com.clauxel.agentmonitorrelay/agentmonitorrelay-mcp — last commit 2026-05-19, shares monitoring
    AI agent run monitoring with incident replay and SLA receipts.
  • com.scoutapm/scout-mcp-local — last commit 2026-06-20, shares monitoring
    An MCP server for Scout Monitoring data interactions.
  • Monitoring AIops — last commit 2026-08-03, shares monitoring
    Governed SolarWinds Orion + PRTG + Zabbix ops: SWQL, alert rollup, health, 42 tools.
  • io.github.arnavranjan005/mcp-telemetry-server — last commit 2026-07-29, shares monitoring
    Streams live progress from mcp-telemetry-sdk-instrumented tools to any connected MCP client.
  • noisefloor — is this number real? — last commit 2026-08-02, shares monitoring
    Is this number real, or is it noise? Peek-safe A/B tests, change detection, honest forecasts.

These share tags the maintainers applied themselves, such as monitoring, sre, devops. Common tags like "mcp" or "ai" are ignored for this: agreeing with six hundred other projects is not a similarity.

This is not a recommendation and not a test result. It is a map of what the authors said their work is about.

Also from cyanheads

How the author describes it

Topics the maintainer set on GitHub: ai-agents, ai-tools, cyanheads, devops, mcp, mcp-server, model-context-protocol, monitoring, sre, status, statuspage, typescript.

This record as data

Every field on this page, with its source and observation date, is in the catalog JSON. Fetch the whole kind at once instead of parsing this HTML.

GET /api/v1/entries/mcp_server.json

Sources

  1. cyanheads/devops-status-mcp-server on GitHub — GitHub, observed , trust tier 3.
  2. Tools declared by the MCP server at https://devops-status.caseyjhand.com/mcp — devops-status.caseyjhand.com, observed , trust tier 4.
  3. Official MCP Registry — Model Context Protocol, observed , trust tier 1.