【DSH 插件·协议与框架】dsh-mcp-connector:接 MCP、找工具、管权限,一个面板

DSH 的配置文件里，MCP server 是一台一段接进去的。第一次接的时候挺顺：打开 cordis.yml，给 @deepseek-ai/dsh-mcp-client 写一段 insert，command、args、env 摆好，重启，工具列表里多出七八个 mcp__ 开头的名字。接到第五台的时候麻烦来了——每台 server 一段配置，凭据就躺在 yml 里；要接的服务商要求 OAuth，token 得自己换、自己塞 headers、过期自己再换一遍；工具加到上百个之后，定义全量常驻上下文，模型每次该看见哪些全凭运气；连接挂了，分不清是授权过期、网络不通还是发现层坏了。问题不在引擎，在管理面——基线至今只给了前者。

给官方引擎补一块管理面板

dsh-mcp-connector（当前 0.2.70，MIT）不重写官方传输层，stdio 和 streamable-http 照样走官方 dsh-mcp-client，它补的是引擎之外的那一圈：一个 109 张卡片的连接器市场、OAuth 2.0 PKCE 全流程、跨连接工具搜索、三层治理和按会话的工具注入。

拆开看是三件事。先说目录：市场页按九类摆着远程 registry 的 109 张连接器卡片加四张随包内置卡，registry 独立于 npm 更新，新服务商上线不用等插件发版，看中一张卡、点连接、按提示补凭据，配置由插件替你写进官方客户端的条目里。授权是第二块：OAuth 走 PKCE 加动态客户端注册，token 自动刷新、退避、撤销，多个 DSH 进程共享一份带锁的授权记录，落在本机受限权限的目录和文件里；同类插件没有一家把这个闭环做完整。可见性是第三块：跨连接的工具搜索基于每台连接最后成功的缓存，对话里一句 tool_search 就能定位工具在哪台 server，连接失败时缓存还能告诉你上次可用时长什么样；治理从 Connection、Server 到 Tool 三层 allow/deny，被批准的工具经会话注入进入上下文，最长 30 分钟自动收回。

换个说法：只接一台 keyless 的本地 stdio server，手写官方配置就够，这个插件价值不大；但只要 server 要 OAuth、超过三台、或者工具多到模型挑花眼，它补的就是基线没有的那半边。

▲ 注入面：插件不重写传输层，向宿主注入工具、存储、loader 等服务，把连接条目写进官方 mcp-client 的配置位置；外联共五个面——目录拉取、版本检查、OAuth、MCP 协议流量、扩展安装——全部有界，目录源可置空实现离线。

装之前，先看它碰什么

静态审计结论是 pass，无 high 无 critical。三条 medium 都属于用户显式动作触发的有界能力：install.sh 提供 curl 竖线 bash 的安装路径，不用它、走 dsh plugin add 就绕开；installFromUrl 接受任意 https JSON，但响应要过 URL 审计器加两兆上限加结构校验；stdio 传输会拉起你配置的 command，带进程组看门狗，挂死会被整组回收。安装期没有任何生命周期脚本，运行时依赖只有 cross-spawn 一个；无遥测、无外部写、导出配置时凭据全部替换成重填占位符。

凭据面值得单独说。授权令牌只落在本机 0700 目录下的 0600 文件里，浏览器侧和编辑器侧永远拿不到敏感值，快照接口只回摘要。对 DSH 用户更实际的一条：真实 ~/.dsh 之外的任何路径它都不写，数据和配置全部收在自己的存储域里，卸载即清。

两个如实交代的保留项。第一，单一维护者，七周发了 73 个版本，迭代极快但没有稳定版可追，装的时候锁定版本号。第二，README 的兼容矩阵还写着只支持 0.1.x 线，实际安装门禁早已放宽到 0.2.x——文档滞后，以包声明和门禁判定为准。

▲ 生命周期：安装进 profile 后，市场页拉目录、选卡接 server、按需走 OAuth 授权，工具发现进缓存，治理层决定可见范围，会话注入带 30 分钟过期；卸载后配置行、工具注册和界面席位全部注销。

