Dify MCP Guide 2026: Connect Servers or Publish an App
Dify supports MCP in two directions. It can import tools from a remote HTTP MCP server, and it can expose a published Dify app as an MCP server. This guide covers both paths and the checks that prevent the most common transport, network, and authorization failures.
Choose the MCP direction you need
| Your goal | Dify's role | Where to configure it | What you receive |
|---|---|---|---|
| Use an external service or data source inside Dify | MCP client | Integrations, Tools, MCP | Imported tools for workflows and agents |
| Let Claude, Cursor, or another client call a Dify app | MCP server | The app's Access Point tab | A private MCP server URL for that app |
Transport boundary: Dify currently imports only MCP servers with HTTP transport. The common filesystem package communicates over stdio by default. Running its npx command does not create an HTTP endpoint or a default web port.
Connect a remote MCP server to Dify
Use this path when a service already exposes tools through an HTTP MCP endpoint. Dify connects to that endpoint, handles the configured authorization method, retrieves its tools, and makes selected tools available to your apps.
Confirm that the server provides HTTP transport
Dify needs the URL of an HTTP MCP endpoint. A local stdio command alone is not a compatible URL and does not open a web port by itself.
Open the MCP tool manager
In the workspace navigation, open Integrations, then Tools, then MCP. Choose the option to add an MCP server.
Enter a stable URL and identifier
Provide the endpoint URL, a clear display name, and a unique identifier. Apps and exported app definitions reference this identifier, so avoid changing it later.
Configure authentication
Keep Dynamic Client Registration enabled when the server supports it. Otherwise enter the OAuth client details shown by the server, or add the required static token under custom headers.
Authorize and review the imported tools
Complete the authorization flow. Dify retrieves the tool list from the server. Review names, descriptions, and write permissions before adding tools to an app.
Add only the tools the app needs
Use imported tools in Workflow or Chatflow Tool nodes, Agent nodes, or Agent apps. Test a read action and any write action separately before publishing.
Connection checklist before you publish
A successful authorization proves that Dify can talk to the server. It does not prove that every imported action is safe for production. Check the boundary explicitly.
Transport
The endpoint uses HTTP. A stdio-only command is not enough.
Reachability
The Dify API service can resolve the hostname and reach the endpoint.
Authentication
OAuth or custom headers match the server configuration.
Scope
The connected identity has only the permissions the app requires.
Tool contract
Names, descriptions, inputs, and write effects are clear.
Self-hosted networking: Test the MCP hostname from the Dify API runtime. A browser on your laptop and the Dify API container do not share the same localhost. Use a resolvable internal service name or a protected HTTPS endpoint that the API runtime can reach.
Publish a Dify app as an MCP server
Use this path when the valuable logic already lives in Dify and another MCP client should call it. The app's description and input descriptions become part of the tool contract, so write them for a machine client as well as a human reader.
1. Publish the app
Publish the current app version so the Access Point configuration represents the workflow you intend to expose.
2. Open Access Point
Find the MCP Server card in the app Access Point tab and enable it. The feature is disabled by default.
3. Describe every input
Use specific descriptions, accepted formats, and required fields so an external client can build a valid call.
4. Copy the server URL
Add the generated URL to the external MCP client and test one normal input plus one rejected input.
Treat the generated server URL like an API key. Dify states that the URL contains authentication credentials. Do not publish it in screenshots, logs, tickets, or source code. Regenerate it if exposure is possible, because the old URL stops working immediately.
Troubleshoot the observable failure
| What you observe | What to check next |
|---|---|
| Dify rejects the server URL | Confirm that it is an HTTP MCP endpoint, not a stdio package command or a general product homepage. |
| The endpoint works on the host but not in Dify | Test reachability from the Dify API container or runtime. Inside Docker, localhost points to that container, not automatically to the host or another container. |
| Authorization does not complete | If Dynamic Client Registration is unavailable, turn it off, enter the assigned client credentials, and register the exact callback URL shown by Dify. |
| Tools are missing or stale | Refresh the tool list. Review affected apps first because a removed or renamed server tool can break a saved workflow reference. |
| Apps stopped finding tools after an edit | Check whether the unique server identifier changed. If it did, add the server tools again in every affected app. |
| A long tool call times out | Measure the server response first. Increase the request or SSE read timeout only when the observed duration requires it. |
Security decisions that belong outside the prompt
- Give the MCP identity the smallest useful scope. A reporting workflow rarely needs write or delete access.
- Keep secrets in the server or deployment secret store, not in a workflow description or exported app definition.
- Review tool descriptions and input schemas before enabling automatic agent use. Ambiguous write tools need human confirmation or a narrower server contract.
- For HTTP servers, require authentication and validate expected origins. Avoid exposing an unauthenticated local service on all network interfaces.
- After a server update, refresh tools deliberately and retest workflows that depend on changed names or inputs.
Primary sources used for this guide
Product screens and protocol details change. These links are the current references for the two Dify paths and their transport and security boundaries.
Choose where Dify and the MCP endpoint will run
A self-managed VPS gives you control over private networking and secret storage. A managed Dify service reduces operating work. In either case, confirm that the Dify API runtime can reach the protected HTTP MCP endpoint before you depend on it in a published workflow.
Dify MCP questions
Does Dify support local stdio MCP servers?
Not directly. Dify currently imports MCP tools from servers that provide an HTTP endpoint. A command that communicates only over standard input and output needs a separate, secured HTTP transport before Dify can reach it.
Where do I add an MCP server in Dify?
Open Integrations, choose Tools, select MCP, and add the server URL, display name, and a unique server identifier. Complete OAuth or add the required request headers, then import the available tools.
Can a Dify app become an MCP server?
Yes. Open the app, publish the current version, go to its Access Point tab, and enable the MCP Server card. Dify creates a server URL that external MCP clients can use.
Does every Dify MCP connection need OAuth?
No. Dify supports OAuth, including Dynamic Client Registration when the server provides it, and custom HTTP headers for servers that use a static token or API key. Use the method required by the server.