Skip to main content
Glama

VibeDeploy

by be.vibedeploy
OverviewDiscussionsAdmin

Deploy a site from a public archive URL

deploy_from_url
Destructive

Fetch a public tar(.gz) archive over HTTPS and deploy its files to an existing site in one call (begin_deploy, upload and commit_deploy combined). Use deploy_from_url when the files are already published at a public URL, such as a repository archive that holds only the built site (no dotfiles), or when your sandbox reaches the allowed hosts (listed under archiveUrl) but not mcp.vibedeploy.be; otherwise use deploy_site or update_site. In replace mode one top-level folder that wraps every file (as in repository archives) is removed, and a site that already has files needs confirm:"I-want-to-replace-all-files". A failed call never leaves a staging session open.

Input Schema

NameRequiredDescriptionDefault
modeYesreplace: the archive becomes the whole site (other files are removed). patch: the archive's files are added or overwritten, the rest stays.
nameYesName of an existing site (see list_sites). This tool does not create sites.
confirmNoRequired only for mode "replace" on a site that already has files. Pass exactly "I-want-to-replace-all-files" to acknowledge that the live files will be deleted and replaced with the archive's files.
archiveUrlYesPublic HTTPS URL of a tar or tar.gz archive (max 100 MB, 60 s). Allowed hosts, also for every redirect: github.com, codeload.github.com, *.githubusercontent.com, gist.github.com, gitlab.com, bitbucket.org, codeberg.org, *.amazonaws.com, *.r2.cloudflarestorage.com, *.backblazeb2.com, *.workers.dev, *.pages.dev, transfer.sh, 0x0.st, mcp.vibedeploy.be. GitHub, GitLab and Codeberg archive links (e.g. https://github.com/<owner>/<repo>/archive/refs/heads/main.tar.gz) are accepted, but the normal file rules apply: any dotfile except .well-known/ (such as .gitignore, .github/, .gitlab-ci.yml) or any file type outside the allowlist (such as .ts, .tsx, .yml) rejects the whole archive with INVALID_FILE_TYPE. Replace mode removes only the one wrapping folder, so the built site must sit at the repository root.

Output Schema

NameRequiredDescriptionDefault
urlYes
modeYes
nameYes
siteIdYes
manageUrlYesDashboard page where the user manages this site (domains, versions, settings).
archiveUrlYes
bytesFetchedYes
filesDeployedYes
strippedPrefixNoTop-level folder removed from every archive path (replace mode, when one folder wraps all files).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / archiveUrl / description
      Previous value: -"Public HTTPS URL of a tar(.gz) archive. The server fetches it (max 100 MB, 60s timeout), parses the tarball, and deploys its files. Allowed hosts: github.com / raw.githubusercontent.com / gist.github.com / gist.githubusercontent.com / gitlab.com / bitbucket.org / codeberg.org / *.amazonaws.com / *.r2.cloudflarestorage.com / *.backblazeb2.com / *.workers.dev / *.pages.dev / transfer.sh / 0x0.st / mcp.vibedeploy.be. Use this when your runtime sandbox can reach the host above but can't reach mcp.vibedeploy.be's upload endpoint directly."New value: +"Public HTTPS URL of a tar or tar.gz archive (max 100 MB, 60 s). Allowed hosts, also for every redirect: github.com, codeload.github.com, *.githubusercontent.com, gist.github.com, gitlab.com, bitbucket.org, codeberg.org, *.amazonaws.com, *.r2.cloudflarestorage.com, *.backblazeb2.com, *.workers.dev, *.pages.dev, transfer.sh, 0x0.st, mcp.vibedeploy.be. GitHub, GitLab and Codeberg archive links (e.g. https://github.com/<owner>/<repo>/archive/refs/heads/main.tar.gz) are accepted, but the normal file rules apply: any dotfile except .well-known/ (such as .gitignore, .github/, .gitlab-ci.yml) or any file type outside the allowlist (such as .ts, .tsx, .yml) rejects the whole archive with INVALID_FILE_TYPE. Replace mode removes only the one wrapping folder, so the built site must sit at the repository root."
    • changedInput schema / properties / mode / description
      Previous value: -"How the archive's files apply: replace wipes the live dist; patch merges them in."New value: +"replace: the archive becomes the whole site (other files are removed). patch: the archive's files are added or overwritten, the rest stays."
    • changedInput schema / properties / name / description
      Previous value: -"Site name to deploy to."New value: +"Name of an existing site (see list_sites). This tool does not create sites."
    • addedOutput schema / properties / manageUrl
      Added value: +{
+  "description": "Dashboard page where the user manages this site (domains, versions, settings).",
+  "type": "string"
+}
    • addedOutput schema / properties / strippedPrefix
      Added value: +{
+  "description": "Top-level folder removed from every archive path (replace mode, when one folder wraps all files).",
+  "type": "string"
+}
    • changedOutput schema / required
      Previous value: -[
-  "siteId",
-  "name",
-  "url",
-  "mode",
-  "filesDeployed",
-  "bytesFetched",
-  "archiveUrl"
-]New value: +[
+  "siteId",
+  "name",
+  "url",
+  "manageUrl",
+  "mode",
+  "filesDeployed",
+  "bytesFetched",
+  "archiveUrl"
+]
  2. Changed1 schema field changed
    • addedInput schema / properties / confirm
      Added value: +{
+  "const": "I-want-to-replace-all-files",
+  "description": "Required only for mode \"replace\" on a site that already has files. Pass exactly \"I-want-to-replace-all-files\" to acknowledge that the live files will be deleted and replaced with the archive's files.",
+  "type": "string"
+}
  3. Changed1 schema field changed
    • removedOutput schema / properties / request_id
      Removed value: -{
-  "description": "Server-assigned request correlation id. Quote it when contacting support.",
-  "type": "string"
-}
  4. Changed1 schema field changed
    • addedOutput schema / properties / request_id
      Added value: +{
+  "description": "Server-assigned request correlation id. Quote it when contacting support.",
+  "type": "string"
+}
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond annotations (which already flag destructiveHint/openWorldHint), the description discloses what replace mode destroys (other/live files are deleted), that exactly one wrapping top-level folder is stripped, that a confirm string is required on an already-populated site, and that a failed call never leaves a staging session open. This is meaningful behavioral context the annotations do not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose, then usage routing, then destructive-mode caveats, and every paragraph maps to an agent decision. It is dense and slightly long, with the dotfile/allowlist sentence partly restating the schema, so it is efficient but not maximally tight.

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?

For a destructive, open-world composite tool, the description covers preconditions (existing site, public URL, allowed hosts, size/time limits), irreversible effects, the confirm safeguard, and failure atomicity; an output schema exists, so return-value detail is correctly omitted.

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, but the description adds real value: it explains the replace-vs-patch semantic at call level, the confirm token's live intent, and the file/type rules that cause an archive to be rejected with INVALID_FILE_TYPE. It largely defers host/limit details to the archiveUrl schema, which is appropriate.

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 verb chain on a concrete resource: fetch a public tar(.gz) over HTTPS and deploy its files to an existing site, explicitly framing it as begin_deploy + upload + commit_deploy combined. It names the target scope ('existing site', 'does not create sites') and contrasts itself with deploy_site and update_site, so an agent can distinguish it from the ~40 siblings.

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

Usage Guidelines5/5

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

It gives an explicit when-to-use (files already published at a public URL, e.g. a repo archive, or when the sandbox can reach allowed hosts but not mcp.vibedeploy.be) and a when-not with named alternatives (deploy_site or update_site). The preconditions for replace mode, including the confirm token, are stated up front.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All VibeDeploy toolsInspect
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.

Resources