MCP 应用市场 Alphauni-x/dsh-mcp-market

dsh-mcp-market

在 DeepSeek Harness 中浏览、扫描并同步 ModelScope MCP 市场——然后一键安装、启用、禁用或移除 MCP 服务器。

dsh-mcp-market 在 DSH Web 侧边栏中添加了一个 MCP Market 面板。它从 modelscope.cn/mcp 拉取服务器目录（12,000+ 项服务），将每条记录转换为 DSH 兼容的 MCP 配置，并写入你配置文件的 cordis.patch.yml——DSH 会通过 HMR 热重载它，无需重启。

English · 简体中文

功能特性

- 🛒 市场标签页——搜索、排序（相关度 / 星标 / 热度 / 最近更新）、按类别以及按托管与本地进行筛选，然后安装。类别名称来自 ModelScope 自带的中文标签（API 仅返回英文 slug；中文名称位于站点的 i18n 词典中，全部 100 个类别均已内置）——将鼠标悬停在标签上可查看原始 slug。排序和筛选使用 DSH 原生下拉菜单，因此与相邻按钮风格一致。
- 📦 已安装标签页——查看你配置文件中的每个 MCP 服务器及其实时状态（运行中 / 失败 / 加载中 / 已禁用）、已注册工具数量，以及每个服务器的操作：启用、禁用、测试连接、移除。移除操作会在卡片内联请求确认，而不是通过 window.confirm——原生对话框会阻塞渲染线程，并且在主题化面板中显得格格不入。安装或切换后，卡片会自动稳定到最终状态；无需手动刷新。
- 🔄 目录同步——构建本地索引，使搜索、排序和类别筛选无需在每次按键时都访问网络。ModelScope 将匿名查询限制为 300 行，因此同步会通过关键词扇出（约 160 次请求）遍历，覆盖 12,500 项服务目录的约 67%；面板会报告真实覆盖率，而不是假装索引是完整的。增量差异会报告自上次同步以来新增 / 更新 / 下架的内容。
搜索可弥补剩余差距：输入查询时也会实时访问市场并合并命中结果。
- ⏱ 定时同步——手动“同步目录”按钮加上自动刷新：索引会按间隔重新拉取，并且当缓存缺失或过期时，会在启动时运行一次追赶同步。两者均可配置，面板会显示上次和下次同步的时间。
- 🔐 无需 ModelScope 账号——公共目录 API 无需登录，并且约 76% 的已索引服务附带 DSH 可直接使用的配置（基于 8,377 条记录的测量；见下文）。
- 🩺 预检测试——在将任何内容写入你的配置文件之前，先启动连接并列出其工具。
- ✍️ 手动添加——对于不在目录中的服务器，或字段不匹配的服务器，可直接在面板中填写：服务器名称、传输方式（本地命令 vs. 远程端点）、命令以及参数（或端点）。本地命令接收环境变量；远程端点接收请求头（例如 Authorization: Bearer ）——两者都以添加/删除键值行的形式呈现。
它经过与目录安装相同的写入路径——相同的重复和冲突检查，相同的托管块，由 DSH 热加载，无需重启。
- 🤝 与其他插件良好协作——此插件只会重写它在 cordis.patch.yml 中自己标记的块。其他插件的行（包括 dsh-skill-mcp-panel）会逐字节保留。

安装

dsh plugin --profile add dsh-mcp-market

或从 tarball 安装：

dsh plugin --profile add ./dsh-mcp-market-0.1.0.tgz

bundle 补丁会自动挂载该插件——无需手动编辑 cordis.patch.yml。
重启该 profile 一次，然后在左侧边栏中打开 MCP Market。

在 pnpm 9 上： 如果安装失败并出现 ERR_PNPM_ADDING_TO_ROOT — Running this command will add the dependency to the workspace root，说明 profile 目录中包含一个由 DSH 生成的 pnpm-workspace.yaml（packages: [.]），pnpm 会将其视为工作区根目录。按照提示操作并添加 -w：

