MCP Support

[kulinacs]

Description

Support for tasks to be exposed via MCP server, allowing LLMs (like coding agents) to be aware of tasks without needing to be aware of taskfile specifically. Wrappers already exist for this, but it'd be much more convenient for this to be built into Task itself.

Looking at the existing API, it makes the most sense to me to implement it as a flag, similar to --list.

For example, running task --mcp would start an MCP server using stdio transport and expose all of the tasks as tools. Existing descriptions and arguments could be included in the tool definitions exposed by the MCP server. Ultimately this would be just another way to call existing tasks.

I'm not sure on the maturity of the project, but assuming the server implementation is complete, I imagine this should be simple to implement with the new Go SDK (https://github.com/modelcontextprotocol/go-sdk)

[andreynering]

I saw this some time ago from @rsclarke:

• https://x.com/rsclarke/status/1932339933693595674
• https://github.com/rsclarke/mcp-taskfile-server

Not an official project, but perhaps you could try and let us know if it fits your need.

I confess I don't know if we want to bring this officially, but I guess we could keep this issue open for discussion.

[pd93]

@andreynering Feels similar to the LSP server I wanted to create ages ago. I made a start on this and it ended up being a separate binary that consumed the Task package API, but it was never production ready, so I never opened a PR.

If we were to go ahead with MCP, I would like to see consistency with any potential LSP server. My general opinion at this time is that most users don't need it and therefore it shouldn't be in the main binary.

[andreynering]

@pd93 Fact is that this kinda of feature fits well for a community project. In theory with the --list enhancements, it's possible to have this an an external program without limitations. And it reduces the development work for us.

The downside is that, in my observation, community projects tend to be become unmaintained not long after started.

I don't discard bringing it officially (be it the same or other binary / repo), but we need to know we'll be able to keep maintaining it.

[rsclarke]

Thanks @andreynering for tagging me into the conversation.

The downside is that, in my observation, community projects tend to be become unmaintained not long after started.

I must admit I haven't even used my own project in anger, I was very much exploring MCP and I like Task so it was a fun project. There are features missing like reloading (adding/removing tools) when task files are updated, other transport mechanisms than stdio/stdout. I am unlikely to do any of this in the immediate future.

Like many, I too am still figuring things out, whether MCP is the right approach for this, documenting in an agent.md file, appropriately prompting "use task build to build the project" or letting it figure things out by having access to the task CLI. If anything, it's having the variety of options that helps the end user for their needs.

[leonard-henriquez]

My team has started challenging PNPM as our task runner because it worked pretty poorly with Claude code.
It was too slow and provided bad discoverability of tasks for AI coding agents.

If Task becomes the first runner with a solid MCP server, I think it could convince a lot of users to switch.

[andreynering]

@leonard-henriquez In my experience, coding agents are usually pretty OK by finding tasks inside a Taskfile.

What you usually have to do is write in your AGENT.md either a list of available tasks, or ask it to read Taskfile.yaml in order to know which tasks are available.

MCP support would just be a further improvement on this.