Build an Autonomous Cloud Operations Agent Workflow with Nutanix Prism & MCP

By Deepak Bagada, CEO at SaaSNext & Principal AI Architect.

Introduction

On August 10, 2026, Nutanix released an open-source Model Context Protocol server that lets AI assistants — including GitHub Copilot — interact with Nutanix Cloud Platform through Prism V4 APIs. The announcement is part of a larger wave we have been tracking on latest AI news: every infrastructure vendor is now shipping an MCP surface, because they know the next generation of operators will not be humans typing into consoles, but agents calling tools. The MCP server is the connective tissue — it turns Prism V4 into a typed, governed tool surface any assistant can call. But a query surface is not an operations team. The value appears one layer up: in the agent that decides what to do with the telemetry, when to act, and when to stop and ask.

This dispatch builds that layer: a LangGraph autonomous cloud operations workflow, prism-ops, that polls cluster and VM telemetry through the Nutanix MCP tools, detects anomalies, classifies their severity, executes safe remediation actions from a catalog, and escalates anything risky to a human approval gate. If you are running hyperconverged infrastructure in 2026, this is the blueprint for turning a vendor MCP server into an operator that never sleeps — and never acts beyond its authority. The same boundary discipline runs through the MCP directory: define exactly what the agent can touch, then observe everything it does.

Why the MCP surface is the easy half

It is worth being precise about what Nutanix's launch does and does not give you. What it gives you: a standardized way for an assistant to query cluster health, list hosts, inspect VMs, read storage utilization, and invoke Prism V4 operations as tools — with the Model Context Protocol handling tool discovery, argument schemas, and authentication. Any MCP-compatible client, from GitHub Copilot to a custom LangGraph agent, can use it without a bespoke integration. That is genuinely valuable: it collapses months of custom API glue into a config file.

What it does not give you: judgment. An MCP server does not know that a 2% CPU blip on one host is noise, that a trending storage-capacity curve is a Tuesday-afternoon incident waiting to happen, or that draining a VM during its backup window will cause more damage than the reboot it was avoiding. That judgment is the agent layer, and it is where the real operational value lives. The pattern generalizes across the ecosystem — every vendor MCP server that launched in the past year is a tool surface, and the workflows that consume it are the differentiator. That is the same conclusion the AI workflows library keeps arriving at: the connector matters, the orchestration decides.

Architecture overview

graph TD
  subgraph Telemetry[Cluster Telemetry]
    T1[Prism V4 Poll] --> T2[Normalizer]
    T2 --> T3[(Ops Store)]
  end
  T3 --> D1[Anomaly Detector]
  D1 --> C1{Severity}
  C1 -->|Low| L1[Safe Auto-Action]
  C1 -->|Medium| L2[Runbook Lane]
  C1 -->|High| H1[Human Approval Gate]
  L1 --> E1[Execute via MCP]
  L2 --> E1
  H1 --> E2[Await Approval]
  E1 --> A1[(Action Audit Log)]
  E2 --> A1
  A1 --> R1[Post-Action Verify]

The pipeline has six stages. Stage one — the poller pulls cluster, host, VM, and storage telemetry through the Nutanix MCP tools on a schedule. Stage two — the normalizer writes a consistent event shape to the ops store. Stage three — the anomaly detector classifies each finding as low, medium, or high severity with a readable signal list. Stage four — the router maps severity to a lane: safe auto-action for low, runbook execution for medium, human approval gate for high. Stage five — approved actions execute through the MCP tools, and every action lands in the audit log. Stage six — the verifier re-polls telemetry after each action to confirm the fix landed. The design goal: the agent acts early on what is safe to act on, and never acts beyond its catalog.

Part 1 — The operations schema

.env

PRISM_MCP_URL=http://prism-ops.internal:3000
PRISM_AUTH_TOKEN=ntnx-...-scoped
POLL_INTERVAL_MIN=5
CPU_ALERT_PCT=85
CAPACITY_ALERT_PCT=80
SAFE_ACTIONS=drain_vm,snapshot_vm,rebalance_storage
AUDIT_TABLE=ops_action_audit

schemas.py

from pydantic import BaseModel, Field
from typing import List, Literal
from datetime import datetime

class HostHealth(BaseModel):
    host_id: str
    cluster_id: str
    cpu_pct: float
    mem_pct: float
    storage_pct: float
    controller_latency_ms: float
    status: Literal["healthy", "warning", "critical"]
    checked_at: datetime

class OpsFinding(BaseModel):
    finding_id: str
    target: str                  # host, vm, cluster, storage pool
    metric: str
    observed: float
    threshold: float
    severity: Literal["low", "medium", "high"]
    runbook: str                 # id of the runbook to invoke
    created_at: datetime

class OpsAction(BaseModel):
    action_id: str
    tool: str                    # the Prism V4 MCP tool to call
    args: dict
    reversible: bool
    requires_approval: bool
    status: Literal["pending", "approved", "executed", "failed", "rejected"]
    executed_at: datetime | None = None

