Dify 的 Agent 策略里已经贴好 MCP SSE 配置鉴权也过了可你问一句“现在几点”画布却回你 tool parameter instruction not found in tool config。这个报错卡住的地方通常不是 SSE 地址而是模型通道对 MCPFunctionCall 的支持。把 Dify 模型供应商里的 Base URL 换成 https://taotoken.net/api用 TaoToken 做统一模型通道再切到支持工具调用的模型多数情况下就能让 Agent 正常解析 MCP 工具参数。Key 去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentdify_mcp 创建模型 ID 以模型广场当时列表为准。下面按排障顺序把 Dify、MCP Agent、SSE 插件和模型供应商这几层拆开一步步把报错消掉。1. Dify 报 tool parameter instruction not found 时先别改画布1.1 报错发生在 Agent 策略解析工具参数那一步Dify 本身是个构建 LLM 应用的底座Agent 是里面能规划任务、拆步骤、调工具的智能助手MCP 则像一份让 Agent 连接外部工具的通用插口协议。三者串起来时Dify 负责把模型、Agent 策略、SSE 插件和画布工作流拼在一起MCP 服务提供具体工具比如查时间、抓网页、做推理模型负责理解你的指令并生成符合 MCPFunctionCall 格式的工具参数。tool parameter instruction not found in tool config 这个报错字面意思是“在工具配置里找不到工具参数说明”。它经常被误解成 SSE URL 失效其实更常见的链路是MCP SSE 插件已经连上工具列表也发现了但模型返回的 tool_calls 结构不符合 Dify Agent 策略的预期Dify 在解析阶段找不到对应参数的 instruction于是直接抛出错误。也就是说问题可能出在模型通道而不是画布节点。你可以这样判断如果 SSE 插件页面显示鉴权成功Agent 策略里也能看到 time、fetch 这类工具名那 MCP 服务大概率已经接通。此时再问一个简单问题就报参数解析错误优先怀疑当前 Dify 模型供应商里的模型不支持 MCPFunctionCall或者它返回的工具调用格式和 Dify 官方 Agent 策略不兼容。原文实践中一开始调用硅基 deepv3 失败换成 sonnet3.5 则正常这个对照很典型。它说明 Dify 的画布、MCP 服务器、SSE 插件未必全错错的是模型在工具调用这一层的表现。排障时先保留这个判断不要一上来就重装插件或重建工作流。1.2 硅基 deepv3 失败不等于 Dify 配置全错硅基 deepv3 在很多对话场景里表现不错但 Dify Agent 策略要的不是普通对话而是模型严格按照工具 schema 吐出结构化参数。模型如果只会用自然语言描述“我可以帮你查时间”却不会生成带参数名的工具调用Dify 就无法继续执行。此时画布看起来像“没反应”或“报参数找不到”根源却在模型通道。这种时候最容易踩的坑是把所有东西推倒重来删 SSE 插件、重新鉴权、重新画流程、换 MCP 平台。实际上更划算的做法是先把 Dify 模型供应商切到一个工具调用兼容性更好的通道再回到原来的画布和 MCP 配置上测一遍。如果换完模型就能跑通说明原配置只是被模型能力卡住不必大改。TaoToken 在这里的角色是统一模型通道你仍然在 Dify 里使用 OpenAI-API-compatible 供应商只是把 Base URL 指到 https://taotoken.net/apiKey 用自己创建的 YOUR_API_KEY模型名称从模型广场里挑支持工具调用的那一类。这样 Dify 侧的 Agent 策略、SSE 插件、MCP 服务地址都不用动只换模型入口。2. 把 Dify 模型供应商的 Base URL 填成 https://taotoken.net/api2.1 去 TaoToken 控制台创建 YOUR_API_KEY打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentdify_mcp 注册并登录进入控制台后创建 API Key。拿到 Key 后不要直接写进文章或截图里在 Dify 里统一用占位符 YOUR_API_KEY 表示。如果你还要在本地脚本或别的工具里测试也建议先复制到密码管理器再粘贴到对应配置项。创建 Key 时建议按用途命名比如dify-mcp-agent这样后面在控制台看调用记录时容易区分。模型 ID 不要凭记忆填回到模型广场查看当时可用的列表选择支持工具调用、函数调用或 MCPFunctionCall 的模型。不同时间模型列表会调整以页面当时显示为准不要编造带日期后缀的模型名。这一步和原文里“选择 MCP 服务平台”是两条并行的准备线MCP 服务负责提供工具TaoToken 负责提供模型通道。两条线都准备好Dify Agent 才有机会把“理解指令”和“实际调工具”串起来。2.2 Dify 模型供应商字段对照在 Dify 的模型供应商设置里新增一个 OpenAI-API-compatible 供应商按下面字段填写。注意 Base URL 是接口地址不是官网落地页末尾不要带/v1。配置项填写值说明API Base URLhttps://taotoken.net/api填进 Dify末尾不要加/v1API KeyYOUR_API_KEY从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentdify_mcp 创建模型名称以模型广场当时列表为准选支持工具调用的模型模型类型LLMAgent 策略按 LLM 使用函数调用/工具调用按模型能力选择不支持时仍会报原错误保存后Dify 会把这个供应商加入可选模型列表。此时先不要急着回画布去供应商页面点一下测试或者用 Dify 自带的调试功能发一条普通消息确认 Key、Base URL、模型名三者能通。普通对话能通但 Agent 仍报错才继续查工具调用格式普通对话都不通先查 Key 和 Base URL。2.3 保存后把 Agent 策略的模型切过去模型供应商添加成功后回到 Agent 策略配置里把原来硅基 deepv3 对应的模型换成新添加的 TaoToken 通道模型。Dify 里可能有多个 Agent 策略节点每个节点都要检查一遍别只改画布外的全局模型。MCP SSE 插件的配置不需要跟着改它只管工具连接和鉴权。切换模型后第一次测试建议只留一个 MCP 服务比如 Time MCP Server。问一句“现在纽约时间几点”看 Agent 是否先规划、再调用 time 工具、最后返回结果。如果这一步能过再逐步加回 fetch 和 sequentialthinking。这样排障范围小不会把模型问题和多服务 JSON 格式问题混在一起。3. MCP SSE 插件配置从 mcp.so 到 Dify Agent 策略3.1 从 mcp.so 复制 SSE URL 后按 Dify 规则包一层原文路径里先在 Dify Marketplace 下载 MCP Agent 策略或 Dify Agent 策略再安装 MCP SSE 插件。MCP SSE 插件的作用是通过 HTTP with SSE 传输发现和调用 MCP 工具让 Agent 策略能调用 SSE 里的服务。然后去 mcp.so 这类平台搜索需要的 MCP 应用复制右上角 Connect Server with SSE URL。mcp.so 给出的原始结构通常只有mcpServers和time之类的键Dify SSE 插件不认这个外层包装。你需要把它改成 Dify 规则下的 server_name 结构每个服务一个键值里放url、headers、timeout、sse_read_timeout。单个 Time MCP Server 可以写成下面这样URL 用你从平台复制的真实地址替换{ time: { url: https://your-mcp-router/sse/your-time-token, headers: {}, timeout: 5, sse_read_timeout: 300 } }注意url必须来自 MCP 平台实际生成的 SSE 地址不要自己拼。headers没有特殊要求就留空对象timeout和sse_read_timeout按 Dify SSE 插件当前版本文档填。保存前用 JSON 校验器过一遍少一个逗号都会让鉴权按钮没反应。3.2 多个 MCP 服务合并成一份 JSON如果你要同时测试时间、网页采集和推理就把多个服务写进同一个 JSON 对象。每个键名就是 Agent 侧看到的工具组名比如fetch、sequentialthinking、time。下面用占位 URL 展示结构实际地址仍从 mcp.so 等平台复制{ fetch: { url: https://your-mcp-router/sse/your-fetch-token, headers: {}, timeout: 5, sse_read_timeout: 300 }, sequentialthinking: { url: https://your-mcp-router/sse/your-thinking-token }, time: { url: https://your-mcp-router/sse/your-time-token } }原文里多个应用共用一份配置时有的服务保留了headers和超时字段有的只写url。这取决于平台返回和插件容忍度。稳妥做法是每个服务都补齐headers、timeout、sse_read_timeout格式统一排障时少一个变量。服务名不要用中文或空格避免 Agent 策略解析工具名时出意外。3.3 粘贴配置并完成鉴权把整理好的 JSON 粘贴进 Dify 的 MCP SSE 插件配置区点击鉴权或授权。鉴权成功后插件页面通常会显示已连接的服务和工具列表。如果这里失败先解决 SSE URL、网络可达性和平台 token 问题不要直接去改模型通道。鉴权成功后回到 Agent 策略确认策略里已经选择这个 MCP SSE 插件并且工具列表里能看到 time、fetch 等条目。此时如果测试仍然报 tool parameter instruction not found再回到第 2 节检查 Dify 模型供应商的 Base URL 和模型。顺序很重要先确认工具连接再确认模型通道最后再看画布指令。4. 在 Dify 画布验证 Time、Fetch、Sequential Thinking 三个 MCP4.1 指令写法一条消息覆盖三个工具在画布中创建一个简单的 Agent 对话工作流把 Agent 策略节点接上 MCP SSE 插件。指令可以写得直白让 Agent 自己拆任务例如“请用 time 工具告诉我当前 UTC 时间用 fetch 采集 https://www.anthropic.com/news/model-context-protocol 并翻译为中文用 sequentialthinking 判断这篇文章的发布时间距今多久并列出三条有价值的信息。”这条指令同时覆盖三个 MCP 服务能测出 Agent 是否会先规划、再逐个调用工具、最后汇总答案。注意 fetch 只是采集公开网页不是让模型直连你的生产库也不要在 Dify 里配置任何业务数据库连接。MCP 在这里的职责是提供工具模型只负责生成调用参数和解释结果。如果 Agent 在第一步就报 tool parameter instruction not found说明模型没有生成合法工具参数回到 Dify 模型供应商检查当前模型是否支持 MCPFunctionCall。如果 Agent 能生成调用但某个工具无响应再看那个 MCP 服务本身是否稳定。4.2 单服务测试只留 Time MCP Server先把 SSE 插件 JSON 精简到只剩time一个服务画布也只用最简单的 Agent 对话。问“现在纽约时间几点”观察 Dify 日志里是否出现tool_calls以及调用参数里是否包含时区字段。Time MCP Server 支持 IANA 时区名称和自动系统时区检测单服务测试最容易看出模型是否按 schema 填参数。单服务通过后再把 fetch 加回来。fetch 对目标网页可达性比较敏感原文也提到出现过无法采集的情况。遇到 fetch 不响应不要立刻认定模型通道坏了先换一个公开网页测试或者看 MCP 平台侧是否有速率限制。模型通道和 MCP 服务是两段路哪段堵了就修哪段。4.3 多服务测试时间、采集、推理一起上三个服务都放回 JSON 后再发一次综合指令。理想情况下Agent 会先调time拿当前时间再调fetch抓文章再调sequentialthinking做时间差和内容价值判断最后合成一段中文回答。这个过程能暴露多服务配置的合并格式问题也能暴露模型在长链路里的工具调用稳定性。如果多服务下开始报参数错误但单服务正常优先检查 JSON 里服务名是否和指令里的名字一致、逗号是否合法、某个服务的 URL 是否过期。Dify Agent 策略有时会把工具名做规范化名字对不上也会导致参数解析失败。把服务名改成短英文避免大小写混用和特殊符号。5. 还在报 tool parameter instruction not found 的排查表5.1 先换模型不要先重装插件Dify Agent 策略对模型的函数调用能力有硬要求。原文里硅基 deepv3 调 MCP 失败换 sonnet3.5 后正常这个对照应该作为第一优先级。在 TaoToken 模型广场挑一个明确支持工具调用的模型替换 Dify 模型供应商里的模型名称。模型 ID 不要凭经验编以模型广场当时列表为准。换模型后只改 Dify 模型供应商不动 SSE 插件 JSON也不动画布。这样如果错误消失就能确认是原模型不支持 MCPFunctionCall如果错误还在再查 Base URL、JSON 格式和日志。排障最怕同时改三处最后不知道哪一处生效。5.2 检查 Base URL 是不是多了 /v1 或填成了官网Dify 模型供应商里的 API Base URL 必须填https://taotoken.net/api末尾不要加/v1。常见错误有两种一是填成https://taotoken.net/api/v1多了一层路径二是把官网落地页粘进去比如带utm_source的页面地址。官网地址只用于注册、创建 Key、看模型广场和看用量不能填进 Dify 的 Base URL。如果你在 Dify 里同时配了多个供应商确认 Agent 策略实际选用的是哪一个。有时供应商 A 配对了策略却还指向旧的硅基供应商测试自然继续报错。改完 Base URL 后保存再点一次连接测试确保当前供应商生效。5.3 检查 SSE JSON 结构和鉴权状态MCP SSE 插件里的 JSON 如果不是合法 JSON鉴权会直接失败但有时页面只显示“未连接”不会明确告诉你逗号错了。把配置复制到本地编辑器用 JSON 格式化工具检查。多个服务时特别注意最后一个服务后面不要多逗号headers如果留空要写{}。鉴权过期也会导致工具列表消失。回到 Dify 的 MCP SSE 插件页面重新点鉴权确认所有服务都显示已连接。如果某个服务一直连不上先把它从 JSON 里移除保证其他服务可用再单独排查那个平台的 SSE URL。5.4 看 Dify 日志里模型返回的 tool_callsDify 的日志和调试面板能看到模型返回的原始结构。重点看tool_calls是否存在、参数名是否和 MCP 工具 schema 对得上。如果tool_calls为空模型只返回了自然语言说明它没有走工具调用如果参数名是location而工具要的是timezone说明模型理解了任务但填错了字段需要换模型或改指令提示。原文提到的报错发生在工具参数说明缺失这一层日志能帮你确认到底缺在哪。看到tool_calls结构完整但 Dify 仍报错再检查 Agent 策略版本和 MCP SSE 插件版本是否匹配。插件和策略都来自 Marketplace版本差异有时会影响参数解析规则。6. 配完后回控制台对账并决定下一步6.1 看这次 Dify 调用有没有记上账Dify 里测试通过后打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentdify_mcp 进入控制台查看这次调用的用量和记录。确认模型 ID 是模型广场里选的那个Base URL 没有误填成官网地址Key 也是当前 Dify 供应商里用的那一把。如果调用记录为空说明 Dify 请求没有真正到达通道回到供应商测试页排查。这一步同时能帮你判断模型是否选对。用量记录里如果出现的是另一个模型名说明 Agent 策略还指向旧供应商。把 Dify 里所有 Agent 节点和全局模型设置都过一遍避免部分节点继续用硅基 deepv3部分节点用新通道导致测试结果时好时坏。6.2 下一步模型对话、Coding Plan、创建 Key、Claude Code 文档Dify 这边跑通后如果还想用同一把 Key 验证模型响应可以去 TaoToken 模型对话 发一条测试消息确认模型 ID 和 Base URL 没填错。长期写代码或频繁调试 Agent可以打开 Coding Plan 看套餐是否够用Key 在 控制台 API Keys 创建和管理。Claude Code 环境变量对照见 接入文档。如果 Dify 里还要接更多 MCP 服务按同样的 JSON 结构加 key先单服务验证再多服务合并不要再让模型通道背 SSE 配置的锅。
