浅析MCP与Function Call知识： MCP是什么及其价值与核心要点、MCP Server的能力、MCP与Function Call 核心区别、Function Call 的作用本质
一、什么是 MCP
MCP（Model Context Protocol，模型上下文协议） 是一套标准化的协议，用来规范 AI 应用如何调用外部工具和数据源。
一句话定义：MCP = AI 调用外部工具的统一标准，就像 USB 统一了设备接口，MCP 统一了 AI 工具调用的接口。
用生活场景理解，类比：充电接口的演变
【没有统一标准的时代】
诺基亚 → 圆口充电器
三星 → 扁口充电器
苹果 → Lightning
华为 → Micro USB
出门带 4 根线，烦死了！
【有了 Type-C 标准后】
所有手机 → Type-C
一根线走天下！
MCP 做的是同样的事
【没有 MCP 的 AI 世界】
高德地图 API → REST + 自定义认证
天气查询 API → GraphQL + API Key
数据库查询 → SQL + 专用驱动
发送邮件 → SMTP + OAuth
每个工具都要单独对接，累死了！
【有了 MCP 标准后】
所有工具 → 统一的 MCP 协议
一套规范接所有！
为什么 MCP 重要？类比：就像以前每个手机品牌都有自己的充电口，现在统一用 Type-C，方便了所有人。
| 之前 | 现在（有 MCP） |
|---|---|
| 每个 AI 应用自己对接工具 | 统一标准，一次开发到处使用 |
| 工具开发者要适配 N 个 AI | 只需实现 MCP 协议即可 |
| AI 能力受限于内置功能 | 可无限扩展外部能力 |
二、MCP Server 能提供什么
三种能力：MCP 定义了三种能力类型，理解它们只需记住：给什么、做什么、怎么做。
1、Resources（资源）—— 给 AI “看”的东西
简单说：只读的数据源，AI 可以读取但不能修改。
常见例子：（1）文件内容（代码、文档、配置）（2）数据库记录（用户数据、订单信息）（3）API 响应（第三方服务返回的数据）
使用场景：”分析一下这个文件有什么问题” → AI 读取文件内容（Resource）→ 分析并给出建议
2、Tools（工具）—— AI 能”做”的事情
简单说：可执行的函数，AI 调用后会产生实际效果。
常见例子：（1）查询地理坐标、规划路线（2）发送邮件、创建日历事件（3）读写数据库、执行系统命令
使用场景：”帮我查北京的天气” → AI 调用天气查询工具（Tool）→ 返回实时天气数据
3、Prompts（提示词模板）—— 标准化的工作流
简单说：预定义的对话模板，用户一键触发常见任务。
常见例子：（1）“代码审查”：自动分析性能、安全、可读性（2）“生成文档”：根据代码自动生成 README（3）“Bug 诊断”：系统化排查问题
使用场景：用户选择”代码审查”模板 → 自动填充代码 → AI 按模板执行审查流程
一句话区分：
| 概念 | 一句话说明 | 最常见用途 |
|---|---|---|
| Resources | AI 读取的数据 | 读取文件、查询数据库 |
| Tools | AI 执行的操作 | 调用外部 API（最常用，占比90%） |
| Prompts | 用户触发的模板 | 标准化工作流 |
Tip：实际使用中 Tools 占 90% ，Resources 适合需要大量上下文的场景，Prompts 用于固定流程。
三、MCP 核心要点
1、MCP 的本质定位：MCP 是协议标准化，不是技术突破
MCP ≠ 新的 AI 技术
MCP = 工具调用的标准化协议
底层还是 Function Call，只是把接口规范统一了
通俗类比：
| 类比对象 | 作用 |
|---|---|
| USB 之于硬件 | 统一了充电口/数据口 |
| HTTP 之于网络 | 统一了请求响应格式 |
| MCP 之于 AI | 统一了工具调用接口 |
关键认知：MCP 不会让 AI 变聪明。该选错工具还是会选错，该提取错参数还是会提取错
2、MCP 解决的三个痛点：用一个智能客服系统的案例说明
需求：做一个能回答"我的订单什么时候到？"的 AI 客服
需要对接：
├── 内部订单系统 (REST API)
├── 顺丰物流 (SOAP XML)
├── 京东物流 (gRPC)
└── 企业微信 (自定义协议)
| 痛点 | 没有 MCP | 有了 MCP |
|---|---|---|
| 接口格式 | 写 4 套适配代码 | 统一格式，写 1 套 |
| 工具描述 | 每个开发者自己定义 | 标准化描述格式 |
| 团队协作 | 前后端反复对齐接口 | 看协议文档就行 |
3、传输方式的选择：非常实用的决策表
你的需求是什么？
├─→ 操作本地文件/数据库？ ──→ 用 STDIO
│ └─ 例：文件搜索、SQLite 查询
└─→ 调用远程服务/API？ ──→ 用 SSE
└─ 例：高德地图、天气 API、团队共享工具
一句话总结：本地用 STDIO，远程用 SSE。
4、务实的使用策略（最有价值）：三个层次的建议
（1）❌ 不要盲目追新
如果你的项目：
- 工具就几个，都是自己的 API
- 一个人开发，不需要团队协作
- 对工具调用有深度定制需求
→ 直接用 Function Call 更合适
（2）❌ 不要一棍子打死
如果需要快速接入：
- 高德地图、天气这类现成服务
- 开源社区的 MCP Server
→ MCP 能省不少事
（3）✅ 混合策略最务实：用智能客服的例子
┌──────────────────────────────────────────────┐
│ 智能客服系统 │
├──────────────────────────────────────────────┤
│ 核心业务（自己实现 Function Call） │
│ ├── 查订单状态 ← 自己的数据库 │
│ ├── 查库存信息 ← 自己的库存系统 │
│ └── 处理退款 ← 核心业务逻辑 │
├──────────────────────────────────────────────┤
│ 通用能力（用 MCP 快速接入） │
│ ├── 地图导航 ← 高德 MCP │
│ ├── 天气查询 ← 天气 MCP │
│ └── 发邮件/短信 ← 通知 MCP │
└──────────────────────────────────────────────┘
5、MCP 的真正价值：争夺 AI 工具生态的话语权，类比 USB 标准的故事
6、正确认知
| 之前可能的误解 | 正确认知 |
|---|---|
| MCP 是革命性新技术 | 只是协议标准化，底层还是 Function Call |
| 用 MCP 就不用写代码了 | 还是要写，只是格式统一了 |
| MCP 能让 AI 更准确 | 不能，该出错还会出错 |
| MCP Server 都免费 | 底层 API 该收费还是收费 |
| 必须全面拥抱 MCP | 混合策略更务实 |
这篇文章不错，可以参考：《MCP 爆火背后：是技术革命，还是精心包装的“新瓶旧酒”？》- https://aicoding.juejin.cn/post/7581888578507522075
四、MCP vs Function Call 核心区别
1、一句话说清楚关系：MCP = Function Call 的"标准化外壳"，它们不是替代关系，而是包装关系
┌─────────────────────────────────┐
│ MCP 协议 │ ← 标准化的接口规范
│ ┌─────────────────────────┐ │
│ │ Function Call │ │ ← 底层核心能力
│ │ (AI 的工具调用能力) │ │
│ └─────────────────────────┘ │
└─────────────────────────────────┘
对比表：
| 维度 | Function Call | MCP |
|---|---|---|
| 本质 | AI 的原生能力 | 协议/规范 |
| 定位 | "引擎" | "方向盘+仪表盘" |
| 作用 | 让 AI 能调用工具 | 让工具调用标准化 |
| 开发方式 | 自己定义格式 | 遵循统一格式 |
| 生态 | 各自为战 | 可复用、可共享 |
| 学习成本 | 需要读各家 API 文档 | 学一套协议通用 |
2、用案例说明 - 场景：让 AI 查天气
（1）方式一：直接用 Function Call（自己实现）
// 1. 自己定义工具格式
const tools = [{
name: "get_weather",
description: "查询天气",
parameters: {
type: "object",
properties: {
city: { type: "string", description: "城市名" }
}
}
}]
// 2. 调用 AI，让它决定是否用工具
const response = await openai.chat.completions.create({
model: "gpt-4",
messages: [{ role: "user", content: "北京天气怎么样" }],
tools: tools
})
// 3. 自己解析 AI 返回的工具调用
if (response.tool_calls) {
const args = JSON.parse(response.tool_calls[0].function.arguments)
// 4. 自己调用真实的天气 API
const weather = await fetch(`https://api.weather.com?city=${args.city}`)
// 5. 把结果返回给 AI 生成最终回复
}
特点：完全自己掌控，但每个项目都要重写一遍。
（2）方式二：通过 MCP（使用标准协议）
// 只需配置一个 MCP Server
{
"mcpServers": {
"weather": {
"url": "https://mcp.weather.com/sse"
}
}
}
然后 AI 自动就能用了，不用写调用代码。
特点：标准化，接入快，但底层还是 Function Call。
3、流程对比图
【Function Call 流程】（自己实现）
用户 → AI → 你的代码解析 → 你调用 API → 你返回结果 → AI 生成回复
↑ ↑
└──────── 全都要自己写 ─────────────────────────┘
【MCP 流程】（标准化）
用户 → AI → MCP Client → MCP Server → 真实 API
↑ ↑ ↑
│ │ └── 按协议暴露工具（别人写好的）
│ └── 按协议调用（框架处理）
└── 还是 Function Call（只是被封装了）
4、核心区别总结
| 问题 | Function Call | MCP |
|---|---|---|
| 谁来定义工具格式？ | 你自己定 | 协议规定好了 |
| 谁来写调用逻辑？ | 你自己写 | 框架/Server 处理 |
| 能复用吗？ | 不能，下个项目重写 | 能，MCP Server 可共享 |
| 能让 AI 更准？ | 取决于你的实现 | 不能，底层一样 |
5、什么时候用哪个？- 以下场景更适合用哪种就用哪种，不需要一刀切，混合策略才是最务实的
选择 Function Call（自己实现）：
├── 工具数量少（1-3个）
├── 需要深度定制逻辑
├── 对调用过程要完全掌控
└── 不需要和别人共享
选择 MCP：
├── 需要快速接入多个第三方服务
├── 团队协作，需要统一规范
├── 想复用社区已有的 MCP Server
└── 项目规模大，工具多
6、类比
Function Call = 自己组装电脑
- 完全掌控每个零件
- 但每台都要从头组装
MCP = 买品牌整机 + 标准配件
- 插上就能用
- 但底层还是那些零件
核心认知：MCP 没有让 AI 变强，只是让"接工具"这件事变简单了。
五、Function Call 作用通俗讲解
1、一句话定义：Function Call = 让 AI 从"只会说"变成"能干活"的能力
2、解决什么问题？
（1）没有 Function Call 的 AI：AI 很聪明，但是个"嘴强王者"——只会说，不会做。
你：北京现在几度？
AI：抱歉，我无法获取实时天气信息，建议你查询天气网站...
（2）有了 Function Call 的 AI：AI 有了"手"，能去查真实数据了
你：北京现在几度？
AI：（内心活动：这个问题需要查天气，我调用一下天气工具）
→ 调用 get_weather(city="北京")
→ 获得结果：15°C，晴
AI：北京现在 15°C，天气晴朗。
3、工作流程（5 步图解）- 用"查天气"完整演示：
第 1 步：用户提问
用户："北京今天天气怎么样？"
↓
第 2 步：AI 分析 + 决策
AI 收到问题，同时看到可用工具列表：
可用工具：
├── get_weather(city) - 查询天气
├── send_email(to, content) - 发邮件
└── search_web(keyword) - 搜索网页
AI 判断：这是天气问题 → 应该用 get_weather
AI 输出：调用 get_weather，参数 city="北京"
↓
第 3 步：执行函数
你的代码接收到 AI 的"指令"：
{
"function": "get_weather",
"arguments": { "city": "北京" }
}
然后调用真实的天气 API，获得结果：{ "temp": "15°C", "weather": "晴", "wind": "北风3级" }
↓
第 4 步：结果返回给 AI
把天气数据塞回对话："工具执行结果：北京，15°C，晴，北风3级"
↓
第 5 步：AI 生成最终回复
AI 根据工具返回的数据，组织自然语言回复："北京今天天气晴朗，气温 15°C，有北风 3 级，适合户外活动，记得带件薄外套哦~"
代码示例（简化版）
// 1️⃣ 定义工具（告诉 AI 有什么能力可用）
const tools = [{
type: "function",
function: {
name: "get_weather",
description: "查询指定城市的实时天气",
parameters: {
type: "object",
properties: {
city: {
type: "string",
description: "城市名称，如：北京、上海"
}
},
required: ["city"]
}
}
}]
// 2️⃣ 调用 AI（带上工具列表）
const response = await openai.chat.completions.create({
model: "gpt-4",
messages: [{ role: "user", content: "北京天气怎么样" }],
tools: tools // ← 告诉 AI 可以用这些工具
})
// 3️⃣ AI 返回的不是文字，而是"调用指令"
// response.choices[0].message.tool_calls = [{
// function: {
// name: "get_weather",
// arguments: '{"city": "北京"}'
// }
// }]
// 4️⃣ 你来执行真实调用
const args = JSON.parse(response.choices[0].message.tool_calls[0].function.arguments)
const weatherData = await 调用真实天气API(args.city)
// 5️⃣ 把结果喂回 AI，让它生成最终回复
const finalResponse = await openai.chat.completions.create({
model: "gpt-4",
messages: [
{ role: "user", content: "北京天气怎么样" },
{ role: "assistant", tool_calls: [...] },
{ role: "tool", content: JSON.stringify(weatherData) } // ← 工具结果
]
})
// 最终得到自然语言回复
console.log(finalResponse.choices[0].message.content)
// → "北京今天 15°C，天气晴朗，适合出行~"
4、核心要点
（1）AI 做什么？
✅ 理解用户意图
✅ 决定用哪个工具
✅ 提取参数（从用户的话里）
✅ 根据结果生成回复
❌ 不执行真实 API 调用（这是你的代码做的）
（2）你的代码做什么？
✅ 定义有哪些工具可用
✅ 接收 AI 的调用指令
✅ 执行真实的 API/数据库操作
✅ 把结果返回给 AI
5、形象类比：餐厅点餐
顾客（用户） ："我要一份宫保鸡丁"
服务员（AI） ：理解需求，写菜单
→ 下单：宫保鸡丁 × 1
厨房（你的代码）：收到订单，真正去做菜
→ 返回：一盘宫保鸡丁
服务员（AI） ：把菜端给顾客，说"您的菜好了"
AI 是服务员：听懂需求、决定点什么、优雅地呈现结果
你的代码是厨房：真正干活的地方
6、常见问题
（1）AI 能直接调用 API 吗？
不能。AI 只能"说"要调用什么，真正的执行是你的代码完成的
（2）AI 怎么知道该用哪个工具？
靠你提供的工具描述。描述写得越清楚，AI 判断越准
// 好的描述
description: "查询指定城市的实时天气，返回温度、天气状况、风力等"
// 差的描述
description: "天气" // AI 可能搞不清什么时候该用
（3）AI 会判断错吗？
会。这是 Function Call 的主要问题：（1）工具太多时容易选错（2）复杂参数容易提取不准（3）一个问题涉及多个工具时处理困难
7、总结：Function Call 的本质
┌─────────────┐ ┌─────────────┐
│ 大脑 │ ──────► │ 手脚 │
│ (AI) │ 指令 │ (你的代码) │
└─────────────┘ └─────────────┘
│ │
│ 理解 + 决策 │ 执行 + 返回
↓ ↓
"要查天气" 真的去查天气
= 让 AI 从"只会说"升级到"能指挥干活"
浙公网安备 33010602011771号