mcp-vdd

Clone Website

vdd_clone

Destructive

Crawl a target domain to generate a clone dataset and manifest, with WordPress-aware schema inference and Payload collections, for cloning external sites.

Instructions

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). Writes vdd/clone-dataset.json, vdd/clone-manifest.json, and vdd/clone.md. Pass the domain as description; tune maxPages, timeoutMs, concurrency, crawl, browser, and refresh (set refresh=true to bypass a cached dataset and re-crawl). Open-world: makes network requests to the target site. 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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`crawl`	No	Clone: run the crawl (default true)
`browser`	No	Clone: run browser/static capture (default true)
`refresh`	No	Clone: force re-crawl, ignore a fresh cached dataset
`maxPages`	No	Clone: max pages to crawl (default 200)
`statement`	No	Freeform vision statement (required for vision)
`timeoutMs`	No	Clone: per-request timeout in ms
`concurrency`	No	Clone: concurrent crawl workers (default 8)
`description`	No	Freeform description input
`projectRoot`	No	Project root: directory that constitution.md and the vdd/ folder are written to and resolved against (default ".")	.

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.4Sep 24, 2026

changedInput schema / properties / statement / description

Previous value: -"Freeform vision statement (required for vision/e2e)"New value: +"Freeform vision statement (required for vision)"

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

Behavior4/5

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

Annotations already provide openWorldHint and destructiveHint, and the description adds useful context beyond them: 'Open-world: makes network requests to the target site', the exact files it writes, and the refresh behavior that bypasses a cached dataset. It does not fully spell out the destructive implications (e.g., whether existing clone files are overwritten), but the annotation covers the core warning.

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 five sentences and every sentence earns its place: purpose, outputs, parameter guidance, open-world caveat, and pipeline positioning. It front-loads the core action and writes before addressing tuning details, with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, open-world, destructiveHint tool with 9 parameters, the description covers purpose, outputs, key parameters, network behavior, and when to avoid it. A small gap is that it does not mention projectRoot or elaborate on the crawl/browser boolean semantics, but the schema fully covers those, so the description is still largely complete.

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 value by clarifying that the 'description' parameter should carry the target domain and by explaining that refresh=true forces a re-crawl bypassing cache. These are meaningful additions beyond the schema's short labels, though not every parameter gets extra explanation.

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 opens with a specific verb-resource pair: 'Crawl and capture a target domain into a clone dataset + manifest', then details the artifacts produced. It also differentiates itself from the VDD phase pipeline ('it is not part of the VDD phase pipeline'), making its scope unmistakable among the sibling tools.

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 explicitly tells the agent when to use this tool ('Use for cloning an external site') and when not to ('for the normal init→validate flow call those phase tools instead'). It also gives concrete invocation guidance by instructing to pass the domain as description and tune specific parameters.

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

Deploy Server