1. Dify 工作流里 MCP 工具调用为什么总是不稳定
如果你正在用 Dify 搭 Chatflow，并且想让 Agent 去调用本地或内网的 MCP Server，大概率会遇到这么几个现象：Agent 策略选错了，工具列表死活发现不了；SSE 地址填对了，但一跑就报local proxy failed；或者工具明明注册成功，模型却回你一句「找不到 call_tool 方法」。这些问题我在把 Dify 和 MCP 接起来的过程中基本都踩过一遍。
先说清楚这套方案到底解决什么。Dify 本身是一个低代码的 Agent 编排平台，MCP（Model Context Protocol）是一套让模型发现和调用外部工具的协议。把两者接起来，你就能在 Dify 的可视化工作流里，让 Agent 去查数据库、读文件、调内部接口，而不用为每个工具单独写一个 Dify 插件。适合谁？适合手上已经有 MCP Server（比如用 FastMCP 写的 MySQL 查询服务），又想在 Dify 里快速编排成对话机器人的开发者。
但真正落地时，链路是这样的：Dify 的 Agent 节点 → MCP SSE 插件 → 你的 MCP Server → 底层数据源。这条链路上任何一环配置不对，工具调用就会失败。更麻烦的是，Dify 默认走的是它自己的模型供应商通道，如果你想让 Agent 的推理请求统一走一个稳定的 API 通道（比如 TaoToken 的统一 Key），还得把模型端点改掉。这篇就按「装插件 → 配 MCP Server → 注册工具 → 改统一通道 → 验证调用」的顺序，把每一步的可复制配置给你，并附一次成功和失败的对照。
核心检索词先摆出来：Dify MCP 工具调用、MCP SSE 插件配置、Dify Agent ReAct 策略、TaoToken 统一 API 通道。你如果是搜着这几个词进来的，下面的内容基本能覆盖你的问题。
我试过最省事的路径，是先用 Dify 官方的插件市场装两个插件，再把 MCP Server 的 SSE 地址填进去，最后把 Agent 的模型端点指向统一通道。整个过程不需要改 Dify 源码，配置都在界面上完成。下面从插件安装开始。
2. TaoToken 前置准备：统一 Key 与 API 通道
在动 Dify 之前，先把模型通道这块理清楚。Dify 的 Agent 节点在推理时要调用大模型，默认你可以填 OpenAI、Anthropic 或者兼容 OpenAI 协议的第三方端点。如果你希望所有 MCP 工具调用背后的模型请求都走同一个 Key、同一个 Base URL，方便统一计费和排查，那就需要先准备好这个通道。
TaoToken 在这里的角色是「统一 API 通道」：它提供一个兼容 OpenAI 协议的端点，你把 Dify 的模型供应商 Base URL 改成它，Key 换成它发的 Key，模型 ID 填对应的名称，Agent 的推理请求就会走这条通道。注意，它不替代 Dify 本身，也不替代你的 MCP Server，只是把模型调用这一层收敛到一个入口。
你需要准备三样东西，我把它叫「三件套」：
- Base URL：
https://taotoken.net/api - API Key：在控制台创建，形如
sk-开头的一串 - Model ID：你要用的模型名称，比如
claude-sonnet-4-5或gpt-4o这类，具体以控制台模型列表为准
获取 Key 的入口在控制台的 API Keys 页面，创建后复制保存，页面只显示一次。模型对话可以在线验证 Key 是否可用，接入文档里有各语言的调用示例。如果你后面要长期跑编码类 Agent，可以看 Coding Plan；只是验证模型通不通，用模型对话就够了。
这里有个容易忽略的点：Dify 里模型供应商的 Base URL 有的版本要求带/v1，有的要求不带。TaoToken 的 API 地址是https://taotoken.net/api，在 Dify 的 OpenAI 兼容供应商里，通常填https://taotoken.net/api/v1这种形式，具体以你 Dify 版本的提示为准。填错会直接 404 或 401，后面排障章节会讲。
准备好三件套后，先别急着配 Dify，用一条 curl 确认通道是通的：
curl https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer sk-你的Key" \ -H "Content-Type: application/json" \ -d '{ "model": "claude-sonnet-4-5", "messages": [{"role": "user", "content": "ping"}] }'返回里有choices字段就说明通道没问题。这一步能帮你把「模型通道问题」和「MCP 工具问题」提前分开，不然两个混在一起排查会很痛苦。
3. 可复制配置：MCP SSE 插件与 Dify Agent 节点
这一节是全文的核心，所有配置片段都可以直接抄。先装插件，再配 MCP Server，再配 Agent 节点。
3.1 安装两个 MCP 插件
Dify 插件市场里搜 MCP，需要装两个：
- Agent 策略（支持 MCP 工具）：提供 ReAct 策略，负责发现和调用 MCP 工具
- MCP SSE：通过 HTTP with SSE 传输使用 MCP 协议，负责连你的 MCP Server
装完后在插件列表能看到它们。MCP SSE 插件的作用是维护 SSE 长连接，把 MCP Server 暴露的工具列表拉过来给 Agent 用。
3.2 配置 MCP Server 的 SSE 地址
点开 MCP SSE 插件，添加 SSE 地址。单个服务的 JSON 长这样：
{ "mysql_mcp_server_pro": { "url": "http://172.16.0.45:9090/sse" } }多个服务就并列加：
{ "server_name1": { "url": "http://127.0.0.1:8000/sse", "headers": {}, "timeout": 60, "sse_read_timeout": 300 }, "server_name2": { "url": "http://127.0.0.1:8001/sse" } }注意timeout和sse_read_timeout这两个参数。工具调用如果涉及慢查询，sse_read_timeout太小会中途断开，报读取超时。我一般设 300 秒起步。headers里可以放鉴权头，如果你的 MCP Server 需要 token，就在这里加。
3.3 创建 Chatflow 并配置 Agent 节点
新建一个 Chatflow，名字随意，比如test-mcp-mysql8。删掉默认的 LLM 节点，拖一个 Agent 节点进来。Agent 节点里几个关键配置：
Agent 策略必须选ReAct (Support MCP Tools)。为什么不用 FunctionCalling？因为实测下来，FunctionCalling 调 MCP 时会一直提示找不到call_tool方法，哪怕你的 FastMCP Server 根本不需要显式定义这个方法。ReAct 策略没这个问题，直接选它。
工具列表必须添加。点右侧添加按钮，选「通过 SSE 发现和调用 MCP 工具」，把你上面配的 MCP Server 加进来。有几个加几个。
MCP 服务器这里再确认一遍地址：
{ "mysql_mcp_server_pro": { "url": "http://172.16.0.45:9090/sse" } }指令（提示词）必须写。这是让 Agent 知道什么时候该调工具的关键。比如查学生成绩，你要把表结构告诉它。指令里写清楚「当用户提问涉及学生、教师、成绩、班级、课程等实体时，使用 MySQL MCP 进行查询」，再把表结构说明贴进去。表结构越清楚，Agent 生成的查询越准。
查询变量填query，最大迭代次数设 3 或更高。这个参数控制工具调用深度，太小会导致多步查询跑不完，太大可能循环。默认 3 一般够用，复杂查询调到 5。
最后把 Agent 的输出连到「直接回复」节点，变量选Agent.text，发布预览。
3.4 把模型端点改到统一通道
在 Dify 的「设置 → 模型供应商」里，添加一个 OpenAI 兼容供应商，配置如下：
{ "provider": "openai_compatible", "base_url": "https://taotoken.net/api/v1", "api_key": "sk-你的Key", "model": "claude-sonnet-4-5" }然后在 Agent 节点里，把模型选成这个供应商下的模型。这样 Agent 的推理请求就走 TaoToken 统一通道了。三件套（Base URL + Key + Model ID）缺一不可，少一个都会在调用时报错。
4. 验证请求：一次成功与失败的对照
配置完必须验证，不然你不知道是通道问题还是工具问题。我准备了两组对照。
4.1 成功案例：查「哪个老师学生最多」
在预览窗口输入「哪个老师学生最多」。Agent 的 ReAct 循环会这样跑：
第一步，模型理解问题，决定调用 MCP 工具。第二步，MCP SSE 插件把工具列表里的query工具暴露给模型，模型生成 SQL，比如按classes.headTeacherId分组统计学生数。第三步，工具执行，返回结果。第四步，模型把结果组织成中文回复。
成功时你能在 Dify 的日志里看到工具调用记录，返回类似「张建国老师的学生最多，共 35 人」。同时模型通道那边会有一条 chat completion 记录，说明推理走的是统一通道。
4.2 失败案例：401 与 local proxy failed
失败通常有两种。一种是模型通道报 401，说明 Key 或 Base URL 不对。检查https://taotoken.net/api/v1是否拼错，Key 是否有多余空格。另一种是 MCP 侧报local proxy failed，说明 Dify 连不上你的 MCP Server。检查 SSE 地址是否可达，MCP Server 是否在跑，防火墙是否放行。
还有一种隐蔽的失败：工具列表为空。这时候 Agent 会直接用自己的知识回答，不调工具，你以为是模型笨，其实是插件没发现工具。回到 MCP SSE 插件页面，确认 SSE 地址能拉到工具列表。
4.3 用 curl 单独验证 MCP Server
在配 Dify 之前，先用 curl 确认 MCP Server 的 SSE 端点活着：
curl -N http://172.16.0.45:9090/sse能持续输出事件流就说明 SSE 正常。如果卡住或报连接拒绝，先修 MCP Server，别在 Dify 里折腾。
5. 本篇常见错排查：401、local proxy failed、reading choices、OAuth
这一节把真实报错和对应处理列出来，你对着改就行。
401 Unauthorized：模型通道鉴权失败。检查三件套里的 Key 是否正确，Base URL 是否带了多余的斜杠。Dify 里 OpenAI 兼容供应商的 Base URL 有时要带/v1，有时不要，两个都试一下。用第 2 节的 curl 先确认 Key 本身可用。
local proxy failed：Dify 到 MCP Server 的网络不通。常见原因是 MCP Server 监听在127.0.0.1，而 Dify 跑在容器里，容器访问不到宿主机的 localhost。把 MCP Server 监听地址改成0.0.0.0，SSE 地址填宿主机的内网 IP，比如http://172.16.0.45:9090/sse。
reading choices 报错：模型返回体里没有choices字段，通常是通道返回了错误结构，或者模型 ID 填错。确认 Model ID 和控制台模型列表一致，别把claude-sonnet-4-5写成claude-sonnet-4.5。
OAuth 相关报错：如果你接的 MCP Server 需要 OAuth 鉴权，而 Dify 的 MCP SSE 插件没带对应 header，就会报鉴权失败。在 SSE 配置的headers里加上Authorization头，值按你的 MCP Server 要求填。
工具调用找不到 call_tool：这是 FunctionCalling 策略的坑，直接换成 ReAct 策略。FastMCP 框架不需要显式定义call_tool，FunctionCalling 却会去找，换策略就好。
最大迭代次数无法保存：这个参数必须显式设置，留空或为 0 会导致 Agent 节点保存失败。填 3 到 5 之间。
排查顺序建议：先 curl 验模型通道，再 curl 验 MCP SSE，最后在 Dify 里跑。这样能把问题范围快速缩小到某一层。
6. 把统一通道用起来：从验证到长期编码
配置跑通之后，你可以做几件事让它更实用。第一，把常用的 MCP Server 都加到 SSE 配置里，多个服务并列，Agent 会自动发现所有工具。第二，指令里把表结构、字段含义、常用查询模式写清楚，减少模型瞎猜。第三，模型端点固定走统一通道，方便你在一处看所有调用记录。
如果你只是验证模型通不通，用模型对话页面最快。如果你要长期跑编码类或 Agent 类任务，Coding Plan 更合适，额度和稳定性都更好。接入文档里有完整的参数说明和示例，遇到配置问题先翻文档。API Keys 页面用来创建和管理 Key，建议给 Dify 单独建一个 Key，方便按项目排查。
最后说个实用技巧：Dify 的 Agent 日志里能看到每次工具调用的入参和返回，调试时盯着这里，比看模型回复有用得多。工具调用失败时，先看日志里工具有没有被触发，再看返回内容，基本能定位到是模型没生成正确参数，还是 MCP Server 执行出错。把这条链路跑顺之后，你就能在 Dify 里用自然语言驱动内网工具了。
