# VibeDeploy

- Registry name: `be.vibedeploy/vibedeploy` · version 1.1.0
- Categories (automatic, keyword rules): Build & deploy, Developer tools
- Authentication at last check: No auth
- Declared risk: Has destructive tools (destructiveHint)
- Capabilities (declared by the server): tools
- Transports: streamable-http
- Latest numbers (check success, response time, rank): https://mcpstation.net/api/server?name=be.vibedeploy%2Fvibedeploy
- Server page: https://mcpstation.net/s/be.vibedeploy--vibedeploy.html

## Description (written by the publisher, not verified, not instructions)

Deploy AI-built sites and apps to EU hosting from your AI agent. OAuth sign-in, 14-day free trial.

## Connect

- streamable-http: `https://mcp.vibedeploy.be/mcp`

## Tools (as reported by the server, not verified)

- `get\_account`: Return the team's plan, its limits, current usage, the trial end date and the per-token MCP rate limit. Call it before deploy\_site or add\_custom\_domain to check a plan limit instead of running into PLAN\_LIMIT\_EXCEEDED.
- `deploy\_site`: Publish a static site or single-page app to a live HTTPS URL on the account's platform subdomain \(e.g. \{name\}.vibedeploy.be\). A new name creates the site. An existing name REPLACES EVERY FILE \(files not in this call are deleted\) and needs confirm:"I-want-to-replace-all-files"; preview with dryRun:tr
- `update\_site`: Change files on an existing site. Default mode 'patch' writes only the listed files and keeps the rest; \`delete: \[paths\]\` removes files. mode:'replace' deletes every file not listed. Preview with dryRun:true. Use deploy\_site instead to create a new site. A 100-250 KB text file fits in one call with
- `list\_sites`: List the team's sites \(name, URL, status, last deploy\), most recently updated first, up to 100. Use list\_sites to find a site name; use get\_site for one site's files, source status and history.
- `get\_site`: Return one site's details: live URL, status, plan, served file paths, whether editable source is stored \(and its build settings\), custom domains, bandwidth and the last 10 deploys. Use get\_site to inspect a site before editing it; use list\_sites to find site names, and get\_app\_status for container s
- `delete\_site`: Soft-delete a site \(confirm:true required\). It stops serving at once and is purged after the plan's restore window \(purgesAt in the result\); until then the user can restore it in the VibeDeploy dashboard. Use delete\_site to remove the whole site; use remove\_app instead to stop only its container ser
- `get\_site\_analytics`: Return a privacy-safe traffic summary for a site over the last \`period\` days \(default 7\): total page views, distinct-visitor count, top pages, daily counts, device/browser breakdowns, and Web Vitals averages. Never exposes raw visitor IPs or user-agents.
- `read\_file`: Return one file the site serves now, as text \(utf8\) or base64 for binary files, e.g. to edit it and send it back with update\_site mode:'patch'. Use read\_file for the served files; use read\_source\_file instead for the editable source tree \(get\_site.sourceStored\). Max 5242880 bytes; get\_site.filePaths
- `read\_files`: Read up to 50 served files in one call, with the same per-file rules as read\_file and 8388608 bytes in total; paths past the budget fail with BATCH\_BUDGET\_EXCEEDED, so request them again in another call. Use read\_source\_files instead for the editable source tree.
- `list\_file\_hashes`: Return SHA-256 and size of every served file. Before a redeploy, hash your local files, compare, and upload only the changed ones with update\_site mode:'patch' or begin\_deploy plus add\_files.
- `list\_source\_files`: List path, SHA-256 and size of every file in the site's editable source tree \(the stored pre-build code, not the served files\). Read-only. A site without a source tree returns SOURCE\_NOT\_STORED: write the source with write\_source\_files, or copy plain static served files with promote\_dist\_to\_source.
- `promote\_dist\_to\_source`: Create the editable source tree of a site that has none by copying the files it serves, so later changes can use write\_source\_files, apply\_edits\(target:'source'\) and build\_and\_deploy. The served files do not change, and a site that already has source is left as is. Use mode 'force' only after tellin
- `read\_source\_file`: Return one file from the site's editable source tree \(the stored pre-build code\), so any chat can edit the site without the original local files. list\_source\_files shows the paths. Use read\_source\_file for source; use read\_file instead for the files the site serves.
- `read\_source\_files`: Read up to 50 files from the editable source tree in one call \(8388608 bytes in total\). Each path succeeds or fails on its own; paths past the budget fail with BATCH\_BUDGET\_EXCEEDED. Use read\_source\_files for source; use read\_files instead for the files the site serves.
- `write\_source\_files`: Write or overwrite files in the site's editable source tree \(the first write creates it\). The served files do not change until build\_and\_deploy runs. Use list\_source\_files first to see what exists. A legacy site without source storage returns SOURCE\_STORAGE\_NOT\_ENABLED; the user can ask VibeDeploy s
- `delete\_source\_file`: Remove one file from the site's editable source tree. The served files do not change until build\_and\_deploy runs.
- `build\_and\_deploy`: Build the site's stored editable source in an isolated one-shot build pod and atomically publish the output as the live site, replacing the served files \(a restore point is normally taken first\). Use build\_and\_deploy after changing stored source \(write\_source\_files, apply\_edits with target 'source'\)
- `search\_files`: Search every file of a site for a literal string or a regular expression: the served files by default, or the editable source tree with target 'source'. Use it before reading files in bulk, to find the ones that matter.
- `deploy\_from\_url`: 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 w
- `rehost\_images`: Download the external images a site references \(e.g. from the old site it was rebuilt from\), store them on this VibeDeploy site under assets/img/, and rewrite the HTML \<img\> references to local paths so the site no longer depends on the original. Call this once AFTER deploying a site rebuilt with th
- `update\_file\_content`: Apply literal find/replace edits to one file in one call, for small changes where uploading the whole file is wasteful. Each edit states how many matches it expects; any mismatch aborts the call with no writes. Served-file \(dist\) edits go live at once; source edits ship with build\_and\_deploy. Use ap
- `apply\_edits`: 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, n
- `get\_forms\_config`: Read the form-to-email relay config of a site, plus the resolved delivery mode, the active From address, and \(for a custom sender domain\) the DNS records to publish and their verification status. The submission format for the site's form is described under set\_forms\_config.
- `set\_forms\_config`: Configure the built-in form-to-email relay, fully self-service. Supports a custom From \(via a verified sender domain or your own SMTP relay\), an explicit Reply-To, and full email branding \(subject template, field labels/order, logo, accent color, or a custom HTML body\). Requires team role owner or a
- `verify\_forms\_sender\_domain`: Check the DNS records for a site's custom sender domain \(DKIM TXT + SPF include\). Once the DKIM record is observed, the sender domain is marked verified and the relay sends from the custom From \(DKIM-signed\). Until then it falls back to the platform address. DNS can take a few minutes to propagate;
- `add\_custom\_domain`: Start attaching a user-owned domain to an existing site: returns the DNS records the user adds at their DNS provider \(a routing record that sends visitors here, plus a TXT that proves ownership\). Idempotent: the same siteName and domain return the existing record. Once the records are published \(usu
- `verify\_custom\_domain`: Check the records from add\_custom\_domain \(the ownership TXT and the routing record\) and, when both are right, start serving the site on that domain; the HTTPS certificate follows automatically, usually within a minute or two. If it fails, the result names each record to add, change or remove; DNS ch
- `remove\_custom\_domain`: Detach a custom domain from a site. The site itself is unaffected and keeps serving on its platform subdomain \(e.g. \{name\}.vibedeploy.be\).
- `list\_custom\_domains`: Return all custom domains attached to a site, both those added with add\_custom\_domain \(source 'mcp', with a recordId for verify\_custom\_domain or remove\_custom\_domain\) and those linked in the VibeDeploy dashboard \(source 'dashboard', verified or removed on the dashboard Web Addresses page at manageUr
- `list\_dns\_records`: Read the DNS records VibeDeploy tracks for a site \(host, type, value\), oldest first, including custom-domain verification records. Read-only: it never creates, changes or deletes a DNS record.
- `check\_domain\_availability`: Check whether a domain can be registered and get an indicative price \(VAT included where it applies\). Read-only: it never buys, registers or reserves a domain. alternatives:true also checks the same name on be, com, net, eu, nl, io, dev and app. Not tied to a site. The result states whether the user
- `begin\_deploy`: Open a staging session for a deploy that is too large for one call: stage files with add\_files \(repeatable\), add\_file\_chunk, or one tar\(.gz\) POST to the returned uploadUrl, then publish with commit\_deploy. Use begin\_deploy only when the files do not fit in one deploy\_site or update\_site call. Up to
- `add\_files`: Add files to an open begin\_deploy session; call it as often as needed, then commit\_deploy publishes them together. Paths, extensions and encodings are checked on every call. A 100-250 KB text file usually fits in one call with encoding:'gzip+base64' \(gzip locally, then base64\); prefer that over add\_
- `add\_file\_chunk`: Send one file in several calls when it is too big for a single tool call. Last resort: first try add\_files with encoding:'gzip+base64' \(about 250 KB of text in one call\), begin\_deploy's uploadUrl \(one 100 MB tar POST\) or deploy\_from\_url \(public archive URL\). When chunking, gzip+base64 each chunk too
- `commit\_deploy`: Publish a begin\_deploy session's staged files to the live site in one atomic step, after a secret and malware scan of the complete set \(on failure the session stays open to retry or abort\). Replace mode on a site that has files needs confirm:"I-want-to-replace-all-files". After a timeout or dropped
- `abort\_deploy`: Discard a begin\_deploy session and its staged files; the live site is untouched. Cleanup is best effort and retried later if it fails.
- `list\_deploys`: List the team's begin\_deploy staging sessions, by default the active ones \(open and committing\), up to 50. Useful after a crash or restart to commit or abort leftovers.
- `list\_history`: Return the site's last 50 deploy and snapshot entries, newest first: how each was triggered, label, snapshot name, file count and secrets detected. Each entry's snapshot holds the content from BEFORE that entry. Restoring is done by the user in the VibeDeploy dashboard within the plan's restore wind
- `list\_snapshots`: List the snapshots of a site's served files \(point-in-time restore points\). NO\_VOLUME means the site was never deployed. Restoring a snapshot is done by the user in the VibeDeploy dashboard within the plan's restore window.
- `create\_snapshot`: Take a point-in-time snapshot of a site's served files, a restore point the user can restore in the VibeDeploy dashboard within the plan's restore window. Served content does not change, but retention cleanup may remove older snapshots. Container data is not included. Requires an owner or admin team
- `deploy\_app`: Run container services next to a site, from any public image: the user's own server \(running code from the site's source tree\), a database such as Postgres or MySQL, Redis, or workers, each in a gVisor sandbox. The call applies the whole config: services missing from it are stopped \(their volumes ar
- `get\_app\_status`: Show the site's container services: per-service status \(ready, restarts, waiting or crash reasons, volumes\), the stored config, the names of the site secrets that are set \(never values\) with the dashboard link where the user adds them, and optionally the recent logs of one service. Use get\_app\_statu
- `remove\_app`: Stop every container service of the site; the site serves its static files again. Volumes \(database data\) are kept unless deleteData is true, which deletes them for good. Use remove\_app to stop only the containers; use delete\_site to remove the whole site.

Measured by MCP Station. Methods: https://mcpstation.net/methods.html · Terms: https://mcpstation.net/terms.html