taskguard-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 | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| taskguard_define_goalA | Call this before starting meaningful work. Defines the task contract: goal, non-goals, and explicit done criteria that later tools use to detect scope drift and verify completion. |
| taskguard_add_checkpointA | Call this when breaking a task into measurable implementation or research steps. Checkpoints make progress auditable instead of relying on vague status updates. |
| taskguard_update_checkpointA | Call this after starting, completing, or intentionally skipping a checkpoint. Attach evidence such as test output, files, or notes whenever possible. |
| taskguard_record_decisionA | Call this when choosing an implementation approach, rejecting an alternative, or deciding whether a requested change is in scope. Records rationale for later review. |
| taskguard_check_scope_driftB | Call this before doing adjacent cleanup, broad refactors, extra features, or work that may not map to the recorded goal. It warns when the proposed action appears outside the task contract. |
| taskguard_add_evidenceA | Call this whenever you have proof of progress: tests, typecheck, lint, review, manual verification, artifacts, paths, or URLs. Link evidence to done criteria when possible. |
| taskguard_update_criterionC | Call this when a done criterion becomes met, not met, pending, or explicitly waived. In strict verification, met criteria should have linked evidence. |
| taskguard_add_blockerB | Call this when progress is blocked by missing input, failing dependencies, permissions, unclear requirements, or external failures. |
| taskguard_update_blockerA | Call this when a blocker is resolved or waived. Open blockers prevent taskguard_verify_done from returning ready. |
| taskguard_verify_doneB | Call this before final response, commit, PR, or handoff. It checks done criteria, checkpoints, blockers, and optional evidence requirements so the agent does not falsely claim completion. |
| taskguard_get_statusA | Call this when resuming work or when the user asks what remains. Returns the active task ledger or a specific session. |
| taskguard_reset_sessionA | Call this only when the user abandons, restarts, archives, or deletes a TaskGuard session. Prefer archive over delete to preserve audit history. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| taskguard_plan_task | Use this prompt when starting a new agent task and you want TaskGuard to create a goal contract and checkpoint plan. |
| taskguard_checkpoint_review | Use this prompt while work is in progress to select the next checkpoint and avoid scope drift. |
| taskguard_done_review | Use this prompt before a final response, commit, push, PR, or handoff to avoid falsely claiming completion. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| taskguard-sessions | List all non-archived TaskGuard sessions. |
TDQS
Scored across 12 tools
Every tool has a clearly distinct role: goal definition, checkpoint management, evidence, criteria, decisions, scope checks, blockers, verification, status, and session reset. No overlap or ambiguity.
All tools follow a consistent pattern: 'taskguard_' + verb_noun (e.g., add_checkpoint, update_criterion, verify_done). Naming is uniform and predictable.
12 tools is an ideal number for a task management server. Each tool serves a necessary function without redundancy or bloat.
The toolset covers the full task lifecycle: definition, execution tracking (checkpoints, evidence, blockers), verification, and status retrieval. No obvious gaps.