在名单之外的基线上跑一遍

插件声明的兼容范围覆盖 0.1.1-rc.2 起与 0.2.x 线，当前的 0.2.1-alpha.1 落在范围内、宿主门禁判定放行——顺带一提，0.2.x 支持是九月底才补上的，此前早期 0.2 宿主上插件会被整体跳过、已接的 MCP server 全部消失，这段历史也解释了 README 矩阵为什么慢半拍。隔离环境里装的是与 npm 发布物哈希一致的 tarball：插件自带的 37 个测试文件跑出 332 个用例，328 个通过、四个跳过、零失败。跳过的四个里三个是需要真实 MCP SDK 的选做集成测试，补上依赖后单独重跑也全过——包括真实客户端从插件的受管入口拉起子进程、完成握手、列出工具，以及两个挂死场景被看门狗按进程组回收，这是 stdio 拉起路径最直接的动态证据。随包七张连接器卡片全部通过包内审计器；装进一次性 DSH_HOME 后组合出的配置行与声明逐字段一致，卸载后归零、无残留。

▲ 测试输出：37 个测试文件的 332 个用例，328 通过、零失败；四个跳过项中三个选做集成测试补跑后全过，真实 MCP 客户端经受管入口完成握手，挂死场景被进程组回收。

▲ 冒烟记录：一次性 DSH_HOME 里 plugin add 后 dump-config 组合出一行 dsh-mcp-connector，字段与声明一致；remove 后归零。真实 ~/.dsh 全程未动。

没碰到的也说清楚：没做真实 OAuth 授权（需要真实服务商账号），没在真实浏览器里渲染面板，没在真实会话里让模型调遍全部对话工具。这些不影响安装判断，但第一次接 OAuth 服务商时，授权流顺不顺畅要自己再看一眼。

同一件事的四条路

▲ 四条路：基线引擎完整但无管理面；manager 走极简 GUI 路线；registry 用 fail-closed 审批换安全；connector 把目录、授权、搜索、治理串成一个闭环，是四条路里唯一齐的。

基线内置的引擎能连、能注册、能重连，但没有 OAuth、没有目录、没有搜索、没有专用界面，每台 server 手写一段配置。@xxxyz/dsh-mcp-manager 走极简路线：GUI 增删改、健康检查、四个模型工具，够快够轻，但授权和跨连接搜索缺位。dsh-mcp-registry 的独门是 fail-closed 审批——destructive 工具硬否决，防误调用放第一位，但没有界面、没有 OAuth，和这个插件是互补不是平替。dsh-mcp-connector 的差异化在闭环：目录解决发现，搜索解决定位，OAuth 解决授权，治理解决边界，四个环节串在一个面板里；目录里任何一家同类，最多补齐其中两环。

反过来看什么人不该装。只接一两台 keyless server 的个人用户，手写官方 overlay 更省心；把防误调用放第一位、不在乎界面的团队，registry 的审批模式更对口。

装不装

MCP 规模化的瓶颈不在连上一台 server，而在工具从十几个涨到上百个之后，模型每次该看见哪些。常驻注入把所有工具定义塞进每次请求，token 和注意力一起被吃掉；按会话注入让批准的工具只在这轮对话里可见，到期自动收回。常驻和按需之间这条线，就是这个插件值不值得装的分水岭，也是评估任何 MCP 管理工具时的第一个问题。

结论是 install：审计干净、新基线实测全过、OAuth 加目录在同类里独有。装的时候认准 npm 的 0.2.70，不用 install.sh，单人高速迭代记得锁版本。今天的第一步：dsh plugin --profile web add dsh-mcp-connector，重启后在市场页接一台 keyless stdio server，到工具页搜一次工具，再在治理层把它收进 project 作用域——从目录到治理走一圈，十分钟就知道这块管理面板合不合手。

参考：github.com/duhu2000/dsh-mcp-connector（v0.2.70）；github.com/deepseek-ai/deepseek-harness（dsh-v0.2.1-alpha.1）；github.com/awesome-dsh-plugin/awesome-dsh-plugin