HostHealth is the telemetry shape. OpsFinding is the anomaly classifier's output — and the runbook field is the bridge between detection and action. OpsAction is the safety contract: every action declares whether it is reversible and whether it requires approval, so the router can decide autonomously or escalate with confidence. The schema is deliberately boring — boring schemas are what make autonomous systems auditable. The same principle applies to the tool definitions in the MCP directory: a tool with a typed schema and documented side effects is a tool an agent can use safely.

Part 2 — The detector and the safe-action catalog

tools.py

import httpx, os, json

PRISM = os.environ["PRISM_MCP_URL"]

def mcp_call(tool: str, args: dict) -> dict:
    """Call a Nutanix MCP tool (Prism V4 surface) and return structured result."""
    r = httpx.post(f"{PRISM}/tools/call",
                   json={"name": tool, "arguments": args},
                   headers={"Authorization": f"Bearer {os.environ['PRISM_AUTH_TOKEN']}"},
                   timeout=30)
    r.raise_for_status()
    return r.json()

def detect(hosts: list[HostHealth]) -> list[OpsFinding]:
    findings = []
    for h in hosts:
        if h.cpu_pct > 85:
            findings.append(OpsFinding(finding_id=f"cpu-{h.host_id}",
                target=h.host_id, metric="cpu_pct", observed=h.cpu_pct,
                threshold=85.0, severity="low" if h.cpu_pct < 92 else "medium",
                runbook="rb_drain_rebalance", created_at=datetime.utcnow()))
        if h.storage_pct > 80:
            findings.append(OpsFinding(finding_id=f"cap-{h.host_id}",
                target=h.host_id, metric="storage_pct", observed=h.storage_pct,
                threshold=80.0, severity="medium", runbook="rb_capacity",
                created_at=datetime.utcnow()))
        if h.controller_latency_ms > 25:
            findings.append(OpsFinding(finding_id=f"lat-{h.host_id}",
                target=h.host_id, metric="controller_latency_ms",
                observed=h.controller_latency_ms, threshold=25.0,
                severity="high", runbook="rb_human_review",
                created_at=datetime.utcnow()))
    return findings

SAFE = {
    "rb_drain_rebalance": [OpsAction(action_id="a1", tool="drain_vm", args={},
                                     reversible=True, requires_approval=False, status="pending")],
    "rb_capacity": [OpsAction(action_id="a2", tool="snapshot_vm", args={"retention_days": 7},
                              reversible=True, requires_approval=False, status="pending")],
    "rb_human_review": [OpsAction(action_id="a3", tool="reboot_host",
                                  args={"reason": "controller latency"}, reversible=False,
                                  requires_approval=True, status="pending")],
}

The detector is threshold-based and transparent — each finding names the metric, the observed value, the threshold, and the runbook. The safe-action catalog is the keystone of the whole design: the agent can only execute actions that exist in SAFE, and each one declares reversible and requires_approval. Draining a VM is reversible; rebooting a host is not and therefore requires human approval by construction. This is what makes autonomous cloud operations defensible: the agent's authority is enumerated in a catalog, not improvised in a prompt. It is the same governance logic the latest AI news coverage of agent security keeps emphasizing — bound the tool surface, then trust the orchestration.

Part 3 — The LangGraph prism-ops workflow

graph.py

from langgraph.graph import StateGraph, END
from typing import TypedDict, List

class OpsState(TypedDict):
    hosts: List[HostHealth]
    findings: List[OpsFinding]
    actions: List[OpsAction]
    approvals: dict[str, bool]
    verified: bool

def poll(s: OpsState) -> OpsState:
    s["hosts"] = [HostHealth(**h) for h in mcp_call("list_hosts", {})["hosts"]]
    return s

def detect_node(s: OpsState) -> OpsState:
    s["findings"] = detect(s["hosts"])
    return s

def plan(s: OpsState) -> OpsState:
    s["actions"] = []
    for f in s["findings"]:
        for a in SAFE.get(f.runbook, []):
            a.args["finding_id"] = f.finding_id
            s["actions"].append(a)
    return s

def gate_approvals(s: OpsState) -> OpsState:
    for a in s["actions"]:
        if a.requires_approval and not s["approvals"].get(a.action_id):
            s["approvals"][a.action_id] = request_human_approval(a)  # blocks on review
    return s

def execute_actions(s: OpsState) -> OpsState:
    for a in s["actions"]:
        if a.status == "pending" and (not a.requires_approval or s["approvals"].get(a.action_id)):
            a.status = "executed" if mcp_call(a.tool, a.args)["ok"] else "failed"
            log_action(a)
    return s

def verify(s: OpsState) -> OpsState:
    s["hosts"] = [HostHealth(**h) for h in mcp_call("list_hosts", {})["hosts"]]
    s["verified"] = all(h.status != "critical" for h in s["hosts"])
    return s

