1. 为什么 stdio 型 MCP 服务在 Dify 里总是接不上如果你最近在折腾 Dify 的 MCP 插件大概率会遇到一个很尴尬的情况社区里能直接填 URL 的远程 SSE 服务一抓一大把但真正想用的开源 MCP 服务翻开源码一看启动方式全是stdio。Dify 的 MCP 插件只认sse或streamableHttp这类网络端点它没法帮你在服务器上拉起一个子进程再喂标准输入输出。于是你手里明明有一堆好用的 MCP 工具却卡在“协议对不上”这一步。这个问题的本质是传输层不匹配。stdio型 MCP 服务是给本地客户端比如 Claude Desktop、Cursor设计的客户端负责 fork 进程、通过 stdin/stdout 收发 JSON-RPC 消息。而 Dify 作为 Web 端的编排平台只能通过 HTTP 去访问一个已经监听端口的服务。中间缺的这层“翻译”就是 Supergateway 要干的事——它把 stdio 子进程包装成一个 SSE 服务对外暴露/sse和/message端点Dify 就能像调用普通远程 MCP 一样调用它。这篇内容面向的是已经在服务器上有 Dify、想把手头 stdio 型 MCP 服务接进去的人。我会把整条链路拆开从 TaoToken 统一 Key 的接入准备到 Supergateway 的启动命令再到 Dify 侧填地址、curl 验证、以及几个我实际踩过的坑。你跟着做最后应该能拿到一个稳定的 SSE 端点并且知道出问题时该看哪一行日志。需要先说明一点Supergateway 本身不解决模型调用的问题它只管传输转换。真正让 MCP 工具背后的大模型跑起来还需要一个统一的 API 通道。我这边用的是 TaoToken 来做 Key 和通道的统一管理后面会讲怎么把它和 MCP 服务的环境变量串起来。2. TaoToken 前置统一 Key 与 API 通道准备在动手转 SSE 之前先把“模型侧”的接入理清楚否则 MCP 工具调通了、背后模型却连不上排查起来会两头乱。TaoToken 在这里的角色是提供一个统一的 API 入口和 Key 管理你不需要在每台服务器、每个 MCP 服务里散落不同的厂商 Key。先到官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册并登录然后在控制台里创建一个 API Key。这个 Key 就是你后面所有请求的凭证。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite Key 管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。创建完之后先复制出来存好页面刷新后就不再完整显示了。API 的基础地址是 https://taotoken.net/api 注意这个地址不带任何查询参数直接作为base_url用。如果你用的是 OpenAI 兼容的 SDK把base_url指向它、api_key填刚才创建的 Key 就行。想先确认模型通不通可以直接去模型对话页 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 发一条测试消息能正常返回就说明 Key 和通道没问题。这里有个关键点MCP 服务本身通常不直接调模型它只是暴露工具。真正调模型的是 Dify 里的 Agent 或工作流节点。所以 TaoToken 的 Key 主要配在 Dify 的模型供应商设置里而不是配在 Supergateway 里。但有些 MCP 服务比如带摘要、带检索增强的会自己发起模型请求这时候就需要通过环境变量把OPENAI_BASE_URL和OPENAI_API_KEY传给它。两种场景我都会在配置章节里给出写法。如果你后面要长期跑编码类 Agent或者想让 MCP 工具链和 Coding 场景打通可以了解一下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。它和本篇的 SSE 转换不冲突属于上层用法。3. 可复制配置Supergateway 启动与 MCP 服务骨架这一章是核心所有命令都可以直接复制改路径使用。整体思路是用 pm2 守护一个 Supergateway 进程Supergateway 再去拉起真正的 stdio MCP 服务。3.1 环境准备与目录创建先确认服务器上有 Node.js建议 18 以上和 npm。然后创建工作目录这个目录是给 filesystem 这类需要读写文件的 MCP 服务用的其他服务可以换成自己的路径。mkdir -p /opt/mcp/my-folder sudo chmod ow /opt/mcp/my-folder npm install -g pm2chmod ow是为了让以非 root 身份运行的 MCP 进程有写权限。如果你用 root 跑可以跳过但不建议长期用 root 跑 MCP 服务。3.2 Supergateway 启动命令拆解官方最简命令长这样我把它拆成带注释的版本方便你替换参数pm2 start --name mcp-filesystem \ npx -- -y supergateway \ --port 8951 \ --baseUrl http://127.0.0.1:8951 \ --ssePath /sse \ --messagePath /message \ --stdio npx -y modelcontextprotocol/server-filesystem /opt/mcp/my-folder逐项说明参数作用建议值--portSupergateway 监听的端口8951按需改--baseUrl对外暴露的基础地址内网用 127.0.0.1 或内网 IP--ssePathSSE 端点路径/sse--messagePath消息回传路径/message--stdio要拉起的 stdio MCP 命令完整命令字符串--baseUrl这个参数容易被忽略。如果你 Dify 和 MCP 在同一台机器填http://127.0.0.1:8951就行如果 Dify 在另一台内网机器要填这台机器的内网 IP否则 SSE 事件里返回的 message 地址会指向 localhostDify 那边就回传不了消息。3.3 带 TaoToken 环境变量的 MCP 服务骨架有些 MCP 服务启动时需要模型凭证。以需要调用模型的场景为例可以在 pm2 启动时注入环境变量pm2 start --name mcp-custom \ --env OPENAI_BASE_URLhttps://taotoken.net/api \ --env OPENAI_API_KEY你的TaoTokenKey \ npx -- -y supergateway \ --port 8952 \ --baseUrl http://内网IP:8952 \ --stdio npx -y 你的-mcp-包名注意OPENAI_BASE_URL填的是https://taotoken.net/api不要加多余路径。Key 就是第 2 章创建的那个。这样 MCP 服务内部如果走 OpenAI 兼容协议就会自动走 TaoToken 通道。3.4 查看启动状态pm2 logs mcp-filesystem --lines 50看到类似Server is running on port 8951以及 stdio 子进程启动成功的日志就说明 Supergateway 已经把 MCP 服务拉起来了。如果日志里出现spawn npx ENOENT说明服务器 PATH 里找不到 npx用绝对路径替换npx即可。4. 验证请求curl 测 SSE 端点与 Dify 调用成功检查配置写完不能直接扔给 Dify先用 curl 确认 SSE 端点活着。4.1 curl 验证 SSE 端点curl -N http://127.0.0.1:8951/sse-N是关闭缓冲让你能实时看到事件流。正常情况会先返回一行event: endpoint后面跟着data: /message?sessionIdxxxx。这个 sessionId 很关键它是后续消息回传的会话标识。如果你只看到连接建立但没有 endpoint 事件多半是--baseUrl配错了或者端口被防火墙拦了。拿到 sessionId 后可以进一步测消息通道是否通curl -X POST http://127.0.0.1:8951/message?sessionId上一步的sessionId \ -H Content-Type: application/json \ -d {jsonrpc:2.0,id:1,method:tools/list,params:{}}如果返回工具列表的 JSON说明整条 stdio 到 SSE 的链路是通的。这一步能过Dify 那边基本不会出问题。4.2 Dify 侧填写 SSE 地址在 Dify 的 MCP 插件配置里填写的结构是这样的{ mcpServers: { filesystem: { type: sse, url: http://你的服务器内网IP:8951/sse } } }几个要点type必须是sseurl用内网 IP不要用127.0.0.1除非 Dify 和 MCP 在同一台机器且同网络命名空间端口要和 Supergateway 的--port一致。保存后 Dify 会去连这个地址连接成功的话插件状态会变成已连接并且能列出该 MCP 服务暴露的工具。4.3 调用成功的检查动作连接成功后在 Dify 的 Agent 或工作流里挂上这个 MCP 工具发一条会触发工具调用的指令。比如 filesystem 服务让它读某个文件。观察两个地方一是 Dify 的运行日志里有没有工具调用记录二是服务器上pm2 logs mcp-filesystem有没有对应的请求日志。两边都有记录才算真正打通。只看到 Dify 显示连接成功但调用无反应通常是--baseUrl导致 message 回传地址不对。5. 本篇常见错排查这一章列几个我实际遇到过的报错按出现频率排序。连接超时或 Dify 一直转圈先确认 Dify 所在机器能不能curl通 MCP 服务器的端口。内网不通多半是安全组或防火墙没放行。云服务器记得在控制台放行对应端口本机ufw或firewalld也要检查。SSE 连上了但工具调用无返回九成是--baseUrl填了127.0.0.1而 Dify 在另一台机器。SSE 事件里返回的 message 地址是127.0.0.1Dify 回传消息时打到了自己身上。把--baseUrl改成 MCP 服务器的内网 IP 重启即可。spawn npx ENOENTpm2 启动时的 PATH 和登录 shell 不一样。用which npx找到绝对路径把--stdio里的npx换成绝对路径比如/usr/local/bin/npx。端口被占用pm2 delete mcp-filesystem后换端口重启。注意 pm2 的进程名不要重复重复了会启动失败但日志不明显。MCP 服务需要写权限却报 EACCES检查工作目录权限以及 pm2 是以哪个用户跑的。pm2 startup配的开机自启默认可能用 root和手动启动的用户不一致权限会错乱。TaoToken Key 报 401确认OPENAI_BASE_URL是https://taotoken.net/api没有多余斜杠或路径Key 没有多余空格如果 Key 是在控制台刚创建的确认复制完整。可以先用模型对话页发一条消息验证 Key 本身有效。Dify 插件保存时报 JSON 格式错误mcpServers的 JSON 结构对缩进不敏感但对引号和逗号敏感。建议在本地用 JSON 校验工具过一遍再粘贴。6. 后续接入与统一通道建议把 stdio 转 SSE 这件事跑通一次之后后面再接其他 MCP 服务就是复制粘贴改参数。我的做法是每个 MCP 服务分配一个独立端口pm2 进程名带服务名日志分开看互不干扰。端口规划上留出区间比如 8951 到 8999避免和现有服务撞车。模型通道这边统一用 TaoToken 的 Key 之后Dify 的模型供应商配置和 MCP 服务内部的环境变量可以共用同一个 Key换 Key 时只改一处。Dify 侧接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有 base_url 和鉴权的完整说明。如果你用的是 Claude Code 这类编码工具Anthropic 兼容的接入方式在 https://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecode-anthropicutm_campaignrewrite 有单独说明和本篇的 SSE 转换是两条并行的链路。最后提醒一个实操细节Supergateway 拉起的 stdio 子进程如果崩了pm2 默认不会自动重启子进程只会重启 Supergateway 本身。可以在--stdio命令外面套一层重试脚本或者用 pm2 的--restart-delay配合健康检查。这个坑在多服务并行时比较隐蔽日志里表现为 SSE 端点还在但工具列表为空重启 pm2 进程就能恢复。