taskqueue-mcp
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 |
|---|---|
| list_projectsA | List all projects in the system and their basic information (ID, initial prompt, task counts), optionally filtered by state (open, pending_approval, completed, all). |
| read_projectB | Read all information for a given project, by its ID, including its tasks' statuses. |
| create_projectB | Create a new project with an initial prompt and a list of tasks. This is typically the first step in any workflow. |
| delete_projectA | Delete a project and all its associated tasks. |
| add_tasks_to_projectC | Add new tasks to an existing project. |
| finalize_projectA | Mark a project as complete. Can only be called when all tasks are both done and approved. This is typically the last step in a project workflow. |
| generate_project_planC | Use an LLM to generate a project plan and tasks from a prompt. The LLM will analyze the prompt and any attached files to create a structured project plan. |
| list_tasksB | List all tasks, optionally filtered by project ID and/or state (open, pending_approval, completed, all). Tasks may include tool and rule recommendations to guide their completion. |
| read_taskB | Get details of a specific task by its ID. The task may include toolRecommendations and ruleRecommendations fields that should be used to guide task completion. |
| create_taskC | Create a new task within an existing project. You can optionally include tool and rule recommendations to guide task completion. |
| update_taskA | Modify a task's properties. Note: (1) completedDetails are required when setting status to 'done', (2) approved tasks cannot be modified, (3) status must follow valid transitions: not started → in progress → done. You can also update tool and rule recommendations to guide task completion. |
| delete_taskC | Remove a task from a project. |
| approve_taskA | Approve a completed task. Tasks must be marked as 'done' with completedDetails before approval. Note: This is a CLI-only operation that requires human intervention. |
| get_next_taskA | Get the next task to be done in a project. Returns the first non-approved task in sequence, regardless of status. The task may include toolRecommendations and ruleRecommendations fields that should be used to guide task completion. |
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 14 tools
Every tool has a clearly distinct purpose targeting specific resources and actions, with no ambiguity. For example, create_project vs. read_project vs. delete_project, and create_task vs. update_task vs. approve_task, each handles a unique operation in the task/project lifecycle.
All tool names follow a consistent verb_noun pattern with snake_case throughout, such as create_project, list_tasks, and update_task. There are no deviations in naming conventions, making the set predictable and readable.
With 14 tools, the count is well-scoped for managing tasks and projects, covering operations from creation to finalization. Each tool earns its place by addressing distinct aspects of the domain without being excessive or insufficient.
The tool set provides complete CRUD/lifecycle coverage for projects and tasks, including creation, reading, updating, deletion, listing, approval, and finalization. There are no obvious gaps, and tools like generate_project_plan and get_next_task enhance workflow support without dead ends.