dsh-mcp-bridge

将 DeepSeek Harness 部署的能力提供给任何 MCP 客户端——记忆、持久任务账本、项目智能体调度以及更广泛的 MCP 生态——以声明的工具形式，而不是模型需要被告知并记住的 shell 命令。

为什么

claude -p 运行自己的智能体循环，因此它永远不会收到 harness 的工具模式：一个由 Claude 驱动的会话没有记忆、没有账本、没有调度。它确实接受 MCP 服务器。这就是那个服务器。

它暴露的一切都已经有命令行入口，因此这增加的是表面，而非权限——它能做的正是调用者在 shell 中已经能做的事。它无法桥接的是仅存在于实时 harness 回合内部的东西（goals、AgentTeams）；这些按设计是会话作用域的，没有外部表面。

Related MCP server: skillsmcp

工具

使用

// mcp-bridge.json
{ "mcpServers": { "dsh": { "command": "node", "args": ["/path/to/src/server.js"] } } }

claude -p --strict-mcp-config --mcp-config ./mcp-bridge.json

如果 DSH_JARVIS_BIN 不是 ~/.dsh-jarvis/bin，请将其指向存放 CLI 的目录。

用惨痛代价学到的三件事

• --mcp-config 是可变参数的。 内联 JSON 后跟位置参数提示符，会让客户端把提示符当作第二个配置路径读取（MCP config file not found: /tmp/List the tool…）。请传入文件。

• 不要在 stdin 报告 EOF 的瞬间退出。 规范说客户端关闭 stdin 即关闭，但有些客户端交给服务器的 stdin 已经处于 EOF；服务器在第一个请求之前就退出，客户端重新生成它，于是陷入循环。观察到：三分钟内 32 次生成，没有一次调用完成。在这里，EOF 只在已经处理过某些内容后才结束进程，并带有有界的空闲超时，因此被遗弃的服务器仍然会消失。

• 用写入来验证桥接，绝不要用读取。 当调用实际失败时，被要求“调用搜索工具”的模型可以从自身上下文中重现看似合理的输出——这里就有一个模型正是这么做的，后来也承认了。用随机令牌进行写入，要么落在存储中，要么没有。

测试

npm test

20 个测试，无依赖，无需客户端：工具目录和 JSON-RPC 层都是纯的。

许可证

MIT