MCP (Model Context Protocol) 实测：Anthropic 新协议解决了什么？

一、先给结论

MCP（Model Context Protocol）不是银弹，但它确实解决了 Function Calling 的一个核心痛点：模型侧能力与外部工具之间的集成成本太高。

如果你正在做 AI agent 开发，尤其是需要让 LLM 稳定调用多个外部数据源/API，MCP 值得纳入技术选型。但如果你只是偶尔做一个 chatbot，Function Calling 完全够用，没必要多一层抽象。

二、Function Calling 的痛点，你肯定遇到过

2024 年以来，主流模型（GPT-4o、Claude 3.5、DeepSeek V3）都支持 Function Calling，开发流程基本是这样：

  1. 你在代码里定义一个函数列表（JSON Schema）
  2. 模型返回要调哪个函数、传什么参数
  3. 你写胶水代码调用 API
  4. 把结果喂回模型，它继续生成回答

问题在于：

  • 胶水代码太多。每加一个工具（比如查数据库、读文件、调内部 CRM），都要写一遍 schema + 调用逻辑 + 错误处理。
  • 上下文爆炸。工具多的时候，system prompt 和 tool schema 很容易塞满上下文窗口，模型开始”忽略”某些工具。
  • 方言不统一。OpenAI 的 Function Calling、Anthropic 的 Tool Use、Google 的 Function Declarations，格式各有差异，换模型就要改代码。
  • 状态管理难。Function Calling 是无状态的——模型不知道你上次调了什么，除非你把历史全塞回 prompt。

简单说：Function Calling 解决的是”模型怎么调用一个函数”，没解决”一套规范怎么集成一堆工具”。

三、MCP 是什么

MCP 是 Anthropic 在 2024 年底推出的一套开放协议，设计目标是把”模型 ↔ 工具”的交互标准化。

核心架构

[Client]     [Host]     [Server]
(你的应用)  (LLM 宿主)  (外部工具/数据源)
    |           |           |
    |--- MCP 双向通信 -------|
  • Host：运行 LLM 的宿主程序（Claude Desktop、IDE 插件、你自己的后端服务）
  • Client：Host 内部与 MCP Server 建立连接的端点
  • Server：外部工具/数据源的封装，暴露出标准化的 tool/resource/prompt 接口

MCP 协议本身是 JSON-RPC over stdio/SSE，所以：

  • 同一个 Server 可以跑在本地进程、远程 HTTP、甚至容器里
  • 只要协议对，Claude、GPT、DeepSeek 都可以接

三大能力模型

能力 对应什么 举个例子
Tools 函数调用 “查数据库”、”发送邮件”
Resources 只读上下文注入 自动把公司 wiki、FAQ 塞进 prompt
Prompts 模板化指令 把常用 agent 提示词封装成可复用模板

这三者配合，基本覆盖了 agent 开发里”模型需要什么”和”外部能提供什么”的匹配问题。

四、实测：我搭了一个最小 MCP 环境

为了搞清楚 MCP 到底好不好用，我花了半天做了一个中文开发者友好的实测环境。

环境

  • Host：Claude Desktop（macOS）
  • Model：claude-3-5-sonnet
  • Server 1：SQLite 数据库查询（本地文件）
  • Server 2：本地文件系统读取
  • Server 3：自定义天气 API（国内直连，无翻墙）

测试任务

让 agent 完成这句话：“读取最近的 3 条发票记录，找出金额最高的那张，然后写一份报销摘要到我桌面的 report.txt 里。”

这个任务需要：SQLite 查询 → 排序 → 写文件 → 生成摘要。单一 Function Calling 最少要定义 3 个函数 + 多轮调用。

MCP 下的表现

Claude Desktop 里，只要启用了对应 Server，我直接说”帮我写报销摘要”，它自动走了以下流程：

  1. 调用 SQLite tool 查询最近 3 条发票
  2. 自己比较金额，找出最高的一笔
  3. 调用 File System tool，把摘要写入桌面
  4. 返回一份可读的总结给我

