跳到主要内容

MCP 入门与实践

学到 Tool Use / Function Calling 之后，一个很自然的问题就是：

当工具不再只是本地函数，而是开始来自文件系统、数据库、设计工具、日历、代码仓库和各种外部系统时，应该怎么把这些能力接进 Agent。

MCP 讨论的就是这一层。

这篇文档主要回答 5 件事：

  • MCP 到底是什么
  • 它和普通 tool calling 的关系是什么
  • Host / Client / Server 分别在做什么
  • 一个 MCP 集成的基本流程是什么
  • 在这个模块里，它应该放在什么位置来理解

本文参考的主要资料：

1. MCP 是什么​

MCP 全称是 Model Context Protocol。

按官方定义，它是一套开放协议，用来把 AI application 和外部系统标准化地连接起来。这里的外部系统可以是：

  • 数据源
  • 工具
  • 工作流
  • 提示模板
  • 文件与资源
  • 其他应用

如果把 Tool Use 理解成“模型会不会调某个能力”，那么 MCP 讨论的是：

这些能力怎样以统一协议暴露出来，并被不同的 AI 应用复用。

可以先这样理解：

Tool Use 解决“模型怎么调用能力”，MCP 解决“能力怎么被标准化地提供出来”。

2. 为什么 MCP 会重要​

在没有 MCP 的时候，常见做法通常是：

  • 每个 Agent 框架定义自己的工具接口
  • 每个应用单独接 Notion、GitHub、Figma、日历、数据库
  • 同一套外部能力在不同客户端里重复接一次
  • 权限、日志、资源暴露方式都分散在不同实现里

系统一旦变复杂，问题就会逐渐显现：

  • 集成成本越来越高
  • 工具定义越来越碎
  • 同一个能力很难被多个 Agent 客户端共用
  • 权限边界和审计点不够集中

MCP 的价值就在这里。

它希望把“外部能力怎么暴露给模型”这件事标准化下来，让：

  • Server 负责暴露能力
  • Client 负责连接和协商
  • Host 负责权限、生命周期和用户体验

这样同一个 MCP server 理论上就可以被不同的 AI 客户端复用。

3. MCP 的核心结构​

官方文档里，MCP 的基本架构通常分成三层：

3.1 Host​

Host 是宿主应用。

它通常是：

  • 聊天客户端
  • IDE
  • Agent 平台
  • 助手型应用

Host 负责：

  • 管理用户体验
  • 管理权限与授权
  • 协调多个 client
  • 决定哪些 server 可以被连接

3.2 Client​

Client 是连接某个 MCP server 的协议端。

它负责：

  • 建立连接
  • 完成协议初始化
  • 能力协商
  • 发起资源、提示、工具相关请求
  • 处理响应与通知

同一个 Host 可以管理多个 Client，每个 client 对应一条到 server 的会话连接。

3.3 Server​

Server 是真正暴露能力的一侧。

它可以提供：

  • Resources
  • Prompts
  • Tools
  • 以及版本、能力、扩展信息

简单说：

  • Host 是应用容器
  • Client 是协议连接器
  • Server 是能力提供方

4. MCP 暴露的三类核心能力​

4.1 Resources​

Resources 适合暴露“给模型看的资料”。

例如：

  • 文件
  • 文档
  • 数据库 schema
  • 配置说明
  • 设计稿文本信息

它更偏“上下文供给”。

4.2 Prompts​

Prompts 适合暴露“可复用的提示模板”。

例如：

  • 某类分析模板
  • 某类代码审查模板
  • 某类业务流程模板

它更偏“提示资产供给”。

4.3 Tools​

Tools 适合暴露“可执行动作”。

例如：

  • 搜索
  • 创建 issue
  • 更新日历
  • 发送邮件
  • 写入数据库

它更偏“行动能力供给”。

这个划分很重要，因为它把：

  • 给模型看的东西
  • 给模型套用的模板
  • 给模型执行的动作

拆成了三种不同能力，而不是都塞进同一个工具接口里。

5. MCP 的基本交互流程​

从协议角度看，一个最典型的 MCP 会话一般会经历下面几步：

5.1 初始化​

连接建立后，client 和 server 会先进行初始化。

