vibedeploy

Update an existing site

update_site

DestructiveIdempotent

Patch or replace files on an existing site. Defaults to patch mode: only the listed files change; everything else stays. Pass mode:'replace' to wipe-and-replace the whole site (the legacy behaviour, surfaced explicitly so it can't happen by accident). Use delete: [paths] in patch mode to remove specific files without wiping the rest. Use dryRun: true to preview the diff before committing. LARGE FILES: a 100-250 KB text file fits in one call with encoding:'gzip+base64' (gzip locally, base64 the result) — prefer that over begin_deploy + add_file_chunk streaming. Errors if the site does not exist.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	No	patch (default): write only the listed files; everything else stays. replace: delete all existing files and write only the listed ones. Use replace only when you genuinely want to throw away the rest of the site.
`name`	No	Site name (preferred).
`files`	No	Files to write. Array form `[{path, content, encoding?}]` (preferred) supports binary via encoding:'base64'; map form `{path: content}` is utf8-only. <= 500 MB total. Optional when `delete` is provided in patch mode for delete-only deploys.
`delete`	No	Patch-mode only: site-relative paths to remove from the pod. Files not in this list are kept. Reported back in `deletedFiles` listing only entries that actually existed. Combine with `files` to atomically rename in one call (write new path + delete old path). Rejected in mode:'replace' since replace already removes anything not in `files`.
`dryRun`	No	If true, validate input + introspect what would change but don't write or delete. Returns the same shape with `dryRun: true` and `deletedFiles` showing what would be removed. Use this before any destructive call (replace mode, or patch with `delete`) to verify the diff.
`siteId`	No	Site id (alternative to name).

Output Schema

TableJSON Schema

Name	Required	Description
`url`	Yes
`mode`	Yes	The mode that was actually applied.
`dryRun`	No	True if this was a dry-run; nothing was written or deleted.
`siteId`	Yes
`warnings`	No	Surfaced issues that did not block the deploy (e.g. DOTFILE_PUBLIC, leaked-secret patterns).
`deletedFiles`	Yes	Files removed by this call. For patch mode this is the entries from `delete` that actually existed; for replace mode it's every pre-existing file not in `files`.
`customHeaders`	No	Result of the Netlify-style _headers sync: ship a _headers file in the site root to override default response headers (e.g. Permissions-Policy). Site-wide (/*) rules only.
`filesDeployed`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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: ship a _headers file in the site root to override default response headers (e.g. Permissions-Policy). Site-wide (/*) rules only."
+}

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?

Annotations already flag destructiveHint=true, but the description delivers the missing context: exactly what gets destroyed in each mode (replace wipes the whole site; delete removes only listed paths), how to preview via dryRun, that it errors if the site doesn't exist, and the gzip+base64 server-side gunzip behavior. This is precisely the 'what gets destroyed' context the rubric rewards, with no contradiction against annotations.

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?

Roughly 140 words, front-loaded with purpose and the safe default (patch mode), with the replace warning placed immediately after and the LARGE FILES heuristic set off as a distinct callout. Every sentence carries non-obvious operational knowledge; no filler.

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?

The description covers the full operational surface — modes, deletion semantics, dry-run preview, large-file encoding strategy, and the error condition — while the 100%-covered schema, annotations, and existing output schema carry parameter details and return shape. Nothing an agent needs to invoke this correctly is missing.

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% and the schema descriptions are already rich, so the baseline is 3. The description adds genuine beyond-schema heuristics: the 100–250 KB sizing guidance for choosing gzip+base64, the 'legacy behaviour, surfaced explicitly' framing for mode:'replace', and the routing preference away from the streaming alternative.

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 and resource ('Patch or replace files on an existing site') and immediately differentiates the two operational modes, patch vs replace. The 'existing site' scoping separates it from source-file siblings like write_source_files and update_file_content, and the mode contrast is the tool's core identity.

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?

Explicitly names the alternative pipeline ('prefer that over begin_deploy + add_file_chunk streaming') and the condition that selects this tool: 100–250 KB files with encoding:'gzip+base64'. It also gives when-not guidance — replace only when you genuinely want to wipe the rest, and dryRun before any destructive call.

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.