Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

Vision Driven Design (VDD) MCP Server

NPM · @SIMONMAK-ASCENT/MCP · 2 COMPONENTS · SCANNED OCT 6

Spec-driven development MCP server: 8 phases, bi-directional traceability, 7 quality gates.

72 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →

Supply Chain Security100
  • No malware found by supply-chain analysis.Pass
  • No known CVEs affecting this package version or its production dependencies.Pass
  • No install/post-install scripts declared.Pass
  • 0 of 5 dependencies flagged as unhealthy. View diagnostics → Pass
Provenance & Transparency48
  • Source repository is publicly reachable at the declared URL. View diagnostics → Pass
  • Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
  • Clear OSI-approved license (MIT).Pass
  • Actively maintained (last published 1 days ago).Pass
  • Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability78
  • 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 3746 tokens (~249/item across 15 items; 15 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management0
  • Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage100
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 100% of tool parameters carry a description.Pass
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 15 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 15 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass

Unverified: 1 category

A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

Install

How do I install the Vision Driven Design (VDD) MCP Server server?

Vision Driven Design (VDD) MCP Server runs locally as an npm package, launched with npx -y @simonmak-ascent/mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

npm · @simonmak-ascent/mcp

# add to Claude Code
claude mcp add simonmak-ascent-vision-driven-design -- npx -y @simonmak-ascent/mcp
// .cursor/mcp.json
{
  "mcpServers": {
    "simonmak-ascent-vision-driven-design": {
      "command": "npx",
      "args": [
        "-y",
        "@simonmak-ascent/mcp"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "simonmak-ascent-vision-driven-design": {
      "command": "npx",
      "args": [
        "-y",
        "@simonmak-ascent/mcp"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add simonmak-ascent-vision-driven-design -- npx -y @simonmak-ascent/mcp
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "simonmak-ascent-vision-driven-design": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@simonmak-ascent/mcp"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add simonmak-ascent-vision-driven-design --command npx --arg -y --arg @simonmak-ascent/mcp
# ~/.hermes/config.yaml
mcp_servers:
  simonmak-ascent-vision-driven-design:
    command: "npx"
    args: ["-y", "@simonmak-ascent/mcp"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "simonmak-ascent-vision-driven-design": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@simonmak-ascent/mcp"
      ]
    }
  }
}
# add to Vellum
assistant mcp add simonmak-ascent-vision-driven-design -t stdio -c npx -a -y @simonmak-ascent/mcp
// mcp.json
{
  "mcpServers": {
    "simonmak-ascent-vision-driven-design": {
      "command": "npx",
      "args": [
        "-y",
        "@simonmak-ascent/mcp"
      ]
    }
  }
}
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 4 Oct 26 +11
    • Known CVEs: unverified → pass ▲ security
    • Dependency health: unverified → 1.00 ▲ functional
  • 3 Oct 26 +4
    • Known CVEs: pass → unverified ▼ security
    • Malware scan: unverified → pass ▲ security
    • Dependency health: 1.00 → unverified ▼ functional
    • Package version: 1.9.1 → 1.9.2 functional
  • 2 Oct 26 57

    First indexed and scored.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 8 Oct 2026 · Analysed npm/@simonmak-ascent/mcp@1.9.2

Provenance No attestation

The registry publishes no build provenance for this version, so there is nothing to verify.

Result No attestation
Ecosystem npm

Background: How many MCP packages publish verified provenance →

Dependencies 5 packages
Packages resolved 5
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 15 exposed · ~3,746 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
vdd_amend ~221

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.

NameTypeReqDescription
descriptionstringyesDescription of the requirement change
projectRootstring–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…
NameTypeReqDescription
_phasestringyesVDD phase that produced this result
_sdtstringyesStrategy-and-Tactic instructions for the next step
artifactstring–Primary artifact produced or returned
errorstring–Error message when the phase fails
gateResultobject–Quality-gate result, when the phase runs a gate
outputobject–Additional structured phase output
successbooleanyesWhether the phase completed successfully

No examples provided.

vdd_clarify ~235

VDD Phase 4b: Clarify an existing spec — scans vdd/specs/<feature>/spec.md and returns the items to resolve: every [NEEDS CLARIFICATION] marker, [e.g.] placeholder, and happy-path acceptance criterion (AC) still needing an edge-case counterpart (AC-E*). Read-only; returns the list without editing the file (the host agent then applies the resolutions). Pass feature (spec directory name). Run after vdd_specify when a spec has unresolved markers; to author a brand-new spec use vdd_specify instead. Parameter relationships: feature must be the exact spec directory name created by vdd_specify.

NameTypeReqDescription
featurestringyesFeature name: the vdd/specs/<feature>/ directory, kebab-case (e.g., "user-auth"); must reference a directory created earlier by vdd_specify
projectRootstring–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…
NameTypeReqDescription
_phasestringyesVDD phase that produced this result
_sdtstringyesStrategy-and-Tactic instructions for the next step
artifactstring–Primary artifact produced or returned
errorstring–Error message when the phase fails
gateResultobject–Quality-gate result, when the phase runs a gate
outputobject–Additional structured phase output
successbooleanyesWhether the phase completed successfully

No examples provided.

vdd_clone ~389

Crawl and capture a target domain into a clone dataset + manifest — WordPress-aware schema inference, Payload collections, and a Next.js + Payload + Postgres scaffold manifest (vdd/clone-manifest.json). Pass the domain as description. Writes vdd/clone-dataset.json, vdd/clone-manifest.json, and vdd/clone.md, overwriting any existing versions in place. Open-world: makes network requests to the target site and reads its sitemap and same-origin links. Use for cloning an external site; it is not part of the VDD phase pipeline, so for the normal init→validate flow call those phase tools instead. Parameter relationships: description is the target domain and statement is the desired outcome (both optional); maxPages, timeoutMs, concurrency, crawl, and browser tune the crawl and refresh=true bypasses a cached dataset.

NameTypeReqDescription
browserboolean–Clone: run browser/static capture (default true)
concurrencyinteger–Clone: concurrent crawl workers, 1-16; above ~16 risks tripping the target site rate limit (default 8)
crawlboolean–Clone: run the crawl (default true)
descriptionstring–Freeform description input
maxPagesinteger–Clone: max pages to crawl, 1-5000 (default 200)
projectRootstring–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…
refreshboolean–Clone: force re-crawl, ignore a fresh cached dataset
statementstring–Freeform vision statement (required for vision)
timeoutMsinteger–Clone: per-request timeout in ms, 1000-60000 (default 10000)
NameTypeReqDescription
_phasestringyesVDD phase that produced this result
_sdtstringyesStrategy-and-Tactic instructions for the next step
artifactstring–Primary artifact produced or returned
errorstring–Error message when the phase fails
gateResultobject–Quality-gate result, when the phase runs a gate
outputobject–Additional structured phase output
successbooleanyesWhether the phase completed successfully

No examples provided.

vdd_detect_environment ~267

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, inspect, 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_inspect. Returns a fixed-shape capability report; tool-name matching is normalized, so pass names as your host exposes them. Parameter relationships: availableTools and capabilities are aliases; omit both to get the per-phase requirements without a present/missing comparison.

NameTypeReqDescription
availableToolsarray–MCP/tool names available to the host agent (e.g., ["brave-search","perplexity","context7","gh_grep","playwright","filesystem"])
capabilitiesarray–Alias for availableTools
projectRootstring–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…
NameTypeReqDescription
_phasestringyesVDD phase that produced this result
_sdtstringyesStrategy-and-Tactic instructions for the next step
artifactstring–Primary artifact produced or returned
errorstring–Error message when the phase fails
gateResultobject–Quality-gate result, when the phase runs a gate
outputobject–Additional structured phase output
successbooleanyesWhether the phase completed successfully

No examples provided.

vdd_get_next_task ~210

VDD Phase 7a: Read vdd/specs/<feature>/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.

NameTypeReqDescription
featurestringyesFeature name: the vdd/specs/<feature>/ directory, kebab-case (e.g., "user-auth"); must reference a directory created earlier by vdd_specify
projectRootstring–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…
NameTypeReqDescription
_phasestringyesVDD phase that produced this result
_sdtstringyesStrategy-and-Tactic instructions for the next step
artifactstring–Primary artifact produced or returned
errorstring–Error message when the phase fails
gateResultobject–Quality-gate result, when the phase runs a gate
outputobject–Additional structured phase output
successbooleanyesWhether the phase completed successfully

No examples provided.

vdd_implement ~237

VDD Phase 7b: Prepare one task for implementation — loads constitution, spec, plan, and contracts and returns the implementation instruction plus the impact-chain commit-message format. Read-only; the tool writes nothing — the host agent performs the code edits, verification, and commit. Pass taskId (e.g. "TASK-003") from the task returned by vdd_get_next_task. Run one task at a time, after vdd_get_next_task; for read-only inspection of tasks use vdd_get_next_task instead. Parameter relationships: taskId comes from vdd_get_next_task (format TASK-###); projectRoot must match the root used by earlier phases.

NameTypeReqDescription
projectRootstring–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…
taskIdstringyesTask ID to implement, format TASK-### (e.g., "TASK-003"); must be an id listed in the feature's tasks.md (see vdd_get_next_task)
NameTypeReqDescription
_phasestringyesVDD phase that produced this result
_sdtstringyesStrategy-and-Tactic instructions for the next step
artifactstring–Primary artifact produced or returned
errorstring–Error message when the phase fails
gateResultobject–Quality-gate result, when the phase runs a gate
outputobject–Additional structured phase output
successbooleanyesWhether the phase completed successfully

No examples provided.

vdd_init ~174

VDD Phase 0: Generate constitution.md at the project root — the immutable tech stack, conventions, security constraints, naming rules, and banned patterns that every later phase obeys. Overwrites any existing constitution.md. Run this first, before vdd_vision; to change a constitution that already exists, use vdd_amend instead of re-running this. projectRoot sets the directory constitution.md is written to and that later phases resolve every vdd/ artifact against (default "."). Parameter relationships: projectRoot defaults to "." and must be the same root every later phase resolves against.

NameTypeReqDescription
projectRootstring–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…
NameTypeReqDescription
_phasestringyesVDD phase that produced this result
_sdtstringyesStrategy-and-Tactic instructions for the next step
artifactstring–Primary artifact produced or returned
errorstring–Error message when the phase fails
gateResultobject–Quality-gate result, when the phase runs a gate
outputobject–Additional structured phase output
successbooleanyesWhether the phase completed successfully

No examples provided.

vdd_inspect ~305

VDD Cross-phase: Read-only inspection of the current project in one call — scope selects the view. scope="project" (default) returns the bidirectional V→S→T→SP→PL→TK traceability matrix across all vdd/ artifacts; scope="feature" returns per-feature spec metrics (acceptance-criteria count, unresolved [NEEDS CLARIFICATION] markers, [e.g.] placeholder density, and whether plan.md/tasks.md exist). Never modifies files. Pass feature for the feature scope; for release-readiness validation with gates use vdd_validate, and to author a spec use vdd_specify. Output is a structured matrix/metrics object, not prose. Parameter relationships: scope="feature" requires feature, while scope="project" (the default) ignores it; projectRoot must match the root used by earlier phases.

NameTypeReqDescription
featurestring–Feature name: the vdd/specs/<feature>/ directory, kebab-case (e.g., "user-auth"); must reference a directory created earlier by vdd_specify
projectRootstring–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…
scopestring–Inspect scope: "project" (default) returns the traceability matrix; "feature" returns per-feature spec metrics (requires feature)
NameTypeReqDescription
_phasestringyesVDD phase that produced this result
_sdtstringyesStrategy-and-Tactic instructions for the next step
artifactstring–Primary artifact produced or returned
errorstring–Error message when the phase fails
gateResultobject–Quality-gate result, when the phase runs a gate
outputobject–Additional structured phase output
successbooleanyesWhether the phase completed successfully

No examples provided.

vdd_plan ~217

VDD Phase 5: Generate the technical blueprint under vdd/specs/<feature>/ — plan.md (component breakdown, AC coverage map, technology choices, verification toolchain), data-model.md (entities, indexes, migrations), and contracts/ (request/response/error schemas). Overwrites these files. Requires an existing spec for the feature; run after vdd_specify or vdd_clarify and before vdd_tasks — if no spec exists yet, run vdd_specify first. Parameter relationships: feature must match the value passed to vdd_specify and vdd_tasks.

NameTypeReqDescription
featurestringyesFeature name: the vdd/specs/<feature>/ directory, kebab-case (e.g., "user-auth"); must reference a directory created earlier by vdd_specify
projectRootstring–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…
NameTypeReqDescription
_phasestringyesVDD phase that produced this result
_sdtstringyesStrategy-and-Tactic instructions for the next step
artifactstring–Primary artifact produced or returned
errorstring–Error message when the phase fails
gateResultobject–Quality-gate result, when the phase runs a gate
outputobject–Additional structured phase output
successbooleanyesWhether the phase completed successfully

No examples provided.

vdd_specify ~325

VDD Phase 4: Generate vdd/specs/<id>/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/<feature>/ 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.

NameTypeReqDescription
actionItemIdstring–Tactical action item ID, format A-### (e.g., "A-001"); must be an item id from vdd/tactics.md
descriptionstring–Freeform description input
featurestring–Feature name: the vdd/specs/<feature>/ directory, kebab-case (e.g., "user-auth"); must reference a directory created earlier by vdd_specify
projectRootstring–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…
NameTypeReqDescription
_phasestringyesVDD phase that produced this result
_sdtstringyesStrategy-and-Tactic instructions for the next step
artifactstring–Primary artifact produced or returned
errorstring–Error message when the phase fails
gateResultobject–Quality-gate result, when the phase runs a gate
outputobject–Additional structured phase output
successbooleanyesWhether the phase completed successfully

No examples provided.

vdd_strategize ~282

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.

NameTypeReqDescription
availableToolsarray–MCP/tool names available to the host agent (e.g., ["brave-search","perplexity","context7","gh_grep","playwright","filesystem"])
capabilitiesarray–Alias for availableTools
projectRootstring–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…
researchFindingsstring–Consolidated research subagent findings to synthesize into strategy.md (effect only on the second strategize call)
NameTypeReqDescription
_phasestringyesVDD phase that produced this result
_sdtstringyesStrategy-and-Tactic instructions for the next step
artifactstring–Primary artifact produced or returned
errorstring–Error message when the phase fails
gateResultobject–Quality-gate result, when the phase runs a gate
outputobject–Additional structured phase output
successbooleanyesWhether the phase completed successfully

No examples provided.

vdd_tactics ~204

VDD Phase 3: Audit the existing codebase into vdd/tactics.md — repo audit, technical-debt assessment, gap analysis, MoSCoW-prioritized action items (A-001, A-002, …), dependency map, and infrastructure requirements. Overwrites vdd/tactics.md. Requires vdd/strategy.md; run after vdd_strategize and before vdd_specify. Needs a filesystem-capable host to scan the repo, so check with vdd_detect_environment first if the host may lack one. Parameter relationships: projectRoot must match the root used by vdd_init, vdd_vision, and vdd_strategize; requires vdd/strategy.md to exist.

NameTypeReqDescription
projectRootstring–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…
NameTypeReqDescription
_phasestringyesVDD phase that produced this result
_sdtstringyesStrategy-and-Tactic instructions for the next step
artifactstring–Primary artifact produced or returned
errorstring–Error message when the phase fails
gateResultobject–Quality-gate result, when the phase runs a gate
outputobject–Additional structured phase output
successbooleanyesWhether the phase completed successfully

No examples provided.

vdd_tasks ~202

VDD Phase 6: Break the plan into atomic test-first tasks in vdd/specs/<feature>/tasks.md — each references acceptance criteria (AC) and contracts, is sized S/M/L, and is marked [P] when parallelizable. Overwrites tasks.md. Requires plan.md; run after vdd_plan. To fetch the next uncompleted task from an existing tasks.md use vdd_get_next_task instead of re-running this. Parameter relationships: feature must match the value passed to vdd_plan.

NameTypeReqDescription
featurestringyesFeature name: the vdd/specs/<feature>/ directory, kebab-case (e.g., "user-auth"); must reference a directory created earlier by vdd_specify
projectRootstring–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…
NameTypeReqDescription
_phasestringyesVDD phase that produced this result
_sdtstringyesStrategy-and-Tactic instructions for the next step
artifactstring–Primary artifact produced or returned
errorstring–Error message when the phase fails
gateResultobject–Quality-gate result, when the phase runs a gate
outputobject–Additional structured phase output
successbooleanyesWhether the phase completed successfully

No examples provided.

vdd_validate ~256

VDD Phase 8: Validate the full chain — bidirectional traceability matrix, drift detection, orphan detection, uncovered vision goals, impact metrics vs targets, and 28 S&T assumption checks across 7 gates. Writes vdd/impact-report.generated.md and never overwrites a hand-authored vdd/impact-report.md. Run after implementation is complete; for the traceability matrix or per-feature spec metrics use vdd_inspect. Parameter relationships: feature narrows the check to one spec; artifactFiles maps artifact path to content for serverless runs and is omitted when resolving against a local projectRoot.

NameTypeReqDescription
artifactFilesobject–Map of vdd/-relative artifact path → full file text, for serverless validate/drift detection where the tool cannot read the filesystem
featurestring–Feature name: the vdd/specs/<feature>/ directory, kebab-case (e.g., "user-auth"); must reference a directory created earlier by vdd_specify
projectRootstring–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…
NameTypeReqDescription
_phasestringyesVDD phase that produced this result
_sdtstringyesStrategy-and-Tactic instructions for the next step
artifactstring–Primary artifact produced or returned
errorstring–Error message when the phase fails
gateResultobject–Quality-gate result, when the phase runs a gate
outputobject–Additional structured phase output
successbooleanyesWhether the phase completed successfully

No examples provided.

vdd_vision ~222

VDD Phase 1: Expand a freeform vision statement into vdd/vision.md — Impact Model (Goal, Actors, Impacts), Stakeholder Map, Success Metrics (leading + lagging), Constraints & Boundaries, and Target Domains. Overwrites any existing vdd/vision.md. Requires statement (freeform 1-3 paragraph intent, not a title) and a prior vdd_init. Run once, after vdd_init and before vdd_strategize; to revise a vision once downstream artifacts exist, use vdd_amend so the change cascades instead of re-running this. Parameter relationships: statement must be freeform prose (1-3 paragraphs), not a title; projectRoot must match the root used by vdd_init.

NameTypeReqDescription
projectRootstring–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…
statementstringyesFreeform vision statement
NameTypeReqDescription
_phasestringyesVDD phase that produced this result
_sdtstringyesStrategy-and-Tactic instructions for the next step
artifactstring–Primary artifact produced or returned
errorstring–Error message when the phase fails
gateResultobject–Quality-gate result, when the phase runs a gate
outputobject–Additional structured phase output
successbooleanyesWhether the phase completed successfully

No examples provided.

Common questions

What is the Vision Driven Design (VDD) MCP Server server?

Vision Driven Design (VDD) MCP Server is listed in the public MCP registry as io.github.simonmak-ascent/vision-driven-design. Spec-driven development MCP server: 8 phases, bi-directional traceability, 7 quality gates. This page covers its npm package (@simonmak-ascent/mcp).

Is the Vision Driven Design (VDD) MCP Server server safe to use?

Vision Driven Design (VDD) MCP Server scores 72 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 4 October 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the Vision Driven Design (VDD) MCP Server server expose?

Vision Driven Design (VDD) MCP Server exposes 15 tools: vdd_init, vdd_vision, vdd_strategize, vdd_tactics, vdd_specify, and 10 more. Their descriptions and schemas cost roughly 3,746 tokens of context every time the server is loaded.

Is the Vision Driven Design (VDD) MCP Server server still maintained?

Vision Driven Design (VDD) MCP Server is still listed as active in the MCP registry. We last reached this channel on 4 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

What licence is the Vision Driven Design (VDD) MCP Server server under?

Vision Driven Design (VDD) MCP Server declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.