Architecture

The Model Context Protocol (MCP) follows a client-host-server architecture where each host can run multiple client instances. MCP is a stateless protocol: every request is self-contained and carries its own protocol version and capabilities. This architecture enables users to integrate AI capabilities across applications while maintaining clear security boundaries and isolating concerns. Built on JSON-RPC, MCP provides a protocol focused on context exchange and sampling coordination between clients and servers.

Core Components

graph LR
    subgraph "Application Host Process"
        H[Host]
        C1[Client 1]
        C2[Client 2]
        C3[Client 3]
        H --> C1
        H --> C2
        H --> C3
    end

    subgraph "Local machine"
        S1[Server 1<br>Files & Git]
        S2[Server 2<br>Database]
        R1[("Local<br>Resource A")]
        R2[("Local<br>Resource B")]

        C1 --> S1
        C2 --> S2
        S1 <--> R1
        S2 <--> R2
    end

    subgraph "Internet"
        S3[Server 3<br>External APIs]
        R3[("Remote<br>Resource C")]

        C3 --> S3
        S3 <--> R3
    end

Host

The host process acts as the container and coordinator:

• Creates and manages multiple client instances
• Controls client connection permissions and lifecycle
• Enforces security policies and consent requirements
• Handles user authorization decisions
• Coordinates AI/LLM integration and sampling
• Manages context aggregation across clients

Clients

Each client is created by the host and communicates with exactly one server:

• Communicates with exactly one server
• Attaches protocol version and capabilities to every request
• Routes protocol messages bidirectionally
• Manages subscriptions and notifications
• Maintains security boundaries between servers

A host application creates and manages multiple clients, with each client having a 1:1 relationship with a particular server.

Servers

Servers provide specialized context and capabilities:

• Expose resources, tools and prompts via MCP primitives
• Operate independently with focused responsibilities
• Request client input (sampling, elicitation, roots) via InputRequiredResult within a reply
• Must respect security constraints
• Can be local processes or remote services

Design Principles

MCP is built on several key design principles that inform its architecture and implementation:

1. Servers should be extremely easy to build

   • Host applications handle complex orchestration responsibilities
   • Servers focus on specific, well-defined capabilities
   • Simple interfaces minimize implementation overhead
   • Clear separation enables maintainable code

2. Servers should be highly composable

   • Each server provides focused functionality in isolation
   • Multiple servers can be combined seamlessly
   • Shared protocol enables interoperability
   • Modular design supports extensibility

3. Servers should not be able to read the whole conversation, nor “see into” other servers

   • Servers receive only necessary contextual information
   • Full conversation history stays with the host
   • Each server maintains isolation
   • Cross-server interactions are controlled by the host
   • Host process enforces security boundaries

4. Features can be added to servers and clients progressively

   • Core protocol provides minimal required functionality
   • Additional capabilities can be negotiated as needed
   • Servers and clients evolve independently
   • Protocol designed for future extensibility
   • Backwards compatibility is maintained

Capability Negotiation

The Model Context Protocol uses a capability-based negotiation system where clients and servers declare their supported features on each request. Clients include their capabilities in _meta.io.modelcontextprotocol/clientCapabilities on every request. Servers advertise their capabilities in response to server/discover, which clients may call before any other request for up-front capability discovery.

• Servers declare capabilities like tool support, resource subscriptions, and prompt templates
• Clients declare capabilities like sampling support and elicitation handling
• Both parties must respect declared capabilities throughout the interaction
• Additional capabilities can be negotiated through extensions to the protocol

sequenceDiagram
    participant Host
    participant Client
    participant Server

    opt Discovery
        Client->>Server: server/discover
        Server-->>Client: supported versions + capabilities
    end

    loop Client Requests
        Host->>Client: User- or model-initiated action
        Client->>Server: Request (with _meta: version, clientCapabilities)
        alt Server requires client input
            Server-->>Client: InputRequiredResult (e.g. sampling/createMessage)
            Client->>Host: Forward to AI
            Host-->>Client: AI response
            Client->>Server: Original request (with input)
        end
        Server-->>Client: Response
        Client-->>Host: Update UI or respond to model
    end

    opt Subscriptions
        Client->>Server: subscriptions/listen (toolsListChanged, resourceSubscriptions, …)
        Server--)Client: notifications/subscriptions/acknowledged
        loop Stream
            Server--)Client: notifications/* (tagged with subscriptionId)
        end
    end

Each capability unlocks specific protocol features on a per-request basis. For example:

• Implemented server features must be advertised in the server’s capabilities
• Receiving resource update notifications requires opening a subscriptions/listen stream with the desired resource URIs
• Tool invocation requires the server to declare tool capabilities

This capability negotiation ensures clients and servers have a clear understanding of supported functionality while maintaining protocol extensibility.

---

Last updated Oct 08, 2026