在 MCP（Model Context Protocol）出现之前，AI 应用开发（尤其是基于大型语言模型 LLM 的应用）主要面临以下核心问题：
- 接口碎片化
不同数据源（数据库、API）和工具（Cursor、Cline）的调用方式不统一，开发者需为每个外部资源单独编写适配代码，重复开发严重。
- 功能局限性
LLM 仅依赖预训练静态知识，无法实时获取外部信息（如最新新闻、用户数据）或直接调用工具（IDE），导致回答滞后、缺乏实用性。
- 高开发成本
每个项目需从头设计交互逻辑，且外部接口一旦变更，整套系统需重新开发调试，维护成本陡增。
- 生态割裂
不同团队开发的工具互不兼容（如 A 公司的知识库插件无法接入 B 公司的系统），形成“工具孤岛”，阻碍技术共享。
- 安全与调试风险
非标准化通信协议易引发安全隐患（如未经验证的数据调用路径），碎片化交互方式也增加了错误排查难度。
这些问题导致 AI 应用开发效率低、扩展性差，限制了大模型的实际落地能力。而 MCP 就是为了解决上述问题而诞生的。
MCP 是什么
MCP（Model Context Protocol，模型上下文协议） 是 Anthropic 推出的开放协议，为了解决大型语言模型（LLM）与外部数据源和工具之间的通信问题。
MCP 的架构
MCP 采用客户端-服务器架构，支持双向通信和标准化 JSON 消息格式。客户端（如 Cursor 或 Claude）通过 MCP 协议调用服务器端暴露的工具（如 GitHub API 或本地数据库），无需为不同服务单独开发适配接口。例如，MCP 允许 Cursor 直接调用 Slack 的 API 读取用户需求，并自动触发代码生成流程。
在 MCP 架构中，一个主机的应用程序可以连接多个服务。我们可以看下架构图：
可以看到，MCP 包含多个组件，分别是：
MCP 主机：像 Claude Desktop、集成开发环境（Cursor）或 AI 工具这类希望通过 MCP 访问数据的程序。
MCP 客户端：与服务器保持一对一连接的协议客户端。用来接收用户的请求，并将其转换为 AI 模型可以理解的格式，同时接收 AI 模型的响应，并将其返回给用户。
MCP 服务器：通过标准化的模型上下文协议暴露特定功能的轻量级程序。负责接收 MCP Client 发送的请求，根据请求的类型，调用相应的数据源和工具，获取所需的数据，并将处理结果返回给 MCP Client。
本地数据源：计算机中的文件、数据库和服务，MCP 服务器能够安全访问。
远程服务：通过互联网（如通过 API ）可用的外部系统，MCP 服务器可以与之连接。
MCP 和 Function calling 的区别
如果你对 Function calling 不熟悉，可以参考我之前写的文章：OpenAI Function calling新功能解析。
看了上述介绍，可能会有疑惑，MCP 和 Function calling 怎么感觉是一个东西，确实他们都是用来增强 AI 模型与外部数据和工具的交互能力。两者的区别如下：
| 对比项 | MCP | Function Calling |
|---|---|---|
| 定义 | 一种标准化协议，用于 LLM 与外部数据源和工具通信 | LLM 直接调用预定义函数的能力 |
| 功能 | 1. 上下文增强 2. 协作扩展 3. 安全控制 |
1. 扩展模型功能 2. 实现模型与外部服务的交互 |
| 交互方式 | 基于 JSON-RPC 2.0 标准的结构化消息传递 | 模型生成函数调用请求，宿主执行并返回结果 |
| 调用方向 | 双向，LLM 和外部工具均可主动发起请求 | 单向，由 LLM 发起函数调用请求 |
| 依赖关系 | 独立于特定模型和函数调用机制 | 可与 MCP 等协议结合，但本身不依赖特定协议 |
| 应用场景 | 1. 智能问答 2. 企业知识库整合 3. 编程辅助 |
1. 数据查询 2. 执行特定任务 3. 与外部服务集成 |
| 示例 | 调用 MCP Server 抓取网页内容 | 模型调用天气查询函数获取实时天气信息 |
MCP 服务在线查询
目前市场社区已经贡献了很多个 MCP 服务，下面整理了几个可以在线查询 MCP 服务的网站：
今天就先介绍到这里，后面有空再写一篇介绍一下 MCP 的具体实践。
