MCP(1)：基础篇

MCP 系列分两期

• MCP(1)：基础篇
• MCP(2)：原理及实现篇

大纲

MCP(1)：基础篇

• 引言
• MCP 是什么
• MCP 解决了什么
• 应用案例
• MCP 是如何工作的
• 技术概要
• 由来
• MCP 解决的是什么
• 现状及未来可能性
• 结论

MCP(2): 原理及实现篇

• MCP 工作机制
• 通信模式
• 命令与参数
• 开发与调试
• 核心流程
• 实现自己的 MCP Server

引言

“Even the most sophisticated models are constrained by their isolation from data – trapped behind information silos and legacy systems.”
—— Anthropic

即使是最复杂的模型，也受制于与数据的隔离–被困在信息孤岛和遗留系统之后

(Anthropic ：Claude AI）

如今的大型语言模型（LLM）在真空环境中非常聪明，但一旦需要冷冻训练数据以外的信息，它们就会陷入困境。要让人工智能代理真正发挥作用，它们必须在正确的时间访问正确的上下文–无论是您的文件、知识库还是工具–甚至根据上下文采取更新文档或发送电子邮件等行动。一直以来，将人工智能模型连接到所有这些外部资源都是一件杂乱无章的临时工作。开发人员不得不为每个数据源或 API 编写自定义代码或使用专门的插件。

这使得“连接在一起”的集成变得脆弱且难以扩展。

为了简化这一过程，Anthropic 公司提出了 “模型上下文协议”（MCP），旨在为人工智能助手与数据和工具世界搭建桥梁，为许多不同的上下文来源提供支持。他们于 2024 年 11 月宣布了这一协议。当时的反应有点平淡。现在，MCP 已经成为一种趋势，主要的人工智能公司和开源社区正团结在 MCP 周围，将其视为构建代理型人工智能系统的潜在游戏规则改变者。

在我们的客户 PayPal 上也能看到 MCP 的身影。

• 订单管理和发货追踪： 可以根据用户请求创建订单、处理付款并追踪发货状态。开发者可以设计一个客服代理，利用 PayPal 工具包处理订单，并通过 PayPal 完成买家身份验证付款。例如，当用户通过对话界面明确确认购买，并且用户登录 PayPal 账户验证付款后，代理可以在 PayPal 中创建订单。
• 智能发票处理： 客服人员可以根据预定义模板或动态创建的参数生成发票，并将其发送给客户，跟踪客户的付款状态，并发送逾期付款提醒。想象一下，一个人工智能助手在服务完成后生成发票，并使用自然语言指令来定义发票详细信息。例如，人工智能助手可以根据所提供服务的详细信息生成 PayPal 发票，并通过电子邮件发送给客户。

PayPal Releases Agentic Toolkit to Accelerate Commerce | by PayPal Tech Blog Team | The PayPal Technology Blog | Apr, 2025 | Medium

GitHub - paypal/agent-toolkit: PayPal Agent

MCP 是什么

MCP 最初由 Anthropic 于 2024 年 11 月下旬开源并发布。当时，这是一个令人兴奋的想法，但并没有多少人注意到并认真对待。直到 2025 年初，MCP 才真正进入了人工智能社区的视野。

MCP 为 AI 如何查找、连接和使用外部工具制定了清晰的规则——无论是查询数据库还是运行命令。这使得模型能够超越训练数据，变得更加灵活，并能够感知周围的世界。

想象一下，你有一个通用插头 ，可以连接所有设备——这本质上就是模型上下文协议 (MCP) 之于 AI 的意义所在。MCP 是一个开放标准（想象一下“ 用于 AI 集成的 USB-C ”），它允许 AI 模型以一致的方式连接到许多不同的应用程序和数据源。

那么，这在实践中意味着什么？如果您正在使用像 Cursor 或 Windsurf 这样的 AI 编程助手，MCP 是一种共享协议 ，允许该助手代表您使用外部工具。例如，使用 MCP，AI 模型可以从数据库获取信息 ——所有这些都通过标准化接口发送自然语言指令来实现。不再需要手动切换上下文或学习每个工具的 API； MCP“翻译器”弥合了人类语言和软件命令之间的鸿沟 。

简而言之，MCP 就像为您的 AI 助手配备了一个通用遥控器 ，可以操控您所有的数字设备和服务。您的 AI 不再局限于自己的世界，而是可以安全智能地触及其他应用程序的按钮。这种通用协议意味着， 只要这些工具具备 MCP 接口， 一个 AI 就可以与数千种工具集成 ，无需为每个新应用进行自定义集成。最终，您的 AI 助手将变得更加强大，不仅能够进行对话，还能在您使用的实际软件中执行操作 。

Introduction - Model Context Protocol：MCP 是一种开放协议，它标准化了应用向 AI 应用提供上下文的方式。您可以将 MCP 视为 AI 应用的 USB-C 端口。正如 USB-C 提供了一种将设备连接到各种外围设备和配件的标准化方式一样，MCP 提供了一种将 AI 模型连接到不同数据源和工具的标准化方式。

MCP 解决了什么

如果没有 MCP，将人工智能助手与外部工具集成就有点像有一堆电器，每个电器都有不同的插头，却没有通用的插座。开发人员到处都在处理支离破碎的集成。例如，您的人工智能集成开发环境可能使用一种方法从 GitHub 获取代码，使用另一种方法从数据库获取数据，使用另一种方法自动化设计工具–每种集成都需要一个自定义适配器。这不仅耗费大量人力，而且很脆弱，无法扩展。

正如 Anthropic 所说

“even the most sophisticated models are constrained by their isolation from data - trapped behind information silos…Every new data source requires its own custom implementation, making truly connected systems difficult to scale.”

即使是最复杂的模型，也受制于与数据的隔离–被困在信息孤岛之后…每一个新的数据源都需要自己的定制实施，这使得真正的互联系统难以扩展。

MCP 为所有这些交互提供了一个通用协议，从而迎头解决了这种碎片化问题。开发人员无需为每种工具编写单独的代码，只需实施 MCP 规范，就能立即让任何会说 MCP 的人工智能访问他们的应用程序。这大大简化了集成矩阵：人工智能平台只需支持 MCP（而不是数十个 API），工具开发人员只需一次（通过 MCP 服务器）即可公开功能，而无需分别与每个人工智能供应商合作。

因此，我们的架构更加稳健，可扩展性更强。我们不再需要建立 N×M 个集成（N 个 Tool 乘以 M 个AI ），而是用一个协议来统领所有集成。正如 Anthropic 的公告所描述的那样，MCP “用单一协议取代了零散的集成”，从而以更简单、更可靠的方式让 AI 访问所需的数据和操作。这种统一性还为保持跨工具的上下文铺平了道路 —— AI 可以将知识从一个支持 MCP 的工具带到另一个工具，因为交互共享一个共同的框架。简而言之，MCP 通过引入共同的连接组织来解决集成难题，使人工智能代理能够像笔记本电脑接受 USB 设备一样轻松地插入新工具。

MCP 应用案例

出行规划

我准备 2025 年 4 月 19 日从南山前海嘉里中心出发去顺德玩，预计出发时间是早上 8 点。请你帮我规划一下一天的行程，当天的天气如何，给出具体的行程路线和交通时间。
行程重点是吃喝，吃喝有对应的点菜推荐和该店的人均价格。

同时请通过单个html页面，清晰的展示他的游玩路线。

页面干净美观。

过程

结果

shunde_trip.html

MCP 是如何工作的

MCP 的核心架构是客户端-服务器架构 ，并针对 AI 与软件之间的通信进行了专门设计。

MCP 大概的工作方式：MCP Host，比如 Claude Desktop、Cursor 这些工具，在内部实现了 MCP Client，然后MCP Client 通过标准的 MCP 协议和 MCP Server 进行交互，由各种三方开发者提供的 MCP Server 负责实现各种和三方资源交互的逻辑，比如访问数据库、浏览器、本地文件，最终再通过 标准的 MCP 协议返回给 MCP Client，最终在 MCP Host 上展示。

• MCP Hosts: 希望通过 MCP 访问数据的程序，例如 Claude Desktop、IDE 或 AI 工具
• MCP Clients：与服务器保持 1:1 连接的协议客户端
• MCP Servers：轻量级程序，每个程序都通过标准化模型上下文协议公开特定功能
• Local Data Sources: MCP 服务器可以安全访问的您的计算机文件、数据库和服务
• Remote Services：MCP 服务器可通过互联网（例如通过 API）连接到的外部系统

在 MCP 之前，AI 如何处理上下文和工具访问

timeline
    title AI 工具集成发展历程
    
    2020-2022 : 孤立的 LLM
              : 纯文本生成
              : 无外部工具访问
    
    2023 早期 : 插件时代
             : ChatGPT 插件
             : 函数调用 API
             : 定制化集成
    
    2023 晚期 : 代理框架兴起
             : LangChain, AutoGPT
             : 多步骤工作流
             : 仍然分散的集成
    
    2024 末期 : MCP 标准化
             : Anthropic 发布 MCP
             : 统一协议规范
             : 开源生态启动
    
    2025 现在 : 生态繁荣
             : 主流平台支持
             : 丰富的 Server 生态
             : 企业级应用

要了解 MCP，不妨回顾一下人工智能助手是如何发展起来的。早期的大型语言模型（LLM）本质上是聪明的文本预测器–给定一些输入，它们会根据训练数据中的模式生成一个延续。它们在回答问题或撰写文本方面功能强大，但功能孤立–它们没有使用外部工具或实时数据的内置方式。如果你要求 2020 年代的模型查看日历或获取文件，它是做不到的；它只知道如何生成文本。

2023 年是一个转折点。ChatGPT 等人工智能系统开始集成 "工具 "和插件。OpenAI 引入了函数调用和插件，允许模型执行代码、使用网页浏览或调用 API。其他框架（LangChain、AutoGPT 等）的出现，实现了多步骤 "代理 "行为。这些方法让 LLM 的行为更像一个可以计划行动的代理：例如，搜索网络、运行一些代码，然后回答问题。然而，在这些早期阶段，每次集成都是一次性的、临时性的。开发人员必须为每种工具分别布线，而且往往使用不同的方法：一种工具可能要求人工智能输出 JSON，另一种需要自定义 Python 封装，还有一种需要特殊的提示格式。人工智能没有标准的方法来了解有哪些工具可用或如何调用它们，一切都是硬编码。

到 2023 年末，社区意识到，要完全解锁人工智能代理，我们就不能再把 LLM 视为孤立的神谕。这就产生了工具增强型代理的想法–人工智能系统可以通过软件工具对世界进行观察、规划和行动。以开发者为中心的人工智能助手（如 Cursor、Cline、Windsurf 等）开始将这些代理嵌入集成开发环境和工作流中，让人工智能除了聊天之外，还能读取代码、调用编译器、运行测试等。每种工具的集成都非常强大，但却非常分散：一个代理可能通过生成 Playwright 脚本来控制网络浏览器，而另一个可能通过执行 shell 命令来控制 Git。这些交互没有统一的 “语言”，因此很难添加新工具或切换人工智能模型。

这就是 Anthropic 在 2024 年底推出 MCP 的背景。他们认识到，随着 LLM 的能力越来越强，瓶颈不再是模型的智能，而是其连接性。每个新的数据源或应用程序都需要定制的胶水代码，从而减缓了创新速度。MCP 的出现源于将人工智能与广阔的软件世界之间的接口标准化的需要–就像建立通用协议（HTTP）促成了网络的爆炸式发展一样。它代表了 LLM 演进过程中自然而然的下一步：从纯文本预测到带有工具（每个工具都是定制的）的代理，再到带有通用工具界面的代理。

集成 API

最常用的方法是为每项服务编写自定义代码或使用 SDK。例如，如果您希望 AI 代理访问 Google Drive 和 SQL 数据库，则需要分别集成 Google 的 API 和数据库驱动程序，每个 API 都有各自的身份验证、数据格式和特性。这真是太麻烦了！
相比之下，MCP 只需一个“钥匙”（协议），就能打开多扇门，而且无需更改客户端即可添加新的 MCP 服务器。

LLM Plugins (OpenAI Plugins, etc.)

2023 年引入的另一种方法是为模型提供标准化的插件规范（通常是 OpenAPI 模式），以便它可以以受控的方式调用外部 API（例如 ChatGPT 插件系统）。虽然在概念上与 MCP（标准化工具访问）类似，但它们是专有且受限的——每个插件仍然需要单独构建和托管，并且只有某些平台（如 ChatGPT 或 Bing Chat）可以使用它们。插件也倾向于专注于单向数据检索（模型调用 API 并获取信息），而不是维护持续的交互会话。
MCP 的特点是开源和通用（任何人都可以实现它，不依赖于某个 AI 提供商）并且支持丰富的双向交互。这就像 AI 和工具之间的对话，而插件通常是无状态的问答调用。

MCP 的现状及未来可能性

一句话总结：目前可玩性大于实用性，但未来可期

2025 年 3 月 8 日, LangChain发布了一篇辩论，在这场关于 MCP 的辩论中，Harrison Chase（LangChain 首席执行官）和 Nuno Campos（LangGraph 负责人）分别从不同角度阐述了他们对 MCP 的观点。

Harrison Chase （支持）

• MCP 的实用性和价值：
  • 为非控制Agent提供工具：MCP 在用户无法控制底层Agent（如 Claude Desktop、Cursor 和 Windsurf）时，能够为这些Agent提供额外的工具支持，添加默认不支持的工具。
  • 降低技术门槛：MCP 使非开发人员能够为Agent添加工具，而无需深入编辑Agent逻辑。这有助于让业务专家（非技术背景人员）也能参与Agent构建。
  • 适应未来趋势：随着基础模型的不断改进，MCP 的工具调用Agent也会变得更好。MCP 的工具定义和提示功能可以帮助Agent更好地理解和使用工具。
• MCP 的长期价值：
  • 当前 MCP 的实现形式可能不够完善，但未来有望改进，例如通过一键安装 MCP 应用程序，使其在 Web 应用中更易用。

Nuno Campos （质疑）

• MCP 的局限性和问题：
  • 工具与Agent的适配性：仅仅通过 MCP 注入工具并不能解决实际问题，因为Agent的架构和系统消息需要与工具高度适配。在实际生产环境中，Agent需要为工具定制化，否则效果不佳。
  • 可靠性问题：当前模型在调用工具时的成功率较低（约一半时间失败），即使在为特定工具集定制的Agent中也是如此。这种可靠性不足使得 MCP 的实用性大打折扣。
  • 复杂性：MCP 的协议过于复杂，例如MCP 的双向通信机制并不是一个足够好的理由，增加了实现的复杂性。当前的实现形式（如需要在本地终端运行服务器）并不实用。
• 对 MCP 能力的质疑：
  • 实际应用不足：尽管 MCP 在 网络上引起关注，但实际应用案例很少。Nuno 认为，MCP 的生态系统并没有比插件（Plugins）更大，且插件也未能成功。
  • 用户期望的挑战：即使模型性能提升，用户的期望也会随之提高。MCP 需要证明其能够满足这些不断上升的期望。

虽然 MCP 前景广阔，但它并不是一根神奇的魔杖–目前它还存在着一些局限性和挑战，开发人员和用户都应该意识到这一点。总之，虽然 MCP 功能强大，但如今使用它需要小心谨慎。这就好比有一个非常聪明的实习生，他们可以做很多事情，但需要监督和偶尔的指导。

总结

MCP 正在迅速发展成为一个强大的标准协议，它将人工智能从一个孤立的“大脑”转变为一个多功能的“行动者”。通过简化代理与外部系统的连接方式，它为更强大、互动性更强、用户友好的人工智能工作流程铺平了道路。