Summary

Workflows you already built, reachable from the assistant you already use.

The design is deliberately narrow: the allowed workflows and their keys are fixed when the server starts, so a model can only call what you listed. Two details decide whether it works first time - the name and key lists must be in the same order, and the workflow's input variable has to be called message.

What it is

A small Go server that fronts Dify workflows. You list which workflows it may reach and their API keys at launch; the client can then see them and run one by name with an input message.

What you get

List the workflows this server has been authorised to call
Execute one by name with an input, and get the workflow's result back
Several custom workflows behind one server, selected per call rather than per deployment

Requirements

Go to build, then either put the binary on your PATH or reference it by absolute path in the client config. Point it at your Dify API base URL with the base-url argument. Two environment variables carry the mapping: DIFY_WORKFLOW_NAME with the workflow names you choose, and DIFY_API_KEYS with the matching keys generated in Dify - the two lists must line up in order. On the Dify side, the workflow's input variable should be named message.