cpa_final_answer exactly once and put the complete natural user-facing answer in its answer argument. Preserve the user’s requested language, format, Markdown, detail level, and brevity inside answer; after the answer is complete, append one final line containing exactly
核心组件
宿主
宿主进程充当容器和协调者：- 创建并管理多个客户端实例
- 控制客户端连接权限和生命周期
- 强制执行安全策略和同意要求
- 处理用户授权决策
- 协调 AI/LLM 集成和采样
- 管理跨客户端的上下文聚合
客户端
每个客户端由宿主创建，并且只与一个服务器通信：- 只与一个服务器通信
- 在每个请求中附加协议版本和能力
- 双向路由协议消息
- 管理订阅和通知
- 维护服务器之间的安全边界
服务器
服务器提供专门化的上下文和能力：- 通过 MCP 基元公开资源、工具和提示
- 各自独立运行，职责明确
- 通过
InputRequiredResult在响应中请求客户端输入（采样、询问、根） - 必须遵守安全约束
- 可以是本地进程或远程服务
设计原则
MCP 建立在若干关键设计原则之上，这些原则指导其架构和 实现：-
服务器应该极易构建
- 主机应用负责处理复杂的编排职责
- 服务器专注于特定、明确定义的能力
- 简单的接口将实现开销降到最低
- 清晰的分离使代码更易维护
-
服务器应该具有高度的可组合性
- 每个服务器都独立提供聚焦的功能
- 多个服务器可以无缝组合
- 共享协议支持互操作性
- 模块化设计支持可扩展性
-
服务器不应该能够读取整个对话，也不应该“看到”其他
服务器
- 服务器只接收必要的上下文信息
- 完整的对话历史保留在主机端
- 每个服务器保持隔离
- 跨服务器交互由主机控制
- 主机进程强制执行安全边界
-
功能可以逐步添加到服务器和客户端中
- 核心协议仅提供最基本所需功能
- 可按需协商额外能力
- 服务器和客户端可独立演进
- 协议为未来扩展而设计
- 保持向后兼容性
能力协商
模型上下文协议使用一种基于能力的协商系统，客户端和 服务器会在每个请求中声明其支持的功能。客户端会在每个请求中 将其能力包含在_meta.io.modelcontextprotocol/clientCapabilities 中。
服务器会在对 server/discover 的响应中声明其能力，客户端可以在
任何其他请求之前调用该接口，以便提前发现能力。
- 服务器声明诸如工具支持、资源订阅和提示 模板之类的能力
- 客户端声明诸如采样支持和引导式输入处理之类的能力
- 双方在整个交互过程中都必须遵守已声明的能力
- 可以通过协议扩展协商额外的能力
- 已实现的 服务器功能 必须在 服务器的能力中进行声明
- 接收资源更新通知需要打开一个
带有所需资源 URI 的
subscriptions/listen流 - 工具 调用要求服务器声明工具能力