logo

MCP 怎么接 OpenAI 兼容 API？两条路线与可运行配置

更新于 2026-10-31 · runapi.cfd

简答：MCP 怎么接 OpenAI 兼容 API，取决于接口能力：支持 Responses API 的服务可按原生 MCP 方式传入远程 Server；只有 /v1/chat/completions 的接口，通常要增加 LiteLLM 这类桥接层，或由应用自行完成 function calling 循环。仅修改 Base URL、API Key 和模型名，不会自动让普通兼容接口获得 MCP 能力。

定义：MCP 是连接模型与外部工具的协议；OpenAI 兼容 API 只是请求格式和接口行为的兼容层，是否支持 MCP 还要看服务端是否实现 MCP 工具字段、传输协议和工具执行流程。

先判断路线：三端分别负责什么

本文核验日期为 2026-10-31。本站是第三方 AI API 接入指南，下面只讨论通用接口和桥接方法，不把某个兼容网关的行为泛化为所有平台规则。

你的接口条件适合的路线最小成功判定
明确支持 Responses API，并在文档中提供 tools 的 type: mcpResponses API 原生连接远程 MCP返回工具结果，或返回待审批的 MCP 工具请求
只有 /v1/chat/completions，但希望自动发现和执行 MCP 工具LiteLLM MCP Gatewaytools/list 能发现工具，模型请求能完成工具调用
不想部署网关，应用可以自己控制工具流程手动 function calling应用完成工具定义、调用 MCP、回传工具结果和二次模型请求

先记住三个边界：模型 API 的 base_url 指向模型接口；MCP Server URL 指向工具服务；网关 URL 是客户端访问桥接层的地址。三者不要互相替换。

OpenAI 当前文档说明，Responses API 连接远程 MCP 时会尝试发现工具，并支持 Streamable HTTP 或 HTTP/SSE；LiteLLM 文档则说明其代理可以把 MCP 工具转换为 OpenAI 兼容的工具调用。可分别查看 OpenAI MCP servers 文档 和 LiteLLM MCP Overview。

路线一：Responses API 原生连接远程 MCP

这条路线的前提不是“有 Responses API”这么简单，而是服务端还要实际支持远程 MCP、对应的传输协议、MCP Server 鉴权，以及审批和工具筛选字段。OpenAI 官方示例使用 type: mcp、server_url、server_label 和 require_approval 连接远程 Server，并支持 allowed_tools 限制工具范围。参考 OpenAI MCP servers 官方指南。

下面的地址和模型名是占位符，不能直接当成真实服务：

curl https://api.openai.com/v1/responses -H "Content-Type: application/json" -H "Authorization: Bearer $OPENAI_API_KEY" -d '{"model":"MODEL_ID","tools":[{"type":"mcp","server_label":"demo_mcp","server_url":"https://mcp.example.com/mcp","require_approval":"always","allowed_tools":["read_only_tool"]}],"input":"请使用允许的只读工具完成一次查询"}'

  1. 将 MODEL_ID 替换为当前接口实际支持且具备工具调用能力的模型 ID。
  2. 将 server_url 替换为 MCP 服务方明确提供的远程地址，确认它使用 Streamable HTTP 或 HTTP/SSE。
  3. 若 MCP Server 需要 OAuth 或 Bearer Token，按服务方文档配置授权，不要把模型 API Key 当作 MCP Token。
  4. 首次验证保留 require_approval: always，并优先使用只读工具；确认权限范围后，再按工具粒度调整审批。

成功不应只看 HTTP 200。应检查响应是否出现 MCP 工具发现结果、工具调用事件、待审批请求或最终工具结果。若只有普通文本，先确认模型是否真的选择了工具，而不是把“工具已配置”误判为“工具已执行”。

路线二：LiteLLM 桥接到 OpenAI 兼容 Chat Completions

如果你的模型网关只有 /v1/chat/completions，LiteLLM 的当前文档提供了对应路径：在请求的 tools 数组中放入 MCP 工具定义，代理负责发现工具、转换为 OpenAI 兼容函数调用，并在 require_approval 为 never 时自动执行工具调用。相关说明见 LiteLLM Chat Completions MCP 文档。

版本边界：本文不虚构一个固定 LiteLLM 版本。LiteLLM 官方页面会持续更新，下面配置按 2026-10-31 可核验的文档结构编写；部署前应在当前文档中确认镜像、字段和协议版本，并记录实际使用的镜像标签。

