本文适用对象：高级水平
目标：将实现MCP服务的连接，扩展Dify系统内的大模型能力。
最近的课麦金叔带大家去了解了MCP，并动手实现了基本的MCP协议各个部分。今天终于可以回到主线了。距离上一期爆火的Dify实现可视化课程也有半个多月了，如果已经没印象了，可按下表链接复习。
往期回顾
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|
今天我们将要继续企业应用之旅，让Dify变成一个超级中间站，能将开源的大几千MCP服务为我所用。
学习完成，你将会让自己的Dify也拥有更专业的使用MCP的能力。
01.
准备环节
我们之前详细学习了MCP所有关键的内容，是时候来表演了。
不过Dify是一个服务端运行的系统，它不像本地可以为MCP服务去准备运行环境。如果让Dify集成stdio方式的MCP，那改动就有点大了。
但是现存海量的MCP服务，绝大多数都是stdio方式，所以关键一点就是打通这个使用方式上的差异。
因此使用一个叫mcp-proxy的工具，就来的如此的顺理成章。(如果听不懂stdio的话，请复习前面的博文)
[大模型的得力干将MCP(5) - 应用场景和发展方向，窥探先机，不容错过](https://mp.weixin.qq.com/s?__biz=MzAxNjQxMTQ3NA==&mid=2452385457&idx=1&sn=3cc0165bad65a8d13b2bb82df2ba3327&scene=21#wechat_redirect)
为了不影响本地电脑的环境配置等，我们同样以容器的方式，去运行这个mcp-proxy。
根据它的说明文档，有两个地方需要修改为自己的。
1. 重新打包一下镜像，加入uv运行环境。新建一个mcp-proxy.Dockerfile文件，内容如下：
2.以上述镜像，加入需要代理的MCP服务，我们以mysql\_mcp\_server为例。新建一个docker-compose.yml文件，内容如下：
现在启动docker compose up -d，去容器中看到输出log如下，就说明成功了。
上述步骤完成，给我们干活的MCP服务就搭好了，接着开始操作Dify。
有两个插件需要准备好。
如果你在插件市场看到他们的版本低于0.0.8，请去插件介绍的github上手动下载，然后通过本地插件的方式去安装。
如果你还没有这么快要去尝试，也不用主动升级，说不定你要用的时候已经有插件市场的0.0.8版本了。（一定要听劝，不要乱尝试）
至此，所有今天需要的准备就完成了，恭喜！
02.
动手做一做
今天为了演示，新建一个chatflow，把所有其他的干扰因素都排除。
在开始节点之后新增一个节点"Agent"。
第一步 需要指定AGENT策略，点下拉箭头会出现"支持MCP工具的Agent"，点击之后会再展开，选择"FunctionCalling(Support MCP tools)"
此时才开始正式配置相关参数。
第二步 ，模型这里选择支持FunctionCall的大模型，如qwen2.5。
第三步 ，工具列表这里点加号，把"通过SSE发现和调用MCP"里面包含的两个工具都加上
如果是第一次配置这个工具，它会问你要授权，填入刚才docker提供MCP Proxy的服务地址和端口，如麦金叔是这样的。
{"mysql\_mcp": {"url": "http://192.168.0.231:8066/sse","headers": {}, "timeout": 50, "sse\_read\_timeout": 300}}
保存时没有报错，说明就成功了。
第四步 ，MCP 服务配置的框内填入提供MCPProxy的地址，如下
{
"mysql_mcp": {
"url": "http://192.168.0.231:8066/sse",
"headers": {},
"timeout": 50,
"sse_read_timeout": 300
}
}
最后把剩余的，指令，查询和最大迭代次数修改完就OK了，见上图。
见证奇迹的时刻到来了。我们进行测试，结果如下：
除了运行时间长点，没毛病。本地测试环境，大模型运行效率不高。嘿嘿！
总结
今天学习了将MCP服务引入Dify系统，从而打通了大模型与更强大扩展工具之间的联系。你的Dify应用将会有更多更好的能力做出更酷的事情来。
如果你对AI的发展感兴趣，欢迎一键三连。有任何问题可以扫码添加好友，我们共同探讨。