VibeDeploy

Build editable source and ship the result as the new dist

build_and_deploy

Destructive

Build the site's stored editable source in an isolated one-shot build pod and atomically publish the output as the live site, replacing the served files (a restore point is normally taken first). Use build_and_deploy after changing stored source (write_source_files, apply_edits with target 'source'); use update_site instead to upload files that are already built. The first build saves buildCommand, outputDir and rootPath on the site, so later calls can omit them. A failed build returns its log in the error details.

Input Schema

Name	Required	Description
`name`	No	Site name as shown by list_sites, e.g. my-portfolio. Provide name or siteId.
`siteId`	No	Site id from list_sites or get_site. Use instead of name.
`rootPath`	No	Subdirectory of the source tree that holds package.json (monorepos). Empty string = source root.
`outputDir`	No	Directory to publish. Default: the saved manifest, then auto-detect (dist > build > out > public).
`buildCommand`	No	Build command override, e.g. 'npm run build:prod' or 'pnpm vite build'. Default: the saved manifest, then 'npm run build'.
`saveManifest`	No	Default true: save these settings on the site for later builds. false = one-off build.

Output Schema

Name	Required	Description
`url`	Yes	Live URL of the site.
`name`	Yes
`siteId`	Yes
`buildLog`	Yes	Combined orchestrator + builder log; truncated to ~32 KB to fit MCP responses.
`manifest`	Yes
`manageUrl`	Yes	Dashboard page where the user manages this site (domains, versions, settings).
`outputDir`	Yes
`totalBytes`	Yes
`customDomains`	Yes	Custom domains of this site and the team's custom-domain allowance; null when they could not be read.
`filesDeployed`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 21, 2026

addedOutput schema / properties / customDomains

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "allowance": {
+          "description": "Custom domains the team's current plan includes.",
+          "type": "number"
+        },
+        "connected": {
+          "description": "Custom domains on this site from both sources, one entry per hostname.",
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "domain": {
+                "description": "Hostname, e.g. shop.example.com.",
+                "type": "string"
+              },
+              "source": {
+                "description": "dashboard: linked on the dashboard Web Addresses page. mcp: added with add_custom_domain or the site API.",
+                "enum": [
+                  "dashboard",
+                  "mcp"
+                ],
+                "type": "string"
+              },
+              "status": {
+                "description": "live: verified and serving this site. pending: linked, not verified yet.",
+                "enum": [
+                  "live",
+                  "pending"
+                ],
+                "type": "string"
+              }
+            },
+            "required": [
+              "domain",
+              "status",
+              "source"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "nextTool": {
+          "const": "add_custom_domain",
+          "description": "Present when this site has no custom domain yet and the team has room for one.",
+          "type": "string"
+        },
+        "used": {
+          "description": "Distinct custom domains in use across the team, both sources (same count as get_account).",
+          "type": "number"
+        }
+      },
+      "required": [
+        "connected",
+        "allowance",
+        "used"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Custom domains of this site and the team's custom-domain allowance; null when they could not be read."
+}

changedOutput schema / required

Previous value: -[
-  "siteId",
-  "name",
-  "url",
-  "manageUrl",
-  "filesDeployed",
-  "outputDir",
-  "totalBytes",
-  "manifest",
-  "buildLog"
-]New value: +[
+  "siteId",
+  "name",
+  "url",
+  "manageUrl",
+  "filesDeployed",
+  "outputDir",
+  "totalBytes",
+  "manifest",
+  "buildLog",
+  "customDomains"
+]

Changed9 schema fields changedOct 14, 2026

changedInput schema / properties / buildCommand / description

Previous value: -"Override for the build script's `npm run build` step (e.g. 'npm run build:prod' or 'pnpm vite build'). If omitted, uses the manifest stored on the site, then falls back to 'npm run build'."New value: +"Build command override, e.g. 'npm run build:prod' or 'pnpm vite build'. Default: the saved manifest, then 'npm run build'."

addedInput schema / properties / name / description

Added value: +"Site name as shown by list_sites, e.g. my-portfolio. Provide name or siteId."

changedInput schema / properties / outputDir / description

Previous value: -"Override for which directory to ship as the new dist. If omitted, uses the manifest, then auto-detects (dist > build > out > public)."New value: +"Directory to publish. Default: the saved manifest, then auto-detect (dist > build > out > public)."

changedInput schema / properties / rootPath / description

Previous value: -"Subdirectory inside the source tree where package.json lives. Empty string = source root. Useful for monorepos."New value: +"Subdirectory of the source tree that holds package.json (monorepos). Empty string = source root."

changedInput schema / properties / saveManifest / description

Previous value: -"If true (default), persists the merged manifest back onto the site so future builds default to these settings. Set false to do a one-off build without changing the saved manifest."New value: +"Default true: save these settings on the site for later builds. false = one-off build."

addedInput schema / properties / siteId / description

Added value: +"Site id from list_sites or get_site. Use instead of name."

addedOutput schema / properties / manageUrl

Added value: +{
+  "description": "Dashboard page where the user manages this site (domains, versions, settings).",
+  "type": "string"
+}

addedOutput schema / properties / url

Added value: +{
+  "description": "Live URL of the site.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "siteId",
-  "name",
-  "filesDeployed",
-  "outputDir",
-  "totalBytes",
-  "manifest",
-  "buildLog"
-]New value: +[
+  "siteId",
+  "name",
+  "url",
+  "manageUrl",
+  "filesDeployed",
+  "outputDir",
+  "totalBytes",
+  "manifest",
+  "buildLog"
+]

Changed1 schema field changedSep 6, 2026

removedOutput schema / properties / request_id

Removed value: -{
-  "description": "Server-assigned request correlation id. Quote it when contacting support.",
-  "type": "string"
-}

Changed1 schema field changedJul 20, 2026

addedOutput schema / properties / request_id

Added value: +{
+  "description": "Server-assigned request correlation id. Quote it when contacting support.",
+  "type": "string"
+}

First observedJun 29, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the destructive and non-idempotent annotations, the description discloses that the build runs in an isolated one-shot pod, that publishing is atomic and replaces served files, that a restore point is normally taken first, and that failed builds return their log in error details.

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?

Three tightly written sentences, front-loaded with the core action and followed by usage routing and persistence behavior. There is no redundant restatement of the title or schema.

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 destructive, open-world deployment tool with annotations and an output schema, the description covers the important behavioral context: what is replaced, the restore-point safeguard, the build environment, alternatives, persistence of settings, and failure logging.

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 already 100%, so the baseline is 3, but the description adds cross-call meaning: the first build saves buildCommand, outputDir, and rootPath on the site so later calls can omit them. It does not add much about name/siteId or saveManifest beyond what the schema already says.

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 states a specific verb and resource: build the stored editable source in an isolated pod and publish the output as the live site. It clearly distinguishes this from update_site, which is for already-built files, and names the source-editing siblings that precede it.

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 says to use this after changing stored source via write_source_files or apply_edits with target 'source', and explicitly routes already-built uploads to update_site. The first-build manifest saving behavior is also called out so repeated calls are understood.

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

All VibeDeploy tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.