Provides tools for listing and running tasks defined in a Taskfile.yml project.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gotask-mcp list available tasks"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) Server for Taskfile/go-task.
This project and the mcp CLI rely on your having the dependency management tool uv installed. You can install via e.g. brew install uv for Homebrew users. See here for alternatives.
You will also need to have Taskfile installed. brew install go-task will work if you are a Homebrew user.
See here for alternatives.
Related MCP server: questlog-mcp
ensure you have the prerequisites installed
clone down this repository
ensure you have a suitable Taskfile.yml in your working project (you can use the example in this project for inspiration)
in Cursor settings > MCP Servers, start a server with the following command:
uv run --with mcp --directory /path/to/gotask-mcp mcp run /path/to/gotask-mcp/src/server.py
It is recommended to copy the contextual rule in .cursor/rules/tool-use-rule.mdc into your working project (or write a similar rule). The Cursor Agent will need some instructions if it is to use the tools properly.
A task runner (such as Taskfile) is a means of defining and running short commands that do regularly required, simple or complex work.
Such tasks can be an important part of the development cycle, for example autofixes and QA checks. Therefore it would seem useful if coding agents powered by generative AI could run these tasks at the appropriate time. The way to achieve this is with an MCP server that provides tools for running such tasks.
The server is designed to run in an isolated environment and to have contextual information about the working project passed in by the Client (tested with Cursor IDE Agent)
a tool to retrieve a list of available tasks
a tool to run a named task
The Cursor Agent is expected to pass in the working directory path as an input to these tools, which allows the tools to read the project Taskfile.yml.
(N.B. at the time of writing MCP resources don't work very well with Cursor IDE - the first tool would ideally be implemented as a resource, not a tool)
Run a specific task. The task_list tool should be used before calling this tool to get a list of available tasks.
Args: current_project: the path to the current project task_name: the name of the task to run
Returns: STDOUT/STDERR output from the task
| Name | Required | Description | Default |
|---|---|---|---|
| current_project | Yes | ||
| task_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It only mentions returning STDOUT/STDERR but does not disclose if the task is destructive, requires permissions, or other side effects. Insufficient for a run action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: purpose, prerequisite, and parameter list. No wasted words, front-loaded with action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, no output schema), the description covers prerequisite, return type, and basic parameter meaning. However, lacking behavioral safety information slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides brief parameter explanations: 'the path to the current project' and 'the name of the task to run'. This adds basic meaning but lacks detail on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run a specific task' and distinguishes from sibling tool 'task_list' by indicating it should be used first. The verb 'run' and resource 'task' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'task_list tool should be used before calling this tool', providing when-to-use guidance. However, no when-not-to or alternative scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tasks defined in the current project's Taskfile.yml
The caller should look for their current project in user_info and pass the project path to this tool.
Args: current_project: The path to the current project
Returns: A string containing the list of tasks
| Name | Required | Description | Default |
|---|---|---|---|
| current_project | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses the source file and return type (string of tasks) but lacks details on side effects, error handling, or behavior beyond reading a file.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise: two sentences plus structured Args/Returns section. No redundant information, every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, no nested objects), the description adequately covers purpose, input, and output format. Could mention output format in more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage; description adds meaning by specifying that the parameter is the project path derived from user_info, beyond just the schema title 'Current Project'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List all tasks defined in the current project's Taskfile.yml', identifying the specific verb and resource, and differentiating from sibling tool 'run_task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context: 'The caller should look for their current project in user_info and pass the project path to this tool.' This guides the agent on sourcing the input, though it doesn't extensively discuss when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: listing tasks and running a specific task. There is no overlap in functionality, so an agent can easily distinguish them.
Both names use underscores, but one follows a verb_noun pattern (run_task) while the other uses noun_verb (task_list). This slight inconsistency could be confusing with more tools, but for two tools it remains clear.
With only two tools, the surface is thin for a task management server. While it covers the basic operations of listing and running, the count is at the lower end of acceptability.
The server lacks task creation, update, and deletion capabilities, which are typical for managing tasks. For a complete workflow, these are notable omissions, though the server may be intended solely for execution.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Task management your AI agents can actually run. One line becomes a context-ready task over MCP.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/PaddyAlton/gotask-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
