架构

Model Context Protocol (MCP) 采用客户端-宿主-服务端架构，其中每个宿主可以运行多个客户端实例。MCP 是一种无状态协议：每个请求都是自包含的，并携带自己的协议版本和能力。 此架构使用户能够跨应用程序集成 AI 能力，同时保持清晰的安全边界和关注点隔离。MCP 构建于 JSON-RPC 之上，提供了一种专注于客户端与服务端之间上下文交换和采样协调的协议。

核心组件

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

宿主

宿主进程充当容器和协调者：

• 创建并管理多个客户端实例
• 控制客户端连接权限和生命周期
• 强制执行安全策略和同意要求
• 处理用户授权决策
• 协调 AI/LLM 集成和采样
• 管理跨客户端的上下文聚合

客户端

每个客户端由宿主创建，并与恰好一个服务端通信：

• 与恰好一个服务端通信
• 为每个请求附加协议版本和能力
• 双向路由协议消息
• 管理订阅和通知
• 维护服务端之间的安全边界

一个宿主应用程序创建并管理多个客户端，每个客户端与特定服务端具有 1:1 关系。

服务端

服务端提供专门的上下文和能力：

• 通过 MCP 原语暴露资源、工具和提示模板
• 独立运行，职责聚焦
• 在回复中通过 InputRequiredResult 请求客户端输入（采样、征询、根目录）
• 必须遵守安全约束
• 可以是本地进程或远程服务

设计原则

MCP 构建于若干关键设计原则之上，这些原则指导其架构和实现：

1. 服务端应当极其易于构建

   • 宿主应用程序处理复杂的编排职责
   • 服务端专注于特定的、定义明确的能力
   • 简单接口最小化实现开销
   • 清晰的分离使代码可维护

2. 服务端应当高度可组合

   • 每个服务端独立提供聚焦的功能
   • 多个服务端可以无缝组合
   • 共享协议实现互操作性
   • 模块化设计支持可扩展性

3. 服务端不应能够读取整个对话，也不应能够"窥视"其他服务端

   • 服务端仅接收必要的上下文信息
   • 完整对话历史保留在宿主中
   • 每个服务端保持隔离
   • 跨服务端交互由宿主控制
   • 宿主进程强制执行安全边界

4. 功能可以逐步添加到服务端和客户端

   • 核心协议提供最小必需功能
   • 可根据需要协商附加能力
   • 服务端和客户端独立演进
   • 协议设计面向未来可扩展性
   • 保持向后兼容性

能力协商

Model Context Protocol 使用基于能力的协商系统，客户端和服务端在每个请求中声明其支持的功能。客户端在每个请求的 _meta.io.modelcontextprotocol/clientCapabilities 中包含其能力。 服务端在响应 server/discover 时公布其能力，客户端可以在任何其他请求之前调用该方法以进行预先能力发现。

• 服务端声明诸如工具支持、资源订阅和提示模板等能力
• 客户端声明诸如采样支持和征询处理等能力
• 双方必须在整个交互过程中遵守已声明的能力
• 可以通过协议扩展协商附加能力

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

每个能力以逐请求的方式解锁特定的协议功能。例如：

• 已实现的服务端功能必须在服务端的能力中公布
• 接收资源更新通知需要打开一个带有目标资源 URI 的 subscriptions/listen 流
• 工具调用要求服务端声明工具能力

这种能力协商确保客户端与服务端对受支持的功能有清晰一致的理解，同时保持协议的可扩展性。