Dify 下怎么对接 MCP 服务？

在上面的示例中，实际上 MCP Server 是由 MCP Client(Cursor) 来本地启动的，这要求 Client 和 Server 在同一台主机上（两者通过 stdio 通信），为了支持跨主机的通信，MCP 有另一个通信模式叫 SSE（Server-Sent Events）。

SSE 底层跑的还是 HTTP，只是上层有自己的通信规范，可以理解为造了个标准的 API。

再回到标题，如果要让 Dify 对接 MCP Server，其实只需要完成下面两件事：

• 在外部服务器部署支持 SSE 的 MCP Server

• 在 Dify 上安装支持 SSE 的 MCP Client（插件）

MCP Server 配置及启动

我参照一个 Weather 的 MCP SSE 项目，用 Github Copilot 将我司的 AI Security API 改成了 SSE 版本的 MCP Server，启动：

uv run src/mcp_server.py
INFO:     Started server process [4093949]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)

看到状态为 Running 且在监听端口之后，就可以在 Dify 中进行测试啦。

配置 MCP Server，参考配置如下，指一下 MCP Server 的 URL 即可：

{
    "PANW-AI-Security": {
        "url": "http://10.10.50.144:8080/sse"
    }
}

配置截图：

调用示例：

MCP 和 Dify Plugin 的对比

在写 SSE Server 的时候，发现有些理念和 Dify Plugin 有点类似，但又有些区别，分别用图片和文字描述下。

• 从架构上来说，如果要让大模型调用外部组件，插件可以一跳直达外部服务，而使用 MCP 则需要外挂一个 MCP Server 做中转。

如果再复杂一点，假如让 Agent 调用多个服务，这时候你会发现两个很像，只是 MCP 把能力集中在了外部，而在 Dify 下能力集中在插件中。

早期 Dify 的插件内置在发行版中，如果要更新、新增插件需要改动项目文件。Dify 1.0 之后可以把插件“外置”，通过 dify-plugin-daemon 来管理和运行，这实际上是一种解耦，只不过这些插件只适用于 Dify 生态，其他平台不能直接拿来使用。 

如果使用 MCP 架构，理论上来说一套 MCP Server 可以给多个 AI 平台使用，没有太多的适配成本。另外如果要对服务进行更新，只需要更改 MCP Server 侧的代码即可，应用本身可以不用动。

说完了优点，再说说 MCP “弱”的地方。

1. 无处安放的 Key/Token

你会发现，在第一个 Cursor 的示例中，调用外部服务的 API Key 直接写在了配置文件的环境变量中，总感觉这类敏感信息需要有个安全的地方存放。

在做第二个 Dify SSE 对接的时候，Key 需要直接放在运行代码的地方，也就是 MCP Server 所在位置，查了很多文档，大家要么直接写在环境变量里，要么直接写在代码里...(说到这里，未来应该会有一些 MCP Manager 方案出来做这些事)

还有一种形式是放在 Client 侧，以 Header 或者 HTTP 请求参数的形式传递给 MCP Server，然而这部分并没有规范。另外，Client 侧如何妥善保存密钥也是个问题，无论 VS Code/Cursor 还是 Dify 的社区 MCP 插件，都是明文直接放在 JSON 中...

相比之下，Dify Plugin 的设计就很好，变量属性为 secret-input 时都会隐蔽保存。

2. 认证怎么做？

官方的一些示例中，会在 Server 设置一个 Key（如上面所说，无处安放），然后 Client 通过 Header 等形式传输同样的 Key 以达到认证的目的，这未免显得有点粗糙（官方有很多和认证相关的 issue，应该会补齐这部分功能）。

而在 Dify 下 Plugin 和 Dify 就是一体的，不需要考虑组件间的信任。

3. 安全隐患

因架构决定 MCP Server 侧的东西可以是动态的，如果有居心叵测之人修改/增加了 MCP Server 中的函数，模型又自动调用了这些模块，风险自不用我说。（已经有安全团队 Demo 通过 MCP tool 的 description、隐藏的提示词、虚假报错信息等诱导大模型执行特定操作...）

相比之下 Dify 的 Plugin 好歹会有官方验证，升级也需要用户干预，虽然不那么自动，但风险相对更小一些。(魔搭社区、smithery 等很多平台已经有成型的 MCP 商店了，有些还集成了安全扫描功能，一定程度上可以解决来源和安全问题)

4. MCP Server 管理及运行

在当前的实现下，通常一个 MCP Server 对应一个服务商的多个服务，如果一个 Agent 需要使用 20 个服务商的服务，那需要配置 20 个 MCP Server，不同 MCP Server 可能会有不同的依赖环境，不同的配置，不同的认证方式，这些还都是通过 json 文件去定义...

不确定官方会不会有一个集中式的管理、运行和接入服务，反正社区是有人在做了。

5. 在 Dify 下，仅能用于 Agent，不能应用于工作流。

虽说 Agent 是未来 AGI 的方向，但实际在应用时，工作流也有其优势，并不是所有场景都适合用 Agent 实现，而目前在工作流下 MCP 并没什么用。

引用一个 Anthropic 《Building effective agents》中的 Checklist：

你会发现日常 AI 应用中，很多时候并不需要用到 Agent，用 Agent 效果不一定更好，但 Token 肯定消耗更多(老黄狂喜)：

• RAG 应用，做个知识检索，贴出结果和参考链接就 OK 了

• 联网检索，工作流+工具+LLM 也能做

• 要多功能，直接做成多个机器人就行了，不同机器人走不同的工作流，不需要 Agent 来判断用户想干什么再去选择不同的工具，用户自己会选

• ...

再看目前最亮眼的 Agent 应用，就是类似 Manus 一样的代码开发系统，满足上面的各种说明：

• 节省（程序员）成本；

• 足够复杂，需要自动试错和纠错；

• 只要开放接口，Agent 可以自己去运行慢慢调试

• ...

说到这里，似乎感觉 MCP 就像是 Anthropic 为了自家代码开发 Agent 打造的一样... 开发类 Agent 就是要调用很多工具，而标准化这些工具的调用，很能受益这类 Agent。

技术上来说，Dify 等平台其实可以做一个专用于 Workflow 的 MCP Client 插件，自动获取 MCP Server 的参数列表，然后将其变成表单供应用使用，不知道未来会不会有这样的东西出现。

感觉这次的分享可以到此结束了， 已 3k 余字，能看到这里的都是真爱。

对待新的事物，还是要冷静分析，感觉 MCP 还是有点过热了。和家人戏说，现在 MCP 生态就像卖装修建材的多(MCP Server)，但是修房子和买房子的不一定有这么大需求(Agent)。