全程我一行胶水代码都没写。

对比：纯 Function Calling 实现

同样的任务，用 OpenAI API：

tools = [
  {"type": "function", "function": {"name": "query_invoices", ...}},
  {"type": "function", "function": {"name": "write_file", ...}}
]

然后你要写：

  • SQLite schema + query 函数
  • 文件写入函数
  • 多轮对话管理
  • 错误处理（模型参数格式不对、SQL 报错、磁盘权限）

代码量大约是 50-80 行 Python，还不包括 token 管理和 prompt 调试。

五、MCP vs Function Calling 对比

维度 Function Calling MCP
集成成本 每个工具都要写一遍 schema + 调用 Server 一旦写好，多个 Host 复用
模型依赖 每家格式不同，换模型要改 协议独立，理论上任意模型都能接
状态管理 无状态，全挤在 prompt 里 Server 保持连接状态，上下文更清爽
生态工具 自己造轮子 已有 PostgreSQL、SQLite、Filesystem、GitHub、Slack 等官方 Server
热插拔 难 容易，类似”安装插件”

六、中文开发者该关注什么

好消息

  • Anthropic 官方维护了 SQLite / PostgreSQL / Filesystem / GitHub / Slack / Google Drive 等 Server，开箱即用。
  • 社区已经在做 中文生态 Server：微信公众号、企业微信、飞书、钉钉、国内短信、支付宝 API。
  • MCP over HTTP/SSE 意味着 Server 可以跑在远程服务器上——这对挂机宝/云服务器场景特别友好。

坑和限制

  1. Anthropic 官方 Server 只支持 Anthropic 模型深度优化。你用 DeepSeek / 通义跑 MCP，虽然协议是对得通的，但提示词工程需要自己调。
  2. 国内访问问题。Claude Desktop 本身需要科学上网；SSE 模式的远程 Server 部署在境外会被墙。本地 stdio 模式最稳。
  3. Server 质量参差不齐。很多第三方 Server 的安全审计做得不好，远程模式下有注入风险。
  4. 缺少成熟的 Node.js / Python 客户端库。官方示例多，生产级 SDK 还在完善。

七、落地建议

什么场景该用 MCP

  • 你的 agent 需要连接3 个以上外部数据源（数据库 + 文件 + CRM + 知识库）
  • 你在做多用户 SaaS，每个用户有独立的数据隔离需求（MCP Server 天然支持 per-user 上下文）
  • 你想做一个可扩展的 agent 平台，允许第三方开发者”插拔”工具

什么场景不需要

  • 单个 chatbot，3 个以内工具，单一模型
  • 原型/MVP 阶段，追求最快上线
  • 团队没人懂 JSON-RPC，纯 Function Calling 更可控

给本站（AI agent 内容站）的启示

如果你的站点将来做 agent 工具市场 / 导航，MCP Server 生态是一个值得自己搭建一条链接分类：

  • 收录”官方 Server 列表”
  • 做”国内可用 Server”专题（去掉那些连不上的）
  • 写教程：”给你的 Dify / FastGPT 加 MCP 支持”

MCP 内容现在 Google 上中文资源少，现在进场能吃搜索红利。

八、总结

MCP 本质上是把 Function Calling 从”函数调用”升级为”工具集成协议“。它不改变模型能力，但大幅降低了 agent 连接外部世界的工程成本。

对于做 AI agent 应用的人：先认识它，再决定要不要入场。如果你的项目还没有超过 3 个工具集成，继续用 Function Calling；如果已经在做平台级 agent，现在就该布局。

参考：

  • Anthropic 官方文档：https://modelcontextprotocol.io
  • GitHub 仓库：https://github.com/anthropics/mcp
  • 官方 Server 列表：https://github.com/modelcontextprotocol/servers

如果你也在测 MCP，欢迎在站点社区话题区留言交流。

发表回复