dsh plugin --profile add -w dsh-mcp-market

pnpm 10+ 已取消此检查，因此在那里不会遇到该问题。这是 pnpm/DSH 之间的交互问题，与本插件无关。

工作原理

Market panel (browser)
│ Typert Remote
▼
Cordis host plugin
├─ mcpMarket ── ModelScope API ──▶ local index cache
└─ mcpInstaller ──▶ cordis.patch.yml managed block ──▶ @deepseek-ai/dsh-mcp-client (HMR)

一个 MCP 服务器就是 ~/.dsh/profiles//cordis.patch.yml 中的一行：

- id: mcp-market-
name: "@deepseek-ai/dsh-mcp-client"
disabled: true # ← "disable" is exactly this flag
config:
serverName:
transport: stdio | streamable-http

因此，安装会追加一行，移除会删除一行，禁用则设置 disabled: true。编辑会通过 HMR 生效。

配置映射

| ModelScope 字段 | DSH 配置 |
| StreamableHTTPServerConfig | transport: streamable-http + url（+ headers） |
| ServerConfig | transport: stdio + command / args / env |
| SSEServerConfig | 不支持——DSH 没有 SSE 传输；面板会将这些标记为“不支持” |
| EnvSchema | 渲染为安装时表单；像 这样的占位值永远不会被写入 |

优先级为远程 → 本地。在整个 8,377 条记录的索引中测得：

| 发现的配置 | 占比 |
| ServerConfig（本地，stdio） | 67.5% |
| StreamableHTTPServerConfig（直接端点） | 8.4% |
| 仅 SSEServerConfig → 不可安装 | 24.1% |

75.9% 的已索引服务可安装；其中 23.4% 至少需要一个环境变量。

ModelScope 托管部署（DeployedUrl）需要已登录账户，并返回一个 SSE 地址，DSH 无法使用。本插件有意不支持它们——本地和直连连接已覆盖目录中的大多数服务，且无需任何凭据。

为什么索引停在约 67%，以及同步实际做了什么

公共目录 API 对匿名请求强制执行偏移量上限 300：一旦 (PageNumber − 1) × PageSize 达到 300，之后每一页都会返回空结果，并且 TotalCount 降为 0。在 11 种页宽/页码组合中测量——停止点始终恰好是 300，因此这是服务端配额，而不是分页 bug。因此，简单的“翻页直到耗尽”式同步会停在 12,520 个服务中的 300 个（2.4%）。

真正有效的是 Query——它是真正的关键词搜索（finance → 20 条命中，搜索 → 222， map → 44）。因此同步会围绕一个关键词列表展开（26 个字母、10 个数字、约 50 个常见词以及目录自身的分类名称），并按 id 合并结果：

| 关键词 | 已索引 | 覆盖率 | 请求数 |
| 36（字母 + 数字） | 7,132 | 57.0% | 100 |
| 80 | 8,331 | 66.6% | ~155 |
| 160 | 8,403 | 67.1% | 236 |

收益很快趋于平缓——最后增加的 80 个关键词只带来 72 条记录——因此默认词表停在 96。一次同步大约需要 4 分钟和约 160 次请求，这就是为什么它在后台运行，并与手动按钮共享进行中的锁。

剩余的缺口在搜索时补齐：当你输入查询时，面板也会实时询问市场，并合并两组结果。

为什么 stdio MCP 在桌面应用中失败（从 Dock 启动时）

桌面构建版（DeepSeek Harness.app）从 Dock 或 Finder 启动时，只继承 launchd 的默认 PATH （/usr/bin:/bin:/usr/sbin:/sbin）——其中没有任何一个包含用户自己的 npx / uvx / pnpm，而这些正是大多数市场 stdio 服务器用作命令的东西。症状是 连接失败：spawn uvx ENOENT：HTTP 服务器继续正常工作，每个本地命令服务器都失败。 看起来像是“某些服务器坏了”，但实际上启动方式只是让几个目录没有进入宿主环境。

