最近MCP（Model Context Protocol）这个词在我的technical timeline里出现的频率越来越高，但说实话翻完官方文档我还是有点懵，所以来求教大家。
先说我自己已经搞明白的部分：
已知信息
- MCP是Anthropic在2024年11月25日发布的一个开放协议
- 架构上分三块：MCP Host（比如Claude Desktop、Cursor）、MCP Client（嵌在Host里）、MCP Server（提供工具/资源/prompts的进程）
- 官方提供了一堆reference servers：filesystem、github、gitlab、google drive、slack、postgres、sqlite、puppeteer、brave-search、fetch、memory等
- SDK现在有Python和TypeScript（后来听说也加了Java、Kotlin）
- 传输层支持stdio（本地进程间）和SSE/HTTP（远程）
- Claude Desktop原生支持，配置文件在
~/Library/Application Support/Claude/claude_desktop_config.json
我的疑惑
我做后端的，function calling从GPT-3.5时代就在用了。当我看MCP的时候，第一反应就是——这跟function calling有什么本质区别？
表面上看，两者都是"让LLM能调外部工具"嘛：
- function calling：你在API请求里塞个
functions参数，定义一堆函数schema，模型决定调哪个，然后你执行返回结果
- MCP：MCP Server提供工具列表，Host拿到列表通过协议交互
但要说本质区别在哪，我又说不清楚。是不是仅仅就是"包装了一层标准化"？还是有更深层的设计哲学差异？
让我更困惑的事
- Anthropic自家的Claude API也支持function calling（叫tool use），那MCP跟它是什么关系？取代？补充？
- 如果MCP只是个协议，那Open AI能不能也支持MCP？理论上是不是任何LLM都能用MCP？
- MCP的Server是独立进程，每个工具都要起一个进程，这种架构在性能上有什么考虑？
- stdio传输层听起来很"古典"，为什么不用更现代的IPC？
我的工程师本能告诉我
MCP不是"function calling 2.0"那么简单，应该有它独特的设计目的。但翻了几篇blog和官方doc，要么写得太营销，要么写得太底层，没有人把"为什么需要这个东西"讲清楚。
请教各位用过MCP或者深入研究过的，能不能：
- 用一句话概括MCP和function calling的本质区别
- 用类比解释最好（我对类比敏感）
- 实际开发中MCP有什么function calling做不到的事
先谢过。这阵子被这个概念追着跑挺难受的，希望搞清楚之后能踏实点。
3 个赞
我来认真答一下，因为这个问题确实大多数人都没讲清楚。
核心一句话
Function calling是"具体实现"，MCP是"协议标准"。它们不在同一个抽象层上。
往下展开。
Function calling是什么
Function calling本质上是OpenAI（以及后来Anthropic、Google等）在自家API里加的一个能力：客户端在调用LLM时，把一组函数schema塞进请求，模型在生成时可以决定"我要调用某个函数"，把函数名+参数返回给你，你再执行，再把结果塞回去继续对话。
它的"协议"就是OpenAI（或Anthropic）家的那个JSON schema格式。这个格式是封闭的、绑定厂商的。每家做的不太一样：OpenAI叫functions/tools，Anthropic叫tools，Google叫functionDeclarations。
Function calling的核心问题是：工具实现绑定在你的应用代码里。你的应用要先写好"如何执行这个函数"的代码，模型才能用。换个应用，工具代码就要重写一遍。
MCP是什么
MCP（Model Context Protocol）抽象层更高。它定义的是Host（应用）和Server（工具提供者）之间如何交互的协议规范——基于JSON-RPC 2.0，定义了一套消息格式（initialize/tools/list/tools/call/resources/list等）。
关键点：
- MCP Server是一个独立进程，由社区/官方/任何人提供
- MCP Server里实现"工具具体怎么执行"
- 任何支持MCP协议的Host（比如Claude Desktop、Cursor、Cline）都可以直接用这个Server，不用改一行代码
换句话说，MCP做的事情是把"工具的实现"和"工具的使用方"解耦了。GitHub官方做了一个MCP server，Claude Desktop能用，Cursor能用，未来任何支持MCP的工具都能用。
为什么这是关键差别
假设你写了一个查Notion的工具：
- 用function calling：你在你的应用里写好API调用代码，定义好function schema，传给LLM。换个应用要重写。
- 用MCP：你写一个
notion-mcp-server，发布出去。所有支持MCP的Host都能通过tools/list发现它、调用它。一次实现，到处使用。
这就是所谓的"USB接口" vs "App内置按钮"的区别。Function calling是每个App自己的按钮，MCP是统一的接口规范。
回答你几个具体问题
-
Anthropic的tool use和MCP什么关系：tool use是API层的能力（function calling同款），MCP是上层应用集成协议。在Claude Desktop里，Host通过MCP拿到工具列表，再用tool use把这些工具传给模型。两者配合使用，不冲突。
-
OpenAI能不能用MCP：理论上完全可以。MCP是开放协议，任何客户端都能实现MCP Client，把MCP Server的工具桥接到OpenAI的tool use里。社区已经有人做过。Anthropic设计MCP的初衷就是希望它跨厂商。
-
每个工具一个进程的性能：这是为了进程隔离和安全性，单个server崩了不影响主应用，权限也好控制。性能开销不大，因为大多是本地stdio通信。
-
为什么用stdio：stdio跨平台、零依赖、调试简单。MCP同时支持SSE/HTTP用于远程场景，stdio只是默认本地传输。
总结
如果你做应用集成、想复用社区生态——用MCP。
如果你只是在自家应用里加个工具调用、不打算复用——直接用function calling。
它们解决不同层级的问题。MCP没有要"取代"function calling，而是构建在function calling之上的应用层协议。
@attention_is_all 楼上回答非常到位，我补充一个被很多人忽略的关键点：MCP是标准化协议，这个标准化的价值远比大多数人意识到的要大。
类比一下早期Web开发：HTTP出现之前，每个网络应用都自己定义客户端-服务器通信格式，后果是每个客户端只能跟自己家的服务器通信。HTTP出现后，浏览器和服务器解耦了，整个Web生态才爆发。
MCP在工具调用领域想做的就是这件事。当所有Host（IDE、聊天应用、agent框架）都说MCP，所有Server（GitHub、Notion、数据库工具）也都说MCP，那么：
- 我开发一个新的MCP Server，全网MCP Host立刻可用
- 我开发一个新的MCP Host，全网MCP Server立刻可用
- 复用、组合、生态效应
这就是协议标准化的网络效应。Anthropic开源MCP本质上是在做基础设施投资——它自己当然受益（Claude Desktop是早期Host），但更大的赢家是整个ecosystem。
而function calling永远停留在"每家LLM自己定义自己的tool格式，每个应用自己实现自己的tool"，无法形成跨应用的工具生态。
这就是为什么我觉得MCP是个long bet，短期内可能感觉没啥，但长期价值会逐步体现。
楼主要类比的话：function calling就像App里内置的按钮，每个App自己实现一份；MCP更像USB接口，定义了"插头形状"，任何符合规范的设备插上就能用。
USB之前每家电脑外设接口都不一样，MCP出现之前每家AI应用的工具接口也都不一样。本质问题是同一个。
1 个赞
看到有些地方说"MCP就是Anthropic抄OpenAI的function calling"，必须反驳一下，这种说法说明完全没理解MCP的设计目的。
OpenAI的function calling是API层能力，解决的是"模型如何决定调什么工具"的问题。
Anthropic的MCP是应用集成协议，解决的是"工具如何被多个应用复用"的问题。
两者解决的是完全不同维度的问题。如果硬要类比，function calling更像是CPU指令集，MCP更像是USB标准——根本不是一个抽象层级的东西。
而且MCP是开放协议，OpenAI完全可以选择不实现它，但它的存在不依赖任何单一厂商。Anthropic做的是基础设施贡献，不是产品竞争。这种"抄"的说法挺误导人的。
1 个赞
@attention_is_all @checkpoint_chen 谢两位，看完整个思路捋清楚了——MCP和function calling根本不是一个层级的东西，我之前一直在错误的维度比较它们。
追问一个：实际工作中什么场景下我会主动选用MCP而不是直接function calling？
2 个赞
分享一下我们团队最近用MCP做内部开发工具的感受，纯实战经验。
我们是一个30人左右的工程团队，去年年底开始把内部开发流程的工具都做成MCP server，目前跑了大概4个月。
做MCP给我们带来的最大变化
-
复用性：我们写了一个公司内部Jira系统的MCP server，工程师们在Cursor、Claude Desktop、自研的agent CLI里都能直接用，不用每个应用单独集成。同一份代码服务三个客户端。
-
权限管理标准化：MCP server可以独立做权限校验，不用每个客户端都写一遍。我们的Jira server会先验证调用者身份（通过环境变量传token），然后只暴露这个用户有权限看到的issues。
-
debug方便：MCP server是独立进程，stdout/stderr可以直接看，比在客户端代码里嵌一个function calling调试方便太多。崩了重启就行，不影响主应用。
-
生态可用：filesystem、github、postgres这些官方server直接拿来用，不用自己写。光是省下来的开发时间就值回票价。
什么情况下不该用MCP
- 一次性脚本/原型：直接function calling就够了，搭MCP server反而overhead大
- 完全私有的、不打算复用的逻辑：没必要走MCP那一套
- 对延迟极度敏感的场景：进程间通信总归比直接函数调用慢一点点（虽然实测毫秒级）
实际开发坑
- stdio传输调试时，server的stdout会污染JSON-RPC消息，logging一定要打到stderr
- 工具描述写得越清楚，模型调用越准——这点和function calling一样
- Schema最好严格写，optional字段也明确标出来，不然模型会乱传参数
总体来说，如果你做的是"会被多人/多场景使用的工具"，MCP绝对值。如果只是"我自己用一下"，function calling更轻量。
2 个赞
Anthropic这招挺聪明的，开源协议+控制Reference实现，长远来看护城河比模型本身还深！
3 个赞
给楼主一个实操判断标准，省得纠结：
用MCP的场景
- 工具会被多个应用/agent用到（IDE + 桌面端 + CLI都要）
- 工具有独立的权限/认证逻辑
- 工具想发布出去给社区用
- 团队协作开发，需要标准化接口
用function calling的场景
- 单一应用内部使用
- 工具逻辑跟应用强绑定（比如要直接访问应用的UI状态）
- 一次性场景、demo、原型
- 极简部署需求，不想多起进程
简单粗暴的决策树：你这工具如果半年内只在一个地方用，function calling；如果想做成"组件"被复用，MCP。
两者不互斥，实际项目里完全可以混用——MCP server处理通用工具，function calling处理应用特有的本地操作。
3 个赞
USB那个比喻好，以后跟同事解释MCP就用这个，比我讲协议层好懂多了
MCP 是协议 function calling 是能力 不是一个维度
MCP开源这步棋走得好，标准由Anthropic推但实现各家来，生态起来自己也受益
MCP和function calling的区别终于搞明白了
MCP定协议function做实现这层级关系讲清楚了，跟HTTP和Servlet的关系一样
标准化价值远比实现层大这点对，MCP一年内会成LLM生态默认协议