MCP LLM Bridge：将 MCP 协议接入任意 OpenAI 兼容大模型的桥梁

你是否曾遇到过这样的困境：团队开发了一套强大的 MCP（Model Context Protocol）工具服务器，功能完善、接口规范，但当你想用自己熟悉的本地大模型（如 Ollama）来调用这些工具时，却发现没有现成的适配层？或者反过来，你想把一个本地部署的 LLM 接入 Anthropic 的 Claude，却苦于协议不兼容？MCP LLM Bridge 正是为解决这类「协议鸿沟」问题而生的工具。

图 1：MCP LLM Bridge 运行时效果——将 MCP Server 的工具能力桥接到 OpenAI 兼容 LLM

一、项目背景：为什么需要一座「协议桥」？

2024 年，Anthropic 推出了 Model Context Protocol（MCP），意图建立 AI 模型与外部数据源、工具之间的标准化通信协议。与此同时，OpenAI 也在推进其 Function Calling 规范。两套协议各有优势：MCP 在工具发现、资源管理方面更为完善；OpenAI 的 function-calling 则在大模型生态中普及度更高。

这种「生态割裂」带来的现实问题是：优秀的 MCP 服务器（如官方 mcp-server-sqlite）无法直接被 Ollama、LM Studio 等本地 LLM 调用。开发者要么为每个 LLM 重写适配层，要么放弃使用某些工具。

MCP LLM Bridge 的作者 bartolli 从这一痛点出发，设计了一个轻量级双向协议转换层——它一端连接 MCP 服务器（通过 stdio 通信），另一端对接 OpenAI 兼容的 LLM API，将两套协议的能力串联起来。整个项目仅用约 400 行 Python 代码就实现了核心逻辑，代码简洁可维护。

二、核心功能：双向协议翻译引擎

2.1 协议转换原理

MCP LLM Bridge 的核心逻辑围绕 工具发现 和 工具调用 两条链路展开：

工具发现链路：Bridge 启动时，通过 MCP Client 向目标 MCP Server 发送 list_tools 请求，获取所有可用工具的名称、描述和输入模式（JSON Schema）。随后，Bridge 将这些 MCP 工具规格转换为 OpenAI Function Schema 格式，注入 LLM 的 tools 参数中。LLM 就能「认识」这些工具，并在回复中以 tool_calls 形式发起调用。

工具执行链路：当 LLM 返回 tool_calls 时，Bridge 解析其中的函数名和参数，通过 MCP Client 将其转发给 MCP Server 执行。执行结果再以 tool 角色消息返回给 LLM，完成一轮完整的多轮对话循环。

这两条链路配合异步上下文管理器（async with）实现，确保 MCP 连接在对话期间保持活跃，工具状态（如数据库连接）不会中断。

2.2 多后端兼容

Bridge 不绑定特定 LLM 提供商。只要模型实现了 OpenAI API 的 tools 接口（GPT-4o、GPT-4o-mini 等），或者兼容此接口的本地运行时（如 Ollama、LM Studio），就可以接入 MCP 工具生态。配置方式只需在代码中指定：

# 方式一：OpenAI 云端
llm_config=LLMConfig(
    api_key=os.getenv("OPENAI_API_KEY"),
    model="gpt-4o",
    base_url=None
)

# 方式二：Ollama 本地
llm_config=LLMConfig(
    api_key="ollama",
    model="mistral-nemo:12b-instruct-2407-q8_0",
    base_url="http://localhost:11434/v1"
)

这种灵活性意味着开发者可以在本地用 Ollama 调试prompt效果，验证通过后再切换到 GPT-4o 上线，无需修改业务逻辑。

三、代码架构：模块化分层设计

项目采用标准 Python 包结构，核心代码在 src/mcp_llm_bridge/ 下：

项目依赖管理采用 uv（Astral 出品的极速 Python 包管理器），同时在 pyproject.toml 中兼容 Poetry 格式。运行时需要 Python 3.12 及以上，充分利用结构化模式匹配（match-case）和改进的类型注解特性。

测试方面，项目使用 pytest + pytest-asyncio + pytest-mock，测试覆盖核心桥接逻辑，测试文件位于 tests/ 目录。代码规范通过 ruff 执行（E/F/I 规则），保持代码风格统一。

四、部署体验：轻量但需手动配置

MCP LLM Bridge 是一个纯 CLI 工具，不提供 Web 界面或 Docker 容器化部署。安装步骤相对简单：

# 1. 安装 uv
curl -LsSf https://astral.sh/uv/install.sh | sh

# 2. 克隆并安装
git clone https://github.com/bartolli/mcp-llm-bridge.git
cd mcp-llm-bridge
uv venv && source .venv/bin/activate
uv pip install -e .

# 3. 配置 API Key
cp .env.example .env
# 编辑 .env 填入 OPENAI_API_KEY

# 4. 启动 MCP Server（示例：SQLite）
python -m mcp_llm_bridge.create_test_db  # 创建测试数据库
python -m mcp_llm_bridge.main            # 启动 Bridge

硬件要求极低——无需 GPU，普通开发机即可运行。但部署过程中有几个需要注意的地方：

1. uv 是必装工具：不能用 pip 直接安装（因为 pyproject.toml 中依赖 mcp 的安装方式需要 uvx），没有 uv 会导致 uvx mcp-server-sqlite 命令无法执行。

2. Python 3.12+ 硬性要求：项目使用了一些较新的 Python 语法特性，在旧版本 Python 上无法运行。

3. MCP Server 需要单独管理：Bridge 本身不包含 MCP Server，需要另行启动（如 mcp-server-sqlite、mcp-server-filesystem 等），并通过 StdioServerParameters 配置通信参数。

4. LLM API Key 安全性：生产环境使用 OpenAI API Key 时，建议通过环境变量注入，避免硬编码在源码中。

五、技术特点与局限性

优势

• 极简接入：只需几十行配置代码，即可将任意 MCP Server 接入 LLM
• 多后端支持：同时支持 OpenAI 云端和 Ollama 等本地运行时
• 代码质量高：使用 Pydantic 数据类 + 完整类型注解，ruff 规范检查，pytest 异步测试
• MIT 许可证：可自由集成到商业项目中

局限

• 无 Web UI：完全命令行操作，非技术用户上手门槛较高
• 无容器化：缺乏 Dockerfile，对于不熟悉 Python 环境的团队来说部署有障碍
• 工具发现链路长：Bridge 依赖 MCP Server 的正确实现，若 MCP Server 工具描述不规范，转换可能出错
• 测试数据库硬编码：当前示例中数据库路径为 test.db，生产使用需自行修改

六、行业意义：协议互操作的轻量范式

MCP LLM Bridge 体现了一种「协议互操作轻量化」的设计思路。它没有试图做一个大而全的代理网关，而是专注于 MCP ↔ OpenAI Function Calling 这一具体场景，用最少的代码解决实际问题。

随着 MCP 生态的壮大（官方已提供 20+ MCP Servers），类似 Bridge 的适配层将成为刚需——因为不是所有 LLM 都会原生支持 MCP，但几乎所有现代 LLM 都支持 OpenAI 兼容的 tool-use 接口。MCP LLM Bridge 填补的正是这一空白。

从增长趋势看，该项目自发布以来获得了 334 颗 GitHub Stars，对于一个专注于协议互操作的工具库而言，这个数字说明其在开发者社区中确实解决了真实痛点。随着 MCP 和 function-calling 两种协议继续并行发展，类似 Bridge 的桥接工具价值会持续提升。