MCP 协议入门：让 Agent 调用标准化工具

二月这几周我一直在折腾 Agent 的工具调用。起因很朴素：给一个 Agent 接第三个外部工具时，我发现自己在写第三套几乎一模一样的胶水代码——鉴权、参数拼装、错误兜底，每个工具一套。那一刻我意识到，问题不在工具多，而在没有一个标准的"插座"。

连得上，是 Agent 落地的第一堵墙

很多人讨论 Agent 时喜欢聊规划、记忆、多智能体协作，但我的体感是：真正拦住大多数原型的，是最不性感的那一步——让模型稳定地调用外部世界。没有标准之前，M 个模型接 N 个工具，理论上要写 M×N 套适配层。每换一个模型或者换一个工具，之前的胶水代码几乎全部作废。

MCP 标准化了什么

MCP（Model Context Protocol）做的事情说穿了不复杂：它把"模型这一侧"和"工具这一侧"之间的通信方式定死了。工具方实现一个 MCP server，声明自己提供哪些 tools、resources、prompts；模型侧的宿主程序作为 client 去连接。双方都只面向协议编程，M×N 就塌缩成了 M+N。

我常用的类比是：它想当工具调用领域的 USB-C。这个类比不完全准确，但方向是对的——重要的不是接口多先进，而是大家都用同一个。

一个最小的心智模型

我自己上手时，把一个工具的声明简化成三件事：名字、干什么、要什么参数。伪代码大概是这样：

tool "query_order":
description: "按单号查询订单状态"
input:
order_id: string, required
output: JSON（状态、金额、时间）

server 把这份声明暴露出去，client 拉到之后转成模型能理解的工具列表。模型决定"要不要调、传什么参"，协议负责"怎么送过去、怎么拿回来"。职责切得很干净。

踩过的两个坑

• 工具描述写得太随意。模型是靠 description 决定用不用这个工具的，描述含糊，调用就乱。我后来把每个 description 当 prompt 来打磨。
• 把 MCP 当成了万能药。它解决的是"连得上"，不解决"调得对"。参数抽取错、时机判断错，该出的问题一个不少，只是排查起来终于有统一的日志了。

协议解决的是秩序问题，不是智力问题。连得上之后，Agent 的难题才刚刚开始。

下一篇我想写写：连上之后，业务规则应该放在哪一层。这个问题我付出过一整个重构的代价。