taskgate-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
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 |
|---|---|
| task_listC | List tasks (optional status filter). |
| task_nextB | Show the one task that may start now: the queue head, planned, with dependencies and the phase gate met. |
| task_claimA | Claim a planned task (-> in_progress, sets owner and started). Refused unless every earlier task is done/cancelled (order and phase gate) and its dependencies are done. |
| task_updateA | Advance a task's status and record evidence (transitions are enforced). Send verification_result and review_result in SEPARATE calls: the caller identity (by) is the verifier; a review must come from the reviewer identity of the task's profile (see task_show), a different one, after that profile's delay since the stored verification, and must list the commands it checked in checks=[...]; closing as done needs a fresh review_result in the same call, unless the task's profile sets require_review = false. A task with open subtasks cannot go to in_review, done or cancelled. |
| task_renderA | Render the Markdown view from tasks.json; check=true fails on drift instead of writing. |
| task_validateA | Validate tasks.json: schema, status transitions and evidence gates. |
| task_showA | One task with its effective closing policy (profile, whether a review is required and by whom, review delay, quality gates) and its subtasks. Read it before verifying or reviewing to know what that task needs. |
| task_profileA | Set or clear the review/verification profile of a draft/planned task (profiles are defined in taskgate.toml, e.g. a docs profile without review). Not allowed once the task has started. Planners only; pass name or clear=true. |
| task_addA | Add a draft/planned task or, with parent, a subtask (id . assigned when id is omitted; one level, phase and default profile come from the parent; the parent must be in_progress before a subtask can start, and cannot close while subtasks are open). profile picks a review/verification profile from taskgate.toml. Duplicate ids and closed phases are rejected. Only identities listed in 'planners' may add tasks; pass by explicitly. |
| task_sortA | Reset the execution order to phase, then id; discards any order set with task_move. |
| task_moveA | Change the execution order: place a draft/planned task directly before or after another. Never in front of a task that is in flight or done, and phases stay ascending. Planners only; pass exactly one of before/after. |
| task_dependsA | Change the dependencies of a draft/planned task: set (replace; [] clears), add and/or remove ids. Each dependency must exist and be placed before the task (use task_move first). Planners only. |
| quality_checkA | Run quality gates and return a compact JSON report. Gate names come from [quality] in taskgate.toml; the built-in gate 'tasks' validates the registry and checks the Markdown view. Without 'checks' every gate runs; with task= only the gates of that task's profile run (a docs task can skip the build and test gates). |
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 13 tools
Each tool targets a fairly distinct operation on the task registry, and descriptions carefully separate near-neighbors like task_claim (order-gated start) vs task_update (status+evidence) and task_move vs task_sort vs task_depends. The main friction is validation overlap: task_validate, task_render with check=true, and quality_check's built-in 'tasks' gate all validate the same registry, which could cause hesitant selection.
Eleven of thirteen tools use a consistent task_<verb> snake_case pattern (task_add, task_show, task_update, task_move, task_claim, etc.). Only quality_check deviates by dropping the task_ prefix, a minor but noticeable inconsistency.
13 tools is well within the sweet spot and each one earns its place: lifecycle (add/claim/update), querying (show/list/next), planning (move/sort/depends/profile), and verification (validate/render/quality_check). No filler tools are present.
The surface covers the full task lifecycle including dependency management, ordering, profiles, claiming, evidence-gated closure, and quality gates, plus subtasks. The notable gap is there is no delete/remove operation for tasks or dependencies beyond cancellation and clearing via task_depends, leaving a dead end for erroneous draft entries.