把 Dify 应用变成 MCP 服务,让 AI 工具互相「认识」

工具越来越多,智能体要调的东西也越来越多,传统做法是一个个硬编码地接进来,既费劲又僵硬。MCP(模型上下文协议)想解决的就是这件事:它是一套标准,让 AI 智能体和各种工具/服务,不用硬编码就能互相「发现」、按需调用,从而拼出一个灵活、可扩展的生态。

Dify 的双重身份

通过插件,Dify 在 MCP 这件事上是双向的:它既能当 MCP 客户端,去调用外部的服务(比如接上 Zapier,撬动一大票自动化能力);也能当 MCP 服务端,把自己做好的应用发布出去,给别的工具用。这种「既能用别人、也能被别人用」的双向能力,是它和很多只能单向集成的方案不一样的地方。

怎么把一个 Dify 应用变成 MCP 服务

社区做的 mcp-server 插件,能把任意一个 Dify 应用,变成一个符合 MCP 规范的服务端点,让外部的 MCP 客户端直接访问。配置上,你定义好端点和应用参数(用 JSON schema 描述),它会生成一个唯一的 URL,像 Cursor、Claude Desktop 这些支持 MCP 的工具,拿到这个地址就能直接调用你的 Dify 应用。

“和传统 REST API 不同,MCP 天生是为 AI 场景设计的——它让智能体自己去发现、去调用服务,省掉了大量手工对接的活。

它能用来干嘛

这个能力不只对开发有意义。你完全可以把一些内部常用的流程——客户请求分类、文档摘要、合同初审之类——做成 Dify 应用,再发布成共享的 MCP 服务,公司里其他的智能体、其他的工具,需要时直接调用,不用重复造轮子。一套能力,多处复用。

MCP 和 REST API 有什么不一样

很多人会问:不就是调接口吗,和 REST API 有啥区别?区别在「谁来对接」。REST API 要开发者读文档、写代码、一个个手工集成;MCP 则让工具自带「说明书」,智能体能自己发现「这个服务能干什么、需要什么参数」,然后按需调用,不用人提前硬编码。换句话说,REST 是给人对接的,MCP 是给 AI 自己对接的——在智能体满天飞的时代,后者省下的集成功夫相当可观。

把内部能力沉淀成「AI 能力货架」

MCP 真正的价值,在企业内部尤其明显。你可以把那些反复要用的能力——客户请求分类、文档摘要、合同初审、知识问答——各做成一个 Dify 应用,再发布成 MCP 服务。之后公司里任何一个智能体、任何一个新搭的流程,需要这些能力时直接调用就行,不用每次重新造。久而久之,这些服务就成了企业自己的「AI 能力货架」,越用越值钱。

想试,从一个内部小服务起步

听起来很大,其实上手可以很小。我们建议第一步别想着改造全公司,而是挑一个你已经做好、又常被别处需要的 Dify 应用——比如一个文档摘要或一个分类小工具,用 mcp-server 插件把它发布成 MCP 服务,再在 Cursor 或 Claude Desktop 里接上试一次。跑通这一个,你就对「发布—发现—调用」这套流程有了直观的感受,再往外推就有底了。

还有个常被问的:已经有 REST API 了,还值得再包一层 MCP 吗?我们的看法是,如果这个能力主要是给「人写代码去调」,REST 够用;但如果你预见到会有越来越多的智能体要自己去发现、调用它,那早点用 MCP 暴露出来,就是在给未来省事。技术选型,有时要往前看一步。

随着智能体能调的工具越来越多,「怎么让这些工具和服务低成本地互相打通」会越来越关键。MCP 提供的,正是这样一套通用的「插座」。对企业来说,早一点用 MCP 的方式把内部能力沉淀成可复用的服务,后面接入新工具、搭新智能体时,会省下大量重复集成的功夫。当然,对外暴露服务也意味着要把好权限和安全这道关——谁能调、能调哪些、传进来的参数合不合法,都得管起来。这点我们在做集成时,从来不敢省。

留下你的场景和痛点,我们帮你判断从哪一步开始。