mcp-vdd

Research Strategy

vdd_strategize

Destructive

Generates a research-backed strategy.md with pillars, competitive analysis, and risk register from vision primers; requires vdd/vision.md and a two-pass research synthesis.

Instructions

VDD Phase 2: Produce research-backed strategy into vdd/strategy.md — strategic pillars, competitive analysis, and a risk register, resolved from the vision target-domain primers. Overwrites vdd/strategy.md. Requires vdd/vision.md; run after vdd_vision and before vdd_tactics. Two-pass: call once with availableTools to get the research-subagent dispatch specs, then re-call with researchFindings to synthesize strategy.md (a first call with neither returns only the dispatch specs). To change strategy after artifacts exist, use vdd_amend. Parameter relationships: availableTools and capabilities are aliases (pass one); researchFindings only has an effect on the second call.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`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 ".")	.
`capabilities`	No	Alias for availableTools
`availableTools`	No	MCP/tool names available to the host agent (e.g., ["brave-search","perplexity","context7","gh_grep","playwright","filesystem"])
`researchFindings`	No	Consolidated research subagent findings to synthesize into strategy.md (effect only on the second strategize call)

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

changedInput schema / properties / researchFindings / description

Previous value: -"Consolidated research subagent findings to synthesize into strategy.md"New value: +"Consolidated research subagent findings to synthesize into strategy.md (effect only on the second strategize call)"

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 flag destructive and open-world behavior, and the description reinforces this ('Overwrites vdd/strategy.md') while adding context annotations cannot carry: the required vdd/vision.md precondition and the full two-pass dispatch-then-synthesize protocol, including the degenerate first-call case.

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 phase, artifact and overwrite behavior, then prerequisites, then the two-pass protocol. Dense but every sentence carries load; the final parameter-relationships sentence is slightly list-like but still adds alias information not in the schema.

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 multi-pass, destructive, open-world tool, the description covers phase ordering, prerequisite, overwrite target, alias handling, and the two-call protocol; with an output schema present, no return-value detail is needed. Nothing required 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?

Schema coverage is 100%, so the baseline is 3, but the description adds non-obvious semantics the schema omits: availableTools/capabilities are aliases (pass one) and researchFindings only takes effect on the second call. These are meaningful operational constraints beyond the field docs.

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 artifact ('Produce research-backed strategy into vdd/strategy.md') plus the concrete contents (strategic pillars, competitive analysis, risk register). It also names the upstream source (vision target-domain primers) and distinguishes itself from siblings vdd_vision/vdd_tactics by phase ordering.

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 prerequisites and sequencing: 'Requires vdd/vision.md; run after vdd_vision and before vdd_tactics.' It also routes post-artifact edits to vdd_amend, which is exactly the when-not-to-use-this guidance.

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

Deploy Server