Hooking a large language model up to internal production services has historically been a painful exercise. During the early days of autonomous agents, every major provider forced us to reinvent the wheel: a proprietary JSON schema for OpenAI, an incompatible format for Anthropic, custom wrappers for Gemini, and a brittle maze of intermediary glue code that collapsed whenever an API version bumped.

The Model Context Protocol (MCP) emerged in late 2024 to curb that madness and establish an open standard. In real-world infrastructure, however, its initial design quickly revealed operational friction. The specification released on July 28, 2026 represents the most significant architectural overhaul of the protocol since its inception: it drops the stateful session model entirely in favor of a purely decoupled, stateless request/response core designed to integrate into modern microservices.

Here is a breakdown of what MCP is, how it operates from first principles, and how to deploy it in production under the rules of the new specification.

1. Fundamentals: The Universal USB-C Port for AI

To understand MCP without drowning in marketing buzzwords, recall how consumer electronics handled device connectivity fifteen years ago. Every phone shipped with a proprietary charging cable. Upgrading your handset meant discarding all your accessories.

The early LLM tooling ecosystem mirrored that exact problem. If you wrote an internal tool to query inventory from PostgreSQL, you had to format the schema according to one vendor's function-calling spec. If you wanted multiple agents to query that same database concurrently — as we covered when examining coordination in agent teams — the integration code had to be duplicated across every model provider.

MCP acts as the USB-C standard for AI applications. It is an open, JSON-RPC 2.0-based protocol that cleanly decouples client hosts from external data sources and execution backends.

+-------------------------------------------------------------+
|               MCP CLIENT (Host / Orchestrator)              |
|  (Antigravity 2.0, Claude Desktop, Cursor, Python Agent)   |
+-------------------------------------------------------------+
                               |
                   JSON-RPC 2.0 (stdio / HTTP)
                               |
                               v
+-------------------------------------------------------------+
|                         MCP SERVER                          |
|         (PostgreSQL, Git, Telemetry, Internal APIs)         |
+-------------------------------------------------------------+

The client (the agent orchestrator or host application running the model, such as Antigravity 2.0) requires zero insight into how your database or underlying infrastructure operates. The MCP server publishes a standard catalog of capabilities, and the client consumes them through a predictable contract.

The Three Core Primitives

