什么是 MCP，为什么 AI 需要一套连接协议

最近在 AI 开发里，经常会看到一个词：

MCP

它的全称是 Model Context Protocol，中文可以叫模型上下文协议。

如果只用一句话解释：

MCP 是一套让 AI 应用连接外部系统的开放协议。

这里的外部系统，可以是本地文件、数据库、搜索服务、代码仓库、设计工具、知识库，也可以是某个公司内部业务系统。

这篇笔记参考 MCP 官方入门文档，按开发者和架构学习的视角重新整理一遍。

一、为什么需要 MCP

大模型本身很强，但它有一个天然限制：

它不一定知道你当前工作现场里的东西。

比如：

• 你的本地项目文件。
• 你的私有文档。
• 你的数据库结构。
• 你的接口返回。
• 你的任务系统。
• 你的设计稿。
• 你的线上日志。

如果 AI 只能停留在聊天框里，它就只能依赖模型训练时学到的知识，或者依赖你手动复制粘贴进去的上下文。

这会带来几个问题：

• 上下文补充很麻烦。
• 私有数据很难接入。
• 实时数据很难获取。
• 外部操作很难执行。
• 每个 AI 应用都要重复适配工具。

以前如果一个 AI 应用想接 GitHub、数据库、Figma、Notion，往往要分别写一套集成逻辑。

另一个 AI 应用也想接这些东西，又要再写一遍。

结果就是：

AI 应用很多
外部系统也很多
每个产品都各接各的

MCP 想解决的，就是这层连接混乱。

它不是让模型突然变聪明，而是给 AI 应用和外部系统之间提供一个统一的连接方式。

官方文档里用了一个类比：MCP 有点像 AI 应用里的 USB-C 接口。

USB-C 不关心你接的是显示器、硬盘还是充电器，它提供的是一套标准连接方式。

MCP 也类似。

它不关心后面接的是数据库、文件系统还是业务工具，它希望这些能力可以用一套协议暴露给 AI 应用。

二、MCP 的基本架构

MCP 是一个客户端和服务端架构。

里面有三个常见角色：

• MCP Host
• MCP Client
• MCP Server

可以先这样理解：

用户
  -> AI 应用 / MCP Host
  -> MCP Client
  -> MCP Server
  -> 外部系统

MCP Host

Host 是用户真正使用的 AI 应用。

例如：

• Claude Desktop。
• Claude Code。
• VS Code。
• Cursor。
• 其他支持 MCP 的 AI 助手。

Host 负责和用户交互，也负责管理多个 MCP 连接。

MCP Client

Client 是 Host 里面负责连接某个 MCP Server 的组件。

一个 Host 可以连接多个 Server。

通常可以理解成：

一个 MCP Client 对应一个 MCP Server 连接。

例如，一个 AI 应用同时连接文件系统 MCP Server、数据库 MCP Server、知识库 MCP Server，那么它内部就会维护多条 MCP 连接。

MCP Server

Server 是能力提供方。

它可以是一个本地进程，也可以是一个远程后端服务。

比如：

• 文件系统 MCP Server：提供读写文件能力。
• 数据库 MCP Server：提供查询数据库能力。
• Git MCP Server：提供查看提交、分支、diff 的能力。
• 知识库 MCP Server：提供检索文档、读取片段、生成摘要的能力。
• 业务系统 MCP Server：把公司内部服务包装成 AI 可调用工具。

这里的 Server 不一定是传统意义上的 Web 服务器。

如果它通过 stdio 跑在本机，也可以叫 MCP Server。

如果它通过 HTTP 部署在远程，也可以叫 MCP Server。

重点不是它跑在哪里，而是它通过 MCP 协议向 AI 应用提供上下文和工具。

三、MCP Server 提供什么

MCP 里最核心的能力，可以先记三个词：

• Tools
• Resources
• Prompts

Tools：AI 可以调用的动作

Tools 是可执行能力。

比如：

• 查询数据库。
• 调用接口。
• 搜索代码。
• 创建任务。
• 读取日志。
• 触发构建。
• 检索知识库。

如果用后端开发的视角理解，Tool 有点像一个被 AI 应用发现并调用的方法。

它需要有清楚的名字、描述、输入参数和返回结果。

