什么是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）。
例如：
你可以使用以下工具完成用户请求（调用格式为JSON）：[{"name": "get_weather", "description": "查询指定城市天气", "parameters": {"type": "object", "properties": {"city": {"type": "string", "description": "城市名"}}, "required": ["city"]}}]指令约束声明：
强制模型结构化输出：在 Prompt 中严格规定输出格式。
例如：
如果用户请求需要使用工具，请输出 **仅包含且严格遵循以下 JSON 结构** 的文本：{ "tool_call": "工具名称", "arguments": { "参数1": "值1", ... }}否则输出自然语言回复。模型生成调用文本：
用户提问：今天北京天气怎么样？
模型（如果决定调用工具）
生成字符串输出：
{"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级别）：
client = 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 执行。自动注入结果 & 最终推理：
- 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…
