VibeDeploy

Commit a staged deploy

commit_deploy

Destructive

Publish a begin_deploy session's staged files to the live site in one atomic step, after a secret and malware scan of the complete set (on failure the session stays open to retry or abort). Replace mode on a site that has files needs confirm:"I-want-to-replace-all-files". After a timeout or dropped connection, call it again with the same deployId: it returns the running or finished commit instead of starting a second one. Use commit_deploy only to finish a begin_deploy session; deploy_site and update_site publish in one call.

Input Schema

Name	Required	Description
`delete`	No	Patch mode only: site-relative paths to remove from the live site in this commit (e.g. the old path of a renamed file).
`dryRun`	No	Preview the commit (filesDeployed, deletedFiles, confirm and plan checks) without touching the live site. Skips the secret and malware scan, which the real commit still runs.
`confirm`	No	Required only for replace-mode commits against a site that already has files. Pass exactly "I-want-to-replace-all-files" to acknowledge that the live files will be deleted and replaced with the staged set.
`deployId`	Yes	Session id returned by begin_deploy.

Output Schema

Name	Required	Description
`url`	Yes
`mode`	Yes
`dryRun`	No	True if this was a dry-run; nothing was committed.
`siteId`	Yes
`deployId`	Yes
`warnings`	Yes
`manageUrl`	No	Dashboard page where the user manages this site (domains, versions, settings). Omitted on dry runs.
`deletedFiles`	Yes
`customDomains`	No	Custom domains of this site and the team's custom-domain allowance; null when they could not be read. Omitted on dry runs.
`customHeaders`	No	Result of syncing the _headers file in the site root (site-wide /* response headers).
`filesDeployed`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field 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. Omitted on dry runs."
+}

Changed4 schema fields changedOct 14, 2026

changedInput schema / properties / delete / description

Previous value: -"Patch-mode only: site-relative paths to remove from the live site as part of this commit. Useful for renames (write new path via add_files, delete old path here)."New value: +"Patch mode only: site-relative paths to remove from the live site in this commit (e.g. the old path of a renamed file)."

changedInput schema / properties / dryRun / description

Previous value: -"If true, preview what commit would do without touching the live site or scratch dir. Returns the diff (filesDeployed, deletedFiles) plus would-be confirmation gate / preflight outcomes. Skips the secret/malware scan to keep the preview fast — the real commit will still scan. Recommended before any replace-mode commit on a populated site."New value: +"Preview the commit (filesDeployed, deletedFiles, confirm and plan checks) without touching the live site. Skips the secret and malware scan, which the real commit still runs."

changedOutput schema / properties / customHeaders / description

Previous value: -"Result of the Netlify-style _headers sync: overrides applied to the site's response headers, plus any validation warnings."New value: +"Result of syncing the _headers file in the site root (site-wide /* response headers)."

addedOutput schema / properties / manageUrl

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

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 changedAug 19, 2026

addedOutput schema / properties / customHeaders

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "applied": {
+          "type": "number"
+        },
+        "changed": {
+          "type": "boolean"
+        },
+        "warnings": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        }
+      },
+      "required": [
+        "applied",
+        "changed",
+        "warnings"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Result of the Netlify-style _headers sync: overrides applied to the site's response headers, plus any validation warnings."
+}

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

Behavior4/5

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

Goes well beyond the annotations by disclosing the secret/malware scan gate, that a failed scan leaves the session open to retry or abort, and the exact confirm token for replace mode. The note that re-calling with the same deployId returns the running/finished commit rather than starting a second one is genuinely useful nuance. It is not fully contradictory to idempotentHint=false (a re-call does return a changed state), but the tension is worth noting; what's missing is any statement about authorization/permission requirements for a destructive live-site write.

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?

Front-loaded with the core action, then failure semantics, then the sibling routing rule at the end. The sentences are dense and nearly all earn their place; the confirm-token restatement slightly duplicates the schema at some cost to brevity.

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 publish operation it covers atomicity, scan gating, failure/retry behavior, the replace-mode confirmation requirement, and the correct sibling choice. Since an output schema exists, no return-value explanation is required, and nothing an agent needs before invoking is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so deployId, delete, dryRun and confirm are already fully documented in the structured field descriptions. The description restates the confirm requirement and adds the deployId-reuse semantics, but adds no new syntax or format detail. Baseline 3 is appropriate.

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?

States a specific verb+resource ('Publish a begin_deploy session's staged files to the live site') and pins down the atomicity and scan semantics. It also explicitly names the siblings that do the same job differently (deploy_site, update_site), so an agent can pick it out without reading schemas.

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?

Gives an explicit when-to-use rule ('Use commit_deploy only to finish a begin_deploy session') plus the alternatives ('deploy_site and update_site publish in one call'). It also covers the retry path (call again with the same deployId) and the abort/retry option on scan failure, leaving little to inference.

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.