1. 为什么要在 Dify 里接 SQLBot 的 MCP 数据引擎如果你正在用 Dify 搭智能体又希望它能直接回答“上个月华东区退货率是多少”这类问题而不是每次都手动写 SQL、导 CSV、再贴进对话里那 SQLBot 的 MCP 数据引擎就是那个值得接进来的部件。SQLBot 负责把自然语言翻译成 SQL 并执行查询MCP 负责把它的能力以标准工具的形式暴露出来Dify 则负责编排整个对话流程。三者串起来之后你的智能体就具备了“自然语言查库”的能力。这篇内容面向的是已经会用 Dify 拖工作流、但对 MCP 协议还不太熟的开发者。我会把整条链路拆成两种落地方式一种是工具调用工作流由你手动搭稳定可控另一种是 AI 自动调用靠提示词让 Agent 自己决定什么时候调mcp_start、什么时候调mcp_question搭起来快适合轻量场景。两种方式我都会给出可复制的配置片段、settings.json骨架以及连通性验证动作目标是让你一次跑通从 Dify 到 SQLBot 的查询链路。先说清楚一个容易踩的坑SQLBot 的 MCP 服务不是无状态的。第一次调用mcp_start会返回access_token和chat_id后续的mcp_question必须带着这两个值才能继续问数。很多人第一次接的时候只调了mcp_question结果一直报鉴权失败就是因为漏了这一步。理解了这一点后面的配置就顺了。2. TaoToken 前置把模型和 Key 准备好在动 Dify 之前先把模型侧的事情理清楚。Dify 里的 Agent 节点、代码执行节点都需要一个能稳定调用的模型服务而 MCP 工具本身也需要一个 API Key 来做授权。我习惯把这两件事放在 TaoToken 上统一处理省得在多个平台之间来回切。TaoToken 的定位是给开发者和智能体应用提供模型调用与密钥管理的能力。你可以把它理解成一个“模型接入层”Dify 通过它拿到对话模型MCP 服务通过它拿到授权凭证。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 注意 API 地址后面不加 UTM 参数配置的时候别多写。具体要准备两样东西。第一是模型对话能力用来驱动 Dify 里的 Agent 和代码节点入口在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 进去之后创建一个 Key复制出来备用。第二是 Coding Plan如果你打算长期跑编码类或 Agent 类任务用套餐会比按量更划算入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。创建完 Key 之后建议先去模型对话页面做一次最小验证确认 Key 是通的入口在 https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 。这里有个细节值得说MCP 服务端的settings.json里需要填 API Key这个 Key 和 Dify 里模型用的 Key 可以是同一个也可以分开。我建议分开因为 MCP 服务的调用频率和模型调用频率不一样分开之后排查问题更清晰。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 在里面可以查看用量和 Key 状态。注意所有 Key 都不要硬编码在前端或公开仓库里。Dify 的工作流配置里引用变量MCP 的settings.json放在服务端本地这是最低要求。3. 可复制配置MCP 服务端 settings.json 骨架SQLBot 的 MCP 服务端需要一份配置文件来声明它暴露哪些工具、连哪个数据库、用什么传输方式。下面这份骨架你可以直接拿去改重点是transport和url两个字段。{ sqlbot_mcp: { url: http://YOUR_IP/mcp, transport: sse, api_key: YOUR_TAOTOKEN_API_KEY, tools: { mcp_start: { description: 初始化会话返回 access_token 和 chat_id, params: [username, password] }, mcp_question: { description: 基于自然语言提问执行查询, params: [chat_id, question, token] } } } }把YOUR_IP换成你部署 SQLBot MCP 服务的实际地址YOUR_TAOTOKEN_API_KEY换成你在 TaoToken 控制台创建的 Key。transport用sse是因为 Dify 的“发现和调用 MCP 工具”组件目前对 SSE 支持最稳如果你用 streamable HTTP部分版本会有握手超时的问题。这份配置在 Dify 里有两个填法一是直接写在“调用 MCP 工具”组件的 MCP 服务配置框里二是放在 API Key 授权配置里统一管理。我推荐后者因为工作流里可能有多个 MCP 调用节点统一管理改一处就行。配置完之后Dify 会去拉取工具列表如果拉不到先检查url能不能在服务器上curl通。curl -N http://YOUR_IP/mcp正常的话你会看到 SSE 流保持连接说明服务端活着。如果返回 404 或连接被拒那就是地址或端口的问题跟 Dify 无关先把这步解决。4. 方案一工具调用工作流手动搭但最稳工具调用的思路是你手动把每个节点连起来用条件分支判断有没有access_token没有就先调mcp_start拿有就直接调mcp_question。整条链路清晰出问题容易定位。4.1 开始节点与会话变量在开始组件的输入字段里加两个参数username、password。然后在工作流的会话变量里加两个access_tokenString 类型、chat_idNumber 类型。这两个变量是跨节点传递的关键尤其是第二次问数的时候必须复用第一次拿到的 token否则会重新走一遍mcp_start既慢又可能触发限流。4.2 条件分支判断 token 是否为空加一个条件分支节点条件写access_token为空。为空走“获取 token”分支不为空直接走“问数”分支。这个判断是整个工作流的分水岭也是很多人漏掉的一步——如果不判断每次都调mcp_start虽然能跑通但效率低。4.3 调用 mcp_start 获取凭证在“发现和调用 MCP 工具”组件里选“调用 MCP 工具”工具名称填mcp_start参数填{ username: 引用变量开始/username, password: 引用变量开始/password }MCP 服务配置填第 3 节那份settings.json里的sqlbot_mcp内容。设置里把“MCP 资源作为工具”和“MCP 提示词作为工具”都选true。调用成功后返回的text里是一段 JSON包含data.chat_id和data.access_token。4.4 代码执行节点做 JSON 标准化加一个代码执行组件输入变量arg1接上一步的textPython 代码这样写import json def main(arg1: str) - dict: json_obj json.loads(arg1) return { chat_id: json_obj[data][chat_id], access_token: json_obj[data][access_token] }输出变量加chat_idNumber和access_tokenString。这一步的作用是把嵌套的 JSON 拍平方便后面引用。4.5 变量赋值节点回写会话变量用变量赋值组件把代码执行输出的chat_id和access_token分别赋给会话变量。这一步做完后面的节点就能通过会话变量拿到凭证了。4.6 调用 mcp_question 执行问数再加一个“调用 MCP 工具”组件工具名称填mcp_question参数填{ chat_id: 引用会话变量chat_id, question: 引用变量开始/sys.query, token: 引用会话变量access_token }注意chat_id是 Number 类型引用时不要加引号question和token是 String正常引用即可。设置里第一个选true第二个选false。最后接一个直接回复组件把mcp_question的text结果展示出来。5. 方案二AI 自动调用靠提示词让 Agent 自己编排如果你不想手动连这么多节点可以用 Agent 的 FunctionCalling 模式让模型自己决定调用顺序。这种方式搭起来快但稳定性依赖提示词质量。5.1 开始节点与 Agent 配置开始节点同样加username、password。然后加一个 AGENT 组件Agent 策略选“支持 MCP 工具的 Agent”模型选 FunctionCalling 模式。MCP 服务配置同上设置里“MCP 资源作为工具”选true“MCP 提示词作为工具”选false。最大迭代次数调到 10记忆窗口调到 20。5.2 指令提示词模板指令部分直接抄这份# 回答要求 按需调用 mcp_start 和 mcp_question 工具获取信息回答问题。 mcp_start 账号密码 username: 引用变量开始/username password: 引用变量开始/password 工具调用逻辑 首先调用 mcp_start 工具获取 access_token 和 chat_id帮我记住这两个参数 之后不要重复调用 mcp_start直接使用即可 然后再调用 mcp_question 工具其中 token 和 chat_id 参数是调用 mcp_start 工具返回 question 是用户提问。 # 用户提问 引用变量开始/sys.query这段提示词的关键是“不要重复调用 mcp_start”这句不加的话模型可能每轮都重新初始化导致 token 失效。最后接直接回复组件把 Agent 输出的text展示出来。6. 验证请求与成功结果配置完之后怎么确认链路是通的我一般分三步验证。第一步单独测 MCP 服务端。用curl发一个mcp_start请求看能不能拿到access_token和chat_id。这一步过了说明服务端和数据库是通的。第二步在 Dify 里跑一次工具调用工作流输入username、password和一个简单问题比如“查一下订单总数”。如果直接回复节点输出了数字和 SQL 语句说明 Dify 到 SQLBot 的链路通了。第三步跑一次 AI 自动调用同样的问题看 Agent 是不是先调mcp_start再调mcp_question。如果 Agent 跳过了mcp_start直接调mcp_question并报错那就是提示词里“先调 mcp_start”的约束不够强把这句话加粗或放到最前面。成功的标志是直接回复里能看到查询结果同时日志里能看到两次 MCP 调用记录第一次是mcp_start第二次是mcp_question。7. 本篇常见错排查报错一mcp_question返回 401 或 token invalid。九成是access_token没传对。检查变量赋值节点有没有把代码执行的输出正确回写以及mcp_question的参数里token是不是引用了会话变量而不是代码执行的临时输出。临时输出在第二次问数时是空的这就是为什么要用会话变量。报错二Dify 拉不到 MCP 工具列表。先确认url在 Dify 服务器上能curl通再确认transport是sse。如果服务端用的是 streamable HTTP换成 SSE 再试。另外检查settings.json里的api_key有没有过期。报错三Agent 反复调用mcp_start。提示词里明确写“获取后记住不要重复调用”并且把mcp_start的账号密码放在指令里而不是让模型自己猜。如果还不行把最大迭代次数降到 5逼模型尽快收敛。报错四代码执行节点报 JSON 解析失败。说明mcp_start返回的text不是纯 JSON可能带了额外的前后缀。在 Python 里加一层容错import json import re def main(arg1: str) - dict: match re.search(r\{.*\}, arg1, re.DOTALL) json_obj json.loads(match.group()) return { chat_id: json_obj[data][chat_id], access_token: json_obj[data][access_token] }报错五问数结果为空但没报错。检查question参数有没有正确引用sys.query以及数据库里确实有数据。有时候是 SQLBot 的权限配置没放开对应表去 SQLBot 后台确认一下。8. 接下来怎么走如果你只是想让智能体具备查库能力工具调用方案已经够用了稳定、可控、好排查。如果你要做的是一套长期运行的 Agent比如每天自动跑报表、或者嵌入到客服系统里那建议走 Coding Plan把模型调用和 MCP 授权统一管理入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有 MCP 相关的参数说明和示例。Key 管理还是去 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。最后留一个我踩过的坑MCP 服务端的settings.json改完之后一定要重启服务不然 Dify 拉到的还是旧配置。这个坑我排查了半小时才发现希望你别再踩。