vibedeploy

Surgical find/replace in one file

update_file_content

Destructive

Apply one or more literal find/replace edits to a single file on the site, in one tool call. Designed for tiny edits where uploading the full file would be wasteful (one nav-button reference, one encoding fix, one env var bump). Each edit must specify how many matches it expects; mismatches abort the whole call with NO writes. For dist edits the change goes live immediately; for source edits you still need to call build_and_deploy.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Site name.
`path`	Yes	File-relative path inside the chosen target tree.
`edits`	Yes	Ordered list of edits to apply atomically. Each is `{find, replace, count?}`. If any edit's match count doesn't equal its expected count, the whole call aborts with no writes.
`target`	No	Which tree to edit. 'dist' (default) edits the served file directly — visitors see the change immediately. 'source' edits the editable source tree; you'll need build_and_deploy (or it short-circuits via noBuild) to ship.

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes
`path`	Yes
`edits`	Yes
`siteId`	Yes
`target`	Yes
`warnings`	No	Secret-scanner findings in the rewritten file that did not block the edit (AWS Access Key, Stripe Key, JWT Token, etc.). Malicious content blocks the edit with MALICIOUS_CONTENT instead.
`afterBytes`	Yes
`beforeBytes`	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 changedSep 5, 2026

addedOutput schema / properties / warnings

Added value: +{
+  "description": "Secret-scanner findings in the rewritten file that did not block the edit (AWS Access Key, Stripe Key, JWT Token, etc.). Malicious content blocks the edit 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.1/5.0

Behavior5/5

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

The description discloses crucial behavioral traits beyond the annotations: mismatched match counts abort the entire call with NO writes, edits are applied atomically, matching is literal rather than regex, and dist edits go live immediately while source edits require build_and_deploy. These details give the agent an accurate model of side effects and failure behavior. No contradiction with the destructiveHint=true annotation.

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?

The description is compact and well-structured: it opens with the precise purpose, then gives the targeted use case, then states the critical match-count behavior, then closes with the deployment consequence. Every sentence earns its place, and the most important operational warning is emphasized.

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?

Given the annotations, explicit schema, and output schema, the description is nearly complete for safe invocation: it covers what the tool does, when to use it, edit-count semantics, atomic failure, and required post-deploy steps. The main missing piece is explicit guidance on choosing this over the similarly named sibling apply_edits, which is more of a tool-selection gap than an invocation gap.

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 the schema already fully documents every parameter. The top-level description mostly restates what the edits array and target field already say, such as count mismatch aborting with no writes and the dist/source deployment difference. It adds operational color but little genuinely new parameter-level meaning.

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?

The description clearly states a specific action: applying one or more literal find/replace edits to a single file in one call. It also gives concrete example use cases (nav-button reference, encoding fix, env var bump). However, it does not explicitly differentiate itself from the sibling tool 'apply_edits', so it stops just short of full sibling-level clarity.

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?

The description gives strong usage context: use this for tiny edits where uploading the full file would be wasteful. It also explains the dist vs source follow-up requirement, naming build_and_deploy. It does not explicitly say when not to use this tool or mention the likely alternative apply_edits by name.

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.