mcpbeat Sign in

Vision Driven Design (VDD) MCP Server

answering

Vision Driven Design (VDD) MCP Server is answering right now. Last checked 5 min ago. It exposes 15 tools. Last commit 23 Oct 2026.

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

Uptime history 32 days of history · worst day 0%
32 days agonow
47.8%
Uptime 24h
87 of 182 checks
15
Tools
read from the server
265 ms
Response time
average over 24h
2
Stars
last commit 23 Oct 2026

What changed 63

Every tool that appeared, vanished or quietly changed what it asks for. Recorded since 1 October 2026. No other catalogue keeps this.

19 Oct a tool changed version
7 Oct 6 tool descriptions were rewritten vdd_clarify, vdd_get_next_task, vdd_implement and 3 more
7 Oct 6 tools changed the parameters they ask for vdd_clarify, vdd_get_next_task, vdd_implement and 3 more
3 Oct the owner changed
3 Oct a tool changed version
1 Oct 15 tools changed the parameters they ask for29 times that day vdd_amend, vdd_clarify, vdd_clone and 12 more
1 Oct 14 tool descriptions were rewritten vdd_amend, vdd_clarify, vdd_clone and 11 more
1 Oct a tool changed version2 times that day
1 Oct 2 tools disappeared vdd_analyze, vdd_trace
1 Oct a tool appeared vdd_inspect
and 15 more, back to 1 October 2026

Vision Driven Design (VDD) MCP Server does not always answer

Over the last week it answered 45.5% of our checks. We check every 15 minutes, so you hear about the next outage within the hour — not from your users.

Three servers free · no card

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 5 min ago.

run in your terminal
claude mcp add vision-driven-design --transport sse https://vdd.simonmak.com/api/sse
Settings → Connectors → Add custom connector, then paste this address
https://vdd.simonmak.com/api/sse
~/.codex/config.toml
[mcp_servers.vision-driven-design]
url = "https://vdd.simonmak.com/api/sse"
.cursor/mcp.json
{
  "mcpServers": {
    "vision-driven-design": {
      "url": "https://vdd.simonmak.com/api/sse"
    }
  }
}
.vscode/mcp.json
{
  "servers": {
    "vision-driven-design": {
      "type": "sse",
      "url": "https://vdd.simonmak.com/api/sse"
    }
  }
}

This server publishes 1 more address. The block above uses the one we reach during checks; the full list is under Endpoints below, and the author may intend a particular one for your client.

Available tools 15

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

vdd
vdd_amend
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.
vdd_clarify
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. On the hosted (stateless) endpoint, pass artifactFiles ({"vdd/specs/<feature>/spec.md": "..."}) so the tool can scan the spec and return the real markers; without it the tool returns a delegation envelope.
vdd_clone
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.
vdd_detect_environment
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.
vdd_get_next_task
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. On the hosted (stateless) endpoint, pass artifactFiles ({"vdd/specs/<feature>/tasks.md": "..."}) so the tool returns the real next uncompleted task; without it the tool returns a delegation envelope.
vdd_implement
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. On the hosted (stateless) endpoint, pass artifactFiles (constitution.md, spec.md, plan.md, contracts/, tasks.md) so the tool can embed the real task text and its AC/contract links; without it the tool returns a delegation envelope.
vdd_init
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.
vdd_inspect
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. On the hosted (stateless) endpoint, pass artifactFiles (path→content for the vdd/ artifacts) so the tool computes the real matrix/metrics; without it the tool returns a delegation envelope.
vdd_plan
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.
vdd_specify
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.
vdd_strategize
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.
vdd_tactics
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. On the hosted (stateless) endpoint the tool cannot scan the repo itself: pass artifactFiles ({"vdd/strategy.md": "..."}) plus codebaseAudit (the repo scan produced by the host agent) to receive the audit; without them it returns a delegation envelope.
vdd_tasks
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.
vdd_validate
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. On the hosted (stateless) endpoint, pass artifactFiles (the vdd/ artifacts) so the tool can run drift/orphan/substance checks; without it the tool returns a delegation envelope.
vdd_vision
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.

Tools removed

Tools this server used to expose. Anything built against them stopped working on the day they went.

vdd_analyze
removed 1 Oct 2026
vdd_trace
removed 1 Oct 2026

Endpoints

URLTransportStateLatencyChecked
https://vdd.simonmak.com/api/sse sse answering 322 ms 5 min ago
https://vdd.simonmak.com/api/mcp streamable-http answering 53 ms 5 min ago

Alternatives to Vision Driven Design (VDD) MCP Server

same job, measured the same way
Vision Driven Design (VDD) MCP Server
by ascent-partners

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

250 installs/wk 15 tools answering
Entalpa Requirements MCP
by entalpa

Spec-driven development for AI coding agents: live requirements, stories and traceability over MCP

answering
Mneme Decision MCP
by mnemehq

Local MCP server for architectural decisions, traceability, and non-authoritative proposals.

965 installs/wk local only
Langfuse
by pulsemcp

MCP server for Langfuse LLM observability — trace and observation analysis.

94 installs/wk local only
A
agentrace
by ura-tools

Structured observability for AI agents. Trace steps, decisions, and errors. MCP server + CLI viewer.

20 installs/wk local only
Tidewave Phoenix
by tidewave-ai

Runtime-level MCP server for Phoenix development: run code, read logs, query the DB, read docs.

local only
Sensations Mergulho
by vercel-ora-x402-gateway

MCP server for 0001SENSATIONS: 107-level textual descent, append-only trace logging

6 tools answering
Kibi MCP
by looted

Kibi requirements, traceability, and proof MCP. Install as a project dev dependency.

746 installs/wk local only

Vision Driven Design (VDD) MCP Server — questions

Answers built from our own checks of this server.

What can Vision Driven Design (VDD) MCP Server do?
It exposes 15 tools, read directly from the server on our last check. Among them: vdd_amend, vdd_clarify, vdd_clone, vdd_detect_environment, vdd_get_next_task, vdd_implement and 9 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
Is Vision Driven Design (VDD) MCP Server working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 87 of 182 checks got a reply (47.8%), average response time 265 ms. The bar chart above shows every period we have measured.
Did Vision Driven Design (VDD) MCP Server ever remove tools?
Yes. vdd_analyze, vdd_trace are no longer exposed — we recorded the date each one disappeared. A tool vanishing usually means a breaking change for anything that depended on it.
How do I connect Vision Driven Design (VDD) MCP Server?
Copy the ready config from this page. We generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each in the form that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does Vision Driven Design (VDD) MCP Server need an API key?
No. Vision Driven Design (VDD) MCP Server completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 15 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is Vision Driven Design (VDD) MCP Server?
It answers our handshake in 265 ms on average, which is faster than 63% of all working MCP servers we measure. The comparison comes from our own checks across the whole registry, every 15 minutes.
Is Vision Driven Design (VDD) MCP Server open source?
The code is open source: it is published under the MIT licence, written in TypeScript and 2 stars on GitHub. The licence covers the code in the repository, not the hosted service at vdd.simonmak.com, which runs on its operator's own terms.