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 or display name (e.g., "cloudflare", "github"). Used to tailor category-specific guidance (CDN outage vs. CI/CD outage vs. auth provider outage).
`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). 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.

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?

Given the annotations already declare readOnlyHint and idempotentHint, the description adds useful behavioral context by explaining that the tool synthesizes built-in incident knowledge and provided context into a playbook, and that it returns pre-filled follow-up tool calls. This goes beyond the annotations without contradicting them.

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?

The description is two sentences with no filler. The first sentence states the core purpose and output characteristic; the second explains the knowledge synthesis and the exact workflow position. Every sentence earns its place, and the most important info is front-loaded.

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?

The description gives enough context for an agent to know when to call this tool, what it does, and how it relates to upstream status/incident tools. The output schema exists, so the description does not need to enumerate return fields, and the input schema fully covers parameter semantics. The tool's role among its siblings is clear.

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%, so the input schema already documents each parameter's meaning, including the vendor enum semantics and how your_domain is used. The description itself does not add parameter-specific detail, but it does not need to because the schema is complete.

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?

The description states a specific verb and resource: 'Return an incident-response playbook tailored to a vendor degradation, with pre-filled follow-up tool calls.' It clearly differentiates this advisory/synthesis tool from siblings like devops_check_certs and devops_status_check, which perform direct checks or status retrieval rather than generating next-step guidance.

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?

The usage guidance is explicit and actionable: 'Use after devops_status_check or devops_get_incidents surfaces a problem to determine what to investigate next.' This clearly communicates the appropriate point in the workflow, though it does not explicitly list what not to use the tool for or name alternative advisory tools.

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.