Taskmaster MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Server port | 8080 |
| SMITHERY_DEPLOY | No | Set to 'true' for Smithery deployment mode |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_matrixA | Return the scope and situation matrix with its selector questions. Call this before start_session. |
| start_sessionA | Start a design session and receive its session_id, the working method, and the first entry's SOP. request: the user's words. end_goal: the observable condition that holds when the work is complete. entries: the matrix entries in the order they will run, worked backward from the end goal. task_conditions: device, platform, audience, existing identity, available assets, stage of completion, and whether identity is open to change. |
| submit_planA | Write or revise the plan for the current entry: one item per SOP step, in order. The first plan starts the work. |
| current_stepA | Re-issue the current step with its SOP, plan item, procedure text, and earlier results. Use after an interruption or condensed context. |
| complete_stepA | Finish the current SOP step (not a verify step) and receive the next one. handoff: one to three sentences naming the actual result and how the next step uses it. responsible_step: required on a trace step — the procedure step (0–9) where the cause lies. |
| report_verificationB | Finish a verify step. outcome: 'done', or the number (0–9) of the procedure step responsible for the earliest discrepancy. findings: each discrepancy with its evidence and responsible step, or what was checked when done. |
| escalateB | End the current entry because its decision belongs elsewhere, and start the right entry in its place. Use when the unit should not exist or should move (escalate to its parent scope), or when a Fix needs the structure replaced (escalate to redesign). reason: what the step showed. |
| get_process_stepB | Return one procedure step from process.txt in full (0–10), for steps an SOP step names only by its Keep rule. |
| add_entriesA | Add matrix entries to a session, after the current entry ('next') or at the end. Use when the work needs another entry, such as a Fix or Redesign the user authorized after a Review. |
| get_statusA | Show a session's goal, entries, plan, position, and recorded results. Without a session_id, list recent sessions. |
| end_sessionC | End a session. summary: what was delivered and any remaining limitations. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| design | Run a design request through Taskmaster. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| process_resource | The full design procedure. |
| matrix_resource | The scope and situation matrix. |
TDQS
Scored across 11 tools
The tools map to mostly distinct workflow phases: matrix discovery, session start, planning, step execution, verification, status, escalation, and ending. Mild overlap exists between current_step and get_process_step (both return procedure-step content) and between complete_step and report_verification (both advance work), but the descriptions clarify when each should be used.
Most names follow a clear snake_case verb_noun pattern such as submit_plan, get_matrix, start_session, complete_step, and end_session. Deviations like current_step (noun phrase) and escalate (bare verb) are minor and still readable, so the set is mostly consistent.
Eleven tools is well-scoped for a session/workflow management server. Each tool appears to earn its place across the session lifecycle, from matrix selection and session start through planning, step execution, verification, escalation, status, and end.
The surface covers the core lifecycle: get matrix, start session, submit plan, advance steps, verify, inspect status, escalate, add entries, fetch procedure steps, and end session. Minor gaps remain around editing or removing entries and richer session listing, but agents can likely work around them.