Skip to main content
Glama
simonmak-ascent

mcp-vdd

by simonmak-ascent
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Amend Requirements

vdd_amend
Read-onlyIdempotent

Plans a requirement-change cascade across VDD artifacts: identifies the highest affected level and returns ordered downward steps through V→S→T→SP→PL→TK with gates to re-run.

Instructions

VDD Cross-phase: Plan a requirement-change cascade through the whole chain — identifies the highest affected level and returns the ordered steps to update downward V→S→T→SP→PL→TK and re-run affected gates (G1–G7). Read-only; returns the cascade plan without editing artifacts (the host agent applies the edits and commits). Pass the change as description. Use when a requirement changes after artifacts already exist; to build a phase from scratch the first time, run that phase's own tool instead of vdd_amend. The plan is an ordered step list naming the affected gates, not rewritten artifacts. Parameter relationships: description is the requirement change to cascade through the artifact chain; projectRoot must match the root used by earlier phases.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
descriptionYesDescription of the requirement change
projectRootNoProject 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
NameRequiredDescriptionDefault
_sdtYesStrategy-and-Tactic instructions for the next step
errorNoError message when the phase fails
_phaseYesVDD phase that produced this result
outputNoAdditional structured phase output
successYesWhether the phase completed successfully
artifactNoPrimary artifact produced or returned
gateResultNoQuality-gate result, when the phase runs a gate

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.9.0
    • 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 \".\")"
  2. Changed1 schema field changedv0.1.3
    • 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 \".\")"
  3. Changed1 schema field changedv0.1.2
    • 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"
+}
  4. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, but the description still adds substantial beyond-annotation context: it returns a plan rather than editing artifacts, the host agent applies edits and commits, the plan names gates rather than rewritten artifacts, and it re-runs gates G1–G7. This is rich behavioral disclosure that goes well past the safety hints.

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?

The core purpose is front-loaded and the routing/scope constraints follow logically. It is dense and the trailing 'Parameter relationships' sentence partly restates the schema, keeping it shy of a 5, but no sentence is filler.

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 planning tool with an output schema, annotations, and 100% param coverage, the description covers everything an agent needs: trigger condition, exclusion, return semantics, safety profile, and cross-phase parameter constraints. Nothing material 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. The description adds relationship semantics beyond the schema: 'description is the requirement change to cascade through the artifact chain' and 'projectRoot must match the root used by earlier phases', giving cross-phase consistency meaning not stated in the field descriptions 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 names a specific verb and resource (plan a requirement-change cascade through the artifact chain V→S→T→SP→PL→TK) and explains the output shape (ordered steps + affected gates). It is clearly distinguishable from phase-building siblings like vdd_vision or vdd_strategize, which is reinforced by the explicit contrast in the usage sentence.

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?

It states the trigger condition ('when a requirement changes after artifacts already exist') and the exclusion with the alternative ('to build a phase from scratch the first time, run that phase's own tool instead of vdd_amend'). Both when-to-use and when-not-to-use are explicit.

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

Deploy Server

Other Tools