架构

Model Context Protocol (MCP) 采用客户端-主机-服务器架构，其中每个主机可以运行多个客户端实例。这种架构使用户能够在应用程序中集成AI功能，同时保持清晰的安全边界和关注点隔离。基于JSON-RPC构建，MCP提供了一个有状态的会话协议，专注于客户端和服务器之间的上下文交换和采样协调。

​

核心组件

​

主机

主机进程充当容器和协调器：

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

​

客户端

每个客户端由主机创建，并维护与服务器的隔离连接：

• 为每个服务器建立一个有状态会话
• 处理协议协商和能力交换
• 双向路由协议消息
• 管理订阅和通知
• 维护服务器之间的安全边界

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

​

服务器

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

• 通过MCP原语公开资源、工具和提示
• 独立运行，具有专注的责任
• 通过客户端接口请求采样
• 必须遵守安全约束
• 可以是本地进程或远程服务

​

设计原则

MCP基于几个关键设计原则，这些原则指导其架构和实现：

1. 服务器应该非常容易构建
   • 主机应用程序处理复杂的编排责任
   • 服务器专注于特定、定义良好的能力
   • 简单接口最小化实现开销
   • 清晰分离实现可维护代码
2. 服务器应该高度可组合
   • 每个服务器独立提供专注的功能
   • 多个服务器可以无缝组合
   • 共享协议实现互操作性
   • 模块化设计支持扩展性
3. 服务器不应该能够读取整个对话，也不能”看到”其他服务器
   • 服务器仅接收必要的上下文信息
   • 完整对话历史保留在主机中
   • 每个服务器连接保持隔离
   • 跨服务器交互由主机控制
   • 主机进程强制执行安全边界
4. 功能可以逐步添加到服务器和客户端
   • 核心协议提供最小的必需功能
   • 可以根据需要协商额外能力
   • 服务器和客户端独立演化
   • 协议设计用于未来的扩展性
   • 保持向后兼容性

​

消息类型

MCP基于JSON-RPC 2.0定义了三种核心消息类型：

• 请求：具有方法和参数的双向消息，期望响应
• 响应：与特定请求ID匹配的成功结果或错误
• 通知：不需要响应的单向消息

每种消息类型都遵循JSON-RPC 2.0规范的结构和传递语义。

​

能力协商

Model Context Protocol 使用基于能力的协商系统，客户端和服务器在初始化期间明确声明其支持的功能。能力决定会话期间哪些协议功能和原语可用。

• 服务器声明能力，如资源订阅、工具支持和提示模板
• 客户端声明能力，如采样支持和通知处理
• 双方必须在整个会话中尊重声明的能力
• 可以通过协议扩展协商额外能力

每个能力解锁会话期间使用的特定协议功能。例如：

• 实现的服务器功能必须在服务器的能力中公布
• 发出资源订阅通知需要服务器声明订阅支持
• 工具调用需要服务器声明工具能力
• 采样需要客户端在其能力中声明支持

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