VibeDeploy

Write files into the editable source tree

write_source_files

DestructiveIdempotent

Write or overwrite files in the site's editable source tree (the first write creates it). The served files do not change until build_and_deploy runs. Use list_source_files first to see what exists. A legacy site without source storage returns SOURCE_STORAGE_NOT_ENABLED; the user can ask VibeDeploy support to enable it.

Input Schema

Name	Required	Description
`name`	No	Site name as shown by list_sites, e.g. my-portfolio. Provide name or siteId.
`files`	Yes	Files to write into the source tree. Same wire shape as add_files. Re-writing a path overwrites the previous source. Per-file cap 5 MB; per-call cap 50 MB; max 200 files per call.
`siteId`	No	Site id from list_sites or get_site. Use instead of name.

Output Schema

Name	Required	Description
`name`	Yes
`siteId`	Yes
`written`	Yes
`warnings`	No	Secret-scanner findings in the written files that did not block the write. Malicious content blocks the whole call with MALICIOUS_CONTENT; dotfiles other than .well-known/ and build config (.npmrc, .nvmrc, .env.example, ...) are rejected with INVALID_PATH.
`totalBytes`	Yes
`totalFiles`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 14, 2026

addedInput schema / properties / files / items / properties / content / description
```
Added value: +"File content: text, or base64 as set by encoding."
```

changedInput schema / properties / files / items / properties / encoding / description

Previous value: -"utf8 (default) for plain text. base64 for binary files. gzip+base64 for text files where you want to fit ~3x more bytes per tool call: gzip the raw bytes first, then base64-encode. Server gunzips before writing. Useful for shipping bigger source files when you're hitting the per-call output budget."New value: +"utf8 (default), base64 (binary files), or gzip+base64 (gzip locally, then base64; fits about 3x more text per call)."

addedInput schema / properties / files / items / properties / path / description

Added value: +"Path inside the source tree, e.g. 'src/App.tsx'. Plain ASCII, no leading slash."

addedInput schema / properties / name / description

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

addedInput schema / properties / siteId / description

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

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 changedSep 5, 2026

addedOutput schema / properties / warnings

Added value: +{
+  "description": "Secret-scanner findings in the written files that did not block the write. Malicious content blocks the whole call with MALICIOUS_CONTENT; dotfiles other than .well-known/ and build config (.npmrc, .nvmrc, .env.example, ...) are rejected with INVALID_PATH.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "file": {
+        "type": "string"
+      },
+      "line": {
+        "type": "number"
+      },
+      "match": {
+        "type": "string"
+      },
+      "type": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "file",
+      "line",
+      "type",
+      "match"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

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

Behavior5/5

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

Annotations already declare destructive/idempotent/open-world, and the description layers on genuinely new behavior: writes are staging-only until build_and_deploy, the tree is lazily created, and legacy sites fail with SOURCE_STORAGE_NOT_ENABLED along with the user-facing remedy. That is exactly the error-mode and side-effect context annotations cannot convey.

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?

Four sentences, each load-bearing: action, deploy semantics, prerequisite, failure mode. The core operation is front-loaded and nothing is padding.

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?

An output schema exists, so return values need no explanation, and the description covers side effects, prerequisites, and the error path. The remaining gap is routing among the several other file-mutation siblings, which the description never addresses.

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%, including path/encoding semantics, size caps, and the 'same wire shape as add_files' note, so the schema carries parameter meaning on its own. The description adds no format, encoding, or limit detail beyond it, which makes 3 the correct baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair (write/overwrite) and a precise resource ('the site's editable source tree'), plus the non-obvious detail that the first write creates the tree. It does not distinguish itself from near-neighbours like add_files, update_file_content, or apply_edits, which is the only thing keeping it from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context: check with list_source_files first, and edits stay invisible to visitors until build_and_deploy runs. It stops short of naming the alternative write tools (add_files, apply_edits, update_file_content) or stating when to prefer one over the other, so no explicit exclusions.

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.