MCP：用工具扩展智能体

Model Context Protocol 如何标准化工具集成——服务器、传输方式，以及它何时胜过自己写胶水代码。

它解决的集成问题

在 MCP 之前，每个智能体都要为每个数据源单独写胶水层：N 个智能体 × M 个工具的对接。每次集成都在重复发明的机制发现、鉴权和结果格式化上做重复劳动。

MCP 标准化的是最后一公里：服务端通过同一套协议暴露工具、资源与提示词，客户端统一消费。工具作者只需实现一次。

宿主（智能体应用） → MCP 客户端 → MCP 服务端 → 你的数据/API

服务端可以是本地（stdio）也可以是远程（HTTP）。客户端不关心——协议是一样的。

服务端暴露的三类原语

这个区分很关键：工具由模型触发，提示词由用户触发。 搞混了就会做出「本该用户手动触发的工作流被模型自动触发」的服务端。

写好工具定义

规则与任何函数调用 schema 一致，但协议层面赌注更大——描述糟糕的工具会被每一个接入的客户端错误使用。

• 名称用动词：search_repositories 而不是 repo_thing
• 一个工具一个动作。别搞 manage_user(create|update|delete) 这种。
• 描述承担全部发现成本。要写清输入、输出与限制。
• 同时返回结构化内容与人类可读的文本形式；有些界面只渲染其中一种。

传输方式：stdio vs HTTP

stdio ——服务端作为宿主的子进程运行。简单、不走网络、继承本地权限。适合本地文件/系统访问与单用户开发工具。

HTTP（可流式） ——服务端是共享的远程服务。多用户、集中托管凭据、SaaS API 必需。需要真正的鉴权（OAuth）、限流，以及按用户隔离。

给将来需要共享凭据的东西选 stdio，迟早要重写。尽早决定。

安全提醒

接入一个 MCP 服务端，等于赋予它所在机器的权限。第三方服务端就是你选择运行的可执行代码——因为事实正是如此。

• 读源码，或者用你信任的厂商
• 凭据最小权限，不要交出主 API Key
• 本地服务端要沙箱化（限定文件路径、不通开网络）
• 广泛信任某个陌生服务端的输出之前，先审计它到底返回了什么

什么时候 MCP 是过度设计

如果你只有一个智能体和一个数据源，直接写函数就行。协议的回报来自跨客户端复用或大量集成。给单一用途的脚本套 MCP 是无收益的仪式。

满足以下任一条时才采用：这个工具需要在多个智能体应用里通用；你维护着多个不断漂移的集成；你希望别人无需定制文档就能用你的工具。