01问题引入：Agent 为什么需要 MCP
这支短视频解决的是一个很典型的 Agent 工程问题：一个会规划、会写作的智能体，如果只依赖语言模型本身，它的能力上限仍然停留在“生成文本”。一旦任务要求它查询数据库、读取实时趋势、运行代码、访问内部系统，就需要一个干净的工具接入层。
Google Cloud Tech 在视频里把目标压得很具体：给一个基于 ADK 的博客写作 Agent 接入一个 MCP server，让它在写文章前先调用 Google Trends 工具，获取真实的趋势数据。这个例子不追求复杂的多智能体编排，而是专注说明 MCP 的核心价值：把 Agent 的推理过程和外部工具的执行过程拆开。
如果把 Agent 看作“大脑”，MCP 就是大脑连接外部能力的标准线缆。大脑决定要问什么，MCP 负责把请求传给外部工具，工具执行后再把 JSON 结果送回模型上下文。这样一来，Agent 不需要知道工具是 Python、Go 还是 Node 写的，也不需要把每一种工具的细节硬编码进主流程。
02核心概念：MCP 到底抽象了什么
MCP 是 Model Context Protocol 的缩写。视频里的解释很务实：它是 Agent 与外部工具之间的一套通用对话方式。工具通常作为独立进程运行，Agent 通过标准输入输出连接过去，先询问“你有哪些工具”，再基于工具返回的名称、参数 schema 和返回结构发起调用。
这背后有三个关键抽象。第一是发现：Agent 不必提前写死所有工具参数，MCP server 会在握手阶段暴露工具列表。第二是调用：Agent 发送工具名和 JSON 参数，server 执行后返回 JSON-friendly 的结果。第三是隔离：工具运行在自己的进程里，崩溃、升级、替换都不应拖垮主 Agent。
视频中提到的 ADK function tool 负责把普通 Python 函数包装成可被 Agent 识别的工具。它会读取函数签名和 docstring，生成工具名称、参数说明和返回结构。这一步减少了手写 schema 的负担，也让“本地函数工具”和“MCP 暴露的远程工具”在 Agent 眼里尽量一致。
视频的核心判断可以概括为：Agent 不需要懂工具内部实现，只要工具会说 MCP，就能被发现、被调用、被替换。
03关键步骤：从普通函数到可调用的 MCP 工具
1. 写一个 JSON 友好的业务函数
示例工具叫 Trends，职责很单一：查询 Google Trends 并返回趋势数据。这里的设计重点不是 Google Trends 本身，而是函数边界。参数要是 JSON 友好的类型，返回值也要能被序列化成 JSON 字典；这样后续 MCP server 才能稳定地把调用结果交回 Agent。
2. 用 ADK 的 FunctionTool 包装函数
视频强调 FunctionTool 做了很多隐形工作：它根据函数签名和 docstring 推导 schema，给工具一个可发现的名字，并描述参数和返回值。对工程实践来说，这一步相当于把“普通代码函数”变成“Agent 可以理解的工具契约”。
3. 创建 MCP server 并实现两个核心 handler
MCP server 的核心并不复杂。第一个 handler 负责 listing tools：当 Agent 连接上来并询问工具列表时，server 返回 Trends 工具的 schema。第二个 handler 负责 calling tool：当 Agent 指定工具名和参数时，server 检查工具名，然后把参数转发给 function tool 执行。
视频里反复强调的简洁性在这里体现得最明显：协议层的输入是“工具名 + 参数字典”，输出是“JSON 结果”。只要这条边界保持干净，业务工具内部可以继续使用自己的依赖、缓存、认证方式或错误处理策略。
4. 通过标准输入输出启动传输
最后，server 通过 stdio transport 接入 MCP。ADK 可以启动这个脚本，完成初始化握手，询问工具列表，再像调用本地工具一样调用 Trends。这种 stdio 方式特别适合本地开发、CLI 工具和编辑器插件场景，因为它不要求额外开启 HTTP 服务。
5. 把 MCP 工具挂到 root agent
在主 agent.py 中，示例把 trends_mcp 放入 root agent 的 tools 列表，和 planner、writer 等工具并列。对 Agent 来说，调用趋势工具与调用本地函数工具没有本质区别；但行为结果已经从“模型猜测”升级为“先查实时趋势，再生成内容”。
04决策矩阵：什么时候该用 MCP
| 接入方式 | 适用场景 | 优点 | 风险 / 取舍 |
|---|---|---|---|
| 直接在 Agent 代码里写函数 | 工具很少、只服务一个 Agent、部署环境单一 | 实现最快，调试路径短，不需要额外进程 | 工具与 Agent 耦合强；多语言、跨团队复用和版本化会变困难 |
| HTTP API 工具 | 已有 Web 服务，需要跨机器访问，权限体系已经成熟 | 基础设施成熟，易于监控和限流 | Agent 侧仍要维护 schema、认证和错误映射；本地工具体验较重 |
| MCP server | 希望工具可发现、可替换、可由不同语言实现，并被多个 Agent 客户端复用 | 隔离性好，schema 可发现，Agent 不必理解工具内部实现 | 需要管理工具进程、stdio/transport 生命周期和错误返回格式 |
| 多 Agent 工作流 | 任务需要角色分工、长链路协作或独立策略 | 可以把规划、执行、审查拆分成更清晰的职责 | 如果只是查一个趋势工具，多 Agent 会过度设计；先用 MCP 扩展单 Agent 更稳 |
这张表的结论是：MCP 不是为了替代所有 API，也不是为了把简单函数复杂化。它最适合用在“Agent 需要标准化接入一批外部工具”的场景，尤其是工具会不断增加、来自不同语言栈、需要被不同客户端复用的时候。
05工程拆解：这个例子真正教会了什么
第一，工具边界要比模型提示更重要。视频里的 blog-writing agent 原本能规划章节、写初稿、给替代标题，但它不知道当下发生了什么。接入趋势工具后，模型提示并没有变得更“神奇”，只是上下文里多了一份真实世界数据。这说明很多 Agent 能力提升来自工具边界，而不是继续堆提示词。
第二，工具要自描述。MCP server 在 listing tools 阶段返回名称、参数和说明，让 Agent 在运行时知道怎么构造调用。这对长期维护很关键：工具参数变更时，server 暴露的 schema 就是最新契约；Agent 客户端不应该依赖陈旧的手写说明。
第三，错误也要协议化。视频提到如果工具调用出错，server 会返回小的 JSON error，并把细节记录到 stderr。这个习惯值得保留：给 Agent 的错误要足够结构化，便于模型判断是否重试、换参数或向用户解释；给开发者的日志则可以包含更具体的堆栈和依赖信息。
第四，stdio 不是玩具。很多本地 Agent、编辑器和 CLI 环境都适合用 stdio 启动工具进程。它减少了端口管理和 HTTP 服务部署的成本，也自然形成进程隔离。等工具需要远程化时，再考虑 HTTP 或其他 transport，并不会推翻 MCP 抽象本身。
06时间戳目录
07相关推荐
如果你已经理解了 MCP 作为工具接入层的价值，可以继续看 Agent 架构、Claude Code 工程流和多 Agent 系统相关课程。下面几页和本视频的主题最接近。