Dify MCP 集成实验03MCP 接入 Dify 全链路——MCP Server 如何接入 Dify 应用Dify 实验系列 · MCP 集成 03/6 | 实验编号DIFY-107-03基于 Dify 1.16.1 实测2026-081. 业务场景先讲一个我们实际遇到的场景。一家做客服工单 SaaS 的公司客服门户的 AI 助手要能回答「我的工单 T12345 什么状态」——状态数据在 107-02 的 MCP server 里。现在要把这个 server 真正接进 DifyConsole 添加 MCP server → 工作流 tool 节点调用 → 冒烟验证。这是集成单最典型的场景外部系统数据通过 MCP 进入 Dify 应用。我们第一次接这类需求时第一反应是「Console 里填个 URL 就能连」。真正动手才发现——接入的未知点全藏在网络路径和 DSL 格式里api 容器访问外部 server 要过 SSRF 代理白名单没覆盖就 403MCP 工具节点在 DSL 里的准确字段网上查不到权威格式只能从 UI 导出反推。不实测排障全靠试。这不是个例。任何「外部系统数据通过 MCP 进入 Dify 应用」的集成都是这个模式网络路径通不通、DSL 字段怎么写——两个未知点不实测后面全凭猜。2. 场景痛点这个流程的痛点在接入时体现得最直接SSRF 双层 403api 容器连外部 MCP server 要走 squid 代理ssrf_proxy白名单没覆盖就 403——而且 403 可能来自两层SDK 2.0 的 DNS rebinding protection / squid 白名单报错信息都叫 403分不清是哪一层。DSL 字段靠猜MCP 工具节点在 DSL 里的准确字段provider_type: mcpprovider_id是什么——写错导入就失败网上又查不到权威格式。工具输出消费错结构化工具outputSchema输出是字段直接展开、text——下游引用 text 就收到空白LLM 误报「未找到」。模型 disabled 400DSL 里写了 disabled 模型本机 deepseek-chat disabledrun 直接 400。本质上接入的未知点集中在「网络路径」和「DSL 权威格式」两处——不实测排障全靠试。3. 方案为什么是 Console UI 导出实证把 107-01/02 的 MCP server 接入 Dify 全链路最可靠的方法是 Console 添加 UI 导出权威 DSL 运行级实证。选它的理由网络路径实测定位api 容器内 curl不走代理POST /mcp 返回 200Dify 客户端走代理403——用排错关键证据锁定代理层而不是瞎改配置UI 导出权威格式从 Console 导出含 MCP 工具节点的 DSL——UI 导出是权威格式回填 skill reference以后生成带 MCP 工具的 DSL 直接引用运行级实证三原语结论Console 工具列表只见 toolsresources/prompts 无入口——107-02 的对照结论用真实运行验证不是源码推断。这篇文章我们就用它把「工单状态查询」MCP 工具接入客服门户应用跑通全链路并固化 DSL 权威格式。4. 整体架构HTTP本地开发机dify107_02_support_serverStreamable HTTP :8902Dify 服务器apiFastAPI未知点1MCP 客户端是否走 squid 代理SSRF_PROXY 白名单 172.16.0.0/12 是否覆盖web控制台 → 工具页 → MCP tab应用 dify107_03_验证应用workflowstartticket_idtoolMCPLLMend链路很清晰本地 serverStreamable HTTP→ Dify api经 squid 代理→ web 控制台配置 → 工作流 tool 节点 → LLM → end。关键设计是验证应用用最简链路start → tool → LLM → end把未知点集中在 MCP 工具节点本身。5. 模块设计5.1 SSRF 双层 403 的修复未知点 1根因链※ MCP 客户端也走代理create_ssrf_proxy_mcp_http_clientDify api 容器core/mcp MCP 客户端SSRF 代理ssrf_proxy/squid :3128host.docker.internal.env 白名单已加本机 uvicorn :8902/mcpSDK 2.0 server层问题修复① SDK 2.0 serverstreamable-http 默认 DNS rebinding protectionHosthost.docker.internal 不在白名单 → 403run(transport_securityTransportSecuritySettings(enable_dns_rebinding_protectionFalse))开发环境生产用 allowed_hosts② squid SSRF 代理MCP 客户端也走 ssrf_proxyhost.docker.internal 不在 squid 白名单 → 403.env加SSRF_PROXY_ALLOW_PRIVATE_DOMAINSlocalhost,host.docker.internaldocker compose up -d --force-recreate ssrf_proxyrestart 不重跑 entrypoint必须 recreate排错关键证据api 容器内 curl不走代理POST /mcp 返回 200Dify 客户端走代理403 → 锁定代理层。5.2 MCP 工具节点 DSL 权威格式未知点 2UI 导出实测-data:provider_id:dify107_02_support_server# MCP provider 的 server_identifierprovider_name:dify107_02_support_serverprovider_show_name:dify107_02_support_serverprovider_type:mcp# ⚠️ 字符串 mcp区分 builtin/workflow 工具tool_name:get_ticket_statustool_node_version:2tool_parameters:ticket_id:type:mixedvalue:{{#start.ticket_id#}}tool_configurations:{}plugin_id:nullplugin_unique_identifier:nulloutput_schema:{}type:tool与 builtin/workflow 工具同 node 类型type: tool靠provider_type: mcp区分provider_id MCP provider 的 server_identifier不是行 UUID。6. 运行验证输入预期结果T1002存在 open工单 T1002 当前状态是 open最后更新于 2026-08-04 09:30:00通过T1001存在 closed工单 T1001 当前状态是 closed最后更新于 2026-08-01 10:00:00通过T9999不存在未找到该工单请核对工单号通过abc格式错 → 工具 isErrorworkflow failed显式失败非静默通过显式失败Console 工具列表只见 search_tickets / get_ticket_statustoolsresources/prompts 无入口通过三原语运行级实证7. 实战坑坑现象修复SSRF 双层 403① SDK 2.0 streamable-http 默认 DNS rebinding protectionHosthost.docker.internal → 403② MCP 客户端也走 squid 代理host.docker.internal 不在白名单 → 403① server.run 关掉或配 allowed_hosts ②.env加SSRF_PROXY_ALLOW_PRIVATE_DOMAINS force-recreaterestart 不生效实测MCP 工具输出 text 为空结构化工具outputSchema输出字段直接展开ticket_id/status/updated_attext下游引用展开字段{{#tool_status.status#}}别引用 text——首版 LLM 收空白误报「未找到」实测DSL provider_typeMCP 工具节点不认 builtin/workflow 的 provider_type 值写provider_type: mcpgraphon 枚举provider_idserver_identifier实测Model is disabledDSL 写 disabled 模型本机 deepseek-chat disabled→ run 400用 active 模型deepseek-v4-flash查GET model-providers/{provider}/models的 status实测MCP 删除/列表 UUID 语义列表接口 idserver_identifier删除/工具端点按 DB 行 UUID 查行 UUID 从 DB 查SELECT id FROM tool_mcp_providers创建响应 id行 UUID实测工具错误行为MCP 工具 isError → Dify tool 节点失败 → workflow failed显式非静默优雅降级 107-06 验收时按需加 fail 分支实测8. 实验文档及源码获取实验文档完整操作步骤DIFY-107-03MCP接入Dify全链路.md源码可直接导入含 MCP 工具节点权威格式dify107_03_验证应用.yml交付验证记录SSRF 根因链 DSL 权威格式 输出消费规则验证记录-03-MCP接入Dify全链路.md全部目录dify-107/experiments | dify-107/dsl | dify-107/servers | dify-107/delivery文章聚焦核心配置与采坑点实验的完整分步操作节点搭建/参数表/调试指引见实验文档原文。下一篇Dify MCP 集成实验04企业系统对接场景——企业系统对接选 MCP 还是插件 你在这个实验的场景里踩过什么坑欢迎评论区分享你的实战经验。
Dify MCP 集成实验03MCP 接入 Dify 全链路——MCP Server 如何接入 Dify 应用Dify 实验系列 · MCP 集成 03/6 | 实验编号DIFY-107-03基于 Dify 1.16.1 实测2026-081. 业务场景先讲一个我们实际遇到的场景。一家做客服工单 SaaS 的公司客服门户的 AI 助手要能回答「我的工单 T12345 什么状态」——状态数据在 107-02 的 MCP server 里。现在要把这个 server 真正接进 DifyConsole 添加 MCP server → 工作流 tool 节点调用 → 冒烟验证。这是集成单最典型的场景外部系统数据通过 MCP 进入 Dify 应用。我们第一次接这类需求时第一反应是「Console 里填个 URL 就能连」。真正动手才发现——接入的未知点全藏在网络路径和 DSL 格式里api 容器访问外部 server 要过 SSRF 代理白名单没覆盖就 403MCP 工具节点在 DSL 里的准确字段网上查不到权威格式只能从 UI 导出反推。不实测排障全靠试。这不是个例。任何「外部系统数据通过 MCP 进入 Dify 应用」的集成都是这个模式网络路径通不通、DSL 字段怎么写——两个未知点不实测后面全凭猜。2. 场景痛点这个流程的痛点在接入时体现得最直接SSRF 双层 403api 容器连外部 MCP server 要走 squid 代理ssrf_proxy白名单没覆盖就 403——而且 403 可能来自两层SDK 2.0 的 DNS rebinding protection / squid 白名单报错信息都叫 403分不清是哪一层。DSL 字段靠猜MCP 工具节点在 DSL 里的准确字段provider_type: mcpprovider_id是什么——写错导入就失败网上又查不到权威格式。工具输出消费错结构化工具outputSchema输出是字段直接展开、text——下游引用 text 就收到空白LLM 误报「未找到」。模型 disabled 400DSL 里写了 disabled 模型本机 deepseek-chat disabledrun 直接 400。本质上接入的未知点集中在「网络路径」和「DSL 权威格式」两处——不实测排障全靠试。3. 方案为什么是 Console UI 导出实证把 107-01/02 的 MCP server 接入 Dify 全链路最可靠的方法是 Console 添加 UI 导出权威 DSL 运行级实证。选它的理由网络路径实测定位api 容器内 curl不走代理POST /mcp 返回 200Dify 客户端走代理403——用排错关键证据锁定代理层而不是瞎改配置UI 导出权威格式从 Console 导出含 MCP 工具节点的 DSL——UI 导出是权威格式回填 skill reference以后生成带 MCP 工具的 DSL 直接引用运行级实证三原语结论Console 工具列表只见 toolsresources/prompts 无入口——107-02 的对照结论用真实运行验证不是源码推断。这篇文章我们就用它把「工单状态查询」MCP 工具接入客服门户应用跑通全链路并固化 DSL 权威格式。4. 整体架构HTTP本地开发机dify107_02_support_serverStreamable HTTP :8902Dify 服务器apiFastAPI未知点1MCP 客户端是否走 squid 代理SSRF_PROXY 白名单 172.16.0.0/12 是否覆盖web控制台 → 工具页 → MCP tab应用 dify107_03_验证应用workflowstartticket_idtoolMCPLLMend链路很清晰本地 serverStreamable HTTP→ Dify api经 squid 代理→ web 控制台配置 → 工作流 tool 节点 → LLM → end。关键设计是验证应用用最简链路start → tool → LLM → end把未知点集中在 MCP 工具节点本身。5. 模块设计5.1 SSRF 双层 403 的修复未知点 1根因链※ MCP 客户端也走代理create_ssrf_proxy_mcp_http_clientDify api 容器core/mcp MCP 客户端SSRF 代理ssrf_proxy/squid :3128host.docker.internal.env 白名单已加本机 uvicorn :8902/mcpSDK 2.0 server层问题修复① SDK 2.0 serverstreamable-http 默认 DNS rebinding protectionHosthost.docker.internal 不在白名单 → 403run(transport_securityTransportSecuritySettings(enable_dns_rebinding_protectionFalse))开发环境生产用 allowed_hosts② squid SSRF 代理MCP 客户端也走 ssrf_proxyhost.docker.internal 不在 squid 白名单 → 403.env加SSRF_PROXY_ALLOW_PRIVATE_DOMAINSlocalhost,host.docker.internaldocker compose up -d --force-recreate ssrf_proxyrestart 不重跑 entrypoint必须 recreate排错关键证据api 容器内 curl不走代理POST /mcp 返回 200Dify 客户端走代理403 → 锁定代理层。5.2 MCP 工具节点 DSL 权威格式未知点 2UI 导出实测-data:provider_id:dify107_02_support_server# MCP provider 的 server_identifierprovider_name:dify107_02_support_serverprovider_show_name:dify107_02_support_serverprovider_type:mcp# ⚠️ 字符串 mcp区分 builtin/workflow 工具tool_name:get_ticket_statustool_node_version:2tool_parameters:ticket_id:type:mixedvalue:{{#start.ticket_id#}}tool_configurations:{}plugin_id:nullplugin_unique_identifier:nulloutput_schema:{}type:tool与 builtin/workflow 工具同 node 类型type: tool靠provider_type: mcp区分provider_id MCP provider 的 server_identifier不是行 UUID。6. 运行验证输入预期结果T1002存在 open工单 T1002 当前状态是 open最后更新于 2026-08-04 09:30:00通过T1001存在 closed工单 T1001 当前状态是 closed最后更新于 2026-08-01 10:00:00通过T9999不存在未找到该工单请核对工单号通过abc格式错 → 工具 isErrorworkflow failed显式失败非静默通过显式失败Console 工具列表只见 search_tickets / get_ticket_statustoolsresources/prompts 无入口通过三原语运行级实证7. 实战坑坑现象修复SSRF 双层 403① SDK 2.0 streamable-http 默认 DNS rebinding protectionHosthost.docker.internal → 403② MCP 客户端也走 squid 代理host.docker.internal 不在白名单 → 403① server.run 关掉或配 allowed_hosts ②.env加SSRF_PROXY_ALLOW_PRIVATE_DOMAINS force-recreaterestart 不生效实测MCP 工具输出 text 为空结构化工具outputSchema输出字段直接展开ticket_id/status/updated_attext下游引用展开字段{{#tool_status.status#}}别引用 text——首版 LLM 收空白误报「未找到」实测DSL provider_typeMCP 工具节点不认 builtin/workflow 的 provider_type 值写provider_type: mcpgraphon 枚举provider_idserver_identifier实测Model is disabledDSL 写 disabled 模型本机 deepseek-chat disabled→ run 400用 active 模型deepseek-v4-flash查GET model-providers/{provider}/models的 status实测MCP 删除/列表 UUID 语义列表接口 idserver_identifier删除/工具端点按 DB 行 UUID 查行 UUID 从 DB 查SELECT id FROM tool_mcp_providers创建响应 id行 UUID实测工具错误行为MCP 工具 isError → Dify tool 节点失败 → workflow failed显式非静默优雅降级 107-06 验收时按需加 fail 分支实测8. 实验文档及源码获取实验文档完整操作步骤DIFY-107-03MCP接入Dify全链路.md源码可直接导入含 MCP 工具节点权威格式dify107_03_验证应用.yml交付验证记录SSRF 根因链 DSL 权威格式 输出消费规则验证记录-03-MCP接入Dify全链路.md全部目录dify-107/experiments | dify-107/dsl | dify-107/servers | dify-107/delivery文章聚焦核心配置与采坑点实验的完整分步操作节点搭建/参数表/调试指引见实验文档原文。下一篇Dify MCP 集成实验04企业系统对接场景——企业系统对接选 MCP 还是插件 你在这个实验的场景里踩过什么坑欢迎评论区分享你的实战经验。
