1. Dify 工作流接入 MCP Server 到底解决什么问题

如果你正在用 Dify 搭 AI 智能体，大概率遇到过这个尴尬：工作流里的大模型很聪明，但它只能“动嘴”，不能“动手”。想让它查一下数据库、调一下内部接口、读一下本地文件，就得自己写 HTTP 节点、拼参数、处理鉴权，一个工具接一次，十个工具接十次，维护起来头大。

MCP（Model Context Protocol，模型上下文协议）就是来治这个病的。你可以把它理解成 AI 世界的 USB-C 接口：以前每个外部工具都要一根专用线，现在统一成一个标准插口，模型、客户端、工具三方按同一套协议握手、发现能力、调用执行。Anthropic 在 2024 年底把它开放出来之后，Cursor、Cline、Claude Desktop、VSCode 这些客户端陆续支持，Dify 也通过社区插件把这条路打通了。

这篇要讲的核心链路是：在 Dify 里把一个工作流发布成 MCP Server，暴露 SSE 端点，然后在 VSCode（Cline 插件）里作为 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 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列出应用接收的所有参数及类型，这里只有author；description是给 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、以及模型 ID；MCP 配置里填的是 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_id=xxxxx

看到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 会更合适。链路本身不复杂，难的是把每个环节的配置对齐，按上面的步骤走，基本能一次通。