1. 安装或启动网关

官方快速开始同时提供 CLI 和容器方式。若使用容器，可先准备一个目录和 config.yaml，再按官方代理启动方式运行：

docker run -v "$PWD/config.yaml:/app/config.yaml" -e MODEL_API_KEY="$MODEL_API_KEY" -e LITELLM_MASTER_KEY="$LITELLM_MASTER_KEY" -p 4000:4000 docker.litellm.ai/berriai/litellm:latest --config /app/config.yaml

该启动命令中的 latest 不是固定版本。生产环境应改用你已经验证过的具体镜像标签，并在升级前重新检查 MCP 配置。LiteLLM 官方代理启动示例见 LiteLLM Getting Started。

2. 准备最小 config.yaml

下面的模型地址、模型名和 MCP 地址均为占位符；其中 transport: http 对应 Streamable HTTP，旧式 SSE Server 必须改为 transport: sse：

mcp_servers: demo_mcp: url: "https://mcp.example.com/mcp" transport: "http" auth_type: "none" model_list: - model_name: "MODEL_ID" litellm_params: model: "openai/MODEL_ID" api_key: "os.environ/MODEL_API_KEY" api_base: "https://api.example.com/v1"

如果上游 MCP 需要静态 API Key，可按官方配置参考改用 auth_type: api_key 和 auth_value: os.environ/MCP_API_KEY；如果需要 Bearer Token，则使用对应的 Bearer 配置。模型密钥、网关密钥和 MCP 凭据应分别放在不同环境变量中。具体字段以 LiteLLM MCP Configuration Reference 为准。

3. 先验证 MCP 工具发现

LiteLLM 官方配置参考明确将 /mcp 用作直接 MCP 客户端访问入口，并给出了 tools/list 的 JSON-RPC 冒烟测试：

curl -s -X POST http://localhost:4000/mcp -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -H "x-litellm-api-key: Bearer $LITELLM_MASTER_KEY" -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

成功判定是 JSON-RPC 响应中的 result.tools 数组包含可访问工具。若返回 401，先查网关 Key；若返回工具为空，检查 MCP Server 地址、传输类型、上游凭据和网关 Key 的访问权限。不要把 /mcp 的 JSON-RPC 测试结果与模型调用结果混为一谈。

4. 再调用兼容的 /v1/chat/completions

LiteLLM 文档给出的 Chat Completions 选择器是 litellm_proxy/mcp/<server_alias>，它是请求体里的逻辑选择器，不是公网 URL：

curl -s http://localhost:4000/v1/chat/completions -H "Content-Type: application/json" -H "Authorization: Bearer $LITELLM_MASTER_KEY" -d '{"model":"MODEL_ID","messages":[{"role":"user","content":"请使用可用的只读工具完成一次查询"}],"tools":[{"type":"mcp","server_url":"litellm_proxy/mcp/demo_mcp","server_label":"demo_mcp","require_approval":"never"}]}'

如果不希望自动执行工具，可省略 require_approval 或不要设置为 never，让工具调用返回给客户端审核。若只允许部分工具，可增加 allowed_tools。LiteLLM 对 litellm_proxy、litellm_proxy/mcp/<server_alias> 和网络形式的 /mcp 入口有明确区分，不能把它们随意替换。

第三条路线：不用网关时，手动完成 function calling

当兼容接口不支持 MCP、又不想部署 LiteLLM 时，可以由应用自己做桥接。function calling 不是 MCP，它只是模型与应用之间约定工具名称、参数 Schema 和调用结果的一种方式。应用需要承担完整循环：

  1. 通过 MCP Client 连接 MCP Server，并调用 tools/list 获取工具名、描述和输入 Schema。
  2. 将 MCP 工具 Schema 转成模型接口接受的 OpenAI 兼容 tools 定义。
  3. 把用户问题和工具定义发送到 /v1/chat/completions。
  4. 如果模型返回 tool_calls，应用校验工具名和参数，再调用对应的 MCP 工具。
  5. 把工具结果以 role: tool 和对应的 tool_call_id 加回消息，再发起第二次模型请求。

最小流程可以抽象为：

客户端 → OpenAI 兼容模型接口 → 返回 tool_calls → 应用调用 MCP Server → 返回工具结果 → 再次请求模型 → 最终回答