例如：

{
  "name": "search_knowledge_base",
  "description": "在指定知识库中检索相关文档片段",
  "inputSchema": {
    "type": "object",
    "properties": {
      "knowledgeBaseId": { "type": "string" },
      "query": { "type": "string" },
      "topK": { "type": "integer", "default": 5 }
    },
    "required": ["knowledgeBaseId", "query"]
  }
}

AI 应用看到这个工具后，就知道：

如果用户要查知识库，可以调用 search_knowledge_base。

Resources：AI 可以读取的上下文

Resources 是数据来源。

比如：

• 某个文件的内容。
• 某个数据库 schema。
• 某篇文档。
• 某个接口返回。
• 某个项目说明。
• 某个配置清单。

Resources 解决的是：

AI 可以读哪些资料？

这和 Tools 不一样。

Tools 更偏动作。

Resources 更偏上下文。

例如，一个数据库 MCP Server 可以把数据库表结构暴露成 Resource，让 AI 在写 SQL 之前先理解有哪些表、有哪些字段。

Prompts：可复用的工作模板

Prompts 是提示模板。

它可以把一些常见工作流提前整理好。

比如：

• 代码审查模板。
• 排障分析模板。
• 数据分析模板。
• 需求拆解模板。
• SQL 查询辅助模板。

这类 Prompt 不是随手一句提示词，而是把某个场景里的经验沉淀成可复用模板。

四、一次 MCP 调用大概怎么发生

一个典型过程可以这样理解。

1. 初始化连接

AI 应用启动后，根据配置连接 MCP Server。

连接时，双方会进行初始化和能力协商。

也就是先确认：

• 协议版本是否兼容。
• Server 支持哪些能力。
• Client 支持哪些能力。
• 是否支持 tools、resources、prompts。
• 是否支持工具列表更新通知。

这一步很重要。

因为 MCP 是会演进的协议，不同客户端和服务端不一定支持完全相同的能力。

2. 发现工具

连接建立后，Client 可以向 Server 发送类似 tools/list 的请求。

Server 返回自己支持的工具列表。

这一步解决的是：

你这里有什么能力？

AI 应用拿到工具列表后，可以把这些能力注册到自己的工具集合里，后续再交给模型判断是否调用。

3. 调用工具

当用户提出一个问题，模型判断需要外部能力时，AI 应用会发起工具调用。

例如：

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "search_knowledge_base",
    "arguments": {
      "knowledgeBaseId": "kb_001",
      "query": "MCP 和 RAG 有什么关系？",
      "topK": 5
    }
  }
}

Server 执行后，把结果返回给 AI 应用。

AI 应用再把工具结果放回对话上下文，让模型继续组织最终回答。

4. 返回结果

工具结果可以是一段文本，也可以包含结构化信息。

例如：

{
  "content": [
    {
      "type": "text",
      "text": "检索到 5 个相关片段，主要来自 MCP 入门文档和 RAG 架构笔记。"
    }
  ],
  "structuredContent": {
    "hits": [
      {
        "documentId": "doc_001",
        "score": 0.86,
        "title": "MCP 入门笔记"
      }
    ]
  }
}

对 AI 应用来说，好的返回结果不只是“能看懂”，还要方便继续推理和编排。

五、MCP 和普通 API 有什么区别

很多人第一次看 MCP，会觉得：

这不就是 API 吗？

某种程度上，是。

但它不是普通意义上的业务 API。

普通 API 往往是给前端页面、后端服务、脚本程序调用的。

调用方需要提前知道接口路径、参数、返回结构和业务含义。

MCP 面向的是 AI 应用。

它更强调：

• 能力发现。
• 工具描述。
• 输入 schema。
• 上下文资源。
• 协议生命周期。
• 权限和安全边界。
• 调用结果如何进入模型上下文。

所以可以这样理解：

普通 API：给程序调用的接口。
MCP：给 AI 应用发现和调用外部能力的协议。

MCP Server 背后当然可以调用普通 API。

但它会把这些 API 重新包装成 AI 更容易理解和使用的 Tools、Resources、Prompts。

六、MCP 和 Function Call 的关系

MCP 也经常会和 Function Call 混在一起。

