mcp-vdd

Detect Environment

vdd_detect_environment

Read-onlyIdempotent

Compares availableTools against per-phase required and optional MCP tools to report which VDD phases have missing capabilities. Run before vdd_strategize to plan subagent dispatch or on phase failure.

Instructions

VDD Environment Detection: Report which tools/MCPs each VDD phase requires vs treats as optional — across the 8-phase pipeline (init through validate) plus the cross-phase helpers (amend, clone, trace, analyze, get-next-task) — and which of the host agent availableTools are present vs missing. Read-only; returns a capability report without modifying files. Run before vdd_strategize to plan research-subagent dispatch, or when a phase fails for lack of a tool; to inspect artifacts instead of capabilities use vdd_trace. Pass availableTools (or its alias capabilities); omitting both returns the per-phase requirements without the present/missing comparison.

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 (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"])

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.

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.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description reinforces this with 'Read-only; returns a capability report without modifying files.' It adds useful behavioral nuance by disclosing what happens when both availableTools and capabilities are omitted: only per-phase requirements are returned, without the present/missing comparison.

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

Conciseness5/5

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

The description is dense but well-organized: it front-loads the core purpose, then covers safety, usage timing, the alternative, and parameter behavior in one efficient pass. Every clause contributes information, with no filler or repetition of the title.

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?

The output schema covers the return shape, so the description does not need to reproduce response details. It fully covers what the tool does, when to run it, the key alternative, and the aliasing/omission behavior, making it complete for an agent to select and invoke correctly.

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 description coverage is 100%, so the baseline is 3. The description adds substantive value by explaining the alias relationship between availableTools and capabilities and the outcome of omitting both parameters, which is not fully evident 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?

The description uses a specific verb ('Report') and names a precise resource: which tools/MCPs each VDD phase requires versus treats as optional, plus the present/missing comparison. It also differentiates from the sibling vdd_trace by clarifying that this tool inspects capabilities rather than artifacts.

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?

Usage conditions are explicit: 'Run before vdd_strategize to plan research-subagent dispatch, or when a phase fails for lack of a tool.' It also names the alternative for artifact inspection ('to inspect artifacts instead of capabilities use vdd_trace'), leaving no ambiguity about when to choose this tool.

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

Deploy Server