TaskWarrior MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_next_tasksC | Get a list of all pending tasks |
| mark_task_doneC | Mark a task as done (completed) |
| add_taskD | Add a new task |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: add_task creates new tasks, get_next_tasks retrieves pending tasks, and mark_task_done updates task status to completed. There is no overlap or ambiguity between these three core operations.
All tools follow a consistent verb_noun pattern (add_task, get_next_tasks, mark_task_done) with clear action verbs and descriptive nouns. The naming is predictable and readable throughout.
With only 3 tools, the server feels thin for task management. While the tools cover basic operations, typical task management systems benefit from more functionality like updating tasks, deleting tasks, or filtering/searching. The count is borderline minimal for the domain.
The tools provide basic CRUD coverage for tasks (create, read, update via marking done), but there are notable gaps. Missing operations include updating task details (beyond marking done), deleting tasks, and filtering/searching tasks beyond 'next' tasks. This limits agent flexibility in handling complex task workflows.