什么是mcp
MCP(Model Context Protocol,模型上下文协议)是一种由 Anthropic 公司于 2024 年提出的开放标准协议,旨在解决大型语言模型(LLM)与外部工具、数据源及服务之间的互联互通问题。它通过标准化接口实现模型与多样化资源的无缝集成,推动智能体(Agent)应用的灵活扩展和安全协作。
打个比方:
大模型就像一个知识渊博但被隔离的"大脑",它只能基于训练数据回答问题。 有了 MCP,这个大脑就获得了一套标准化的感官和手脚 ------ 它可以通过统一的方式调用工具、读取数据库、访问实时信息、执行操作 , 从"纸上谈兵"变成真正能感知世界、采取行动的智能体。
mcp工具相当于一个脚本,可以通过prompt或者function call来告诉模型工具是做什么的,需要什么样的参数,可以让模型进行调用
mcp的三种通信方式
1. Stdio:本地交互
Stdio(标准输入/输出)传输是MCP框架中的默认传输机制,它利用标准输入/输出流在客户端和服务器之间进行通信。
工作原理:
- 通过进程的标准输入(stdin)和标准输出(stdout)流进行数据交换
- 客户端将请求写入标准输入
- 服务器处理请求后将响应写入标准输出
- 通信双方通过管道(pipe)或重定向连接
适用场景:
- 命令行工具和本地集成
- 容器化环境中的进程间通信
- 资源受限环境(无需网络开销)
2. SSE
SSE(Server-Sent Events)是一种服务器推送技术,使客户端能够通过HTTP连接从服务器自动接收更新,通常用于服务器向客户端发送消息更新或连续的数据流。
工作原理:
- 基于HTTP长连接
- 客户端发起单向连接到服务器
- 服务器可以多次向客户端发送事件
- 使用
text/event-stream
MIME类型
在MCP中的应用:
- MCP提供了SSE作为主要的传输机制之一,用于Client和MCP服务器之间的通信
- HTTP Stream Transport层支持通过SSE进行流式传输
3. HTTP-Streamable
比如前端的fetch,在tcp连接上不必等待缓冲区接收到全部内容,而是对每部分内容进行解码返回,就实现了类似于http对通信方式,而且fetch相比sse更灵活,比如支持aborthandler,支持自定义请求头,支持除get(sse只支持get请求)以外的方法
2025年3月26日,MCP引入了一项关键更新:用Streamable HTTP替代原先的HTTP + SSE作为默认传输方式。
工作原理:
- 基于HTTP分块传输编码(chunked transfer encoding)
- 支持双向流式通信
- 保持HTTP语义,但允许在单个连接上进行多次响应
- 通常使用gRPC或自定义二进制协议增强效率
总结对比
stdio就是需要把mcp脚本下载到本地,
sse和http-streamble到mcp服务可以部署在云上,通过api请求这种去调用
大模型怎么调用mcp工具(与mcp工具进行通信)
好的,我们从 Prompt(提示词) 和 Function Calling(函数调用) 两种核心方法深入阐述大模型(如 Claude/GPT)如何与 MCP 工具通信。
🧠 一、Prompt(提示词)驱动方式 - "告诉模型手动打电话"
核心逻辑 :在对话上下文中,直接通过自然语言指令 要求模型生成符合 MCP JSON-RPC 规范的结构化调用指令。
适用模型:理论支持所有 LLM,但对模型的结构化输出能力要求极高(Claude 3/GPT-4 为佳)。
-
工具描述注入:
-
在 Prompt 的开头,显式声明所有可用的 MCP 工具信息(名称、功能描述、参数 JSON Schema)。
-
例如:
css你可以使用以下工具完成用户请求(调用格式为JSON): [{"name": "get_weather", "description": "查询指定城市天气", "parameters": {"type": "object", "properties": {"city": {"type": "string", "description": "城市名"}}, "required": ["city"]}}]
-
-
指令约束声明:
-
强制模型结构化输出:在 Prompt 中严格规定输出格式。
-
例如:
javascript如果用户请求需要使用工具,请输出 **仅包含且严格遵循以下 JSON 结构** 的文本: { "tool_call": "工具名称", "arguments": { "参数1": "值1", ... } } 否则输出自然语言回复。
-
-
模型生成调用文本:
-
用户提问:
今天北京天气怎么样?
-
模型(如果决定调用工具)
生成字符串输出:
json{"tool_call": "get_weather", "arguments": {"city": "北京"}}
-
-
客户端提取 & 转发:
- LLM 应用客户端(MCP Host)检测到输出的 JSON 文本块。
- 客户端解析 JSON ,将其转化为真正的 MCP JSON-RPC 请求。
- 客户端通过之前建立的通信通道(
stdio
/Streamable HTTP
)将请求发送给对应的 MCP Server。
-
处理结果 & 反馈模型:
-
MCP Server 执行工具逻辑。
-
结果返回给客户端(Host)。
-
客户端将工具执行结果(JSON)作为新消息注入上下文中。
-
模型"看到"这个结果后,生成最终的自然语言回答给用户:
北京今天天气为:多云,气温 25℃。
-
⚠️ 局限与风险:
-
依赖提示工程:需要精心设计提示词,确保模型正确理解和输出格式。
模型可靠性问题:
- 模型可能拒绝调用工具(输出自然语言)。
- 模型可能输出错误格式(JSON 语法错误、参数错误)。
- 模型可能在不需要调用工具时强行调用。
-
安全性问题:如果 Prompt 被用户恶意引导,可能绕过规则输出任意指令(潜在风险)。
-
效率较低:需要两次模型生成调用(一次调用指令,一次整合结果回复用户)。
🤖 二、Function Calling(函数调用)方式 - "让模型使用内置电话"
核心逻辑 :在模型推理过程中,模型识别到调用工具的意图 ,触发一个内部的、预定义的"函数调用事件" (包含完整的 JSON 参数)。应用框架(Host)捕获此事件并执行真正的 MCP 调用,结果自动注入后续推理。
适用模型与框架:原生支持 Function Calling 的模型(如 OpenAI GPT-3.5+, Anthropic Claude 3+, 等)+ 集成了 MCP 功能调用支持的 LLM 应用框架。
-
工具功能向模型注册:
-
开发者向 LLM 应用框架/Host 注册可用工具列表。
-
框架自动将工具信息转换成模型原生理解的"Function Calling Schema" 。
-
注册示例如下(API级别):
makefileclient = ChatClient(...) client.register_tool( name="get_weather", description="查询指定城市天气", parameters={ "type": "object", "properties": { "city": {"type": "string", "description": "城市名"} }, "required": ["city"] } ) # 或自动发现并注册所有 MCP Server 提供的工具
-
-
推理触发 Function Call:
-
用户提问:
今天北京天气怎么样?
-
模型内部决策:
- 判断是否需要调用工具 (
get_weather
)。 - 直接在推理过程中触发一个结构化调用事件 (API 返回的是一个特殊的
tool_calls
对象,而非文本字符串输出)。 - 此事件包含精确的
工具名
和结构化参数列表
(已根据 Schema 验证)。
- 判断是否需要调用工具 (
-
-
框架捕获 & 执行调用:
- LLM 应用框架/Host 接收到的 API 响应不再是普通文本,而是包含
tool_calls
和占位文本的结构。 - 框架自动解析
tool_calls
,提取工具名和参数。 - 框架将参数转换成 MCP JSON-RPC 请求。
- 框架通过已建立的通信通道(
stdio
/Streamable HTTP
)将请求发送给对应的 MCP Server 执行。
- LLM 应用框架/Host 接收到的 API 响应不再是普通文本,而是包含
-
自动注入结果 & 最终推理:
- MCP Server 返回结果(JSON)。
- 框架自动收集执行结果 ,并将其以结构化方式(作为该 Function Call 的 "tool use result")注入回模型的下一次输入上下文中。
- 模型自动整合结果,生成最终的自然语言回复,此过程对开发者透明。
✅ 核心优势:
- 模型原生支持 :调用决策和参数生成是模型推理能力的一部分,准确率更高。
- 高度结构化 :输入(工具定义 Schema)和输出(调用事件)都是 API 内部结构化数据,格式强保证。
- 开发者友好:框架自动处理繁琐的格式转换、结果注入流程。开发者只需关注核心工具实现(MCP Server)。
- 效率更高 :通常只需一次模型请求调用(结果整合在后台完成,如 OpenAI
response_format: auto
)。 - 安全性更好:模型只能在注册过的工具中做选择,API 层严格控制输入参数类型。
📊 对比总结:Prompt vs. Function Calling
特性 | Prompt (提示词) | Function Calling (函数调用) |
---|---|---|
核心驱动 | 外部 Prompt 约束文本输出 | 模型推理内核的意图识别与结构化触发 |
模型要求 | 理解 Prompt 并有良好结构化输出能力的模型 | 必须原生支持函数调用功能的模型 |
调用指令形式 | 模型输出一个 JSON 格式的文本块 | 模型在推理过程中触发一个内部的结构化调用事件 |
可靠性 | 较低 (依赖 Prompt,易出错) | 高 (格式强约束,调用决策更准确) |
安全性 | 较低 (Prompt 可能被篡改) | 较高 (API 层控制参数) |
开发者体验 | 手动处理 JSON 解析、错误处理、结果注入 | 框架自动处理调用、结果注入、错误处理 |
是否需要复杂框架支持 | 不需要 (基本客户端即可实现) | 需要 (Host 框架或 API 需原生支持 Function Call) |
推荐场景 | 快速原型测试、不支持 Function Call 的模型或环境 | 生产环境首选 (主流商业模型 API 或支持功能调用的开源框架) |
📌 结论
- Function Calling 是主流且推荐的方式:它利用 LLM 内核能力,通过框架自动化流程,提供了更高可靠性、效率和开发便捷性。与 MCP 结合天然契合,是实现"工具调用-执行-结果整合"闭环的理想方案。OpenAI API、Anthropic Messages API、LangChain Agent 等主流实现都基于此模式。
- Prompt 方式仍有特定价值:在快速验证、旧模型支持或某些受限环境(如纯前端无服务器环境调用本地代理)时可作为备用方案,但需要付出更多的工程成本和应对更高风险。
内容就到这里了,如果有不清楚的推荐去看下下面这个up的视频,讲的蛮清楚的
【MCP是怎么对接大模型的?抓取AI提示词,拆解MCP的底层原理】www.bilibili.com/video/BV1P3...