Vibedeploy vs TatNet — website deployment

A side-by-side look at the Vibedeploy and TatNet — website deployment MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.

Vibedeploy logoVibedeployCloud Platforms · Remote HTTP/SSEDeploy and host AI-built websites on EU infrastructure, straight from your AI agent.56GoodAuth: oauth 2.0TatNet — website deployment logoTatNet — website deploymentCloud Platforms · Remote HTTP/SSEDeploy static and SSR websites via AI; manage Git/Docker apps, builds, logs and domains on TatNet.40FairAuth: not declared

Verdict: choose Vibedeploy for cloud platforms work over a hosted endpoint; choose TatNet — website deployment for cloud platforms over a hosted endpoint. You can also run both side by side in one mcpServers block.

Which MCP server should you choose?

Vibedeploy logoChoose Vibedeploy when

  • You need dedicated capabilities in the Cloud Platforms domain.
  • You prefer a remote HTTP/SSE transport.
  • Its auth model fits you: OAuth 2.0.
  • You want tools like get_account, deploy_site, update_site.
Explore Vibedeploy

TatNet — website deployment logoChoose TatNet — website deployment when

  • You need dedicated capabilities in the Cloud Platforms domain.
  • You prefer a remote HTTP/SSE transport.
Explore TatNet — website deployment

Feature & specification comparison

Rows where the two servers differ are marked.

SpecVibedeploy logoVibedeployTatNet — website deployment logoTatNet — website deployment
CategoryCloud PlatformsCloud Platforms
Quality signal56/100 · Good40/100 · Fair
Install commandConfirmedConfirmed
TransportRemote HTTP/SSERemote HTTP/SSE
AuthOAuth 2.0Not declared
PricingFreemiumNot declared
Required env varsNone listedNone listed
Verified ownerCommunity listingCommunity listing
GitHub stars00
Directory activity 0 views 0 installs 0 upvotes 0 views 0 installs 0 upvotes
Tools43Not listed

Tools & capabilities

Vibedeploy tools 43

  • get_accountReturn 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_sitePublish 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:true. Use update_site instead to change some files of an existing site. A 100-250 KB text file fits in this call with encoding:'gzip+base64' (gzip locally, then base64); use begin_deploy only when the files do not fit in one call. Ship a top-level 404.html for multi-page sites (otherwise unknown paths serve index.html) and use plain ASCII file names. Afterwards add_custom_domain can serve the site on the user's own domain.
  • update_siteChange 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 encoding:'gzip+base64' (gzip locally, then base64); prefer that over begin_deploy plus add_file_chunk. Fails with SITE_NOT_FOUND when the site does not exist.
  • list_sitesList 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_siteReturn 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 services.
  • delete_siteSoft-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 services.
  • get_site_analyticsReturn 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_fileReturn 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 lists the paths.
  • read_filesRead 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_hashesReturn 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_filesList 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_sourceCreate 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 telling the user that build output (minified bundles) is not original source.
  • +31 more on the listing page

TatNet — website deployment tools

No tool names declared yet. Check the project README from the listing page.

Ready-to-paste client configs

Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.

Vibedeploy

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "vibedeploy-2": {
      "url": "https://mcp.vibedeploy.be/mcp"
    }
  }
}

TatNet — website deployment

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "tatnet-website-deployment": {
      "url": "https://mcp.tatnet.cloud/mcp"
    }
  }
}

Frequently asked questions

Vibedeploy is categorized under Cloud Platforms and uses a remote HTTP/SSE transport. TatNet — website deployment belongs to Cloud Platforms and uses a remote HTTP/SSE transport. Pick Vibedeploy for cloud platforms work and TatNet — website deployment for cloud platforms.

Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.

Vibedeploy is listed as freemium — a free tier with paid plans. Auth: oauth 2.0. TatNet — website deployment has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.

Yes. MCP clients support multiple servers: add vibedeploy-2 and tatnet-website-deployment as separate keys in the same mcpServers object, and your assistant will call tools from either one.

On AllMCPs, Vibedeploy has a quality signal of 56/100 (Good) with 0 views, 0 installs and 0 GitHub stars. TatNet — website deployment has 40/100 (Fair) with 0 views, 0 installs and 0 GitHub stars.