文章信息基本来源于官方网站：modelcontextprotocol.io/introductio…
大量文章都在介绍 MCP 是什么？解决什么问题？使用场景、对比 Tools Callings等。该专栏就不过多的介绍 Mcp的概念，主要对核心概念进行深入理解并实战，从实战反向学习。
一、MCP 是什么？
2024年11月底，Anthropic公司发布了全新的MCP（Model Context Protocol）协议，即模型上下文协议 。该协议是一种开放协议，支持大模型应用程序与外部数据源和工具之间的无缝集成。无论您是构建 AI 驱动的 IDE、增强聊天界面，还是创建自定义 AI 工作流，MCP 都提供了一种标准化的方式来连接 LLMs 需要的上下文。
MCP 最新规范文档：spec.modelcontextprotocol.io/specificati…
虽然大模型日新月异，但是AI应用层开发没有多少新的内容，基本上都是 Prompt、RAG、Agent。也并没有一个主流的杀手级的 AI 应用出现。那问题出在哪里了呢？
其中最重要的一个原因在于大模型与现有应用和数据的集成度比较低，无法获取多种数据，形成数据孤岛。真是应了那句 “巧妇难为无米之炊”。即使你大模型在强大，没有数据集成、工具的调用，大模型的能力无用武之地。
在 Anthropic 发布 MCP 之后将会将 AI 应用开发推向一个高度。许多大模型开发框架 Spring AI、 LangChain4j 都已经集成，包括 OpenAI 也宣布支持 MCP。
二、MCP 核心内容
以上为本文整理的关于 MCP 的核心内容思维导图，本人知识量有限，目前只能看到这些，欢迎大家补充。后续会基于该思维导图对其内容一一说明。
三、理解核心概念
对于概念的更加深入内容，还是的深入阅读MCP官方文档，这里只做简单的说明。
3.1、架构模式
MCP 遵循客户端服务器架构，具体如下图所示：
| 架构组件 | 描述 |
|---|---|
| MCP Host | 通过 MCP 访问数据的 Claude Desktop、IDE 、 AI 工具或自己开发应用等程序 |
| MCP Clients | 与服务器保持 1：1 连接的协议客户端 |
| MCP Servers | 轻量级程序，每个程序都通过标准化的 Model Context Protocol 公开特定功能 |
| Local Data Sources | MCP 服务器可以安全访问的计算机文件、数据库和服务 |
| Remote Services | MCP 服务器可以连接到的 Internet 上可用的外部系统（例如，通过 API） |
架构上也是非常简单，核心内容还是在于三部分内容：MCP Client、MCP Server 以及 Client 与 Server之间的交互协议 Transport。
3.2、MCP Client
MCP Client 有两个核心能力：Roots 和 Sampling。下面分别详细介绍
3.2.1、Roots
如何为根呢？ 较为抽象的定义：用于定义服务器可以运行的边界，另外一个疑问接踵，这个边界又是啥？在官方文档列举如下：
- Project directories 项目目录
- Repository locations 存储库位置
- API endpoints API 终端节点
- Configuration locations 配置位置
- Resource boundaries 资源边界
我相信也不是仅局限于以上几种。在我的理解上是不是可以更加抽象一层，是对 MCP Server 的一种权限上的限制。 对于如何使用 Root 以及 如何使用好 Root 在后续的文章在深入的实践。
3.2.2、Sampling
基本上所有的文章对于 Sampling 都翻译为 “采样”， 当我看到 “采样” 也是一头雾水。我们看一下其它大神对其的理解：
MCP Server 可以发起请求到 MCP Client，再MCP Client 接收到请求后，执行相应的动作，比如：人工确认或者是调用大模型等。
3.3、Transport
MCP Client 如何连接到 MCP Server，底层协议是什么？ 通信方式是什么？
3.3.1、通信方式
| 通信方式 | 介绍 | 场景 |
|---|---|---|
| STDIO | 标准输入/输出 | 本地集成和命令行工具特别有用, - 构建命令行工具; - 本地集成; - 简单的通信; -使用 shell 脚本 |
| Server-Sent-Events | 服务端推流，单向 | - 需要服务端到客户端的流式传输; - 网络受限 |
| Streamable HTTP | 流式 Http，将替换 SSE | 高效灵活，支持更大模块的分布式部署 |
至于 Streamable HTTP 和 Server-Sent-Events 之间的对比，为什么会使用 Streamable HTTP 替换 SSE，大家可以参考 github.com/modelcontex…
3.3.2、通信协议
MCP 使用 JSON-RPC 2.0 作为其传输格式。传输层负责将 MCP 协议消息转换为 JSON-RPC 格式进行传输，并将收到的 JSON-RPC 消息转换回 MCP 协议消息。
对于 JSON-RPC 协议 大家有兴趣自行研究其原理～～
3.4、MCP Server
MCP Server 可以提供三种核心能力：Resources、Templates、Tools
3.4.1、Resources
资源是模型上下文协议 （MCP） 中的核心基元，它允许服务器公开可由客户端读取并用作LLM交互上下文的数据和内容。
资源被设计为 application-controlled。这就意味着客户端应用程序可以决定如何以及何时使用它们。不同的客户端对资源的处理采用不同的方式。
MCP Server 以唯一URI标识的形式提供给 MCP Client，可以提供如下两类型的数据；
| 资源类型 | 示例 |
|---|---|
| 文本资源 | 包含 UTF-8 编码的文本数据，例如：源代码/配置文件/日志文件/JSON、XML数据/纯文本 |
| 二进制资源 | 包含 base64 编码的原始二进制数据，例如：图像、图片/PDF文件/音视频文件/其它非文本格式 |
对于资源需要了解定义资源 URI 标准格式：[protocol]://[host]/[path] 、资源的发现、使用以及资源更新通知，具体 API 请参照官方文档吧！
3.4.2、 Prompts
创建可重用的提示词模板和工作流。怎么理解这句话呢？
- 第一，服务器可预定一些提示词模板，客户端根据自己的场景，填入参数并使用它与 LLM 交互。
- 第二，将更为复杂的多步任务，封装一个工作流程的 Prompt，比如“先读日志、再查代码、最后给建议”。
提示词设计为 user-controlled，这意味着提示词由服务器向客户端公开，由用户自由选择使用。
定义提示词的标准结构如下；
{
name: string; // 提示词的唯一标识
description?: string; // 提示词的描述，必须清晰、可理解
arguments?: [ // 参数 （可选）
{
name: string; // 参数名称
description?: string; // 参数的描述，也必须清晰、可理解
required?: boolean; // 参数是否必填
}
]
}
在 MCP Server 定义提示词模板时，必须遵循如上的标准结构。对于提示的获取、使用以及更新自行参考官方文档。还有一个比较重要的知识点，就是定义动态提示词，可以嵌入用户的一些上下文信息
- 嵌入资源上下文
- 多步骤工作流
动态提示词模板可以动态填入变量，比如代码片段、错误信息，生成针对性的输出。在实际的业务场景下使用也是非常多的。
3.4.3、Tools
工具是模型上下文协议 （MCP） 中一个强大的原语，它使服务器能够向客户端公开可执行功能。通过工具，LLMs可以与外部系统交互、执行计算并在现实世界中执行作。
工具设为为 model-controlled，这意味着工具从服务器公开给客户端，然后由 AI 模型决策调用哪个工具（在循环任务中需要授权批准）。
MCP 对于工具的定义规范如下；
{
name: string; // 工具的唯一标识
description?: string; // 工具描述，清晰、易懂
inputSchema: { // 工具参数的 JSON Schema 描述
type: "object", // 参数类型
properties: { ... } // 工具的参数属性描述
}
}
四、总结
本文主要根据官方文档进行了 MCP 相关概念进行了讲解，可能还有有些晦涩难懂，后续会进行实战项目亲身体会每个概念的使用场景。另外还有一部分内容本文并未涉及，比如连接的生命周期、消息格式等等，在官方文档中都有详细说明，并不要过多的解释说明，大家自行学习！希望对你有帮助～～～～
参考 & 引用
