Model Context Protocol (MCP) Architectural Overview & Protocol Specification

#1. Executive Summary & The Interoperability Imperative

The Model Context Protocol (MCP) is an open standard spearheaded by Anthropic to solve the combinatorial integration challenge between Large Language Model (LLM) agents and external computing ecosystems. Prior to MCP, connecting AI coding assistants (such as Claude Desktop, Cursor IDE, VS Code Cline, Windsurf, and Zed) to databases, cloud APIs, and developer tools required proprietary plugins, hardcoded API wrappers, or brittle custom extensions for every combination of client and tool.

MCP unifies tool and resource exposure under a standardized, client-agnostic protocol. By establishing formal message conventions over JSON-RPC 2.0, MCP enables AI agents to discover available tools at runtime, inspect environment resources, invoke operations with strict parameter validation, and stream execution progress safely within isolated workstation runtime environments.

The architecture separates concerns cleanly: client applications act as the host orchestration layer and human-in-the-loop permission boundary, while MCP servers act as lightweight adapters mediating between the host and external APIs, databases, file trees, or operating system shells.

#2. Protocol Transport Layer: STDIO vs Server-Sent Events (SSE)

The Model Context Protocol supports two primary transport implementations depending on deployment topology: Standard Input/Output (stdio) for local process execution, and Server-Sent Events (SSE) over HTTP for remote or distributed microservice architectures.

Under stdio transport, the host client application (e.g. Claude Desktop) directly spawns the MCP server as a local child subprocess using commands such as npx -y @modelcontextprotocol/server-postgres or Python uvx. The client writes newline-delimited JSON-RPC 2.0 request strings directly to the child process's stdin and reads responses from its stdout. Diagnostic logs and debug traces are directed to stderr to prevent JSON-RPC stream corruption.

Under SSE transport, the MCP server runs as a standalone HTTP server. The client establishes an initial GET request to open a long-lived text/event-stream for server-to-client notifications, while dispatching client-to-server RPC requests via HTTP POST payloads to a designated endpoint.

+-------------------------------------------------------------+
|          Model Context Protocol Stdio Framing Architecture  |
+-------------------------------------------------------------+
  Client Host (Claude Desktop / Cursor IDE)
      |
      | 1. spawn child subprocess (e.g., npx, uvx, binary)
      v
  [ Child Subprocess Stdio Boundary ]
      |
      |-- STDIN  : Newline-delimited JSON-RPC 2.0 requests -----> [MCP Server]
      |-- STDOUT : Newline-delimited JSON-RPC 2.0 responses <---- [MCP Server]
      |-- STDERR : Diagnostic logs, traces & telemetry -------> [Host Log File]
      |
  [ External Systems: PostgreSQL, GitHub API, Local Filesystem ]

Copy

#3. Fundamental Protocol Primitives: Tools, Resources, Prompts, & Logging

The Model Context Protocol structures interaction around four foundational primitives:

• Tools: Executable functions callable by the language model. Every tool defines a unique identifier, human-readable description, and a formal JSON Schema declaring expected input parameters, data types, and required fields.

• Resources: Read-only structured or binary data sources exposed via custom URI schemes (e.g. postgres://localhost/mydb/schema or file:///var/logs/app.log). Resources allow agents to inspect application state, database schemas, and documentation without mutating system state.

• Prompts: Pre-packaged, parameterized prompt templates exposed by the server to guide the AI assistant through multi-step operational workflows (e.g., automated release triage, pull request reviews).

• Logging: Standardized diagnostic telemetry channels allowing servers to stream contextual log levels (DEBUG, INFO, WARNING, ERROR) back to the client UI console for user auditing.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": {
      "sql": "SELECT id, name, status FROM deployments WHERE env = 'production' LIMIT 10;",
      "timeout_ms": 5000
    }
  }
}

Copy

#4. Protocol Lifecycle: Handshake, Discovery, & Execution

An MCP session follows a deterministic three-phase lifecycle:

1. Initialization Handshake: Upon spawning, the client sends an initialize request specifying supported protocol versions and capabilities. The server responds with its protocol version, server metadata, and declared capabilities (tools, resources, prompts, logging). The client concludes negotiation with an initialized notification.

2. Discovery Phase: The client invokes tools/list and resources/list to populate the LLM's available context matrix with tool names, parameter schemas, and resource URI templates.

3. Execution Loop: When an agent decides to invoke an operation, the client emits a tools/call request containing validated arguments. The server executes the target logic and returns a structured result containing text, embedded images, or resource references.

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Query executed successfully. 10 production deployments returned in 12ms."
      }
    ],
    "isError": false
  }
}

Copy

#5. Security Architecture & Process Isolation

Security is paramount in Model Context Protocol deployments. Because AI agents are granted access to powerful tools, MCP enforces strict security boundaries:

• Human-in-the-Loop Confirmation: Hosts like Claude Desktop require explicit human confirmation before executing tool invocations that perform write, update, or delete operations.

• Local Secret Isolation: API keys, database credentials, and session tokens are defined strictly within local client configuration files (such as claude_desktop_config.json) and injected into the subprocess via OS environment variables. Auth secrets are never transmitted across remote cloud proxies or included in LLM context windows.

• Subprocess Sandboxing: Stdio servers run under the operating system permissions of the user account. Administrators can further isolate execution using Docker containers (docker run -i --rm --read-only --user 1000:1000) or Linux systemd namespaces.

#6. Stream Framing, Buffer Limits & Diagnostic Telemetry

In production environments, both client hosts and MCP servers must adhere to robust stream framing mechanics. Standard input and output lines are delimited strictly by newline characters (\n). Servers must never emit unformatted text or arbitrary debugging statements to stdout, as this poisons the JSON-RPC parsing pipeline with parse errors (code -32700).

All diagnostic messaging, stack traces, and internal status updates must be routed to stderr or dispatched via formal notifications/message telemetry. Furthermore, host clients enforce stream buffer ceilings (typically 4MB to 16MB) to guard against runaway payload allocations when querying massive database tables or reading binary artifacts.