Regardless of complexity, every MCP server revolves around three fundamental primitives:

  1. Tools: Verbs. Executable functions that take input parameters and return results. They carry intentional side effects: executing an SQL query, bouncing a container, or opening an incident ticket.
  2. Resources: Passive nouns. Structured data identified by URI schemes (postgres://metrics/cpu, file:///var/log/syslog). The client reads them to hydrate its context window without triggering runtime logic or altering state.
  3. Prompts: Pre-packaged prompt templates. Structured recipes supplied by the server that help client models format queries correctly to interact with available tools.

2. Transport Mechanisms: stdio vs. Remote HTTP

To communicate, the client and server must bind across a transport layer. MCP defines two primary channels, each matching a specific deployment model.

Standard Input/Output (stdio) Transport

This is the default channel when the server executes on the same physical host or container as the client. The host spawns the MCP server as a native child process, writing JSON-RPC frames to stdin and reading output from stdout.

This pattern delivers two critical engineering benefits: it eliminates network roundtrips entirely, and execution remains strictly sandboxed within the host OS user's permission boundaries — a non-negotiable safeguard when executing autonomous agents in Linux environments. If a process attempts an unauthorized syscall or file access, the Linux kernel terminates the request directly.

Remote HTTP Transport (Server-Sent Events)

When the MCP server runs remotely in a Kubernetes cluster or managed cloud service, communication traverses HTTP. The client issues commands via POST requests while listening for asynchronous responses and telemetry streams over Server-Sent Events (SSE).

This remote boundary is where early MCP implementations suffered critical production bottlenecks.

3. Production Architecture: The 2026-07-28 Specification and the Stateless Core

Between November 2024 and mid-2026, the original MCP specification carried an architectural liability: it relied on a stateful session model.

The Problem with Stateful Sessions

Under legacy specifications (2024-11-05 and 2025-11-25), clients had to complete a mandatory handshake (initialize followed by initialized). The server returned an active session token via the Mcp-Session-Id header.

While workable on a local developer workstation, this broke down across production topologies:

  • Incompatibility with Standard Load Balancing: It forced sticky sessions across Nginx, HAProxy, or cloud load balancers. When round-robin traffic landed on an alternate replica that lacked the in-memory session ID, the call crashed with an unhandled protocol disconnect.
  • Storage and Latency Overhead: Teams were forced to synchronize session state into Redis clusters, introducing network hops and additional points of failure.
  • Serverless and Ephemeral Friction: If a container scaled to zero or recycled under memory pressure, active sessions vanished, leaving agentic loops hanging indefinitely.

The Modern Paradigm: Self-Contained Requests

The specification released on July 28, 2026 re-architected the protocol from the ground up to solve this exact issue:

1. Removal of Handshakes and Mcp-Session-Id

The mandatory initialization handshake and session tracking headers have been entirely dropped. Servers no longer retain caller context between turns. Every transaction is completely atomic and self-contained.

2. Direct Payload Metadata (_meta)

Rather than relying on pre-negotiated state, each JSON-RPC frame carries its protocol version and client capabilities inside an explicit _meta object. Any healthy server instance can process the request immediately without checking a shared state store.

{
  "jsonrpc": "2.0",
  "id": "req-4819",
  "method": "tools/call",
  "params": {
    "name": "check_cluster_health",
    "arguments": {
      "node": "prod-k8s-worker-03"
    },
    "_meta": {
      "protocolVersion": "2026-07-28",
      "clientInfo": {
        "name": "antigravity-agent",
        "version": "2.4.0"
      }
    }
  }
}

3. Header-Based Routing (Mcp-Method and Mcp-Name)

Previously, reverse proxies and API gateways were blind to traffic intent without parsing the entire JSON body.

The 2026-07-28 spec standardizes the Mcp-Method and Mcp-Name HTTP headers. Perimetral proxies like Envoy, Cloudflare Workers, or Traefik can now perform route matching, enforce rate limits, and block restricted tools at the network edge without deserializing payload bytes.

POST /mcp/v1 HTTP/1.1
Host: api.srdata.dev
Content-Type: application/json
Mcp-Method: tools/call
Mcp-Name: check_cluster_health
Authorization: Bearer eyJhbGciOi...

4. Unified Discovery (server/discover)

Instead of issuing sequential polling requests across tools/list, resources/list, and prompts/list, clients now rely on the atomic server/discover RPC method. A single request returns all supported capabilities, compatible protocol versions, and schema definitions.

4. Real-World Implementation: Building an Infrastructure Diagnostics MCP Server

To see this in action, we can build a functional, production-ready MCP server in Python using the official SDK and the FastMCP interface.

This service audits host storage pressure across mount points, extracts systemd error logs defensively, publishes system load averages, and supplies an incident triage prompt.

Server Implementation (infra_sentinel.py)

import os
import shutil
import subprocess
from mcp.server.fastmcp import FastMCP, Context
from pydantic import BaseModel, Field

# Initialize server instance with metadata
mcp = FastMCP(
    name="infra-sentinel",
    description="Production-grade MCP server for Linux host diagnostics and incident triage"
)

# --- STRICT SCHEMA AND VALIDATION MODELS ---

class DiskAuditInput(BaseModel):
    alert_threshold: int = Field(
        default=85,
        ge=10,
        le=99,
        description="Disk utilization percentage threshold that triggers an alert."
    )
    mount_point: str = Field(
        default="/",
        description="Filesystem mount point to evaluate."
    )

class ServiceLogsInput(BaseModel):
    service_name: str = Field(
        description="Target systemd service name (e.g., nginx, postgresql, docker)."
    )
    lines: int = Field(
        default=30,
        ge=5,
        le=200,
        description="Number of recent log lines to pull from journald."
    )

# --- RESOURCES (PASSIVE DATA) ---

@mcp.resource("system://kernel/version")
def get_kernel_version() -> str:
    """Returns the current host kernel version and architecture."""
    return f"{os.uname().sysname} {os.uname().release} ({os.uname().machine})"

@mcp.resource("system://metrics/loadavg")
def get_system_load() -> str:
    """Returns 1, 5, and 15-minute system load averages along with logical CPU counts."""
    load1, load5, load15 = os.getloadavg()
    cpu_count = os.cpu_count() or 1
    return (
        f"Load: 1min={load1:.2f}, 5min={load5:.2f}, 15min={load15:.2f} | "
        f"Logical CPUs available={cpu_count}"
    )

# --- TOOLS (ACTIONABLE VERBS) ---

@mcp.tool()
def audit_disk_space(params: DiskAuditInput) -> dict:
    """Evaluates filesystem volume capacity and detects critical storage exhaustion."""
    try:
        total, used, free = shutil.disk_usage(params.mount_point)
        usage_pct = (used / total) * 100

        status = "CRITICAL" if usage_pct >= params.alert_threshold else "OK"

        return {
            "mount_point": params.mount_point,
            "total_gb": round(total / (1024 ** 3), 2),
            "used_gb": round(used / (1024 ** 3), 2),
            "free_gb": round(free / (1024 ** 3), 2),
            "usage_pct": round(usage_pct, 2),
            "alert_triggered": status == "CRITICAL",
            "status": status
        }
    except FileNotFoundError:
        return {"error": f"Mount point '{params.mount_point}' does not exist."}
    except Exception as exc:
        return {"error": f"Storage audit failed: {str(exc)}"}

@mcp.tool()
def extract_service_logs(params: ServiceLogsInput, ctx: Context) -> str:
    """Pulls recent journald system entries for a target service."""
    # Strict alphanumeric sanitization to prevent shell injection vectors
    if not params.service_name.replace("-", "").replace("_", "").isalnum():
        return "Security error: Service name contains disallowed characters."

    cmd = [
        "journalctl",
        f"-u={params.service_name}",
        f"-n={params.lines}",
        "--no-pager",
        "-p=err..emerg"
    ]

    try:
        result = subprocess.run(
            cmd,
            capture_output=True,
            text=True,
            timeout=5,
            check=False
        )

        output = result.stdout.strip()
        if not output:
            return f"No priority errors detected in recent logs for '{params.service_name}'."
        return output
    except subprocess.TimeoutExpired:
        return "Error: Query timed out while accessing host system journal."
    except Exception as exc:
        return f"Error executing journalctl: {str(exc)}"

# --- PROMPTS (CONTEXT RECIPES) ---

@mcp.prompt()
def triage_service_incident(service_name: str) -> str:
    """Generates structured triage guidelines for investigating host system service degradations."""
    return (
        f"You are auditing an operational fault on service '{service_name}'. Execute in this exact order:\n"
        f"1. Query 'system://metrics/loadavg' to assess immediate CPU and scheduler saturation.\n"
        f"2. Invoke 'audit_disk_space' to confirm root volume '/' has not run out of inodes or space.\n"
        f"3. Call 'extract_service_logs' to inspect recent journald failures.\n"
        f"4. Propose an actionable remediation path avoiding speculative assumptions."
    )

if __name__ == "__main__":
    # Launch stdio transport for local process communication
    mcp.run()

Client Configuration (Host / Orchestrator)

To register this server inside a client environment (such as Antigravity 2.0 or Claude Desktop), register the process definition in the client configuration file:

{
  "mcpServers": {
    "infra-sentinel": {
      "command": "python3",
      "args": [
        "/home/leif/dev/services/infra_sentinel.py"
      ],
      "env": {
        "PATH": "/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

Upon boot, the client spawns the child process, fires the initial server/discover RPC call, and registers the returned tools directly into the agent's callable execution pool.

5. Production Governance and Hardening: What Demos Ignore

Wiring MCP in a local dev setup with root permissions is trivial. Running it across production environments introduces severe operational risks that require explicit safeguards.

1. Zero-Trust Tool Execution

An MCP server must treat all LLM-generated arguments as untrusted inputs. Language models are susceptible to hallucinated parameters and indirect prompt injection attacks. If an agent reads an untrusted input containing hidden instructions, it may attempt to invoke tools with destructive payloads.

Every tool must enforce rigid schemas (via Pydantic or JSON Schema) and validate path parameters before accessing filesystems. For write or delete operations, the server must function as an enforcement gate, requiring human verification (Human-in-the-loop) before commit.

2. Context Poisoning and Schema Bloat

Every tool exposed on an MCP server injects its complete JSON Schema definition into the model's system prompt. Exposing 70 tools from a single monolithic server burns thousands of context tokens before the user enters a prompt.

Beyond token costs, prompt bloat degrades model attention and tool-routing accuracy. The recommended pattern is deploying small, domain-specific MCP servers that can be mounted modularly by the orchestrator based on workload requirements.

3. Loop Termination and Cost Controls

Granting an autonomous system access to external execution can trigger infinite retry loops upon unexpected errors. When designing remote network topologies, enforce the same boundaries we apply to billing circuit breakers in CI/CD pipelines. If an agent enters a cascading failure loop, your infrastructure must cut execution after a predetermined threshold.

The Standard Infrastructure Required

The shift to a stateless core in the July 2026 specification elevates MCP from a desktop-centric curiosity to an enterprise-ready protocol. By treating each invocation as an atomic transaction and aligning authentication with standard OAuth 2.0 resource server patterns, MCP servers now deploy and operate just like standard REST or gRPC services.

The true value of the protocol is not architectural novelty, but contract discipline: isolating non-deterministic model reasoning from the rigid, deterministic execution required by production systems.