omniroute-mcp-bridge

一个 stdio MCP 桥接器，由 DSH 作为子进程启动（通过 dsh-mcp-client 插件，transport: stdio）。它将 tools/list / tools/call 代理到位于 https://llm.claassen.family/api/mcp/stream 的 omniroute streamable-http MCP 服务器，并且只将白名单中的工具暴露给模型。

为什么

• 上游 streamable-http 会话在空闲时会失效（"Unknown Mcp-Session-Id" 404）。桥接器检测到这一确切的错误，会拆除失效的客户端，重新执行 MCP initialize 握手（获取新的 session id）并重试——这样，失效的上游会话不再导致工具调用失败。

• dsh-mcp-client 插件没有工具过滤配置。该桥接器在服务端过滤 tools/list，因此只暴露 omniroute_web_search，而不是约 70 个工具（节省模型上下文；保留稳定的 serverName: omniroute，因此公开名称仍是 mcp__omniroute__omniroute_web_search）。

• 上游认证头通过子进程的 env 传递，而不是 argv——密钥不会出现在进程列表中。它只存在于 web profile 中权限为 0600 的 cordis.patch.yml。

Related MCP server: mcp-streaming-http-proxy

文件

SDK 解析

package.json 将 @modelcontextprotocol/sdk 固定到桥接器开发时所依据的确切版本。有两种方式获取它：

• 独立使用： 在此目录中运行 npm install。

• 在 DSH 主机内部（本部署）： node_modules 是指向 /usr/lib/node_modules/@deepseek-ai/dsh/node_modules 的 符号链接，因此桥接器始终使用 DSH 自带 mcp-client 插件所使用的同一套 SDK 构建。该符号链接已被 gitignore 忽略——在该环境中克隆后需重新创建它：

  ln -sfn /usr/lib/node_modules/@deepseek-ai/dsh/node_modules node_modules

配置（环境变量，在 ~/.dsh/profiles/web/cordis.patch.yml 中设置）

测试

凭据不会被提交。请先导出它们（值来自你的 patch 文件）：

export MCP_BRIDGE_UPSTREAM_URL='https://llm.claassen.family/api/mcp/stream'
export MCP_BRIDGE_UPSTREAM_HEADERS='{"Authorization":"Bearer …","X-Forwarded-For":"127.0.0.1"}'

然后：

node test-reinit.mjs   # deterministic: dead session -> re-init -> success (no network needed)
node test-bridge.mjs   # live: handshake + filtered list + real search
node probe.mjs         # dump the upstream's raw tool names
node probe-ttl2.mjs    # measure upstream session idle TTL

修改白名单

修改 patch 文件中的 MCP_BRIDGE_ALLOWED_TOOLS（来自 node probe.mjs 的逗号分隔的原始工具名称）。include-plugin 的 HMR 会在文件变更时重新应用补丁；mcp-client 插件会重新生成桥接器子进程。