mcp-vdd

Generate Spec

vdd_specify

Destructive

Generate a spec.md file for one tactical action item, capturing user stories, Always/Ask/Never boundaries, Given/When/Then acceptance criteria, and MoSCoW priorities.

Instructions

VDD Phase 4: Generate vdd/specs//spec.md for one tactical action item — user stories, Always/Ask/Never boundaries, Given/When/Then acceptance criteria (AC), MoSCoW priorities, non-functional requirements, and impact verification. Overwrites the spec file. Pass actionItemId (e.g. "A-001") or a freeform description to skip the V/S/T chain. Use for a NEW spec; to resolve leftover [NEEDS CLARIFICATION] markers in an existing spec use vdd_clarify instead. Parameter relationships: feature names the vdd/specs// directory and must match the feature passed to vdd_clarify, vdd_plan, and vdd_tasks; actionItemId is the A-### id from tactics.md and is optional when authoring from a freeform description.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`feature`	No	Feature name: the vdd/specs/<feature>/ directory, kebab-case (e.g., "user-auth"); must reference a directory created earlier by vdd_specify
`description`	No	Freeform description input
`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 ".")	.
`actionItemId`	No	Tactical action item ID, format A-### (e.g., "A-001"); must be an item id from vdd/tactics.md

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.

Changed3 schema fields changedv1.9.0Oct 2, 2026

changedInput schema / properties / actionItemId / description

Previous value: -"Tactical action item ID (e.g., \"A-001\")"New value: +"Tactical action item ID, format A-### (e.g., \"A-001\"); must be an item id from vdd/tactics.md"

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 \".\")"

Changed1 schema field changedv0.1.3Sep 24, 2026

changedInput schema / properties / projectRoot / description

Previous value: -"Path to project root directory"New value: +"Project root: directory that constitution.md and the vdd/ folder are written to and resolved against (default \".\")"

Changed1 schema field changedv0.1.2Sep 24, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "_phase": {
+      "description": "VDD phase that produced this result",
+      "type": "string"
+    },
+    "_sdt": {
+      "description": "Strategy-and-Tactic instructions for the next step",
+      "type": "string"
+    },
+    "artifact": {
+      "description": "Primary artifact produced or returned",
+      "type": "string"
+    },
+    "error": {
+      "description": "Error message when the phase fails",
+      "type": "string"
+    },
+    "gateResult": {
+      "additionalProperties": false,
+      "description": "Quality-gate result, when the phase runs a gate",
+      "properties": {
+        "checks": {
+          "description": "Number of checks run",
+          "type": "number"
+        },
+        "passed": {
+          "description": "Whether the quality gate passed",
+          "type": "boolean"
+        },
+        "total": {
+          "description": "Total number of checks",
+          "type": "number"
+        }
+      },
+      "required": [
+        "passed",
+        "checks",
+        "total"
+      ],
+      "type": "object"
+    },
+    "output": {
+      "additionalProperties": {},
+      "description": "Additional structured phase output",
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "success": {
+      "description": "Whether the phase completed successfully",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success",
+    "_phase",
+    "_sdt"
+  ],
+  "type": "object"
+}

First observedv0.1.0Sep 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and openWorldHint=false, and the description specifies the exact consequence ('Overwrites the spec file'), naming the affected artifact. It also discloses the alternate invocation path that bypasses the V/S/T chain, adding context beyond the safety annotation.

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 the phase/purpose, then overwrite warning, then routing, then parameter relationships. Dense but every clause carries routing or constraint information; slightly lengthy, but not padded.

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 complex authoring tool with an output schema covering return values, the description supplies the missing pieces: overwrite behavior, alternate entry path, sibling disambiguation, and cross-phase parameter consistency.

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?

Schema coverage is already 100%, but the description adds cross-parameter and cross-tool meaning: 'feature ... must match the feature passed to vdd_clarify, vdd_plan, and vdd_tasks' and 'actionItemId ... is optional when authoring from a freeform description'. That consistency contract is not derivable from the schema alone.

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+resource+artifact: 'Generate vdd/specs/<id>/spec.md for one tactical action item' and enumerates the produced content (user stories, boundaries, ACs, MoSCoW, NFRs, impact verification). It also explicitly distinguishes itself from vdd_clarify, so an agent can differentiate it from siblings without opening schemas.

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?

Explicit routing: 'Use for a NEW spec; to resolve leftover [NEEDS CLARIFICATION] markers in an existing spec use vdd_clarify instead.' It also states an entry condition ('Pass actionItemId ... or a freeform description to skip the V/S/T chain'), leaving nothing 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