VibeDeploy

Multi-file find/replace in one call

apply_edits

Destructive

Apply literal find/replace edits to several files in one call, in the served files (target 'dist', live at once) or the editable source (target 'source', shipped by build_and_deploy). Same edit rules as update_file_content. All or nothing: if any edit's match count differs from its expected count, no file is written.

Input Schema

Name	Required	Description
`name`	Yes	Site name as shown by list_sites, e.g. my-portfolio.
`files`	Yes	Files + edits to apply. Up to 25 files / 200 total edits per call. All-or-nothing: if any edit's match count differs from its expected count, NOTHING is written.
`target`	No	Tree to edit, dist (default) or source. Same tree applies to every file in this call.

Output Schema

Name	Required	Description
`name`	Yes
`files`	Yes
`siteId`	Yes
`target`	Yes
`warnings`	No	Secret-scanner findings in the rewritten files that did not block the call. Malicious content blocks the whole call with MALICIOUS_CONTENT instead.
`totalEdits`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 14, 2026
- addedInput schema / properties / files / items / properties / edits / items / properties / count / description
```
Added value: +"Expected matches: default 1, -1 = replace all, or an exact number."
```
- addedInput schema / properties / files / items / properties / edits / items / properties / find / description
```
Added value: +"Literal text to find (not a regex). Max 64 KB."
```
- addedInput schema / properties / files / items / properties / edits / items / properties / replace / description
```
Added value: +"Literal replacement; empty string deletes the match. Max 64 KB."
```
- changedInput schema / properties / files / items / properties / path / description
```
Previous value: -"File-relative path inside the chosen target."New value: +"Path inside the chosen tree, e.g. index.html."
```
- addedInput schema / properties / name / description
```
Added value: +"Site name as shown by list_sites, e.g. my-portfolio."
```

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 rewritten files that did not block the call. Malicious content blocks the whole call with MALICIOUS_CONTENT instead.",
+  "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.5/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior: atomic all-or-nothing writes keyed to expected match counts, and the fact that dist edits go live immediately while source edits only ship via build_and_deploy.

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, front-loaded with the core action and then the two targets and the atomicity guarantee. Every clause carries distinct, decision-relevant information with no padding.

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?

With an output schema present and rich annotations, the description need only cover behavior and routing. It covers targets, edit semantics, and the atomic failure mode, so nothing an agent needs to call it 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%, so the baseline is 3. The description adds meaning beyond the schema by explaining what each target tree implies operationally (live-at-once vs build-and-deploy) and by tying the count parameter to the all-or-nothing failure rule.

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 (apply literal find/replace edits), a specific resource (several files in one call), and scope (dist vs source trees). It is clearly distinguishable from the single-file sibling update_file_content, which it references.

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?

Explains the two target modes and their consequences (dist live at once, source shipped by build_and_deploy) and points to update_file_content for the edit rules. It gives clear context but never explicitly states when to prefer this over the single-file tool.

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.