# gotoolkits/DifyWorkflow [Health: Active]

**Category:** 🛠️ Other Tools and Integrations  
**Repository:** https://github.com/gotoolkits/mcp-difyworkflow-server  
**GitHub Stars:** 61  
**Views:** 3  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/gotoolkits-difyworkflow

## Description
Tools to the query and execute of Dify workflows

## Claude Desktop Quick Installation
Heuristic fallback — verify the package name and runner against the repository README before running it. Uses `npx` (confidence: low):

```json
"mcpServers": {
  "difyworkflow": {
    "command": "npx",
    "args": ["-y","gotoolkits-difyworkflow"],
    "env": {
      "DIFY_WORKFLOW_NAME": "",
      "DIFY_API_KEYS": ""
    }
  }
}
```

**Requires environment variables:** `DIFY_WORKFLOW_NAME`, `DIFY_API_KEYS` — the values above are empty placeholders; fill in real credentials before running (see the repository for what each one is for).

## Documentation

## What gotoolkits/DifyWorkflow MCP server does

gotoolkits/DifyWorkflow MCP server exposes Dify workflow operations through MCP. It provides one operation for listing the workflows configured for use and another for running a selected workflow with supplied input.

The server is intended for setups with multiple custom workflows. Each workflow receives a name that can be referenced in prompts or tool calls, while its corresponding Dify API key authorizes access to that workflow.

## How it works

At startup, the server reads the Dify platform API base URL from the command-line configuration and reads workflow names and API keys from environment variables. The names and keys are paired by position, so the first name must match the first key, the second name must match the second key, and so on.

The `list_workflows` tool returns the authorized workflows available through the configured server. The `execute_workflow` tool accepts a workflow name and an input value, then sends the request to Dify. The documented workflow input variable is `message`, so workflows should define that input name when they are created in Dify.

## Setup and configuration

Build the executable from the repository with Go or the provided Make target. The resulting binary can be placed on the system path or referenced by its absolute path in an MCP client configuration.

A typical server entry supplies the Dify API base URL as the `-base-url` argument. The example uses `http://localhost/v1`, but the value should point to the API endpoint for the relevant Dify deployment.

Set these environment variables:

- `DIFY_WORKFLOW_NAME`: comma-separated workflow names exposed by the server.
- `DIFY_API_KEYS`: comma-separated Dify workflow API keys.

The two lists must contain corresponding entries in the same order. API keys are generated for the applicable workflows in Dify.

## Tools and capabilities

- `list_workflows`: lists the workflows authorized by the configured name and key pairs.
- `execute_workflow`: runs a named workflow with an input message.
- Multiple workflow configuration: supports on-demand use of multiple custom Dify workflows from one MCP server process.

## Limitations and notes

gotoolkits/DifyWorkflow MCP server depends on a reachable Dify API endpoint and valid workflow API keys. The provided material does not describe OAuth, alternative authentication methods, transport options, or support for workflow inputs with names other than `message`.

The workflow name and API key configuration is positional rather than independently keyed. A mismatch in ordering can associate a name with the wrong credential, so both environment variable lists should be maintained together. The documentation also does not specify a release package or platform-specific binary; building from source is the documented installation path.

For a client to execute a workflow successfully, that workflow must exist in Dify, its API key must be available to the server, and its expected input variable should be defined as `message`.

_Full upstream README: https://allmcps.com/mcp/gotoolkits-difyworkflow/readme_