从终端启动同一个应用则不受影响（zsh 已经从 .zprofile / .zshrc 导出了这些路径），所以这关乎应用是如何启动的，而不是配置错误。

插件会自行修复：加载时，任何存在但不在宿主 PATH 中的候选目录（~/.local/bin、/opt/homebrew/bin、/usr/local/bin、/opt/local/bin、……）都会被前置到 process.env.PATH。只写这一处就足够了——官方 @deepseek-ai/dsh-mcp-client 正是从同一个 process.env 构建子环境，因此连接测试和真实启动会一起被修复，且无需改动任何配置文件。

| 选项 | 默认值 | 含义 |
| fixHostPath | true | 设为 false 以永不触碰宿主 PATH |
| probeLoginShell | true | 同时向登录 shell（$SHELL -lc）询问其完整的 PATH（当 $SHELL 未设置时，回退到 /bin/zsh → /bin/bash → /bin/sh）；设为 false 则仅使用内置候选路径 |

边界：

- 仅前置添加——不会丢弃任何一条继承来的条目；只有存在且尚未出现在 PATH 中的目录才会被添加；
- 当宿主 PATH 已经正常时（例如从终端启动），一个字节都不会改动；
- 一旦所有目录都已存在，待处理集合即为空，因此重复加载是幂等的；
- 在 Windows 上禁用（分隔符和 PATHEXT 语义不同）；
- 这是一种运行时修复：不会写入任何文件，重启应用即可将系统恢复到原状。

若想自行掌控，可将 fixHostPath: false，改为在该行的 env 中放入 PATH （config.env 会在父环境之后合并，官方客户端与本插件的探测行为完全一致）：

- id: mcp-market-fetch
name: "@deepseek-ai/dsh-mcp-client"
config:
transport: stdio
command: uvx
args: [mcp-server-fetch]
env:
PATH: /Users/you/.local/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin

为什么“测试连接”能瞬间返回

stdio 连接几乎把所有时间都花在启动上，而非协议本身。
用真实 SDK 实测：

| 场景 | connect | listTools | close | 总计 |
| uvx stdio，首次运行 | 5023ms | 4ms | 74ms | 5.1s |
| 同一服务器，第二次运行 | ~475ms | 2ms | 71ms | 545ms |
| HTTP 传输 | 128ms | 69ms | 1ms | 197ms |

uvx --help 只需 14ms——uv 二进制本身不是问题；问题在于每次运行都要重建包环境。
listTools 本身只花 2ms。因此所有优化都针对“不再重复支付启动成本”：

1. 运行中的服务器直接从宿主读取：实时连接已经存在，因此直接从宿主读取其已注册的工具，而不是再启动一个进程（545ms → 亚毫秒级）。
2. 关闭操作移出返回路径：结果立即返回，子进程在后台回收（节省约 70ms）。
3. 按钮显示已用秒数：首次运行可能耗时数秒，而一个卡住的“测试中……”比跳动的计数器更难等待。

第 1 点有一条值得留意的边界：只有当 fiber 处于 active 且至少注册了一个工具时，该行才算作运行中。启动失败的 stdio 服务器仍会让 fiber 保持 active（官方默认值为 failOnStartupError: false）——只有工具数量诚实地停留在 0。这类行会走一次真实连接，否则你看到的将是“已连接，0 个工具”，这比直接报错更难调试。

调试时请记住这个特征：绿点 + stdio + 0 个工具 = 它从未启动过。

“连接已关闭”：原因去了哪里，以及为什么有些服务器永远装不上一旦 PATH 修复落地，错误就会从 spawn npx ENOENT 变成 MCP error -32000: Connection closed。这是进展，而不是新的故障：进程启动了，然后自行崩溃了。但界面仍然没有显示任何有用的信息——原因被打印到子进程的 stderr，而传输层默认使用 stderr: "inherit"，所以那些行直接进入宿主机的 stderr，永远不会到达面板。

