1. Dify 工作流接入 MCP Server 到底解决什么问题如果你正在用 Dify 搭 AI 智能体大概率遇到过这个尴尬工作流里的大模型很聪明但它只能“动嘴”不能“动手”。想让它查一下数据库、调一下内部接口、读一下本地文件就得自己写 HTTP 节点、拼参数、处理鉴权一个工具接一次十个工具接十次维护起来头大。MCPModel Context Protocol模型上下文协议就是来治这个病的。你可以把它理解成 AI 世界的 USB-C 接口以前每个外部工具都要一根专用线现在统一成一个标准插口模型、客户端、工具三方按同一套协议握手、发现能力、调用执行。Anthropic 在 2024 年底把它开放出来之后Cursor、Cline、Claude Desktop、VSCode 这些客户端陆续支持Dify 也通过社区插件把这条路打通了。这篇要讲的核心链路是在 Dify 里把一个工作流发布成 MCP Server暴露 SSE 端点然后在 VSCodeCline 插件里作为 MCP Client 去发现并调用它。同时覆盖本地调试和远程调用两种场景。跑通之后你的 AI 智能体就能真正调用外部工具形成“理解需求 → 发现工具 → 执行 → 返回结果”的最小闭环。适合谁看已经在用 Dify 做工作流、想把手头应用变成可复用工具能力的开发者或者刚接触 MCP想找一个能跟着做的实战入口的人。下面每一步我都会给可复制的配置片段和验证方法踩过的坑也会标出来。2. 前置准备Dify 插件、TaoToken 模型接入与 MCP 概念对齐动手之前先把地基打好。这一节解决三件事Dify 侧要装什么插件、模型从哪来、MCP 的几个关键概念怎么对应到 Dify 的界面。先说 Dify 侧。你需要一个能正常登录的 Dify 实例云版或自部署都行然后进插件市场装两个插件mcp-server扩展类型插件作用是把 Dify 应用变成 MCP Server对外暴露 SSE 端点。MCP SSE工具类型插件作用是让 Dify 自己的智能体应用能作为 MCP Client 去发现和调用 MCP 服务。这两个插件分工不同别搞混。前者是“我对外提供服务”后者是“我去调用别人的服务”。本篇两条链路都会用到。再说模型。Dify 工作流里的大模型节点需要接一个可用的模型服务。如果你手头没有现成的 API Key可以用 TaoToken 这类聚合入口来统一管理模型调用。它的 API 地址是https://taotoken.net/api兼容 OpenAI 风格的接口格式在 Dify 的模型供应商配置里填 Base URL 和 Key 就能用。具体操作进入 Dify 右上角头像 → 设置 → 模型供应商 → 选择 OpenAI-API-compatible → 填入API Base URL: https://taotoken.net/api API Key: 你的 TaoToken Key Model Name: 按你实际要用的模型 ID 填保存后测试连通性能列出模型就说明通了。这一步不做后面工作流的大模型节点会直接报错。最后对齐几个 MCP 概念不然后面看配置会懵MCP 概念含义在 Dify 里的对应MCP Server提供工具能力的一方你用 mcp-server 插件发布的应用MCP Client发现并调用工具的一方Cline、Cursor、Dify 智能体Endpoint / SSE URL客户端连接的地址插件保存后生成的 GET 后面那串 URLinputSchema工具入参的 JSON Schema发布时填的那段 JSON工具发现客户端拉取可用工具列表MCP SSE 插件的 list 能力理解这张表后面配置就是填空。另外提醒一句MCP Server 的端点本质是一个 HTTP SSE 服务本地调试时确保你的 Dify 实例和客户端网络可达如果是自部署在内网VSCode 那台机器要能访问到 Dify 的地址否则会卡在连接阶段。3. 可复制配置把 Dify 工作流发布成 MCP Server这一节是重头戏从建工作流到拿到 SSE 端点全程给可复制的片段。3.1 建一个最小工作流新建应用 → 选“工作流”。开始节点加一个输入变量比如author类型 string。然后接一个大模型节点系统提示词里引用这个变量让它模仿指定作者的风格写一首诗。大模型节点后面接结束节点输出变量指向大模型的输出。配置大模型节点时模型选你在上一节接好的那个。提示词参考你是一位诗歌创作者。请模仿 {{author}} 的写作风格创作一首短诗并附上简要解析。发布更新然后点运行输入李白测试。能看到输出诗歌就说明工作流本身没问题。这一步别跳过工作流本身跑不通后面发布成 MCP Server 也是白搭。3.2 用 mcp-server 插件发布端点回到插件列表找到 mcp-server点右侧的 号。在配置表单里端点名称随便起比如poem-server选择应用选刚才那个工作流参数inputSchema填下面这段 JSON{ name: poem, description: 模仿输入的作者风格写诗歌, inputSchema: { title: poem, type: object, properties: { author: { title: author, description: 作者, type: string } }, required: [author] } }这段 JSON 里三个字段要理解清楚properties列出应用接收的所有参数及类型这里只有authordescription是给 MCP Client 看的系统靠它判断什么时候该调用这个工具所以写得越清楚越好required声明必填参数聊天类或 Agent 类应用通常参数必填。保存后插件会自动生成一个 Endpoint URL就是 GET 后面那串地址。把它复制下来格式类似https://你的dify域名/e/xxxxx/sse这个 URL 就是 MCP Server 的入口后面 VSCode 和魔搭都连它。3.3 让 Dify 智能体也能调用它如果你还想在 Dify 内部建一个智能体来调用这个 MCP Server需要装 MCP SSE 工具插件。安装后在工具列表里找到它把授权配置填进去主要是 SSE 地址和相关鉴权信息保存后右侧显示“已授权”就说明配置成功。然后新建一个 Agent 类型应用提示词写调用 mcp 工具回答用户问题先获取工具列表再选中可用的工具最后返回工具结果中的诗歌原文以及解析内容。在编排界面下方的工具选项里把 MCP SSE 插件的两项能力发现工具、调用工具加进去。测试时输入作者名能看到大模型先走工具调用再返回诗歌就说明 Dify 内部的闭环通了。3.4 VSCode / Cline 侧配置在 VSCode 里装 Cline 插件打开 MCP 配置。Cline 的 MCP 配置通常是一个 JSON 文件路径在插件设置里能看到。填入{ mcpServers: { dify-poem: { url: https://你的dify域名/e/xxxxx/sse, type: sse } } }保存后 Cline 会尝试连接。连接成功的标志是工具列表里出现poem这个工具。如果用的是需要鉴权的端点还要在 headers 里带上 token具体看你的 Dify 部署配置。这里有个关键点Base URL、Key、Model ID 三件套要写全。Cline 自己也要配模型它的模型配置和 MCP 配置是两回事。模型配置里填 TaoToken 的 Base URLhttps://taotoken.net/api、你的 Key、以及模型 IDMCP 配置里填的是 Dify 的 SSE 地址。两者别混。4. 验证请求从 VSCode 到 Dify 的连通性测试配置写完不算完得验证。这一节给两种验证方式命令行直连和客户端实际调用。4.1 命令行验证 SSE 端点最直接的办法是用 curl 看端点是否活着。SSE 是长连接直接 curl 会挂住所以加超时curl -N -m 5 https://你的dify域名/e/xxxxx/sse正常的话你会看到类似这样的输出event: endpoint data: /e/xxxxx/messages?session_idxxxxx看到event: endpoint就说明 SSE 服务在正常握手。如果返回 404检查 URL 是否复制完整如果返回 401说明端点需要鉴权得在请求头里带 token。4.2 在 Cline 里实际调用打开 Cline 对话框输入请模仿李白的风格写一首诗观察执行过程。正常情况下 Cline 会先列出可用工具选中poem然后弹出参数填写或自动填入author: 李白调用后返回诗歌。你会在对话里看到工具调用的中间步骤最后是诗歌原文和解析。如果 Cline 没有自动调用工具而是直接用自己的模型回答说明工具没被发现。检查 MCP 配置里的 URL 是否正确、Cline 是否重启过、以及 Dify 端点是否可达。4.3 在 Dify 智能体里验证回到 Dify 那个 Agent 应用输入同样的请求。预期行为是大模型先调用 MCP SSE 的发现工具拿到工具列表再调用poem工具最后把结果整理返回。如果只返回了模型自己编的诗说明工具没被引用回去检查工具是否加进了编排。4.4 远程调用场景如果你的 Dify 部署在服务器上VSCode 在本地这就是远程调用。要点是Dify 的端点必须公网可达或者通过内网穿透让本地能访问。自部署在内网的话确保 VSCode 所在网络能路由到 Dify 地址。远程场景下延迟会高一些SSE 长连接偶尔会断Cline 一般会自动重连不用太担心。验证通过的标准很简单同一个请求在 Cline 和 Dify 智能体里都能触发poem工具并返回诗歌。两个都通说明 MCP Server 发布和客户端集成这条链路完整跑通了。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节按真实报错来。下面这几个是我在实际配置里遇到过的对照着查。401 Unauthorized最常见。原因通常是端点需要鉴权但请求没带凭证。排查顺序先确认 Dify 端点是否开启了 API 鉴权如果开了在 Cline 的 MCP 配置里加 headers{ mcpServers: { dify-poem: { url: https://你的dify域名/e/xxxxx/sse, type: sse, headers: { Authorization: Bearer 你的token } } } }如果加了还报 401检查 token 是否过期、是否复制时带了空格。local proxy failed这个报错一般出现在客户端连不上端点时。可能是 Dify 地址写错、端口不通、或者本地网络策略拦截。先用 curl 验证端点可达再检查 Cline 配置里的 URL 有没有拼错。如果是自部署确认 Dify 的容器端口映射正确。reading choices 相关报错这类报错通常出现在模型调用环节不是 MCP 本身的问题。意思是模型返回结构不符合预期常见于模型 ID 填错、Base URL 不对、或者模型不支持当前调用格式。检查三件套Base URL 是否为https://taotoken.net/api、Key 是否有效、Model ID 是否和实际可用模型一致。改完在 Dify 模型供应商里重新测试连通性。OAuth 相关报错如果 MCP Server 配置了 OAuth 2.1 认证客户端需要走授权流程。报错通常是 token 获取失败或 scope 不对。检查 OAuth 配置里的 client_id、client_secret、授权地址是否和 Dify 侧一致。如果只是本地调试可以先用无鉴权端点跑通再逐步加认证。工具列表为空Cline 连上了但看不到poem工具。检查 inputSchema 的 JSON 是否合法用 JSON 校验器过一遍name字段是否和客户端期望的一致。另外保存配置后有时需要重启 Cline 或重新加载窗口。Dify 智能体不调用工具提示词里明确要求“先获取工具列表”但模型还是自己回答。可能是工具没加进编排或者模型能力不足以触发工具调用。换一个支持 function calling 的模型试试同时在提示词里把调用步骤写得更死。排查的核心思路就一条分段验证。先 curl 端点再客户端连接再工具发现再实际调用。哪一段断了就查哪一段别一上来就怀疑全部。6. 把 MCP 能力沉淀成可复用资产跑通之后你会发现这套东西的价值不只是“写首诗”。真正的用法是把你手头重复性高的 Dify 工作流——比如查订单、生成报表、调内部知识库——都发布成 MCP Server然后在 Cline、Cursor、Dify 智能体里统一调用。一套服务多处复用改一处全生效。几个实操建议。第一inputSchema 的 description 一定要写清楚这是模型判断“什么时候用这个工具”的唯一依据写得含糊模型就不会调。第二端点命名用业务语义别用test1、app2这种后面工具多了根本分不清。第三本地调试和远程调用用同一套配置只是 URL 不同别维护两份。第四模型接入统一走一个入口Base URL 和 Key 集中管理换模型时只改一处。如果你还没开始建议从这篇的最小闭环入手一个工作流、一个 MCP Server、一个 Cline 客户端。跑通之后再往上加工具、加鉴权、加多客户端。需要 Key 和模型接入的可以从 API Keys 页面拿凭证接入细节看接入文档想先验证模型对话效果的用模型对话页面试如果是长期做编码和 Agent 的Coding Plan 会更合适。链路本身不复杂难的是把每个环节的配置对齐按上面的步骤走基本能一次通。
