vibedeploy

Write files into the editable source tree

write_source_files

DestructiveIdempotent

Stage edits to a site's editable source tree (not the live dist). Use list_source_files first to discover what's there. The dist is unchanged until you re-deploy via update_site or run build_and_deploy. Sites have source storage enabled by default; if a legacy site doesn't, the call fails with SOURCE_STORAGE_NOT_ENABLED and the user should contact VibeDeploy support to enable it.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No
`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

Output Schema

TableJSON 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.
`request_id`	No	Server-assigned request correlation id. Quote it when contacting support.
`totalBytes`	Yes
`totalFiles`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

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

Behavior5/5

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

The annotations already signal a destructive write, and the description adds important behavioral context: changes are not immediately live, they only take effect after redeployment, and legacy sites may fail with SOURCE_STORAGE_NOT_ENABLED with a clear resolution path. This goes well beyond what the annotations provide.

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 tight sentences that front-load the core purpose, then cover prerequisite discovery, deployment timing, and a specific failure mode. No filler or redundancy.

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?

Covers the core workflow: discover via list_source_files, stage edits, redeploy to affect dist, and handle legacy source-storage failure. The presence of an output schema reduces need to document return values. Minor gaps remain around ambiguous parameters, but overall the agent has enough to use the tool safely and effectively.

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

Parameters2/5

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

Schema description coverage is only 33%; name and siteId are undocumented in the schema and the description does not clarify them. The required files parameter is well described in the schema, but the description itself adds no parameter-level meaning, leaving the agent to guess how siteId and name are used.

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 action ('Stage edits') on a specific resource ('a site's editable source tree') and explicitly contrasts it with the live dist. This makes the tool's job immediately clear and distinguishes it from deployment-related siblings.

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 usage context: use list_source_files first, edits are staged, and the dist only changes after update_site or build_and_deploy. It also explains the legacy-site failure path. It does not explicitly name alternatives like add_files or apply_edits, but the staging-vs-dist distinction provides solid selection guidance.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Most tools target a distinct resource and action—deploy, file, domain, snapshot, form, analytics—and the descriptions carefully clarify overlap (e.g., deploy_site vs update_site vs begin_deploy). A few pairs like read_file/read_source_file or list_file_hashes/list_source_files could be confused, but the pattern is clear enough to avoid misselection.

Naming Consistency5/5

Every tool follows a consistent verb_noun snake_case pattern (add_, list_, get_, read_, update_, delete_, verify_, etc.), with singular verbs for single resources and plural verbs for batches. This makes the surface highly predictable.

Tool Count2/5

39 tools is well beyond the typical well-scoped surface and many could be consolidated (e.g., read_file/read_files/read_source_file/read_source_files, or the multiple deploy entry points). The broad domain explains some of the count, but the set feels bloated and will slow tool selection.

Completeness3/5

The core deploy lifecycle is well covered: create/read/update/delete sites, patch files, manage custom domains, and configure forms. However, there are notable gaps—snapshots can be created and listed but not restored or deleted, and there is no explicit rollback-to-previous-deploy mechanism, which are common expectations for a deployment platform.

Write files into the editable source tree

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources