MCP TaskManager
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 |
|---|---|
| request_planningA | Register a new user request and plan its associated tasks. You must provide 'originalRequest' and 'tasks', and optionally 'splitDetails'. This tool initiates a new workflow for handling a user's request. The workflow is as follows:
The critical point is to always wait for user approval after completing each task and after all tasks are done, wait for request completion approval. Do not proceed automatically. |
| get_next_taskA | Given a 'requestId', return the next pending task (not done yet). If all tasks are completed, it will indicate that no more tasks are left and that you must wait for the request completion approval. A progress table showing the current status of all tasks will be displayed with each response. If the same task is returned again or if no new task is provided after a task was marked as done but not yet approved, you MUST NOT proceed. In such a scenario, you must prompt the user for approval via 'approve_task_completion' before calling 'get_next_task' again. Do not skip the user's approval step. In other words:
|
| mark_task_doneA | Mark a given task as done after you've completed it. Provide 'requestId' and 'taskId', and optionally 'completedDetails'. After marking a task as done, a progress table will be displayed showing the updated status of all tasks. After this, DO NOT proceed to 'get_next_task' again until the user has explicitly approved this completed task using 'approve_task_completion'. |
| approve_task_completionA | Once the assistant has marked a task as done using 'mark_task_done', the user must call this tool to approve that the task is genuinely completed. Only after this approval can you proceed to 'get_next_task' to move on. A progress table will be displayed before requesting approval, showing the current status of all tasks. If the user does not approve, do not call 'get_next_task'. Instead, the user may request changes, or even re-plan tasks by using 'request_planning' again. |
| approve_request_completionA | After all tasks are done and approved, this tool finalizes the entire request. The user must call this to confirm that the request is fully completed. A progress table showing the final status of all tasks will be displayed before requesting final approval. If not approved, the user can add new tasks using 'request_planning' and continue the process. |
| open_task_detailsB | Get details of a specific task by 'taskId'. This is for inspecting task information at any point. |
| list_requestsB | List all requests with their basic information and summary of tasks. This provides a quick overview of all requests in the system. |
| add_tasks_to_requestC | Add new tasks to an existing request. This allows extending a request with additional tasks. A progress table will be displayed showing all tasks including the newly added ones. |
| update_taskB | Update an existing task's title and/or description. Only uncompleted tasks can be updated. A progress table will be displayed showing the updated task information. |
| delete_taskB | Delete a specific task from a request. Only uncompleted tasks can be deleted. A progress table will be displayed showing the remaining tasks after deletion. |
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 10 tools
Each tool has a clearly distinct purpose with no overlap: request_planning initiates workflows, add_tasks_to_request extends them, get_next_task fetches pending tasks, mark_task_done and approve_task_completion handle task completion steps, delete_task and update_task modify tasks, open_task_details inspects tasks, list_requests provides overviews, and approve_request_completion finalizes requests. The descriptions reinforce these boundaries, making misselection unlikely.
All tool names follow a consistent verb_noun pattern with underscores, such as add_tasks_to_request, approve_request_completion, and get_next_task. There are no deviations in style or convention, making the naming predictable and easy to parse for an agent.
With 10 tools, the set is well-scoped for a task management domain, covering the full lifecycle from planning to completion. Each tool serves a specific role in the workflow, and there are no extraneous or missing tools that would suggest over- or under-engineering.
The tool surface provides complete CRUD and lifecycle coverage for task management: request_planning (create), list_requests (read), update_task (update), delete_task (delete), along with workflow-specific tools like get_next_task, mark_task_done, approve_task_completion, and approve_request_completion. There are no obvious gaps, and the descriptions outline a coherent end-to-end process.