这条路线的优点是控制细，缺点是需要自行处理工具名称冲突、参数校验、超时、重试、并发、审批和敏感操作拦截。LiteLLM 官方 Python SDK 示例也展示了“读取工具调用、调用 MCP、把结果追加回 messages、再次请求模型”的循环，可参考 LiteLLM Python SDK MCP Bridge。

凭据、传输和排错：按调用链分层检查

凭据或地址作用检查位置
模型 API Key网关访问模型服务model_list、环境变量和模型服务响应
网关 Key客户端访问 LiteLLMAuthorization 或 x-litellm-api-key
MCP Token 或 OAuth 凭据网关访问具体 MCP ServerMCP Server 的 auth_type、上游请求头或按服务器转发的 Header
模型 Base URL接收模型请求兼容网关的 /v1 地址
MCP Server URL接收 MCP JSON-RPC远程 MCP 配置中的 /mcp 或 SSE 地址

固定排查闭环：先确认模型 API Key、网关 Key、MCP Token 没有混用；再确认模型 Base URL 和 MCP Server URL 分开；然后用 tools/list 验证发现；最后再测试模型工具调用。

  • 401：区分是模型服务、LiteLLM 网关还是 MCP Server 返回，分别检查对应凭据。
  • 403：检查网关 Key 是否获准访问该 MCP Server、工具是否被权限策略过滤，以及上游账号是否有权限。
  • 404：检查模型请求路径、MCP 路径、Server alias 和传输端点，不要把模型的 /v1/chat/completions 当成 MCP 地址。
  • 工具列表为空：检查 MCP Server 是否可达、传输类型是否匹配、上游认证是否成功，以及工具是否被 allowed_tools 或权限策略过滤。
  • 模型不调用工具：确认后端支持 tool calling，提示词确实需要工具，并检查是否设置了错误的工具选择器或审批策略。
  • 超时或流式中断：分别测试模型请求、网关到 MCP Server 的连接和 MCP 工具本身，避免只根据一个状态码判断故障来源。

对于公网 MCP Server，先核对 TLS、传输协议和服务端鉴权；对于内网或本机 MCP Server，应让桥接层位于能访问该网络的位置。stdio 适合由网关主机启动本地进程，不能把 stdio 命令直接填成远程 URL。LiteLLM 的传输矩阵和 OpenAI Agents 文档分别说明了 http、SSE 与 stdio 的配置边界，可参考 LiteLLM 传输配置参考 和 OpenAI MCP connections 文档。

结论：怎么选最小实现

如果接口确实实现了远程 MCP，优先用 Responses API 原生路线；如果只有 /v1/chat/completions，优先使用 LiteLLM MCP Gateway，并先完成 /mcp 的 tools/list 冒烟测试；如果无法部署网关，再由应用手动完成 function calling 循环。

无论选择哪条路线，都要把模型接口、网关、MCP Server 和三类凭据分别验证。真正的成功标准不是“配置文件能启动”，而是工具能够被发现、参数经过校验、调用结果能回传模型，并且敏感操作仍处于可控的审批范围内。

常见问题

OpenAI 兼容 API 能直接使用 MCP 吗？

不一定。OpenAI 兼容通常只说明部分请求路径、鉴权或响应格式接近 OpenAI；是否支持 MCP，要看接口是否实现 MCP 工具类型、远程传输和工具执行流程。只有普通 /v1/chat/completions 时，通常需要网关桥接或手动 function calling。

MCP Server 地址应该填到 Base URL 里吗？

通常不应该。模型 Base URL 指向模型 API，MCP Server URL 指向工具服务。原生 Responses API 通过 MCP 工具字段配置，LiteLLM 则在 mcp_servers 中注册，并在模型请求中使用对应的逻辑选择器。

LiteLLM 的 litellm_proxy/mcp/demo_mcp 是公网地址吗？

不是。它是 LiteLLM 模型请求体中的逻辑选择器，用于选择已注册的 MCP Server。直接 MCP 客户端访问 LiteLLM 时，才使用实际网络地址，例如网关的 /mcp 入口。

为什么 tools/list 成功，但模型不调用工具？

工具可发现不等于模型一定会调用。先确认模型或后端支持 tool calling，再检查提示词是否需要工具、工具是否被 allowed_tools 或权限策略过滤、审批设置是否阻止自动执行，以及请求中的 Server 选择器是否正确。

