Model Context Protocol Overview and Architecture

Overview

The Model Context Protocol (MCP) is a stateless, JSON-RPC-based standard that coordinates context exchange and sampling between AI models and external data sources. Built on a modular client-host-server architecture, MCP isolates security boundaries while allowing applications to integrate composable AI tools and resources.

Key Insights

• Strict Privacy Isolation: Servers receive only task-relevant contextual data; the host process retains full conversation history and manages all cross-server permissions.
• 1:1 Client-Server Topology: The host process creates and manages multiple client instances, where each client maintains an exclusive, bidirectional connection to a single server.
• Per-Request Capability Negotiation: Every request explicitly declares protocol versions and feature sets via metadata, enabling independent client/server evolution and backwards compatibility.
• Decoupled Orchestration: Complex workflow management, user consent, and LLM sampling are centralized in the host process, keeping server implementations lightweight and focused.

Technical Details

Core Architecture Components

MCP divides responsibilities across three distinct entities:

• Host: The primary process (e.g., an AI-enabled desktop application) that acts as the coordinator and container. It controls connection lifecycles, enforces user security and consent policies, aggregates context, and coordinates LLM sampling workflows.
• Clients: Lightweight instances generated by the host. Each client maintains a strict 1:1 relationship with a single server, routing bidirectional JSON-RPC messages, attaching metadata, and managing resource subscriptions.
• Servers: Specialized local processes or remote services that expose capabilities using three core primitives: Resources (data), Tools (executable actions), and Prompts (templated interactions). Servers operate independently and can request client-side actions—such as LLM sampling—via InputRequiredResult payloads.

Design Principles

MCP relies on four architectural principles to maintain stability and security:

1. Minimal Server Complexity: Servers expose focused, domain-specific capabilities. Complex orchestration, routing, and UI state management are handled entirely by the host application.
2. High Composability: Isolated servers can be combined seamlessly under a single host, allowing developers to modularly attach databases, local file systems, and external APIs.
3. Contextual Isolation: Servers cannot inspect other servers or view overall chat history. The host mediates all data exchange and controls contextual scope.
4. Progressive Feature Adoption: The core protocol enforces minimal mandatory requirements. Optional features (e.g., real-time resource updates or prompt templates) are dynamically negotiated without breaking core message parsing.

Capability Negotiation and Execution Flow

MCP operates statelessly over JSON-RPC. Features and extensions are established dynamically through capability negotiation:

[Host / Client]                                    [Server]
       |                                               |
       |-------------- server/discover --------------->|  (Optional upfront capability check)
       |<-- supported versions, tools, resources ------|
       |                                               |
       |--- Request (_meta: clientCapabilities) ------>|  (Standard request carrying metadata)
       |                                               |
       |<-- InputRequiredResult (e.g., sampling) ------|  (Alt: Server requests client/LLM input)
       |--- Request (with resolved input) ------------>|
       |                                               |
       |<-------------- Response Payload --------------|
       |                                               |
       |-- subscriptions/listen (URIs) --------------->|  (Opt: Subscribe to state changes)
       |<-- notifications/* (subscriptionId) ----------|  (Stream state updates)

1. Discovery Phase: Clients can issue a server/discover request to identify available server primitives (tools, prompt templates, resource URIs) and protocol versions.
2. Metadata Injection: Clients attach supported features to every outbound request within _meta.io.modelcontextprotocol/clientCapabilities.
3. Interactive Execution: If a server action requires AI sampling or user intervention, the server yields an InputRequiredResult (such as sampling/createMessage). The host processes the prompt with the LLM and re-issues the request with the required input.
4. State Subscriptions: Clients open persistent channels via subscriptions/listen to receive server-driven updates (e.g., toolsListChanged or resource state changes) tagged with a unique subscriptionId.