MCP Final Spec Shipped. Now It Needs SRE Governance

#mcp #ai #sre #agentaichallenge

The Model Context Protocol shipped its final specification on July 28, 2026 — adding Tasks and MCP Apps extensions, with LangGraph 1.0 treating MCP tools as first-class graph nodes and Netzilo shipping cross-platform runtime kill switches for compromised agents.

MCP stops being an experimental protocol today. It is production infrastructure.

Production infrastructure needs SRE governance. Here is what that looks like for MCP.

What Changed in the Final Spec

The final MCP spec introduces two extensions that change the reliability picture significantly:

Tasks: Long-running operations are now a first-class primitive in MCP. An agent can initiate a task, the MCP server executes it asynchronously, and the result is available when complete. This is not a workaround — it is the specified behavior. Tasks can now run for minutes or hours autonomously without the agent polling.

MCP Apps: A standardized way for MCP servers to expose UI components alongside tool calls. Agents can now interact with structured interfaces, not just raw function returns.

The reliability implication of both: MCP is no longer a request-response protocol with human-timescale latency. It is an orchestration layer for long-running autonomous work.

The Four SRE Gaps That Arrive With the Final Spec

1. Every MCP Tool Needs an SLO

Your agent's reliability is bounded by the worst MCP server it calls. An agent that calls five MCP tools has five dependency SLOs. If any one fails silently — returning an unexpected format, timing out without an error, returning stale data — your agent's Decision Quality Rate degrades with no infrastructure-layer signal.

Instrument Tool Invocation Efficiency per MCP server, not just per task class:

from agentsre import AgentSLICollector, TaskRecord

collector = AgentSLICollector()

# Track per MCP server — not just per task
for mcp_server, tool_calls in mcp_trace.server_calls.items():
    collector.record(TaskRecord(
        task_id=task_id,
        task_class=f"mcp:{mcp_server}",   # per-server tracking
        tool_calls=tool_calls,
        decision_confidence=task_confidence,
        completed=task_completed,
    ))

# Each MCP server gets its own TIE baseline and breach alert
results = collector.collect(f"mcp:{mcp_server}")

This gives you per-MCP-server behavioral baselines. When a specific server starts generating elevated tool call counts — retry storms, format changes, latency degradation — TIE catches it before it surfaces as task failure.

2. MCP Circuit Breaker at the Boundary

When an MCP tool fails, what does your agent do? Most frameworks retry. Retry logic without a circuit breaker at the MCP boundary produces retry storms — the agent calls a failing tool repeatedly, TIE climbs silently, and the first observable signal is a cost spike.

Apply the circuit breaker at the MCP call layer:

from agentsre import AgentChainCircuitBreaker

# Circuit breaker per MCP server
mcp_breakers = {
    server_name: AgentChainCircuitBreaker(
        open_threshold=85.0,    # open if semantic success rate drops below 85%
        close_threshold=95.0,   # close after recovery
        on_state_change=lambda state: alert_mcp_server_owner(server_name, state),
    )
    for server_name in mcp_servers
}

def call_mcp_tool(server_name: str, tool: str, params: dict):
    breaker = mcp_breakers[server_name]

    if not breaker.allow_request(server_name, tool):
        # Circuit open — route to fallback or human escalation
        return fallback_handler(server_name, tool, params)

    result = mcp_client.call(server_name, tool, params)
    success = validate_mcp_result(result)
    breaker.record_result(server_name, tool, success=success)
    return result

3. Long-Running Tasks Need Approval Gates

The Tasks extension means an MCP operation can run for minutes or hours. During that time, the agent is making autonomous decisions with no human checkpoint. The governance question is not whether Tasks should exist — it's which tasks get an approval gate and which run fully autonomous.

Map your task classes to your blast radius tiers:

from agentsre.production_readiness import BlastRadiusTier

MCP_TASK_GATES = {
    "log-analysis":       BlastRadiusTier.LOW,     # fully autonomous
    "config-validation":  BlastRadiusTier.LOW,     # fully autonomous
    "service-restart":    BlastRadiusTier.MEDIUM,  # approve before execute
    "database-migration": BlastRadiusTier.HIGH,    # always human approval
    "credential-rotation":BlastRadiusTier.CRITICAL,# named approver + audit
}

def should_gate_task(task_type: str) -> bool:
    tier = MCP_TASK_GATES.get(task_type, BlastRadiusTier.HIGH)
    return tier in [BlastRadiusTier.HIGH, BlastRadiusTier.CRITICAL]

4. Kill Switches Need Runbooks

Netzilo ships kill switches for compromised agents. A kill switch without a runbook is a panic button — you know how to stop the agent, but not what to check, what to preserve for the postmortem, or how to safely restart.

Before enabling any MCP-connected agent in production, write three runbook sections:

Trigger conditions: What observable signal causes you to reach for the kill switch? TIE > 3x baseline? AQDD > 5x? An out-of-scope API call in your audit log?

Kill procedure: Kill switch activation → preserve agent state for postmortem → notify dependent systems → route pending tasks to human queue.

Recovery criteria: What must be true before restarting the agent? Root cause identified, blast radius assessed, SLO targets reviewed.

Connecting to the Existing Framework

The MCP final spec adds one new governance requirement to the existing agentsre framework:

Per-MCP-server TIE tracking — instrument task_class=f"mcp:{server_name}" for each server
MCP boundary circuit breaker — AgentChainCircuitBreaker at the MCP call layer
Task blast radius mapping — BlastRadiusTier per MCP task class
Kill switch runbook — added to RunbookDefinition detection/containment/recovery