# io.github.cyanheads/devops-status-mcp-server (remote · devops-status.caseyjhand.com)

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

- Trust score: 68/100 (medium)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `devops-status.caseyjhand.com`: 68/100 (this document), [markdown](https://verifymcp.io/servers/cyanheads-devops-status-mcp-server/devops-status.md), [page](https://verifymcp.io/servers/cyanheads-devops-status-mcp-server/devops-status)
- npm · `@cyanheads/devops-status-mcp-server`: 35/100, [markdown](https://verifymcp.io/servers/cyanheads-devops-status-mcp-server/cyanheads-devops-status-mcp-server.md), [page](https://verifymcp.io/servers/cyanheads-devops-status-mcp-server/cyanheads-devops-status-mcp-server)

## Channel facts

- Endpoint: `https://devops-status.caseyjhand.com/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.8.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 66/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 6 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC is configured correctly; the domain's records validate against the full chain to the root.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 62/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2324 tokens (~332/item across 7 items; 7 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

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

### Codex

```toml
[mcp_servers.cyanheads-devops-status-mcp-server]
url = "https://devops-status.caseyjhand.com/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "cyanheads-devops-status-mcp-server": {
      "type": "remote",
      "url": "https://devops-status.caseyjhand.com/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add cyanheads-devops-status-mcp-server --url https://devops-status.caseyjhand.com/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  cyanheads-devops-status-mcp-server:
    url: "https://devops-status.caseyjhand.com/mcp"
```

### Other

```json
{
  "mcpServers": {
    "cyanheads-devops-status-mcp-server": {
      "type": "http",
      "url": "https://devops-status.caseyjhand.com/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 68, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-01 (score 67, +11)

- [functional improvement] Schema quality: unverified → excellent

### 2026-07-31 (score 56, −9)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 65, 0)

- [security] The server rewrote its instructions, which are the text every model session reads
- [security] Tool “devops_check_dns” rewrote its description, which is the text the model reads
- [security] Tool “devops_check_certs” rewrote its description, which is the text the model reads
- [security] Tool “devops_get_incidents” rewrote its description, which is the text the model reads
- [security] Tool “devops_status_check” rewrote its description, which is the text the model reads
- [security] Tool “devops_watch_stack” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 237 → 331
- [functional regression] Schema quality: 237 → 328
- [functional regression] Schema quality: 237 → 283
- [functional] MCP protocol: Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.
- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server
- [functional] Server version: 0.6.0 → 0.7.0
- [functional] Server version: 0.5.6 → 0.6.0
- [functional] Server version: 0.5.5 → 0.5.6
- [cosmetic] “devops_status_check” added an optional parameter “component_limit”
- [cosmetic] “devops_status_check” added an optional parameter “component_filter”
- [cosmetic] “devops_watch_stack” added an optional parameter “component_limit”
- [cosmetic] “devops_watch_stack” added an optional parameter “component_filter”
- [cosmetic] “devops_get_incidents” reworded the description of “filter”
- [cosmetic] “devops_get_incidents” reworded the description of “offset”
- [cosmetic] “devops_watch_stack” reworded the description of “mode”
- [cosmetic] “devops_status_check” reworded the description of “mode”

### 2026-07-29 (score 65, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 64, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 63)

First indexed and scored.

## MCP tools (7)

### `devops_list_vendors` (~131 tokens)

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.

Input parameters:

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

Output parameters:

- `categories` (array): All available category values for use in the category filter.
- `total` (number): Total number of vendors returned.
- `vendors` (array): Matching vendors from the built-in registry.

### `devops_status_check` (~390 tokens)

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, 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.

Input parameters:

- `component_filter` (string): 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…
- `component_limit` (integer): 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…
- `mode` (string): summary: indicator + degraded components + active incidents only. detailed: adds the component list and scheduled maintenance windows.
- `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_vend…

Output parameters:

- `cap` (number): The per-vendor component_limit that was applied. Present only when truncated.
- `notice` (string): Plain-language explanation of the capped component lists — how many components were omitted and how to reach them (component_filter to target one, component_limit to raise the cap). Present only when…
- `results` (array): Per-vendor status results in the same order as the input vendors list.
- `shown` (number): Components returned across all vendors. Present only when truncated.
- `summary` (object): Aggregate health counts across all checked vendors. Buckets partition the batch: operational + degraded + down + maintenance + unavailable = total.
- `totalCount` (number): Components matching component_filter across all vendors before the cap. Present only when truncated.
- `truncated` (boolean): True when at least one vendor's component list was capped at component_limit. Absent when nothing was capped.

### `devops_get_incidents` (~358 tokens)

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 reachable only on the vendor status page, not at a higher offset. An empty result explains itself in notice.

Input parameters:

- `filter` (string): all: incidents plus scheduled maintenances. active: only incidents with status investigating/identified/monitoring. resolved: only fully resolved incidents. scheduled: only scheduled maintenance wind…
- `limit` (integer): Maximum incidents to return per call (1–50). Page through longer history with offset rather than raising this.
- `offset` (integer): 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 fi…
- `vendor` (string, required): Vendor slug (e.g., "github", "aws") or raw Atlassian Statuspage base URL. Use devops_list_vendors to find slugs.

Output parameters:

- `cap` (number): The limit that was applied. Present only when truncated.
- `incidents` (array): Matching incidents.
- `name` (string): Display name of the vendor.
- `nextOffset` (number): The offset to pass on the next call to continue from where this page stopped, already computed as offset + the number returned. Present only when truncated — its absence means this page reached the e…
- `notice` (string): Plain-language explanation of this result — how to page onward, why it came back empty (the vendor currently publishes nothing at all, a filter the backend cannot satisfy, or an offset past the end),…
- `shown` (number): Number of incidents returned after applying the limit. Present only when truncated.
- `statuspage_url` (string): Status page base URL used.
- `totalCount` (number): Total incidents matching the filter, across all pages, before offset/limit windowing. Present only when the result was truncated.
- `total_returned` (number): Number of incidents in the response.
- `truncated` (boolean): True when more incidents matched than the limit returned. Absent when the result was not capped.
- `upstreamCeiling` (number): Maximum incidents the vendor's own status API serves in one fetch, present only when that ceiling was reached on this call. It bounds the history independently of limit and offset: incidents older th…
- `vendor` (string): Vendor slug or URL as provided.

### `devops_watch_stack` (~348 tokens)

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. Ideal for morning status checks or pre-deploy sweeps. Multiple stacks can coexist (e.g., "production", "staging").

Input parameters:

- `component_filter` (string): 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…
- `component_limit` (integer): 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 componen…
- `mode` (string): summary: indicator + degraded components + active incidents. detailed: adds component lists and maintenance windows.
- `stack_name` (string): Name for this vendor stack. Defaults to "default". Use distinct names to manage multiple stacks (e.g., "production", "data-layer").
- `vendors` (array): 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.

Output parameters:

- `cap` (number): The per-vendor component_limit that was applied. Present only when truncated.
- `checked_at` (string): ISO 8601 UTC timestamp of this check.
- `health` (string): Aggregate health rollup: all_operational = everything clear, maintenance = at least one vendor in a scheduled window and nothing worse open, degraded = at least one minor issue, partial_outage = at l…
- `notice` (string): Plain-language explanation of the capped component lists — how many components were omitted and how to reach them (component_filter to target one, component_limit to raise the cap). Present only when…
- `omitted_vendors` (array): Entries that could not be resolved or whose URL was blocked; they still appear in vendors[] with an error. A call that saved the stack left them out of the write; a call that reused a saved stack lea…
- `shown` (number): Components returned across the stack. Present only when truncated.
- `stack_name` (string): Name of the stack checked.
- `stack_persisted` (boolean): True when the vendor list was saved to state on this call. Only the vendors that resolved are saved — see omitted_vendors.
- `summary` (object): Aggregate health counts across all checked vendors. Buckets partition the stack: operational + degraded + down + maintenance + unavailable = total.
- `totalCount` (number): Components matching component_filter across the stack before the cap. Present only when truncated.
- `truncated` (boolean): True when at least one vendor's component list was capped at component_limit. Absent when nothing was capped.
- `vendors` (array): Per-vendor status results.

### `devops_check_certs` (~281 tokens)

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.

Input parameters:

- `domains` (array, required): Domains to inspect. Do not include "https://" — pass the bare hostname. Up to 10 per call.
- `port` (integer): TLS port. Defaults to 443. Use 8443 or custom ports for non-standard HTTPS endpoints.
- `timeout_ms` (integer): 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.

Output parameters:

- `results` (array): Per-domain certificate inspection results.

### `devops_check_dns` (~372 tokens)

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.

Input parameters:

- `domains` (array, required): Domain names to query. Up to 10 per call.
- `record_types` (array): DNS record types to resolve. Defaults to A, AAAA, MX, and TXT. Add NS to check nameserver delegation. Add CNAME when investigating redirect chains.
- `resolvers` (array): Resolver IP addresses to query. Defaults to Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). Add custom resolvers to test resolver-specific behavior. Each must be an IP literal, not a hos…
- `timeout_ms` (integer): Query timeout per domain+resolver combination in milliseconds. Defaults to the DEVOPS_STATUS_DNS_TIMEOUT_MS env var (3000 when unset).

Output parameters:

- `results` (array): Per-domain DNS resolution results.

### `devops_suggest_action` (~272 tokens)

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.

Input parameters:

- `affected_components` (array): Component names affected (from devops_status_check degraded_components or devops_get_incidents affected_components). Used to tailor suggestions to the impacted subsystem.
- `incident_summary` (string): Latest incident description or update body from devops_get_incidents. Paste the most recent update to get more targeted advice.
- `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).
- `vendor_indicator` (string): 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 che…
- `your_domain` (string): Your own domain or service URL. When provided, nextToolSuggestions will be pre-filled with your domain for cert and DNS checks.

Output parameters:

- `diagnostics_summary` (object): Summary of input context used to generate the playbook.
- `guidance` (string): Markdown playbook — immediate steps, diagnostic checks, mitigation options, and what to monitor for resolution. Tailored to the vendor category, reported severity, and affected components.
- `nextToolSuggestions` (array): Recommended follow-up calls with arguments already populated. Execute these in sequence to gather diagnostic data.
- `vendor` (string): Vendor as provided.
- `vendor_category`: Detected category from registry (e.g., "cdn-edge", "auth"). Null for unrecognized vendors.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/cyanheads-devops-status-mcp-server/devops-status#diagnostics

## Score history

- 2026-08-03: 68
- 2026-08-02: 67
- 2026-08-01: 67
- 2026-07-31: 56
- 2026-07-30: 65
- 2026-07-29: 65
- 2026-07-28: 64
- 2026-07-27: 64
- 2026-07-26: 63

## Links

- Remote endpoint: https://devops-status.caseyjhand.com/mcp
- Repository: https://github.com/cyanheads/devops-status-mcp-server
- Changelog RSS feed: https://verifymcp.io/servers/cyanheads-devops-status-mcp-server/devops-status/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/cyanheads-devops-status-mcp-server/devops-status/changelog.json
- HTML version of this page: https://verifymcp.io/servers/cyanheads-devops-status-mcp-server/devops-status