上一章里，我们给大脑（LLM）接上工具、自己转循环，跑出了一个最小的智能体。那份手感想必让你明白了一件事——智能体的实力，几乎由"接上了什么样的工具"来决定。本章要从"每次都自造工具"的消耗中脱身，学习用MCP（Model Context Protocol）这一通用规范，以标准方式接入外部工具与数据。MCP 诞生于 Claude，如今正成为遍及整个行业的连接标准。
目标是"不自造工具，用标准规范安全地连接"
为什么工具连接是智能体的关键
LLM 本身，再聪明也只会"生成文字"。想知道最新的库存数，想往文件里写一行，只要没有触及外部世界的手段，就都办不到。智能体之所以能转起"调查·执行·确认"的循环，无非是因为它持有对外施加作用的工具。
也就是说，智能体的能力上限，由所连工具的质与量来决定。同一个 LLM，只有计算器的智能体，与接上了数据库·搜索·文件·内部 API 的智能体，能做的事天差地别。比起把大脑换成更高级的，把好工具精准地接上，往往能让体感的能力大幅提升——这并不稀奇。
💡 "脑子好"不如"工具齐"。 再优秀的人，工具箱空空也无从下手。智能体开发的许多时间，其实都花在"给哪些工具、怎么安全地给"的设计上。本章正是这一核心。
裸工具定义的局限
上一章里，我们亲手定义了工具。写函数，把名称·参数·说明交给 LLM，收到调用请求就执行并返回结果——这个流程本身是对的，至今也是基础。问题在于，要每次·每件工具·每个项目地重造它。
就拿"检索数据库的工具"来想。写连接处理，拼查询，整理结果，处理错误，安全地保管凭据……这一整套，在你的项目里、隔壁团队里、别的语言里，各自都在独立实现。同一件工具，全世界的开发者在一次又一次重复造轮子——这就是裸工具定义的现实。
为某个项目写的工具，被绑在那个框架、那门语言上，难以移到别处。
把 M 种工具接到 N 个智能体平台，理论上要 N×M 份连接代码。
每当接入方的规格一变，就得把散落各处的自造工具逐个去改。
这与"每种外设都要专用线缆"的年代很像。打印机有打印机专用、鼠标有鼠标专用的插口——设备越多，连接方式的种类就爆炸。只要有一个"通用插口"，这些麻烦就能一并消失。于是 MCP 登场了。
什么是 MCP ― 工具连接的通用规范
MCP（Model Context Protocol），是一套用标准方式把 AI 与外部工具·数据连接起来的开放规范。由 Anthropic 于 2024 年底面向 Claude 公开，之后各种 AI 工具与服务陆续支持。截至 2026 年，它已跨越厂商被广泛采用，在中立的运营体制下成长为行业标准。重要的是，它并非某一家公司的产品，而是谁都能实现的通用规范。
MCP 的构想一言以蔽之，就是"AI 工具连接版的 USB"。正如 USB 出现后，任何厂商的外设都能用同一个插口，支持 MCP 的工具，只要是支持 MCP 的智能体，谁都能"插上就用"。制作方与使用方遵循同一套约定，N×M 的组合地狱就被折叠成"N＋M"。
你做的智能体，或 Claude 这样的应用属于这一侧。它向服务器询问"现在接上了哪些工具？"，并调用所需的工具。
把文件操作·数据库检索·SaaS 联动等功能作为"工具"打包公开的一侧。一台服务器可持有多个工具。
两者按固定的步骤对话。客户端一连上，先从服务器收到"可用工具的清单"以及"各自的说明·参数"。LLM 看着这份清单，挑出合目的的工具去调用，服务器执行并返回结果——这一往返，无需为每件工具单独实现即可成立，正是 MCP 的关键。
客户端 → 服务器 :"告诉我有哪些可用的工具" 服务器 → 客户端 :"有 search_docs / read_file / query_db 三个，说明如下" LLM 判断 :"用 query_db，参数 {sql:"..."}" 客户端 → 服务器 :"执行 query_db" 服务器 → 客户端 :"结果是这些行数据"
公开方式主要有两种。在本机作为进程运行的本地型，与跨网络连接的远程型。本地适合自己的文件或开发用数据库，远程适合团队共享的 SaaS 联动等。两者"拿到工具清单再调用"的约定都一样，客户端侧的用法几乎没有区别。
📖 先从全貌入手。 把 MCP 的来龙去脉·术语·支持情况浅显梳理过的《什么是 MCP》讲解文章先读一遍，本章的内容就会顺理成章地进来。规范的细节与版本演进很快，实现前请务必以官方文档确认最新情况。
使用与制作 MCP 服务器
MCP 最香的地方在于，已经公开在世上的服务器可以直接拿来用。常用的工具，多半已经有人做成了 MCP 服务器。接到自造的智能体上，就能不重造轮子地让能力一口气增多。
读写指定文件夹。让它读文档、写出产物的基础。
执行 SQL 或查看 schema。对"帮我汇总"，能查询真实数据来作答。
Web 搜索或内部知识检索。成为引来最新信息与依据的"调查之手"。
任务管理·聊天·存储等。把现有的业务工具变成智能体的手脚。
接入的步骤本身很简单。启动想用的服务器（或指定 URL），在客户端侧的配置里登记服务器的位置与凭据即可。之后智能体在连接时收到工具清单，按需调用。你无需去写"数据库检索工具的内部"。把提供好的工具，按目的组合起来，才是你的活儿。
⚠️ "方便就全接上"要不得。 每加一台服务器，交给 LLM 的说明就多出对应工具的份量，判断被打散，误操作的余地也变大。只挑这个智能体真正需要的工具去接，才是基本。工具太多，反而会拉低精度。
也能自造服务器
没有现成服务器的工具——内部的自有 API、特殊的业务逻辑等——自己写一个 MCP 服务器就好。这正是 MCP 的妙处，一旦作为服务器公开，任何支持的智能体都能同样地用它。为某个项目做的工具，在下个项目里、在团队别的智能体里，都能不改写地复用。
做服务器的内容，无非是"把想提供的功能定义成工具，声明名称·参数·说明，被调用就执行处理并返回结果"。与上一章写的裸工具定义构想相同，但输出目标从"某个特定的智能体"变成了"MCP 这一通用插口"，这一点有决定性的不同。制作的力气只花一次，复用可以无数次。
🛠 想深入到实现，就看这里。 用 Claude 搭智能体或工具连接的具体代码，《Claude Agent SDK 入门》很实用。SDK 内置了处理 MCP 服务器的机制，接现成服务器还是自造，都能照官方文档的步骤推进。
给什么工具、怎么给
能把工具"接上"之后，下一个问题就是"给什么、怎么给"。这里是左右智能体质量与安全性的设计要领，也是后续各章的地基。抓住 3 条原则。
只给这项任务所需的工具·范围。"只读就够，就别给写入权限"。数据库用只读的受限账户，文件只给目标文件夹，是基本。
LLM只凭工具的说明文字来判断用不用。要具体写清"这是干什么的工具·何时用·参数的含义·不该用的场合"。含糊的说明会催生误用。
写入·删除·扣费·执行命令等无法挽回的操作，不要与只读类放在同一档。执行前的确认、对象的限制、留痕，务必配齐。
③尤其重要。"调查"类工具（搜索·查看·读取），误调用了也难成大害；而"改动"类工具（写入·删除·发送·执行），一次误操作就会造成无法挽回的后果。有意识地把只读类与写入类分开，对后者层层加护，是铁则。
| 类型 | 例子 | 风险 | 交付要点 |
|---|---|---|---|
| 只读类 | 搜索·查看·读取文件 | 较低（注意信息的处置） | 相对自由，但范围收窄 |
| 写入类 | 更新文件·写入数据库·发送 | 高（难以撤销） | 确认·限制·留痕必备 |
| 执行类 | 执行命令·外部调用·扣费 | 最高（失控·滥用的入口） | 原则加护＋插入人工审批 |
🔒 这里会在第 6 章彻底展开。 危险工具的控制、提示词注入的防范、审批流程的设计，是把智能体推上本番绕不开的主题。第 6 章《护栏与安全》会集中处理，本章你只要把"工具存在危险度差异"这份感觉带走即可。别轻易接上不可信的 MCP 服务器，也是重要的习惯。
浏览器操作等高级工具
工具当中，近来尤其受关注的是浏览器操作。看画面、点链接、填表单、按按钮——把人类在浏览器里做的操作交给智能体，就能把许多没有专用 API 的 Web 服务也变成"手脚"。作为 MCP 服务器提供浏览器操作的实现也已出现，接入的门槛在降低。
不过，这也是最强大、同时最高风险的工具之一。会直接照单全收画面上指示的危险（诱导·假信息）、意外的点击或发送、凭据外泄——上一节"执行类"的注意事项，原样适用。明智的做法是，先从浏览·取信息这类偏只读的用途起步，涉及写入的操作则谨慎地设好护栏。
🌐 能交给它到什么程度？ 浏览器操作智能体现实的实力与局限，在《AI 能把浏览器操作自动化到什么程度》里做了具体验证。把握好"并非万能，但收窄用途就实用"这个分寸，选工具时的判断就不会飘。
不限于浏览器，越是高级的工具，"能做的事"与"可能发生的事"就同比例地变大。越是交付强工具，越要把权限·说明·加护这三原则做仔细——这是本章反复传达的信息。
- 智能体的能力由所连工具的质与量决定。工具的设计常比大脑更管用。
- 裸工具自造难以复用，会陷入 N×M 的组合地狱，让人渴望一个通用插口。
- MCP 是把 AI 与外部工具标准连接的开放规范。客户端（使用方）与服务器（提供方）用同一套约定对话，是"AI 版 USB"。
- 现成的 MCP 服务器（文件/数据库/搜索/SaaS）可插上就用，自有工具可做成自造服务器复用。
- 交付原则是①权限最小化 ②说明文字的质量 ③危险工具区别对待。浏览器操作等强工具越要谨慎。
会攒工具之后，接下来是"增多智能体"的阶段。把一个智能体扛不动的活儿，交给多个智能体分担·协作的设计。下一章《多智能体设计》里，我们来学角色分工与智能体之间的协调（A2A）。