g = StateGraph(OpsState)
g.add_node("poll", poll)
g.add_node("detect", detect_node)
g.add_node("plan", plan)
g.add_node("gate", gate_approvals)
g.add_node("execute", execute_actions)
g.add_node("verify", verify)
g.set_entry_point("poll")
g.add_edge("poll", "detect")
g.add_edge("detect", "plan")
g.add_edge("plan", "gate")
g.add_edge("gate", "execute")
g.add_edge("execute", "verify")
g.add_edge("verify", END)
app = g.compile()

main.py

if __name__ == "__main__":
    result = app.invoke({"hosts": [], "findings": [], "actions": [],
                         "approvals": {}, "verified": False})
    print("Findings:", len(result["findings"]))
    print("Actions:", [(a.tool, a.status) for a in result["actions"]])
    print("Verified:", result["verified"])

Run it and the workflow polls Prism V4, classifies the findings, and acts within its catalog: a hot host gets drained, a storage pool at 80% gets a snapshot, and a controller-latency spike opens a human approval request instead of rebooting anything on its own. The post-action verify pass confirms the fix landed or flags the residual. That loop — poll, detect, plan, approve, execute, verify — is the complete operations cycle, and it runs continuously with no human in the middle of the routine.

Retry rules: telemetry polls retry 3 times with exponential backoff (5s, 10s, 20s) on transport errors; a poll failure never triggers an action. Action execution retries twice on transient MCP failures, but a failed action after retries is logged and re-queued for the next cycle — never re-executed blindly, because infrastructure actions are not idempotent by default. Human approval requests never auto-retry and never auto-timeout into approval; a pending approval stays pending. Post-action verification runs once per cycle with no retry — if verification fails, the finding re-enters the detector on the next poll with fresh evidence. These retry rules match the AI workflows library standard: transient errors retry cheaply, judgment calls wait for humans, and destructive actions never improvise.

Part 4 — The audit loop and production checklist

Every action the workflow executes lands in the ops_action_audit table with the tool, arguments, approval status, and outcome. That audit trail is the difference between an autonomous operator your organization trusts and one it fears. When a capacity incident happens at 3am and the snapshot tool ran at 2:47am, the audit row is the evidence that the agent acted inside its catalog, reversibly, with a post-action verification. Build that trust before you expand the catalog — the same staged rollout discipline that runs through every workflow guide we publish.

1. Start read-only. Run the workflow in monitor-only mode for the first two weeks. Let it detect and plan, but skip execution, and tune the thresholds on real traffic.
2. Enumerate the safe-action catalog. Every action the agent may take lives in the catalog with reversible and requires_approval flags. Authority by enumeration, never by improvisation.
3. Gate the destructive ones. Anything not reversible — reboots, deletes, reconfigures — requires human approval by construction. The gate is the feature, not the friction.
4. Verify after every action. Re-poll telemetry and confirm the fix landed. An action without verification is a guess.
5. Audit everything. The audit log is your trust capital and your incident evidence. If the agent cannot prove what it did, it should not have done it.
6. Expand slowly. Add one runbook at a time, observe the false-positive rate, and only then widen the catalog. The same incremental pattern applies to the MCP directory tools you wire in — each new tool is new authority.

Frequently Asked Questions

Q: What did Nutanix launch on August 10, 2026?

A: Nutanix released an open-source Model Context Protocol server that lets AI assistants, including GitHub Copilot, interact with Nutanix Cloud Platform through Prism V4 APIs — the foundation for AI-driven cloud operations.

Q: Why does infrastructure need an MCP server?

A: MCP gives agents a standardized, governed tool surface over infrastructure APIs. Instead of bespoke integrations, any MCP-compatible assistant gets typed tools for the same operations tasks, with the protocol handling auth and tool discovery.

Q: What makes autonomous cloud operations safe?

A: A safe-action catalog: the agent may only execute actions that are reversible (snapshots, drains) or non-destructive (reports, queries), while risky changes like node reboots go through a human approval gate.

Q: How does the workflow decide what to do?

A: It polls telemetry, runs an anomaly detector that classifies severity, and maps each verdict to a runbook: low-severity findings trigger safe auto-actions, high-severity findings open a human review ticket with the full evidence trail.

Q: What should an operations agent monitor first?

A: Cluster health, node utilization, storage capacity, VM density, and controller latency — the telemetry that predicts the incidents you actually get paged for, plus an audit log of every action the agent takes.

Closing thoughts

Nutanix's open-source MCP server is a small file that signals a large shift: infrastructure vendors have accepted that the next operators are agents. The server gives you the surface; the workflow in this dispatch gives you the operator. Poll telemetry, classify findings, act within a safe catalog, gate the destructive stuff behind humans, verify every action, and audit everything. Start read-only, expand slowly, and let the audit log be your proof. That is autonomous cloud operations done right — and it is the same pattern the latest AI news coverage of agentic infrastructure keeps pointing to. Wire the MCP surface from the MCP directory, build the workflow, and let the fleet operate itself while the humans keep the authority.