MCP 全解:从理解到深度开发
从 MCP 解决的问题与核心名词讲起,演示如何在 Cursor 中配置 MCP、盘点主流市场,再到优质榜单、从零开发、真实案例与最佳实践,一份较完整的 MCP 知识体系。
1. MCP 解决了哪些问题
MCP —— Model Context Protocol,模型上下文协议,是 Anthropic 设计推出的开放数据交互协议,标准化定义了应用程序与大语言模型(LLMs)之间的数据交互方式,大体上可以对标到 Web 领域的 HTTP 协议。MCP 通过三层抽象实现了模型与异构系统的标准化通讯:
- 协议元数据描述:采用声明式 Schema 描述数据源能力,使得 Client 端可通过各类标准通讯事件了解 MCP 能力,例如包含了哪些 tools、每一个 tools 是干什么的、怎么调用等等,LLM 可通过这些信息了解 MCP 能力细节,决定调用方式。
- 协议栈分层:定义控制平面(指令交互)与数据平面(上下文流)的分离式通信架构,并且支持基于 Server-Sent Events 的双向通讯。
- 松耦合架构:通过协议网关实现运行时无关性,确保跨平台互操作性。这也是 MCP 与 Function Call 的最大差异点——Function Call 往往平台强相关,而 MCP 与平台解耦,一旦开发完成即可复用到任何支持 MCP 的场景中。
🖼️ 配图待补:DlOyb4h4Qoo86UxxNpbcB1bRnAb
某种程度上,可以将 LLM 看作负责统筹指挥的大脑,而 MCP 则是负责完成各种特定功能的外部设备。LLM 能完成大部分复杂任务(例如运行游戏),但接入 MCP 之后才能完成特定需求(例如接入游戏手柄)。就像 USB 接口标准化了主机与各种外部设备、配件的通讯方式一样,MCP 也标准化了 LLM 与不同数据源和工具的交互方式。
扩展阅读:
这种标准化能极大降低 LLM 与数据源的交互成本。过去在 Langchain、Coze 等工具语境下,我们需要为各类不同数据源设计专用 Plugin 供 LLM 调用,但实现方式不够标准统一,导致需要各种定制化设计,开发效率相对较低。MCP 能很好地解决这个问题:即便脱离 Langchain 等工具语境,这类 MCP 实现依然能被复用到其他场景中,堪称 USB——走到哪插到哪,实现:
- 消除"胶合层代码":无需为每个数据源编写适配器,通过标准 MCP Endpoint 暴露原子化功能模块;
- 动态编排能力:基于 MCP 元数据实现服务发现,由 LLM 自行决定何时、何地、以何种方式调用 MCP;
- 跨生态复用:平台与插件解耦,符合 MCP 规范的组件可被复用到各种 LLM 平台(如 Cursor、Claude 等)中。
其次,MCP 作为一种标准化 AI 模型和工具集成的协议,与之前出现的 Function Call 等能力不同,其设计理念更开放也更务实:
- 简单:理想情况下,每个 Server 只做一件事情,再由 Host 搭配 LLM 处理复杂的编排任务,以此保证 Server 只需专注于特定、明确定义的功能上,简化开发;
- 可组合:每个 Server 只做一件事情,但允许 Server 之间互操作,从而组合实现更复杂功能;
- 安全性:服务器仅接收必要的上下文信息,不允许访问完整的对话历史;每个 Server 保持独立运行,当操作存在副作用(例如 Tools)时,应由用户人工确认。
2. 没有银弹
MCP 理念本身很美好,社区热度也很高,但截止发文为止,并没有出现太多杀手级的 MCP。我个人试用过不少热门 MCP,也开发过不少自己的 MCP 服务,有过不少惊艳瞬间,但多数时候也仅仅是"瞬间",大部分情况下都没能达到预期效果,让人不禁疑惑:MCP 真的有用吗?
个人感觉,业界对这事儿可能看得有点过于理想化了,目前阶段的 MCP 协议还存在许多问题:
- 调试难度非常高:相信不少同学遇到过,在 Cursor 上配置了 MCP 却没有正常运行的情况,目前缺乏合适的工具或方法能将这部分错误日志暴露出来,多数时候无从优化;
- 噪音过多:MCP 生态虽然还处于比较早期的阶段,但已经卷出了大量产品,例如 smithery 市场目前就收录了超过 2600 个实例,仅 Browser 相关的就超过 100 个,但这些产品乏善可陈,社区目前又缺乏相关评测,对用户而言试错成本还是比较高的;
- 市场理解度低:这也是许多新产品必经的阶段。概念本身有很大想象空间,但无论多好的产品,交给未经训练的用户通常无法发挥预期效果。用户可能能理解某个 MCP 的具体能力,却无法与自身面临的具体场景结合,也很难调教好 LLM 解决实际问题,需要更长的时间培养用户认知。
🖼️ 配图待补:TzqGblnEdo2E6Sx7DGNc0aKAnsz
并且,隐隐感觉正在进入一个不太好的趋势:有了一把新锤子,看啥都是钉子——为了 MCP 而 MCP,而这会产生大量质量不佳、或并无现实意义的"噪音"。
但归根结底,这毕竟是目前为止最靠谱的数据联通方案,还是非常值得关注学习的。
3. 名词解释
在学习具体内容之前,先梳理几个关键名词的含义:
MCP:Model Context Protocol,模型上下文通讯协议,最早由 Anthropic 提出,用于解决大语言模型与具体应用的交互问题。在此之前还出现过 Function Call(GPT 提出)、Plugins(各类 LLM 应用平台如 Coze)等方案解决通讯问题;MCP Client:MCP 消费方,例如 Cursor、Claude Desktop、Cline 等。Client 侧通常具有 LLM 能力,由大模型决定何时、如何调用 MCP Server;MCP Server:MCP 提供方,也就是我们需要重点学习、介绍、开发的对象。可以简单理解为胶水层(类似 BFF),负责对接下游数据源,主要用于提供各类数据、操作、Prompt 等。
需要注意的是,MCP Server 与 Client 并非泾渭分明。复杂场景中我们完全可以在一个应用程序中同时实现:对外提供 Server 服务接口,同时向下调用更多 Client 应用。
4. 在 Cursor 中配置 MCP
Cursor 很强大,算得上遥遥领先的辅助编程工具,然而其闭源架构导致社区难以自行扩展其能力。例如,开发者虽能通过自然语言交互完成代码生成,却无法将这一过程无缝嵌入到完整的 DevOps 链路中——分支管理、版本提交、PR 构建等环节仍需人工介入。
这一问题现在算是被解决了:0.45 版本之后 Cursor 接入了 MCP 机制,用户可以在这一基础上非常轻易地接入各类下游服务,例如:
- 异构数据源整合:基于 MCP 接入私域数据库,实现私有知识库的精准语义检索;
- 数据持久化操作:完成数据库事务的原子性操作;
- API 生态集成:构建跨系统的编排式工作流,具备更强的整合能力,实现从离散式代码生成向端到端工程化落地的关键跃迁。
在此基础上,Cursor 用户可通过配置实用的 MCP 矩阵,为 Cursor 补足更强大的知识获取能力与操作能力。Cursor 支持两级配置模式:
全局配置:右上角配置按钮 => MCP => Add new global MCP server,之后编辑 JSON 文件配置 MCP 服务信息即可:
🖼️ 配图待补:Vsynbwj3RoTNrXx4yVIcwv2dnKc
🖼️ 配图待补:K5xZbjknIoPgsbxxn3rcwoECnph
项目级配置:项目根目录下创建 .cursor/mcp.json,内容结构与 Global MCP JSON 一致,之后可将该文件提交到 git 中,方便团队其他成员复用。
mcp.json 文件的内容结构如下:
{
"mcpServers": {
"figma-mcp": {
"type": "http",
"url": "http://localhost:3333/sse"
},
"advanced-prompt": {
"type": "stdio",
"command": "node /path/to/start.js advanced",
"env": {}
}
}
}type:MCP 通讯方案,支持http/stdio两类;url:http 方案下的通讯端口;command:stdio 模式下的执行命令。当 LLM 决定使用该 MCP 时,会执行该命令并获取程序的标准输出;env:stdio 模式下执行命令时的环境变量,例如可以通过环境变量传递各类密钥。
配置后注意观察 Cursor 的 MCP Servers 面板:
🖼️ 配图待补:QtiVbQzZlovH7rxd7xfcRpbJnfd
- 红色表示命令运行失败,无法使用该 MCP;
- 黄色表示加载中,需要等待;
- 绿色表示运行成功,可直接使用。
5. MCP 市场
目前,业界已经出现了许多 MCP 应用市场,归类收纳了市面上许多知名 MCP 服务,以便用户快速安装调用。开发者可以直接在上面查找自己需要的工具:
-
🖼️ 配图待补:Va7Rb6vXHodKcuxA8X0cBoXJn1i
-
🖼️ 配图待补:H9DZbgEXPohECLxhkjnciBAHnM8
-
🖼️ 配图待补:TszbbgBNyoG9zFxZUwecOKLInVh
-
🖼️ 配图待补:MqzpbpkUmoiNnNxXhwYcesIinNg
-
🖼️ 配图待补:TKC4bkl2qoNU8gxAxHucymcCnhg
-
🖼️ 配图待补:VWxUbMb6xoGpGmxavmFcksQkngd
PS:内容都比较同质,我个人会更习惯使用 Smithery。
截止发文为止,业界还没有出现特别标准、大一统的市场,且 MCP 协议并不具备服务发现能力,因此目前还是需要人工筛选、应用 MCP,暂时还没有特别好的自动化路径。反而是 Google 推出的 Agent2Agent 率先实现了服务发现,未来应该会反向影响 MCP,值得期待。
6. 后续章节
对齐了基本概念之后,下面按一套较完整的逻辑,把 MCP 的使用与开发梳理成若干章节:
