1. 为什么要把 Dify 工作流变成 MCP Server如果你已经在 Dify 里搭过几套能跑通的工作流大概率会遇到一个尴尬这些工作流只能在 Dify 自己的对话界面里用一旦想接到 Cursor、Cherry Studio 或者别的支持 MCP 的客户端里就得重新写一遍逻辑。Dify 工作流本身封装得挺好但对外输出能力这件事过去一直缺一个标准出口。MCPModel Context Protocol解决的正是这个问题。它把「工具」抽象成一套客户端能识别的协议只要你的服务端按 MCP 格式暴露工具描述和调用入口任何 MCP Client 都能像调用本地函数一样调用它。把 Dify 工作流包装成 MCP Server本质上是给工作流加了一个「万能转换头」工作流还是那个工作流但对外说话的方式变成了 MCP 普通话。这篇面向的是已经用 Dify 搭过工作流、想快速把工作流升级成智能 Agent 可调用插件的开发者。我会交付一套可复制的 MCP Server 插件配置骨架含 settings.json / config.toml 示例把 TaoToken 统一 Key 接入进去再给出插件调用的验证动作和常见报错排查清单。目标很明确一次跑通「工作流 → MCP Server → 客户端调用」的闭环。需要提前说一句MCP Server 插件官方建议只在私有网络环境里使用因为它会把你的工作流端点暴露出去敏感数据的工作流别往公网扔。2. TaoToken 前置统一 Key 与 API 通道准备在配 MCP Server 之前先把模型调用通道理顺。Dify 工作流里如果涉及 LLM 节点默认走的是 Dify 自己配置的模型供应商。但当你把工作流包装成 MCP Server 对外提供服务时调用方可能是 Cursor 这类客户端它们自己也要调模型。这时候如果每个客户端都单独配一套 Key管理起来会很乱。TaoToken 在这里的作用是提供一个统一的 Key 和 API 通道。你可以在 TaoToken 控制台生成一个 API Key然后让 Dify 工作流和 MCP Client 都走这个通道。这样模型调用入口收敛到一处排查问题时不用在多个供应商后台之间跳。具体操作路径进入 TaoToken 控制台在 API Keys 页面创建一个新 Key记下sk-开头的字符串。这个 Key 后面会同时用在两个地方一是 Dify 的模型供应商配置里二是 MCP Client 的模型配置里。TaoToken 的 API 地址是https://taotoken.net/api兼容 OpenAI 风格的接口。在 Dify 里配置模型供应商时选择「OpenAI-API-compatible」类型Base URL 填https://taotoken.net/apiAPI Key 填刚才生成的 Key模型名称按你实际要用的填。如果你还没决定用哪个模型可以先到模型对话页面试一下通道是否通。这一步别跳过因为后面 MCP Server 调用失败时有一半概率是模型通道本身就没通。对于长期跑编码类工作流、或者要接 Agent 的场景可以考虑 Coding Plan它在调用频次和成本上更适合持续性的开发任务。但如果你只是先跑通闭环用按量计费的 API Key 就够了。3. 可复制配置MCP Server 插件骨架这一节是核心。我会给出 Dify 侧 MCP Server 插件的配置步骤以及客户端侧的 settings.json / config.toml 骨架。3.1 Dify 侧安装并配置 MCP Server 插件进入 Dify 控制台打开插件市场搜索mcp-server点击安装。安装完成后进入插件配置界面点「」新增一个工具端点。这里有几个字段需要填Endpoint Name 填一个你认得出来的名字比如drawing-master。App 选择你要发布为 MCP Server 的那个 Dify 应用App Type 选Workflow。App Input Schema 是重点它定义了外部系统怎么理解这个工具的输入。Schema 的 JSON 结构长这样{ name: drawing_master, description: generate the image based on the input description of the user, inputSchema: { title: drawing master description, type: object, properties: { query: { title: User Query, description: The users description of the image to be generated, type: string } }, required: [query] } }name是对外暴露的工具名description是给客户端模型看的说明inputSchema.properties里定义参数。上面这个例子对应一个「输入一段文字描述生成图片」的工作流所以只有一个query字符串参数且设为必填。保存后系统会生成一个端点 URL格式类似https://your-dify-host/v1/e/xxxxx/sse。这个 URL 就是 MCP Server 的入口相当于你家门禁密码别随便贴到公开地方。3.2 客户端侧settings.json 配置以 Cursor 为例打开设置里的 MCP 配置添加{ mcpServers: { drawing-master: { url: https://your-dify-host/v1/e/xxxxx/sse } } }如果你用的是支持 stdio 方式的客户端或者想把配置写进项目级的settings.json结构是一样的只是url换成对应的传输方式。注意url里的xxxxx要替换成你实际生成的端点 ID。3.3 config.toml 配置骨架有些客户端比如部分 CLI 工具用 TOML 格式管理 MCP Server。对应的config.toml骨架[[mcp_servers]] name drawing-master transport sse url https://your-dify-host/v1/e/xxxxx/sse timeout 30 [mcp_servers.env] TAOTOKEN_API_KEY sk-your-taotoken-key TAOTOKEN_BASE_URL https://taotoken.net/api这里把 TaoToken 的 Key 和 Base URL 通过环境变量注入好处是客户端调模型时可以直接读这两个变量不用在每个工具里重复配。timeout设 30 秒工作流如果涉及图片生成可以适当调大。4. 验证请求从客户端调通工作流配置写完别急着高兴先验证。第一步确认 MCP Server 端点本身活着。用 curl 探一下 SSE 端点curl -N https://your-dify-host/v1/e/xxxxx/sse如果返回一串event: endpoint之类的 SSE 流说明端点通了。如果返回 404 或 502说明 Dify 侧插件没配好或者服务没起来。第二步在 Cursor 里打开 MCP 面板看drawing-master是否显示为已连接。如果显示连接错误先看下一节的排查清单。第三步实际调用一次。在 Cursor 的对话里输入类似「用 drawing-master 生成一张日落海滩的图」观察客户端是否把query参数传给了 MCP Server以及 Dify 工作流是否被触发。一个成功的调用链路是这样的Cursor 识别到需要调用drawing-master工具 → 通过 SSE 把{query: 日落海滩}发给 Dify MCP Server → Dify 触发对应工作流 → 工作流内部通过 TaoToken 通道调模型 → 返回结果 → Cursor 展示。如果工作流跑通了但客户端没收到结果大概率是 SSE 连接超时或者返回格式不对。这时候去 Dify 的插件日志里看请求记录对比客户端发出的参数和工作流期望的参数是否一致。5. 常见报错排查清单这一节按我实际踩过的坑整理遇到问题按顺序查。连接错误 / SSE 握手失败先确认 Dify 实例是否可以从客户端所在网络访问。如果 Dify 部署在内网客户端也在内网检查端口和防火墙。如果 Dify 在本地localhost客户端在另一台机器localhost是不通的要换成实际 IP。工具列表为空MCP Server 连上了但客户端看不到工具。检查 Dify 插件里是否真的保存了端点配置以及inputSchema的 JSON 是否合法。一个常见的错误是properties里参数类型写错比如把string写成str。调用返回 400 / 参数校验失败客户端传的参数名和 Schema 里定义的不一致。比如 Schema 里定义的是query客户端传的是input就会报错。检查客户端侧工具描述是否和 Dify 侧同步。工作流执行超时图片生成、长文本处理这类工作流容易超时。把客户端timeout调大同时检查 Dify 工作流本身是否有节点卡住。如果工作流里调了 TaoToken 通道确认 Key 没过期、余额够。模型调用 401 / 403TaoToken 的 Key 无效或没权限。到控制台确认 Key 状态以及 Base URL 是否填成了https://taotoken.net/api注意不要多加斜杠或路径。返回结果乱码或截断SSE 流式返回时客户端没正确处理分块。这种情况通常换一个客户端版本或者改用非流式传输能解决。排查时有个通用思路先在 Dify 里单独跑一遍工作流确认工作流本身没问题再用 curl 直接打 MCP 端点确认端点没问题最后才怀疑客户端配置。这样能把问题范围快速缩小。6. 把闭环跑顺之后工作流变成 MCP Server 之后最大的变化是复用成本降下来了。以前每接一个新客户端就要重写一遍对接逻辑现在只要客户端支持 MCP改一下settings.json里的 URL 就能用。Dify 里已经调好的工作流不用二次开发就能被 Cursor、Cherry Studio 这些工具调用。TaoToken 统一 Key 在这里的价值也会随着接入的客户端数量增加而放大。一个 Key 管住所有模型调用入口换模型、查用量、控成本都在一处。如果你后面要接多个 MCP Client建议把 Key 和 Base URL 统一放到环境变量里别硬编码在配置文件里。最后留一个实操建议先把一个最简单的工作流比如只做文本处理、不涉及图片生成的包装成 MCP Server 跑通确认整条链路没问题再往上叠复杂工作流。这样出问题时排查范围小不至于一上来就被多个变量搞晕。
1. 为什么要把 Dify 工作流变成 MCP Server如果你已经在 Dify 里搭过几套能跑通的工作流大概率会遇到一个尴尬这些工作流只能在 Dify 自己的对话界面里用一旦想接到 Cursor、Cherry Studio 或者别的支持 MCP 的客户端里就得重新写一遍逻辑。Dify 工作流本身封装得挺好但对外输出能力这件事过去一直缺一个标准出口。MCPModel Context Protocol解决的正是这个问题。它把「工具」抽象成一套客户端能识别的协议只要你的服务端按 MCP 格式暴露工具描述和调用入口任何 MCP Client 都能像调用本地函数一样调用它。把 Dify 工作流包装成 MCP Server本质上是给工作流加了一个「万能转换头」工作流还是那个工作流但对外说话的方式变成了 MCP 普通话。这篇面向的是已经用 Dify 搭过工作流、想快速把工作流升级成智能 Agent 可调用插件的开发者。我会交付一套可复制的 MCP Server 插件配置骨架含 settings.json / config.toml 示例把 TaoToken 统一 Key 接入进去再给出插件调用的验证动作和常见报错排查清单。目标很明确一次跑通「工作流 → MCP Server → 客户端调用」的闭环。需要提前说一句MCP Server 插件官方建议只在私有网络环境里使用因为它会把你的工作流端点暴露出去敏感数据的工作流别往公网扔。2. TaoToken 前置统一 Key 与 API 通道准备在配 MCP Server 之前先把模型调用通道理顺。Dify 工作流里如果涉及 LLM 节点默认走的是 Dify 自己配置的模型供应商。但当你把工作流包装成 MCP Server 对外提供服务时调用方可能是 Cursor 这类客户端它们自己也要调模型。这时候如果每个客户端都单独配一套 Key管理起来会很乱。TaoToken 在这里的作用是提供一个统一的 Key 和 API 通道。你可以在 TaoToken 控制台生成一个 API Key然后让 Dify 工作流和 MCP Client 都走这个通道。这样模型调用入口收敛到一处排查问题时不用在多个供应商后台之间跳。具体操作路径进入 TaoToken 控制台在 API Keys 页面创建一个新 Key记下sk-开头的字符串。这个 Key 后面会同时用在两个地方一是 Dify 的模型供应商配置里二是 MCP Client 的模型配置里。TaoToken 的 API 地址是https://taotoken.net/api兼容 OpenAI 风格的接口。在 Dify 里配置模型供应商时选择「OpenAI-API-compatible」类型Base URL 填https://taotoken.net/apiAPI Key 填刚才生成的 Key模型名称按你实际要用的填。如果你还没决定用哪个模型可以先到模型对话页面试一下通道是否通。这一步别跳过因为后面 MCP Server 调用失败时有一半概率是模型通道本身就没通。对于长期跑编码类工作流、或者要接 Agent 的场景可以考虑 Coding Plan它在调用频次和成本上更适合持续性的开发任务。但如果你只是先跑通闭环用按量计费的 API Key 就够了。3. 可复制配置MCP Server 插件骨架这一节是核心。我会给出 Dify 侧 MCP Server 插件的配置步骤以及客户端侧的 settings.json / config.toml 骨架。3.1 Dify 侧安装并配置 MCP Server 插件进入 Dify 控制台打开插件市场搜索mcp-server点击安装。安装完成后进入插件配置界面点「」新增一个工具端点。这里有几个字段需要填Endpoint Name 填一个你认得出来的名字比如drawing-master。App 选择你要发布为 MCP Server 的那个 Dify 应用App Type 选Workflow。App Input Schema 是重点它定义了外部系统怎么理解这个工具的输入。Schema 的 JSON 结构长这样{ name: drawing_master, description: generate the image based on the input description of the user, inputSchema: { title: drawing master description, type: object, properties: { query: { title: User Query, description: The users description of the image to be generated, type: string } }, required: [query] } }name是对外暴露的工具名description是给客户端模型看的说明inputSchema.properties里定义参数。上面这个例子对应一个「输入一段文字描述生成图片」的工作流所以只有一个query字符串参数且设为必填。保存后系统会生成一个端点 URL格式类似https://your-dify-host/v1/e/xxxxx/sse。这个 URL 就是 MCP Server 的入口相当于你家门禁密码别随便贴到公开地方。3.2 客户端侧settings.json 配置以 Cursor 为例打开设置里的 MCP 配置添加{ mcpServers: { drawing-master: { url: https://your-dify-host/v1/e/xxxxx/sse } } }如果你用的是支持 stdio 方式的客户端或者想把配置写进项目级的settings.json结构是一样的只是url换成对应的传输方式。注意url里的xxxxx要替换成你实际生成的端点 ID。3.3 config.toml 配置骨架有些客户端比如部分 CLI 工具用 TOML 格式管理 MCP Server。对应的config.toml骨架[[mcp_servers]] name drawing-master transport sse url https://your-dify-host/v1/e/xxxxx/sse timeout 30 [mcp_servers.env] TAOTOKEN_API_KEY sk-your-taotoken-key TAOTOKEN_BASE_URL https://taotoken.net/api这里把 TaoToken 的 Key 和 Base URL 通过环境变量注入好处是客户端调模型时可以直接读这两个变量不用在每个工具里重复配。timeout设 30 秒工作流如果涉及图片生成可以适当调大。4. 验证请求从客户端调通工作流配置写完别急着高兴先验证。第一步确认 MCP Server 端点本身活着。用 curl 探一下 SSE 端点curl -N https://your-dify-host/v1/e/xxxxx/sse如果返回一串event: endpoint之类的 SSE 流说明端点通了。如果返回 404 或 502说明 Dify 侧插件没配好或者服务没起来。第二步在 Cursor 里打开 MCP 面板看drawing-master是否显示为已连接。如果显示连接错误先看下一节的排查清单。第三步实际调用一次。在 Cursor 的对话里输入类似「用 drawing-master 生成一张日落海滩的图」观察客户端是否把query参数传给了 MCP Server以及 Dify 工作流是否被触发。一个成功的调用链路是这样的Cursor 识别到需要调用drawing-master工具 → 通过 SSE 把{query: 日落海滩}发给 Dify MCP Server → Dify 触发对应工作流 → 工作流内部通过 TaoToken 通道调模型 → 返回结果 → Cursor 展示。如果工作流跑通了但客户端没收到结果大概率是 SSE 连接超时或者返回格式不对。这时候去 Dify 的插件日志里看请求记录对比客户端发出的参数和工作流期望的参数是否一致。5. 常见报错排查清单这一节按我实际踩过的坑整理遇到问题按顺序查。连接错误 / SSE 握手失败先确认 Dify 实例是否可以从客户端所在网络访问。如果 Dify 部署在内网客户端也在内网检查端口和防火墙。如果 Dify 在本地localhost客户端在另一台机器localhost是不通的要换成实际 IP。工具列表为空MCP Server 连上了但客户端看不到工具。检查 Dify 插件里是否真的保存了端点配置以及inputSchema的 JSON 是否合法。一个常见的错误是properties里参数类型写错比如把string写成str。调用返回 400 / 参数校验失败客户端传的参数名和 Schema 里定义的不一致。比如 Schema 里定义的是query客户端传的是input就会报错。检查客户端侧工具描述是否和 Dify 侧同步。工作流执行超时图片生成、长文本处理这类工作流容易超时。把客户端timeout调大同时检查 Dify 工作流本身是否有节点卡住。如果工作流里调了 TaoToken 通道确认 Key 没过期、余额够。模型调用 401 / 403TaoToken 的 Key 无效或没权限。到控制台确认 Key 状态以及 Base URL 是否填成了https://taotoken.net/api注意不要多加斜杠或路径。返回结果乱码或截断SSE 流式返回时客户端没正确处理分块。这种情况通常换一个客户端版本或者改用非流式传输能解决。排查时有个通用思路先在 Dify 里单独跑一遍工作流确认工作流本身没问题再用 curl 直接打 MCP 端点确认端点没问题最后才怀疑客户端配置。这样能把问题范围快速缩小。6. 把闭环跑顺之后工作流变成 MCP Server 之后最大的变化是复用成本降下来了。以前每接一个新客户端就要重写一遍对接逻辑现在只要客户端支持 MCP改一下settings.json里的 URL 就能用。Dify 里已经调好的工作流不用二次开发就能被 Cursor、Cherry Studio 这些工具调用。TaoToken 统一 Key 在这里的价值也会随着接入的客户端数量增加而放大。一个 Key 管住所有模型调用入口换模型、查用量、控成本都在一处。如果你后面要接多个 MCP Client建议把 Key 和 Base URL 统一放到环境变量里别硬编码在配置文件里。最后留一个实操建议先把一个最简单的工作流比如只做文本处理、不涉及图片生成的包装成 MCP Server 跑通确认整条链路没问题再往上叠复杂工作流。这样出问题时排查范围小不至于一上来就被多个变量搞晕。