Stdio 传输现在使用 stderr: "pipe"，并将尾部内容（最多 6 行 / 2 KB，去除 ANSI 颜色代码）折叠进错误中：

Connection failed: MCP error -32000: Connection closed
子进程输出： boom: cannot find module '@modelcontextprotocol/sdk/types.js' 详情：模块解析失败，请检查依赖是否装全

子进程输出： 这个标题是原样保留的：宿主侧的探测消息仍然只有中文，不像面板上的双语文案。子进程自身的输出则原样透传。

还有第二个更棘手的陷阱：“测试连接”会杀掉它正在等待的安装进程。

第一次运行 npx -y 必须把包下载到 ~/.npm/_npx//。有一个真实案例（12306-mcp）拉取了 200 多个依赖，运行了 8 分 44 秒 仍未完成 node_modules，而 15 秒的探测超时早已把它杀掉了。npm 在解包被中断后留下的状态不会自愈：

- 嵌套的 node_modules 是一个空目录；
- .package-lock.json 把依赖记录为 {}；
- 留下一堆 .pkg- 暂存目录。

npx 永远不会修复这种状态——所以每次点击“测试连接”都会再次中断安装，永远如此。当前的处理方式：

| 阶段 | 行为 |
| 冷启动检测 | 命令是 npx 且 ~/.npm/_npx 中没有该包 → 冷启动 |
| 预算 | 冷启动时 60 秒（热启动预算仍为 15 秒） |
| 超时时 | 不杀掉进程——让它继续运行 3 分钟以完成安装 |
| 面板 | 5 秒后显示“首次运行正在下载依赖……”并显示已用秒数 |
| 按钮 | 测试期间禁用——两个包运行器写同一个缓存只会让情况更糟 |

所以“测试一次 → 等一分钟 → 再测试”就能成功，而且等待过程能明显看到进展。

检测刻意保持保守：只有 npx 能被精确检查；uvx / pnpx / bunx 都报告“未知”，并按热启动处理。宁可跳过较长的预算，也不要让每个服务器都等一分钟。

如果你已经卡在损坏的缓存上，插件现在能识别它，并直接把路径放进错误中：

Connection failed: MCP error -32000: Connection closed
子进程输出： code: 'ERR_MODULE_NOT_FOUND', url: 'file:///Users/you/.npm/_npx/a1b2c3d4e5f60718/node_modules/mcp-http-server/node_modules/@modelcontextprotocol/sdk/types.js' 这个包的缓存不完整（上次安装被中断，留下一个空壳目录），npx 不会自动修复。清掉后重装即可：rm -rf "/Users/you/.npm/_npx/a1b2c3d4e5f60718"，再在终端里跑一次 npx -y 等它装完。

有两条出路：原地修复（快，推荐）或从头再来（慢，但保证干净）。
npm 将下载的包保存在其内容寻址存储中，路径为 ~/.npm/_cacache，因此
重新解包它们无需下载：

D=~/.npm/_npx/ # 错误信息中的路径

半途而废的残留：npm 在解包中途留下的 .pkg- 暂存目录 find "$D/node_modules" -maxdepth 1 -type d -name '.-' -delete 空壳：目录存在但没有任何文件——这正是 npx 一直从中加载的东西 find "$D/node_modules" -type d -empty -delete

cd "$D" && npm install # 解包 package-lock.json 中缺失的任何包

只会删除空目录和 npm 自己的暂存残留——两者都不包含真实数据，而已成功安装的包则原封不动。

如果你更想从头开始，就删除整个目录。请注意，你必须复用配置中的确切命令：npx 会根据命令推导出缓存目录名，因此不同的命令会安装到完全不同的位置。

rm -rf ~/.npm/_npx/
npx -y # 来自你 MCP 配置的命令；安装后它会启动并停留在那里——稍等，然后按 Ctrl+C

定时同步

两个触发器，共用一把锁——手动同步和定时同步绝不会同时运行：

