LLM 天生只能文字进、文字出。它不能查数据库、不能改文件、不能调用 API——这些能力需要 Tools 来提供。如果把 LLM 类比成大脑，Tools 就是手和脚。

但 Tools 怎么给 LLM 装上，在 MCP 出现之前和之后，是两套完全不同的思路。

一、Tools 的本质

Tools 是给 LLM 用的外接能力单元。常见的有 Search（搜索网络）、Browser（浏览网页）、File（读写文件）、Code Run（执行代码）、Database（查询数据库）。

LLM 不直接执行工具。它做的事是：读完工具描述（JSON Schema）后，输出一个标准 JSON，告诉程序该调用哪个函数、传什么参数。真正干活的是程序。

一个典型的调用过程：

LLM 输出：{"function": "search", "args": {"query": "北京到上海航班"}}
程序收到：执行 search 函数，把结果返回给 LLM
LLM 看到结果：再推理下一步，输出下一个 JSON

写 Tool Schema 的关键是 description。LLM 通过阅读描述来推理该用哪个工具，所以 description 要写场景而不是功能——不要写"搜索互联网"，而要写"当用户需要查找最新信息、实时数据时使用"。

二、纯 Function Calling 的局限

Function Calling 是各家大模型厂商 API 里的一个私有字段——OpenAI 叫 tools，Anthropic 叫 tool_use，Gemini 叫 function_declarations。它跟模型强绑定。

这意味着如果你有 N 个客户端和 M 个工具，需要写 N×M 份适配代码。3 个客户端 × 5 个工具 = 15 份适配。10 个客户端 × 50 个工具 = 500 份适配——乘法增长，规模一大就失控。

三、MCP：从乘法到加法

MCP（Model Context Protocol）由 Anthropic 于 2024 年 11 月开源。它的核心贡献不是"更好的 Function Calling"，而是把工具调用这件事从模型能力升维成系统协议。

MCP 基于 JSON-RPC 2.0 协议，定义了标准握手、能力协商、Client/Server 分离。写一份 Server，任意 Client 都能复用。复杂度从 N×M 降到 N+M——还是 10 客户端 × 50 工具，500 份变成 60 份。

MCP 怎么工作

MCP Host（AI 应用）
  └─ MCP Client（协议转换）
       └─ MCP Server 1（搜索）
       └─ MCP Server 2（文件操作）
       └─ MCP Server 3（数据库）

一次典型的 MCP 调用：

initialize（握手，确认双方能力）
  → tools/list（Client：你能提供什么工具？）
  → tools/call（Client：调用 search，参数是...）
  → 结果返回（JSON-RPC 格式）

这跟 HTTP 的工作方式如出一辙——握手建立连接 → 列出资源 → 请求资源 → 返回响应。MCP 之于 AI 工具，就像 HTTP 之于 Web。

MCP Server 的三类能力

不只是 Tools。一个 MCP Server 可以暴露：

• Tools（可执行函数）：给 LLM 调用的操作能力
• Resources（上下文数据）：可读取的外部数据源
• Prompts（预定义模板）：可加载的提示词模板

MCP vs 直接 Tools

维度	Function Calling	MCP
本质	厂商 API 的私有字段	基于 JSON-RPC 2.0 的开放协议
集成复杂度	乘法增长 N×M	加法增长 N+M
复用性	换客户端就得重写	写一份 Server，任意 Client 复用
生态	各自为政	社区共享 MCP Server 市场

MCP 不是升级，是降级

MCP 不是 Function Calling 的升级版——它做了相反的事：把工具调用从模型 API 特有的魔法行为，降级为普通的网络协议请求。任何语言、任何框架、任何模型，只要实现了 JSON-RPC 2.0，就能接入 MCP。这是它最核心的价值。

四、CLI vs MCP：什么时候用哪个

CLI 和 MCP 是两种不同的工具集成路径：

维度	CLI	MCP
实现成本	低，任何脚本都能暴露为 CLI	需要实现 JSON-RPC 协议
结构化程度	低，输出可能是纯文本	高，有标准 Schema
适用场景	一次性操作、快速验证	长期维护、需要参数化的操作

选型建议：已有 CLI 工具直接用 CLI 封装，不需要额外写 MCP Server。需要参数化、组合化、跨 Agent 复用的工具，用 MCP 暴露。

五、纯 Tools 的另一个局限

MCP 解决了工具集成的问题，但不解决工具选择的问题。当工具数量超过 15 个时，LLM 选择工具的准确率会显著下降——实验数据表明，工具从 10 个扩展到 200 个时，准确率从 95% 跌到 41%。

这个问题的解决方案是 Skill——把多个工具的调用顺序打包成一个命名概念，LLM 不需要从 200 个工具中选 4 个排好序，而是直接选 1 个 Skill。