Model Context Protocol（MCP），中文常译为“模型上下文协议”，是一种连接 AI 应用与外部数据、工具的开放协议。它为不同应用接入同一项外部能力提供共同接口，减少为每个客户端重复编写适配层的工作。
例如，一台服务器可以提供文档检索能力；支持 MCP 的聊天应用、编程助手或 AI Agent 可以通过协议获取工具定义并调用检索。模型如何决定搜索什么、怎样利用结果，仍由应用与模型的运行机制负责。
Host、Client 与 Server
MCP 的官方架构说明区分三种角色：
- Host（宿主应用）：面向用户的 AI 应用，管理模型交互、上下文组织、连接许可和用户授权；
- Client（客户端）：Host 内负责与某一台服务器通信的连接组件；一个 Host 可以管理多个 Client；
- Server（服务器）：提供具体数据或能力的服务，可以是本地进程，也可以是远程服务。
服务器只应获得处理请求所需的信息。接入一台服务器，并不意味着它可以读取整个会话或其他服务器的数据。
三类基础能力
MCP 将常见的服务器能力区分为三类：
| 能力 | 作用 | 示例 |
|---|---|---|
| Tools（工具） | 执行操作或获取信息的可调用接口 | 搜索文档、查询业务数据 |
| Resources（资源） | 可由应用读取并纳入上下文的数据 | 文件内容、参考资料 |
| Prompts（提示词模板） | 可发现和获取的参数化消息模板 | 预设分析任务的提示内容 |
工具需要明确名称、用途和输入结构。客户端通过 tools/list 获取可用工具，通过 tools/call 调用；结果可以包含文本、结构化数据或其他受支持内容。具体消息格式见工具规范。工具返回结果之后，应用仍需判断是否成功、是否满足任务目标。
通信与版本
MCP 使用 JSON-RPC 消息。标准传输方式包括本地子进程的 stdio，以及面向 HTTP 服务的 Streamable HTTP。传输方式规定消息如何送达，具体业务能力则由服务器实现。
协议版本会影响连接和能力声明方式。以 2026-07-28 规范为例，核心采用自包含的无状态请求，版本和客户端能力随请求携带，并可通过 server/discover 提前查询服务器能力。更早版本使用初始化握手和连接级会话。阅读教程或选择 SDK 时，应核对双方支持的协议版本，不能混用不同版本的示例。
核心协议之外还可以有可选扩展。是否支持某项扩展，要看客户端和服务器的实际实现，不能仅凭“支持 MCP”推断全部能力都可用。
与工具调用和 Skills 的关系
Agent 工具调用描述模型提出操作请求、运行框架执行并回传结果的机制；MCP 为应用与外部服务器提供统一通信接口。应用可以把 MCP 工具映射为模型能理解的工具定义，模型本身不必直接处理 MCP 消息。
Agent Skills用操作说明、脚本和资源组织可复用能力，可以指导 Agent 使用 MCP 工具。大量服务器接入后的筛选、检索和按需加载，则属于Agent 工具发现的设计问题。统一协议并不要求把所有工具定义一次性放入上下文。
权限与信任边界
协议互通不能代替业务授权。Host 需要控制连接和用户同意，服务器及其后端需要检查调用者对目标资源的权限。工具说明和返回内容也可能来自不可信来源，不能因此扩大操作权限。
接入时应了解服务器会读取哪些数据、能执行哪些操作，以及是否会把数据发送到其他系统。具体访问范围取决于服务器实现和授权配置。以本站的Kloudy MCP 使用指南为例，指南说明的是该服务自身的能力与限制。