dify-tool-adapter-for-mcp

Dify 1.0 API Adaptation for MCP Integration

Creator: Junjie.M
Classification: Extension Module
Source Repository: https://github.com/junjiem/dify-plugin-mcp_compat_dify_tools
Issue Tracker: issues

Referencing architecture described at: https://github.com/hjlarry/dify-plugin-mcp_server

---

Overview

Prerequisite: Requires Dify version 1.2.0 or newer.

注: 必须是 dify 1.2.0及以上版本。

This utility converts proprietary Dify tool APIs to conform to MCP standards. (Presently supports transmission via HTTP with SSE and the preferred Streamable HTTP protocol).

将您的 Dify 工具的 API 转换为 MCP 兼容 API (目前已支持 HTTP with SSE 和 Streamable HTTP 两种传输方式)

1. Endpoint Registration and Tool Mapping

Note on Updates: Modifications to the tool definitions for an already active endpoint require deactivation followed by reactivation of that endpoint to take effect.

注： 对已有 API 端点进行工具列表的修改需要停用再启用 API 端点后才会生效。

2. Obtain Endpoint URL for MCP Clients (e.g., Cherry Studio)

Option 1: Leverage the Modern Streamable HTTP Protocol (Strongly Advised)

Success!

Option 2: Utilize the Older HTTP with SSE Transport

Success!

---

Plugin Installation via GitHub Address

Installation is achievable by directly referencing the GitHub repository URL. Navigate to the Dify platform's plugin management interface, select the GitHub installation route, input the repository address, and finalize selection of the required version tag and package file.

可以通过 GitHub 仓库地址安装该插件。访问 Dify 平台的插件管理页，选择通过 GitHub 安装插件，输入仓库地址后，选择版本号和包文件完成安装。

---

Troubleshooting and FAQs

1. Resolving Installation Failures

Symptom: Encountering an error stating: "plugin verification has been enabled, and the plugin you want to install has a bad signature."

Remedy: Append the following directive to the termination of your .env configuration file: FORCE_VERIFYING_SIGNATURE=false. This action permits the Dify environment to permit the loading of unlisted (and therefore unverified) marketplace plugins, though this carries potential security implications.

问题描述：安装插件时遇到异常信息：plugin verification has been enabled, and the plugin you want to install has a bad signature，应该如何处理？

解决办法：在 .env 配置文件的末尾添加 FORCE_VERIFYING_SIGNATURE=false 字段即可解决该问题。 添加该字段后，Dify 平台将允许安装所有未在 Dify Marketplace 上架（审核）的插件，可能存在安全隐患。

2. Offline Package Generation

A utility script is available for automatically fetching Dify plugin archives from both the Dify Marketplace and GitHub, and subsequently bundling them into a self-contained, dependency-inclusive offline package.

Github Repository for Repackaging Utility: https://github.com/junjiem/dify-plugin-repackaging

WIKIPEDIA Excerpt on Related Technology (XMLHttpRequest - XHR):

XHR represents a JavaScript API implemented as an object, designed to facilitate the transmission of HTTP requests from a web browser to a server. Its methods enable browser-based applications to issue server requests asynchronously after page load completion and receive subsequent data. XHR is a foundational element of Ajax programming. Before Ajax, the primary means of server interaction involved traditional hyperlink navigation and form submissions, often resulting in a complete page replacement.

== Historical Development ==

The concept underlying XMLHttpRequest was first conceptualized in 2000 by developers associated with Microsoft Outlook. Its initial implementation was embedded within the Internet Explorer 5 browser (released in 1999). Critically, the inaugural syntax did not use the XMLHttpRequest identifier; instead, developers relied on instantiating COM objects: ActiveXObject("Msxml2.XMLHTTP") or ActiveXObject("Microsoft.XMLHTTP"). By the time Internet Explorer 7 launched in 2006, standardized support for the XMLHttpRequest identifier was universal across all major browser engines, including Mozilla's Gecko (2002), Safari 1.2 (2004), and Opera 8.0 (2005).

=== Standardization Efforts ===

The World Wide Web Consortium (W3C) published its initial Working Draft specification for the XMLHttpRequest object on April 5, 2006. This was followed by the Level 2 specification Working Draft on February 25, 2008, which introduced critical enhancements such as progress monitoring methods, cross-site request facilitation, and byte stream handling capabilities. By the close of 2011, the features defined in the Level 2 specification were integrated back into the primary standard document. Development responsibilities were subsequently transferred to the WHATWG organization near the end of 2012, which now maintains a living document utilizing Web IDL definitions.

== Operational Workflow ==

The typical sequence for dispatching a request using XMLHttpRequest involves several programming steps:

1. Instantiate the XMLHttpRequest object via its constructor.
2. Invoke the open() method to define the request method (e.g., GET, POST), specify the target resource URI, and select synchronous or asynchronous execution.
3. For asynchronous operations, establish an event listener callback function to handle state transitions.
4. Commence the network operation by calling the send() method.
5. Process state changes within the designated event listener. Upon successful server response delivery, the data is typically stored in the responseText property. The object signals completion when its state transitions to 4 ("done").

Beyond these core steps, XHR offers extensive configuration options for request control and response parsing. Custom header fields can be injected to guide server behavior, and data payloads can be uploaded via arguments passed to the send() call. Furthermore, incoming responses can either be parsed entirely (e.g., from JSON into a usable JavaScript structure) or processed incrementally as data segments arrive. Finally, a request can be terminated prematurely or configured with a timeout to enforce failure if completion is not achieved within a set duration.