TaskTracker 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
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| add_taskA | Register a single follow-up task discovered mid-investigation. Use add_tasks_bulk() instead if defining the full plan upfront. |
| add_tasks_bulkA | FIRST CALL: Register your entire investigation plan as a DAG in one atomic call. All tasks are validated before any are inserted. Returns a prioritised execution plan showing which tasks to start with. |
| update_taskA | Resolve a task after completing work on it. Always provide a finding for completed/skipped/blocked. Completing a task automatically unblocks any dependents. Can also rewire dependencies (pending tasks only) or update a finding without changing status. |
| get_ready_tasksA | CALL AFTER EVERY update_task: Returns all tasks whose dependencies are fully resolved, sorted by priority (high → medium → low). These are the tasks you should work on next. Empty list means either all done or everything is blocked. |
| get_all_tasksA | Get a full snapshot of the entire DAG — all tasks, their current status, findings, dependencies, and overall progress. Use when you need to review the full picture or check what is blocked. |
| conclude_analysisA | FINAL CALL: Close out the investigation. Blocks and returns actionable instructions if any tasks are still pending or in_progress. Returns a full grouped summary (by status and category) once everything is resolved. Call this when you believe all tasks are done. |
| reopen_taskA | Reopen a blocked task after its blocker has been resolved. Resets the task to pending, preserves the original finding in history, and recalculates its dependency state. Provide a reason explaining what changed. |
| resetA | Clear all tasks and start a new investigation session. Irreversible — all tasks and findings are permanently deleted. Only use when starting a completely new investigation. |
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 8 tools
Each tool has a distinct purpose: adding single vs bulk tasks, updating vs reopening, getting ready vs all tasks, plus reset and conclude. No overlap or ambiguity.
Most tools follow verb_noun pattern (add_task, update_task, reopen_task, get_ready_tasks), but 'reset' is a bare verb and 'conclude_analysis' breaks the pattern slightly. The inconsistency is minor and doesn't hinder readability.
8 tools is well-scoped for a task tracking server, covering creation, updates, queries, and lifecycle management without being overly heavy or sparse.
The tool surface covers the full investigation lifecycle: plan creation (bulk), incremental additions, status updates, dependency rewiring, reopening, readiness queries, full snapshot, reset, and final conclusion. No obvious gaps that would block typical workflows.