上一篇讲了 @tool——定义应用内的工具。这一篇讲 MCP（Model Context Protocol）——一个让工具能跨应用共享的开放协议。
上一篇的 @tool 是「私有工具」，写在自己应用里，自己用。MCP 解决的是另一类需求：我想用别人写好的工具，或者把我的工具给别人用。
MCP 解决什么问题
假设你写了一个很好的「查询公司内部知识库」工具。没有 MCP，这个工具只能在你自己的应用里用——别的应用想用，得重新实现一遍。
MCP 解决的就是这个：把工具变成跨应用共享的标准服务。你把工具实现成一个 MCP server，任何支持 MCP 的应用（包括 LangChain Agent）都能直接用，不用重新实现。
类比一下：@tool 是项目内的私有函数，MCP 是对外发布的 Web API。前者自己用，后者谁都能调。
MCP 是什么
MCP（Model Context Protocol）是 Anthropic 提的一个开放协议，标准化「应用如何向模型提供工具和上下文」。
它定义了一套标准：一个 MCP server（工具提供方）按这个协议暴露工具，一个 MCP client（工具使用方，比如你的 Agent）按这个协议调用。双方不用关心对方怎么实现，只遵循协议。
LangChain 通过 langchain-mcp-adapters 集成 MCP：把 MCP server 转成 LangChain 兼容的工具，于是 MCP 工具和原生 @tool 工具可以混用，都能塞进 Agent。
@tool vs MCP：边界在哪
| 维度 | @tool | MCP |
|---|---|---|
| 定位 | 应用内私有工具 | 跨应用共享的协议 |
| 复用 | 只在自己应用里 | 任何 MCP client 都能用 |
| 实现 | 写个函数 | 实现 MCP server |
| 适合 | 应用专属逻辑 | 通用能力、想分享给生态 |
简单判断：
- 只有我这个应用需要 → 用
@tool，简单 - 多个应用都要用，或想用别人现成的 → 走 MCP
MCP 的价值在于生态复用。你写一个「查 GitHub issue」的 MCP server，整个团队、甚至整个社区的应用都能用。这比每个应用各写一遍强得多。
MCP 不只是工具
值得注意：MCP 提供的不止是工具（Tools）。它有三种能力：
- Tools——模型可调用的函数（最常用，等同上面的工具）
- Resources——模型可读的数据源（比如一段文档、一个配置）
- Prompts——可复用的 prompt 模板
多数人只知道 MCP 的 Tools，但 Resources 和 Prompts 也是它的能力。下一篇（34）会展开讲这三种。
一个生态视角
MCP 的意义不止是「跨应用共享工具」，它在推动一个工具生态：工具从「每个应用各写各的」，变成「标准化、可发布、可复用」的模块。
未来很可能出现大量 MCP server（官方的、社区的、商业的），你的 Agent 像装插件一样组合它们——需要查 GitHub 就接 GitHub MCP，需要操作数据库就接数据库 MCP。这比每个 Agent 从零写工具高效得多。
这也是为什么 MCP 值得关注——它可能成为 Agent 时代的「工具标准」，就像 HTTP 之于 Web。
收束：MCP 让工具可共享
这一篇讲了 MCP：
- 它解决「工具跨应用共享」的问题
- 是 Anthropic 提的开放协议，server/client 架构
- LangChain 通过 mcp-adapters 集成，MCP 工具和 @tool 可混用
- @tool 是私有，MCP 是共享，按复用需求选
- MCP 不只工具，还有 Resources 和 Prompts
- 推动工具生态标准化
下一篇展开 MCP 的三种能力——Tools / Resources / Prompts 各是什么。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。我相信 AI 是程序员的最佳搭档。
如果你想跟完这套「图解 LangChain」，欢迎关注公众号 「十三Tech」。全系列 42 篇，会按认识基础、LangGraph 状态机、Agent 与 middleware、RAG 检索、Tools/MCP/记忆、生产化收束这条线更新。