Streamable HTTP、SSE 和 stdio 怎么选？

远程 MCP Server 应先按服务方文档确认使用 Streamable HTTP 还是旧式 HTTP/SSE；stdio 适合由本机或网关主机启动的子进程。LiteLLM 的配置需要显式设置 transport，避免不同入口使用不同默认值。

模型 API Key、网关 Key 和 MCP Token 能共用吗？

不建议共用，也不能假设它们可以互换。模型 API Key 用于网关访问模型，网关 Key 用于客户端访问网关，MCP Token 或 OAuth 凭据用于访问具体 MCP Server。分开配置更容易定位 401、403 和权限问题。

相关阅读

参考资料

  1. OpenAI API：MCP servers
  2. OpenAI API：MCP connections
  3. LiteLLM：MCP Overview（docs.litellm.ai）
  4. LiteLLM：Using your MCP（docs.litellm.ai）
  5. LiteLLM：MCP Configuration Reference（docs.litellm.ai）
  6. LiteLLM：Getting Started（docs.litellm.ai）
温馨提示
置顶

【RunAPI 新域名启用通知】
https://runapi.host
原域名 runapi.cfd 需要使用代理才能访问，RunAPI 现已启用新域名： https://runapi.host

新域名可直接访问，账户、余额及服务数据均不受影响。（注意：新域名在非代理环境下只可见国内模型，api调用不受影响）

2 个月前 · 2026-08-07 11:30

claude-haiku-5.5已上线

14 小时前 · 2026-10-09 12:14

gemini-nano-banana-2.1已上线

1 天前 · 2026-10-08 21:58

🎉 国庆限时充值 9 折！ 10 月 2 日 18:00:00 — 10 月 7 日 23:59:59，点击任意额度充值并选择支付宝支付，支付页面将自动享受 9 折优惠！

⚠️ 本次优惠仅限支付宝支付，Creem 支付暂未同步折扣，仍按原价结算。

1 周前 · 2026-10-02 19:02

gpt-6.1-sol已上线

1 周前 · 2026-10-01 23:20

claude-sonnet-5-5已上线
coding和claude_normal分组可使用

1 周前 · 2026-09-29 18:20

claude-opus-5-5, gpt-6-sol已上线

2 周前 · 2026-09-23 14:11

grok-4.7上线，grok、default分组可用
支持chat, responses,messages格式

2 周前 · 2026-09-22 13:35

【分组更新通知】
deepseek-sale分组上线，价格5折，支持v1/messages；v1/responses；v1/chat/completions格式请求

deepseek-v4.1-flash同步上线

提示：glm-sale和kimi-sale分组价格5折，接口均服务正常

3 周前 · 2026-09-13 23:10

gpt-image-2.5上线

0 个月前 · 2026-09-10 21:49

因官方下架gpt-5.4模型，平台codex分组已同步下架，需要调用该模型可切换至default/plus分组使用

1 个月前 · 2026-09-06 16:27

gpt-6-astra已上线

1 个月前 · 2026-09-05 14:58

gemini-3.8-flash已上线

1 个月前 · 2026-09-05 04:06

claude-fable-5-1已上线

1 个月前 · 2026-09-03 13:33

【分组更新通知】
1.kimi-sale分组5折
2.glm-sale分组5折
3.grok分组降价为0.7折，资源为grok heavy
以上均可通过v1/chat/completions；v1/responses；v1/messages格式调用

1 个月前 · 2026-09-03 10:50

glm-5.3, glm-5.3-flash
qwen3.8-flash, qwen3.7-flash
均已上线，default分组即可调用

1 个月前 · 2026-08-27 22:46

【公告】关于模型访问受限域名的处理说明
为遵守相关合规要求，平台已对模型访问政府类网站（gov域名）实施限制。
若您在对话过程中遇到提示“内容审计命中风险规则，请调整输入后重试”的报错，烦请移除对话中涉及的gov相关链接后再重新请求。
感谢您的理解与配合。

1 个月前 · 2026-08-22 22:11

最近codex更新后，如果遇到“401 token not provided”这个错误，是因为环境变量失效，重新配置后重启codex即可

1 个月前 · 2026-08-22 00:51

gemini-3.7-flash上线

1 个月前 · 2026-08-15 23:21

grok-4.6
qwen3.8-max
均已上线

1 个月前 · 2026-08-13 15:49