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
`request_id`	No	Server-assigned request correlation id. Quote it when contacting support.
`beforeBytes`	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 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.3/5.0

Behavior5/5

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

The description goes well beyond the annotations by disclosing critical behavioral traits: 'mismatches abort the whole call with NO writes,' 'literal find/replace' (not regex), and the difference in deployment behavior between dist and source edits. This adds real safety context on top of destructiveHint=true, and it does not contradict any 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?

Four tightly written sentences with no filler. The first sentence front-loads the core action, the second gives concrete use cases, the third states the safety guarantee, and the fourth explains deployment implications. Every sentence earns its place.

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 schema is rich and a separate output schema exists, so return-value details are already covered. The description adds the missing contextual pieces: atomic whole-call aborts, expected-count semantics, and dist/source deployment flow. There is no critical invocation context left unexplained.

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 baseline is 3 because the schema already thoroughly documents name, path, edits, and target. The description restates the literal-match and count-expectation semantics, but it adds no new parameter-level detail beyond what the schema provides. It provides use-case context but not additional parameter 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 verb and resource: 'Apply one or more literal find/replace edits to a single file on the site, in one tool call.' It distinguishes itself from uploading the full file, but it does not explicitly differentiate from the sibling tool apply_edits, which is likely an overlapping alternative. The scope of 'tiny edits' is conveyed but sibling differentiation is incomplete.

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 clear context on when to use the tool: 'Designed for tiny edits where uploading the full file would be wasteful' with concrete examples. It also explains the post-edit workflow difference between dist and source edits, and that build_and_deploy is needed for source changes. It does not explicitly name alternatives like apply_edits or state an explicit when-not-to-use beyond 'tiny edits,' so it stops short of full routing 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.

Surgical find/replace in one file

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources