dagu-dev
feat: Model Context Protocol (MCP) Support
I'd like to explore integrating the Model Context Protocol (MCP) into Dagu to enable AI agents, such as Claude Code, to create, execute, and update DAGs dynamically. MCP is an open standard that facilitates seamless integration between AI models and external tools or data sources.
Benefits:
- Dynamic Workflow Management: AI agents can programmatically manage DAGs, allowing for more adaptive and responsive workflows.
- Standardized Integration: MCP offers a consistent interface for AI agents to interact with Dagu, reducing the need for bespoke integrations.
- Scalability: Dagu MCP server enables AI agents execute complex workflow in parallel at scale in distributed environment.
Future Enhancements:
- Human-in-the-Loop Interactions: Introduce checkpoints within workflows that require human approval or input, ensuring critical decisions are overseen by humans.
- Agent-to-Agent (A2A) Communication: Enable AI agents to coordinate and delegate tasks among themselves, enhancing efficiency in complex workflows.
I'm open to collaborating on this initiative and would appreciate any feedback or suggestions.
@yottahmd I'm quite interested in participating to this dev ! I guess the main resource is the go-sdk. What do you have in mind ? Starting a MCP server as an independent process ? What tools could be added ?
- Creating a DAG
- Listing DAGs
- Executing DAGs
- Updating DAGs
Hi @SiwonP,
Thanks for your interest. I’d be really happy to have your help with development.
Yes, we should use the official SDK. We could either modify the existing server process to expose a JSON RPC endpoint alongside the REST API, or run it on a separate port. I’m not sure yet which approach is better for us.
All of those tools look useful. We’ll also need something for listing DAG runs (execution history). That said, all of these features can be accessed through HTTP requests using curl from an AI agent like Claude Code, so I’m still not completely sure how much additional value MCP would give us. I feel like there might be other possibilities worth exploring. What do you think?
@yottahmd I feel like a strict separation between the existing REST API and a future MCP server is right : that is, to use an entirely different process and port. Good point on the "Listing DAG runs", it seems valuable to expose this. Concerning your doubt about the reasons to support MCP whereas dagu already have HTTP endpoints, it seems to me that The former is a real plug and play for LLMs/agents. MCP does return very specific payloads for LLMs/Agents, so having support for MCP would ease in the compatibility with AI agents, instead of tweaking the already existing HTTP API. I hope I make sense !
@SiwonP Thanks for the explanation, that makes sense to me. We could add a separate JSON RPC endpoint process as its own command, something like dagu mcp using different port. I’m also wondering whether the MCP server should be included when running dagu start-all. My instinct says probably not, but I’m open to thoughts.
Regarding authentication, we currently have basic auth, API tokens, and OIDC, but we lack user management and RBAC. Do you have any ideas or knowledge for how MCP authentication should work?
@SiwonP We can reuse API token authentication. It's very simple, and should work. What do you think? https://docs.dagu.io/configurations/authentication/token
@yottahmd sorry i have been busy else where !
I agree on not starting the MCP server with dagu start-all, at least for now.
Concerning the authentication, I have no knowledge of how it should be done for MCP, but I guess token authentication is a way to go !
I'll try and look into it this week
@yottahmd I've been working on the actual implementation on my own fork. Are you interested in me creating a Pull Request so that you can see what I've done/I'm doing ?
It is not yet ready (far from it) but I've managed to add a command : go run ./cmd mcp that start the mcp server.
It appears I am on the right track because I've tried to register this mcp server on my continue.dev VSCode extension and it show the 3 tools I've added to the server.
However I'm unsure about some parts (I'm still new to MCP as well..), but from my understanding mcp server can either run locally or remotely, communicating either with stdout or http.
In case it runs locally, the MCP client (in my case the continue.dev extension) runs the mcp server : I think it might be useful to only package the MCP server a part from the rest of the code ?
Either way the MCP server will use the dagu REST API so here comes my first uncertainty :
Shall we pass the REST API config as env variables ? This is needed because the MCP server is not likely to run on the same machine as the dagu server.
I still cannot actually use the tools, but I'm looking into it, as I also need to enforce some tests
@SiwonP Thanks a lot for the update! Sounds like great progress. Yes, please open a PR so we can have code rabbit to check the PR as well as myself.
Regarding server endpoint configuration, we could have an argument to specify the server endpoint like dagu mcp --url=http://192.168.0.10/api/v2. Just an idea. What do you think?
@yottahmd I agree on giving the possibility to pass the endpoint as an argument. Would it also be convenient to look for an environment variable ? Something like DAGU_URL=http://192.168.0.10/api/v2 ?
I'm not sure, but how about focusing on building the simplest version of the mcp server functionality? I feel like even supporting only a positional argument would be suffice, for example dagu mcp http://192.168.0.10/api/v2.