devops-status-mcp-server

Devops Suggest Action

devops_suggest_action

Read-onlyIdempotent

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 Schema

TableJSON Schema

Name	Required	Description
`vendor`	Yes	Vendor slug, display name, or raw status page URL (e.g., "cloudflare", "Amazon Web Services"). Used to tailor category-specific guidance (CDN outage vs. CI/CD outage vs. auth provider outage). A name that matches no registry vendor gets a devops_list_vendors search as its first follow-up instead of an incidents call.
`your_domain`	No	Your own domain or service URL. When provided, nextToolSuggestions will be pre-filled with your domain for cert and DNS checks.
`incident_summary`	No	Latest incident description or update body from devops_get_incidents. Paste the most recent update to get more targeted advice.
`vendor_indicator`	No	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.
`affected_components`	No	Component names affected (from devops_status_check degraded_components or devops_get_incidents affected_components). Values pre-filled by devops_status_check read "Group / Leaf" for a component the status page files under a group. Used to tailor suggestions to the impacted subsystem.

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 14, 2026

changedInput schema / properties / affected_components / description

Previous value: -"Component names affected (from devops_status_check degraded_components or devops_get_incidents affected_components). Used to tailor suggestions to the impacted subsystem."New value: +"Component names affected (from devops_status_check degraded_components or devops_get_incidents affected_components). Values pre-filled by devops_status_check read \"Group / Leaf\" for a component the status page files under a group. Used to tailor suggestions to the impacted subsystem."

changedInput schema / properties / vendor / description

Previous value: -"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)."New value: +"Vendor slug, display name, or raw status page URL (e.g., \"cloudflare\", \"Amazon Web Services\"). Used to tailor category-specific guidance (CDN outage vs. CI/CD outage vs. auth provider outage). A name that matches no registry vendor gets a devops_list_vendors search as its first follow-up instead of an incidents call."

changedOutput schema / properties / nextToolSuggestions / items / properties / toolName / description

Previous value: -"Tool to call next (e.g., \"devops_check_dns\", \"devops_check_certs\")."New value: +"Tool to call next (e.g., \"devops_get_incidents\", \"devops_list_vendors\", \"devops_check_dns\")."

Changed4 schema fields changedSep 20, 2026
- removedOutput schema / properties / diagnostics_summary / properties / incident_snippet / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / diagnostics_summary / properties / incident_snippet / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / vendor_category / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / vendor_category / type
```
Added value: +[
+  "string",
+  "null"
+]
```

Changed6 schema fields changedAug 25, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / anyOf

Added value: +[
+  {
+    "not": {
+      "required": [
+        "error"
+      ]
+    },
+    "required": [
+      "vendor",
+      "vendor_category",
+      "guidance",
+      "diagnostics_summary",
+      "nextToolSuggestions"
+    ]
+  },
+  {
+    "required": [
+      "error"
+    ]
+  }
+]

addedOutput schema / properties / error

Added value: +{
+  "additionalProperties": {},
+  "description": "Present when the call failed. Absent on success.",
+  "properties": {
+    "code": {
+      "description": "JSON-RPC error code for this failure.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "data": {
+      "additionalProperties": {},
+      "properties": {
+        "reason": {
+          "description": "Machine-readable failure mode.",
+          "type": "string"
+        },
+        "recovery": {
+          "additionalProperties": {},
+          "description": "Actionable next step for the caller.",
+          "properties": {
+            "hint": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "hint"
+          ],
+          "type": "object"
+        },
+        "retryable": {
+          "description": "Whether retrying may succeed.",
+          "type": "boolean"
+        }
+      },
+      "type": "object"
+    },
+    "message": {
+      "description": "Human-readable description of what went wrong.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "code",
+    "message"
+  ],
+  "type": "object"
+}

removedOutput schema / required

Removed value: -[
-  "vendor",
-  "vendor_category",
-  "guidance",
-  "diagnostics_summary",
-  "nextToolSuggestions"
-]

Changed2 schema fields changedJul 31, 2026

changedInput schema / properties / vendor_indicator / enum

Previous value: -[
-  "none",
-  "minor",
-  "major",
-  "critical"
-]New value: +[
+  "none",
+  "minor",
+  "major",
+  "critical",
+  "maintenance"
+]

changedOutput schema / properties / diagnostics_summary / properties / vendor_indicator / anyOf

Previous value: -[
-  {
-    "enum": [
-      "none",
-      "minor",
-      "major",
-      "critical"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "none",
+      "minor",
+      "major",
+      "critical",
+      "maintenance"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

Changed1 schema field changedJul 11, 2026

changedOutput schema / properties / diagnostics_summary / properties / incident_snippet / description

Previous value: -"First 200 characters of incident_summary truncated for context, or null when not provided."New value: +"The incident_summary input echoed in full for context, or null when not provided."

Changed4 schema fields changedJul 2, 2026

addedInput schema / properties / vendor_indicator

Added value: +{
+  "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.",
+  "enum": [
+    "none",
+    "minor",
+    "major",
+    "critical"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / diagnostics_summary / properties / vendor_indicator / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "none",
+      "minor",
+      "major",
+      "critical"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedOutput schema / properties / diagnostics_summary / properties / vendor_indicator / description

Previous value: -"Overall vendor indicator from the calling context, or null when not provided as input."New value: +"Vendor status indicator echoed from the vendor_indicator input, or null when not provided."

changedOutput schema / properties / guidance / description

Previous value: -"Markdown playbook — immediate steps, diagnostic checks, mitigation options, and what to monitor for resolution. Tailored to the vendor category and affected components."New value: +"Markdown playbook — immediate steps, diagnostic checks, mitigation options, and what to monitor for resolution. Tailored to the vendor category, reported severity, and affected components."

AddedMay 31, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnly, idempotent, closed-world behavior, so the bar is lower. The description adds genuine context: guidance is synthesized from built-in incident knowledge plus the caller's context, and the output is a playbook with pre-filled follow-up calls. It stops short of noting any limits or caveats on that generated guidance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the verb and deliverable, then the synthesis mechanism, then the trigger. Every sentence carries information and none is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description needn't enumerate return values. It covers purpose, trigger conditions, input tailoring, and behavioral nature — everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the per-parameter descriptions (vendor slug fallback, your_domain pre-fill, indicator enum, component grouping) are richer than anything the prose adds. Baseline 3 is appropriate since the schema carries the parameter burden; the description only alludes to 'provided context'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (return) and resource (incident-response playbook), plus distinguishing detail: pre-filled follow-up tool calls tailored to vendor degradation. It names the sibling tools that surface the problem, so an agent can tell it apart from devops_status_check and devops_get_incidents without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to invoke it (after devops_status_check or devops_get_incidents surfaces a problem) and the goal (determine what to investigate next). Clear context, but no explicit exclusions or counter-indications for when a different sibling would be preferable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All devops-status-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.