| 触发器 | 时机 | 默认值 |
| 手动 | 你在面板中按下 Sync catalog | 始终可用 |
| 启动 | 每次启动一次，仅当本地缓存缺失或超过 6 小时 | 开启，启动后 15 秒 |
| 间隔 | DSH 运行期间每隔 intervalHours | 每 24 小时 |

通过向你的 profile 的 cordis.patch.yml 添加一行具有相同 id 的配置来配置它—— profile 层优先，而补丁会替换整个 config，因此请重新声明你想保留的每一个键：

- id: mcp-market
name: dsh-mcp-market
config:
autoSync: false # 完全关闭间隔同步 intervalHours: 12 # 0.25 – 168 syncOnStart: true startDelayMs: 30000 maxRequests: 400 # 关键词扇出请求预算

配置修改通过 HMR 热重载。面板的状态行始终显示当前计划和上次同步时间。定时器绑定到插件的生命周期，并在卸载或重载时清除，因此插件被禁用后不会有任何东西继续轮询。

兼容性

| 层面 | 状态 |
| DeepSeek Harness | 0.1.7-rc.1（已验证） |
| Node | ^22.19.0 \|\| >=24.0.0 |
| 平台 | 全部（纯 ESM，无原生代码） |
| 模型 | 任意（无模型交互） |

开发

node test/patch.test.mjs # 配置文件安全性（重写、共存、校验）
node test/market.test.mjs # 过滤、转换、差异比较 + 实时目录检查
node test/scheduler.test.mjs # 同步计划：配置钳制、生命周期、并发
node test/keywords.test.mjs # 关键词扇出 + 300 行匿名上限
node test/status.test.mjs # 加载器入口查找、fiber 阶段、已注册工具及其名称bash
node test/host-path.test.mjs # 宿主 PATH 修复：幂等性、仅前置、回退、开关
node test/package-runner.test.mjs # 运行器检测 + 冷启动检查（从不猜测）
node test/gateway-live.test.mjs # 从宿主读取正在运行的服务器（包括“绿点说谎”回退）
node test/probe-close.test.mjs # 探测：关闭返回路径 + 毫秒级快速失败
node test/probe-recovery.test.mjs # stderr 透传 + 不终止冷启动安装 + 损坏缓存提示
node test/client-render.test.mjs # 无需浏览器渲染客户端 bundle + 源码守卫
node test/wire-contract.test.mjs # 宿主清单 ↔ 客户端贡献对等 + 保留名称

market.test.mjs 和 keywords.test.mjs 需要网络访问；设置 SKIP_ONLINE=1（或断开连接）以仅运行其离线部分。client-render.test.mjs 通过一个桩模块加载器安装客户端 bundle，并用 react-dom/server 渲染它——它能捕获仅运行时才会出现的故障，例如未定义的标识符，否则会使面板空白。它还带有一组源码契约守卫，用于检查语法检查无法发现的问题：主题令牌拼写（见下文）以及原生 window.confirm 的误用。

主题令牌（一个值得了解的陷阱）

拼写错误的 CSS 自定义属性会静默失败——它只会回退到继承的颜色，因此面板看起来会微妙地出错，而控制台中没有任何信息。对照浅色主题测量：

- --dsw-alias-state-warn-primary ✅ 存在（#f59e0b）
- --dsw-alias-state-warning-primary ❌ 未定义

本插件中有两处使用了后者，导致 loading 状态点完全没有背景色。它们现在使用回退链，
var(--dsw-alias-state-warn-primary,var(--dsw-alias-state-warning-primary,#f59e0b))，并且
client-render.test.mjs 会对照已验证的允许列表检查所使用的每个令牌。

主题令牌是在运行时注入到 上的——不是 document.documentElement，也不是作为可枚举的 CSSOM 规则。检查它们的唯一方法是 getComputedStyle(document.body)。

卸载 bash
dsh plugin --profile web remove dsh-mcp-market

你安装的服务器会保留在 cordis.patch.yml 中（它们是普通的 DSH MCP 行）。如果你希望该文件保持干净，请先从“已安装”标签页中移除它们。

许可证

MIT