这里通常会完成：

  • 协议版本协商
  • 能力声明
  • 实现信息交换

5.2 能力发现​

初始化后，client 才知道当前 server 提供哪些能力，例如：

  • 哪些 resources
  • 哪些 prompts
  • 哪些 tools

5.3 读取或调用​

随后 Host 或上层 Agent 才能基于需要：

  • 读取资源
  • 取提示模板
  • 调用工具

5.4 结果回注​

工具结果或资源内容会再回到上层系统，作为：

  • 上下文
  • 工具结果
  • 后续决策输入

这和 Tool Use 的基本循环是相通的，但 MCP 把能力发现和协议协商标准化了。

6. MCP 的传输方式​

按当前规范，MCP 基于 JSON-RPC，并定义了标准传输方式。

目前最常见的是：

  • stdio
  • Streamable HTTP

6.1 stdio​

适合本地或子进程模式。

典型场景：

  • IDE 拉起本地 server
  • 桌面客户端连接本地工具
  • 代码助手接本机文件或命令能力

6.2 HTTP​

适合远程服务化接入。

典型场景：

  • 团队共享的内部能力服务
  • 远程知识库或工具网关
  • 多个客户端复用同一个 server

这层差异很实际：

  • stdio 常见于本地进程接入
  • HTTP 常见于共享服务接入

7. MCP 和 Tool Use 应该怎么配合理解​

这两者不是替代关系，而是不同层次。

7.1 Tool Use 讨论的是调用行为​

在 Tool Use / Function Calling 里，重点是：

  • 什么时候该调用工具
  • 选哪个工具
  • 参数怎么抽取
  • 调用结果怎么回注

7.2 MCP 讨论的是能力暴露方式​

在 MCP 里，重点是：

  • 工具和资源怎么被标准化提供
  • 客户端怎样发现这些能力
  • 如何统一权限、协商和协议边界

所以可以这样记：

  • Tool Use 是模型行为层
  • MCP 是能力接入层

8. MCP 适合什么场景​

8.1 适合多应用复用同一组能力​

如果同一套能力希望被：

  • 聊天客户端
  • IDE
  • Agent 平台
  • 内部自动化工具

共同使用，那 MCP 很有价值。

8.2 适合把上下文、模板、工具统一管理​

如果希望：

  • 资源暴露方式统一
  • 提示模板可复用
  • 工具注册有规范

那 MCP 会比各自手写接入更稳。

8.3 适合把本地与远程能力纳入同一套协议​

例如：

  • 本地文件与终端能力
  • 远程 API 与内部系统
  • 团队共享知识服务

都可以放进同一套接入心智模型里。

9. MCP 不适合什么场景​

9.1 不适合最小原型一开始就上重协议​

如果场景只是：

  • 一个函数
  • 一个 API
  • 一个最小 demo

那直接做本地 tool calling 往往更快。

9.2 不适合把所有问题都协议化​

MCP 的价值在于复用和标准化。

如果没有跨应用复用、没有多能力治理、没有权限和接入统一的需求，协议层可能会比问题本身更重。

10. 在这个模块里，MCP 应该放在什么位置​

放在 Tool Use / Function Calling 之后会比较顺。

原因很简单：

  • 先理解工具调用原语
  • 再理解工具怎样被统一接入

如果顺序反过来，协议层很容易变成抽象名词堆。

更稳的阅读顺序是：

  1. Tool Use / Function Calling
  2. 本文
  3. MCP vs Tool Calling
  4. A2A 入门与使用场景
  5. OpenAI Agents SDK 指南

11. MCP 和现有框架是什么关系​

这篇文档不把 MCP 当成某个单独框架，而把它看成协议层。

它更适合和这些内容一起看：

因为到了这一步，问题已经从“模型怎么回答”变成：

  • 系统怎么接外部能力
  • 工具怎么治理
  • 外部资源怎么统一暴露

12. 小结​

MCP 最适合放在“工具调用之后、工程接入之前”来理解。

它不是替代 tool calling，也不是自动让 Agent 更聪明的魔法层。

它真正解决的是：

  • 外部能力怎样被统一提供
  • 客户端怎样发现和调用这些能力
  • 资源、提示、工具怎样放进同一套协议里治理