@cyanheads/devops-status-mcp-server

中文文档
0.11.1发布于 2026/11/01Apache-2.0TypeScriptES Module

Check vendor status pages, inspect SSL/TLS certificates, verify DNS propagation, and get incident-response playbooks via MCP. STDIO or Streamable HTTP.

原始使用文档
文档目录22 节
  1. Overview
  2. Tools
  3. Resources
  4. Capability reference
  5. devops_list_vendors tool
  6. devops_status_check tool
  7. devops_get_incidents tool
  8. devops_watch_stack tool
  9. devops_check_certs tool
  10. devops_check_dns tool
  11. devops_suggest_action tool
  12. devops-status://vendors/{name} resource
  13. Features
  14. Getting started
  15. Configuration
  16. Running the server
  17. Local development
  18. Docker
  19. Project structure
  20. Development guide
  21. Contributing
  22. License

@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

Version License Docker MCP SDK npm TypeScript Bun

Install in Claude Desktop Install in Cursor Install in VS Code

Framework


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

ToolDescription
devops_list_vendorsList vendors in the built-in registry, optionally filtered by name or category. Returns slug, display name, category, and status page URL.
devops_status_checkCheck 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_incidentsFetch incident history for a vendor — active, resolved, or scheduled maintenance. Returns the full incident timeline with per-update bodies and affected components.
devops_watch_stackCheck the health of a named vendor stack. Where the server identifies the caller (stdio, or HTTP with jwt/oauth auth), pass vendors once to save the list and later calls reuse it; on HTTP with MCP_AUTH_MODE=none nothing is saved and vendors is required on every call. Returns an aggregate health rollup plus per-vendor detail.
devops_check_certsInspect 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 on HTTP ports. Pure TypeScript — no external API.
devops_check_dnsResolve 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_actionInstruction 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

ResourceDescription
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

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

CategoryVendors
clouddigitalocean, linode, aws, gcp, azure
cdn-edgecloudflare, akamai
dev-platformgitlab, github, azure-devops, npm, vercel, netlify, render, fly-io, circleci, travis-ci, snyk, atlassian, jira, confluence, bitbucket, jira-service-management, atlassian-compass, atlassian-developer, trello, figma, launchdarkly
datamongodb-atlas, planetscale, supabase, neon, redis-cloud, elastic, influxdb, upstash, cloudinary, segment
commsslack, discord, twilio, sendgrid, mailgun, hubspot, brevo, courier, loops
authauth0, clerk, workos, atlassian-guard
monitoringdatadog, datadog-us3, datadog-us5, datadog-eu1, datadog-uk1, datadog-ap1, datadog-ap2, datadog-us1-fed, datadog-us2-fed, sentry, new-relic, grafana-cloud, honeycomb, opsgenie, atlassian-statuspage
aiopenai, anthropic, elevenlabs, pinecone, cohere

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)

devops_check_dns tool

  • Accepts domain names, URLs, or host:port; the first 10 domains are queried (up to 100 accepted) and the rest come back in deferred_domains. IP addresses get their own error row
  • Queries Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9) in parallel for A, AAAA, CNAME, MX, TXT, NS, CAA, and SOA (default A, AAAA, MX, TXT)
  • Reports per-resolver latency and typed discrepancies: partial_resolution (some resolvers did not answer) is a real problem; value_variation (different values) is normal for anycast or geo-steered domains
  • Custom resolvers take public IP literals, first 5 queried and the rest in deferred_resolvers; private and loopback addresses need DEVOPS_STATUS_ALLOW_PRIVATE_TARGETS=true. timeout_ms applies per domain and resolver (max 10000)

