mcp-vdd

Get Next Task

vdd_get_next_task

Read-onlyIdempotent

Read a feature's tasks.md and return the next uncompleted task for an isolated implementation session, or a completion marker when none remain. Read-only.

Instructions

VDD Phase 7a: Read vdd/specs//tasks.md and return the next uncompleted task (or a completion marker when none remain). Read-only; never edits tasks.md. Pass feature (the exact spec directory name). Use before each implementation session to keep context isolated; to regenerate the whole list use vdd_tasks, and to execute the returned task use vdd_implement. Parameter relationships: feature must match the spec directory; the returned taskId (TASK-###) is the argument to vdd_implement.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`feature`	Yes	Feature name: the vdd/specs/<feature>/ directory, kebab-case (e.g., "user-auth"); must reference a directory created earlier by vdd_specify
`projectRoot`	No	Project root: directory that constitution.md and the vdd/ folder are written to and resolved against. Relative paths resolve from the current working directory; keep the same value across every phase (default ".")	.

Output Schema

TableJSON Schema

Name	Required	Description
`_sdt`	Yes	Strategy-and-Tactic instructions for the next step
`error`	No	Error message when the phase fails
`_phase`	Yes	VDD phase that produced this result
`output`	No	Additional structured phase output
`success`	Yes	Whether the phase completed successfully
`artifact`	No	Primary artifact produced or returned
`gateResult`	No	Quality-gate result, when the phase runs a gate

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.9.0Oct 2, 2026

changedInput schema / properties / feature / description

Previous value: -"Feature name (spec directory name)"New value: +"Feature name: the vdd/specs/<feature>/ directory, kebab-case (e.g., \"user-auth\"); must reference a directory created earlier by vdd_specify"

changedInput schema / properties / projectRoot / description

Previous value: -"Project root: directory that constitution.md and the vdd/ folder are written to and resolved against (default \".\")"New value: +"Project root: directory that constitution.md and the vdd/ folder are written to and resolved against. Relative paths resolve from the current working directory; keep the same value across every phase (default \".\")"

Addedv0.1.4Sep 24, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, yet the description adds genuinely useful context beyond them: it never edits tasks.md, and it returns a completion marker rather than erroring when no tasks remain. It stops short of describing the return payload shape, but an output schema exists to cover that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the read-only guarantee, then usage, then parameter relationships in a compact block. It is slightly dense with phase labels and parenthetical restatements, but every sentence carries actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only lookup tool with full schema coverage and an output schema handling return values, the description covers purpose, safety, usage timing, alternatives, and the parameter hand-off to vdd_implement. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage the baseline is 3, but the description adds real meaning: it explains that feature is the exact spec directory name, that it must match a directory created earlier, and that the returned taskId (TASK-###) is the argument fed to vdd_implement — a cross-tool parameter relationship the schema cannot express.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read vdd/specs/<feature>/tasks.md and return the next uncompleted task') including the exhaustion behavior (completion marker). It clearly distinguishes itself from the sibling vdd_tasks, which regenerates the full list, so an agent can pick the right tool without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit usage moment ('Use before each implementation session to keep context isolated') and names both alternatives with their selecting conditions: vdd_tasks to regenerate the list, vdd_implement to execute the returned task. Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server