Function Call 更偏模型调用层。

它解决的是：

模型在一次对话里，要不要调用某个函数？

MCP 更偏协议和连接层。

它解决的是：

AI 应用怎么连接外部系统，并发现有哪些工具可以用？

很多时候，AI 应用会先通过 MCP 从 Server 获取工具列表，然后把这些工具转换成模型可用的 Function Call。

也就是说：

MCP 负责连接和暴露能力。
Function Call 负责模型侧选择和调用工具。

两者不是同一个层次。

七、MCP 和 RAG 的关系

RAG 解决的是让 AI 在回答前先检索外部知识。

MCP 解决的是 AI 应用怎么连接外部系统。

它们可以组合使用。

例如，一个知识库系统可以做成 MCP Server。

它对外暴露几个工具：

• list_knowledge_bases
• search_knowledge_base
• read_document_chunk
• answer_with_sources

当 AI 应用需要回答某个问题时，可以通过 MCP 调用知识库检索工具，把检索结果拿回来，再交给模型生成回答。

这时候，RAG 是内部能力。

MCP 是对外连接协议。

可以这样理解：

RAG：怎么从知识库里找资料并增强回答。
MCP：怎么把这个知识库能力暴露给 AI 应用。

八、使用 MCP 时要注意什么

MCP 让 AI 应用能接入更多外部能力，但能力越大，边界越重要。

权限要最小化

不要一上来就给 AI 应用全部权限。

能只读，就先只读。

能限定目录，就不要开放整个文件系统。

能提供受控查询，就不要直接暴露任意 SQL。

涉及删除、修改、部署、重建索引这类操作，最好单独授权，并且加入确认机制。

工具描述要清楚

Tool 的名字、描述和参数非常重要。

模型会根据这些信息判断什么时候调用工具。

如果工具描述模糊，模型就容易误用。

例如：

不好：run
更好：search_knowledge_base

名字越清楚，AI 越容易正确调用。

返回结果要结构化

如果工具只返回一大段文本，AI 当然也能读。

但在复杂工作流里，结构化结果更稳定。

比如检索工具最好返回：

• 命中文档 ID。
• 文档标题。
• 分数。
• 片段内容。
• 来源链接。
• 可能的警告信息。

这样 AI 后续才能更好地组织答案、引用来源、判断置信度。

不要把内部接口原样暴露出去

MCP Server 不是内部 API 的简单搬运。

更好的方式，是站在 AI 应用的视角重新设计能力。

比如内部可能有很多底层接口：

• 查询文档表。
• 查询 chunk 表。
• 查询向量索引。
• 查询任务状态。

但对外暴露时，可以整理成更高层的 Tool：

search_knowledge_base

这样 AI 应用不需要理解内部细节，只需要调用一个语义清楚的能力。

九、适合用 MCP 的场景

MCP 适合用在这些场景：

• 你希望 AI 应用读取本地文件或项目代码。
• 你希望 AI 助手连接数据库、日志、监控或内部系统。
• 你希望一个工具能力被多个 AI 客户端复用。
• 你有一个知识库系统，想让外部 AI 应用调用它的检索能力。
• 你在做 Agent，需要把外部工具整理成统一协议。
• 你希望工具调用有更清楚的权限、发现和描述机制。

如果只是一个很简单的页面功能，普通 API 可能就够了。

但如果你希望这个能力被不同 AI 应用接入，MCP 就很值得考虑。

十、总结

我现在对 MCP 的理解是：

MCP 不是 AI 的大脑，而是 AI 应用连接外部能力的一层协议。

它不负责让模型变聪明。

它负责让 AI 应用更标准地连接文件、数据库、工具、知识库和业务系统。

从开发者视角看，MCP 的价值主要在于：

• 统一连接方式。
• 降低重复集成成本。
• 让外部能力可以被发现。
• 让工具调用更结构化。
• 让权限和边界更清楚。
• 让一个 MCP Server 可以服务多个 AI 应用。

所以 MCP 最重要的不是“又多了几个工具”。

而是 AI 应用和外部系统之间，终于开始有一层比较标准的连接协议。

这也是它值得学习的原因。

参考

• What is the Model Context Protocol?
• MCP Architecture overview