devops_suggest_action tool

  • Takes a vendor slug or display name and returns a category-tailored markdown playbook, with generic guidance for unrecognized vendors
  • Optional incident_summary, affected_components, and vendor_indicator add a subsystem section and severity-based urgency
  • nextToolSuggestions pre-fills follow-up calls, including cert and DNS checks when your_domain is given. With DEVOPS_STATUS_DISABLE_ACTIVE_PROBES=true, guidance uses manual commands (dig, openssl s_client) instead

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

  • Returns the full registry entry for a vendor slug: status page URL, category, API type (statuspage, statusio, slack, aws, gcp, azure, azure-devops, firehydrant, datadog), component_scope_prefix where a vendor covers part of a shared page (sendgrid), and product_slugs on an umbrella page that publishes no components (atlassian)
  • Cached publicly for 1 hour; the same data is reachable via devops_list_vendors

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 the Node.js standard library
  • 71-vendor built-in registry across eight categories; native adapters normalize Status.io, Slack, AWS Health, Google Cloud, Azure, Azure DevOps, Firehydrant, and Datadog into the Statuspage shape
  • Vendor-authored text is escaped so it reads as data, not markup; DNS record values and certificate names render as code spans that read back exactly as resolved
  • 60-second in-memory cache on status reads, shared across tenants
  • devops_watch_stack saves named vendor lists for repeat checks and pre-deploy sweeps
  • devops_suggest_action is deterministic, with no LLM sampling dependency

Agent skill:

  • devops-status-guide carries the gates for using these tools together: what a status reading can and cannot establish, how far incident history reaches on each backend, where regions live, and how to diagnose a DNS change or a certificate failure. MCP clients read it from the server as skill://devops-status-guide/SKILL.md; it also ships in the npm package, the Docker image, and the .mcpb bundle, and plugin installs scan it from skills/.

Agent-friendly output:

  • Batch tools never let one failing target block the rest; errors come back as inline error fields
  • checked_at on every status result is the time of the check; cached: true marks a status read served from the cache, which can be up to the cache TTL (60 seconds by default) older
  • Fixed indicator and status enums (none / minor / major / critical / maintenance) let callers branch on data
  • nextToolSuggestions pre-fills follow-up tool arguments from incident context

Getting started

Connect to the hosted instance, no install:

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

Or run it locally:

claude mcp add devops-status-mcp-server -- npx -y @cyanheads/devops-status-mcp-server

For other clients, add this to the MCP config file:

{
  "mcpServers": {
    "devops-status-mcp-server": {
      "command": "npx",
      "args": ["-y", "@cyanheads/devops-status-mcp-server"]
    }
  }
}

No API key required. For Docker or a source build, see Running the server.


Configuration

No API keys required. All environment variables are optional.

VariableDescriptionDefault
DEVOPS_STATUS_CACHE_TTL_MSIn-memory cache TTL for vendor status reads (all backends) in milliseconds.60000
DEVOPS_STATUS_FETCH_TIMEOUT_MSPer-request timeout for vendor status API calls (all backends) in milliseconds.8000
DEVOPS_STATUS_CERT_TIMEOUT_MSDefault timeout_ms for devops_check_certs (1000–15000).5000
DEVOPS_STATUS_DNS_TIMEOUT_MSDefault timeout_ms for devops_check_dns (1000–10000).3000
DEVOPS_STATUS_ALLOW_PRIVATE_TARGETSWhen true, disables the SSRF guards on user-supplied status-page URLs, devops_check_certs hosts, and devops_check_dns resolver IPs. Trusted local deployments only.false
DEVOPS_STATUS_DISABLE_ACTIVE_PROBESWhen true, removes devops_check_dns and devops_check_certs. For shared public instances.false
MCP_TRANSPORT_TYPETransport: stdio or http.stdio
MCP_HTTP_PORTPort for HTTP server.3010
MCP_SESSION_MODEHTTP session handling: stateless, stateful, or auto.stateless
MCP_AUTH_MODEAuth mode: none, jwt, or oauth.none
MCP_LOG_LEVELLog level (RFC 5424).info
LOGS_DIRDirectory for log files (Node.js only).<project-root>/logs
OTEL_ENABLEDEnable OpenTelemetry instrumentation.false

An invalid DEVOPS_STATUS_* value stops startup with an error naming the variable.

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


Running the server

Local development

Requires Bun v1.4.0 or higher (or Node.js v24+).

  • Clone and install:

    git clone https://github.com/cyanheads/devops-status-mcp-server.git
    cd devops-status-mcp-server && bun install
    cp .env.example .env   # optional overrides
    
  • 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 run --rm -p 3010:3010 ghcr.io/cyanheads/devops-status-mcp-server:latest

The image defaults to HTTP transport, stateless session mode, and logs to /var/log/devops-status-mcp-server. To run it over stdio from an MCP client, use "command": "docker" with "args": ["run", "-i", "--rm", "-e", "MCP_TRANSPORT_TYPE=stdio", "ghcr.io/cyanheads/devops-status-mcp-server:latest"]. To build locally, docker build -t devops-status-mcp-server .; OpenTelemetry peer dependencies are installed by default — build with --build-arg OTEL_ENABLED=false to omit them.


Project structure

PathPurpose
src/index.tscreateApp() 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, legacy-TLS retry, HSTS read.
src/services/dns/DNS wire client (node:dgram / node:net): message encoding and bounds-checked decoding, UDP with TCP retry; multi-resolver fan-out and propagation discrepancy detection.
src/services/statuspage/Statuspage public API client (reads through the shared cache in src/utils/cached-fetch.ts).
src/services/status-adapters/Native-API adapters (Status.io, Slack, AWS Health, Google Cloud Service Health, Azure status, Azure DevOps status, Firehydrant, Datadog), the shared RSS extractor, + 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).
src/utils/Shared helpers — response cache and fetch, SSRF guard, domain-entry normalizer, HTML-to-text, vendor-text markdown escaping, code-span rendering of DNS and certificate values, input-bound notices, word matching.
skills/Published agent skill (devops-status-guide), served over MCP and shipped in the npm package, Docker image, and .mcpb bundle.
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.

版本与发布记录

@cyanheads/devops-status-mcp-server 共发布 30 个版本,首次发布于 2026/05/30;过去 12 个月发布了 30 个版本。

版本发布日期距今
0.11.1latest2026/11/012 天前
0.11.02026/10/313 天前
0.10.02026/10/1519 天前
0.9.12026/10/0826 天前
0.9.02026/09/251 个月前
0.8.32026/09/251 个月前

关于 @cyanheads/devops-status-mcp-server 的常见问题

@cyanheads/devops-status-mcp-server 是什么?

检查供应商状态页面,检查SSL/TLS证书,验证DNS传播,并通过MCP获得事件响应剧本。STDIO或可流HTTP。

如何安装 @cyanheads/devops-status-mcp-server?

在项目目录运行 npm install @cyanheads/devops-status-mcp-server,或使用 pnpm add / yarn add / bun add。它还提供命令行工具 devops-status-mcp-server,可以用 npx devops-status-mcp-server 直接运行。

@cyanheads/devops-status-mcp-server 支持 TypeScript 吗?

支持。包内自带 TypeScript 类型声明(package.json 声明了 types 入口),安装后即可获得类型提示,无需再安装 @types 包。

@cyanheads/devops-status-mcp-server 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@cyanheads/devops-status-mcp-server 需要什么版本的 Node.js?

package.json 的 engines 字段要求 Node.js >=24.0.0。版本不符时 npm 默认只给出警告,开启 engine-strict 后会拒绝安装。

@cyanheads/devops-status-mcp-server 可以商用吗?

@cyanheads/devops-status-mcp-server 使用 Apache-2.0 许可。宽松许可:允许商业使用、修改和再分发,并附带明确的专利授权;分发时需保留许可与 NOTICE 文件,修改过的文件要注明改动。以上为概括,不构成法律意见,请以许可原文为准。

@cyanheads/devops-status-mcp-server 还在维护吗?

最新版本 0.11.1 发布于 2026/11/01(2 天前);至今共发布 30 个版本,其中过去 12 个月发布了 30 个;首次发布于 2026/05/30。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。