Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Swigs Cloud MCP server Deploy my project folder to Swigs Cloud and give me the URL."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Deploy and manage your projects on Swigs Cloud, Swiss hosting, from Claude Code, Cursor, or any MCP client. Send a folder from your machine or a public git repository, get an HTTPS address in about two minutes.
You need an account on https://swigs.cloud and the API token from your console. Thirty days are free, no card required.
Claude Code:
claude mcp add swigs-cloud --env SWC_TOKEN=your-token -- npx -y @swigs-cloud/mcpAny other MCP client, in its configuration file:
{
"mcpServers": {
"swigs-cloud": {
"command": "npx",
"args": ["-y", "@swigs-cloud/mcp"],
"env": { "SWC_TOKEN": "your-token" }
}
}
}Variable | Default | |
| — | required, from your Swigs Cloud console |
|
| |
|
|
Related MCP server: mcp-cloud-deploy
| Create a project from a folder or a public git repository, and put it online over HTTPS. Returns the final URL right away; the build takes one to two minutes. |
| Replace the content of a project you already deployed. The address does not change and it does not use up a slot of your quota. |
| Your projects: name, state, address, identifier. |
| State of one project. |
| Build log of the latest deployment. |
| Build the project again from its current source. |
| Set or remove environment variables, then redeploy. Never returns the values. |
| Permanently delete a project. |
Just ask, in your own words:
deploy this folder to Swigs Cloud as my-shop
deploy and update_site archive the folder and upload it. Excluded, and it
matters:
.env and every variant. Your secrets stay on your machine. Pass
environment variables through env on deploy, or through set_env; they
are stored on the project, never inside the archive.
.DS_Store and ._*, the macOS metadata that breaks builds.
node_modules, .git, dist, .next: the build runs on the cluster.
Plain HTML, Vite, React, Vue, Angular, Svelte and Node apps are detected automatically. A site exported from Lovable, v0 or Bolt deploys as is, with no build configuration. Archives are capped at 200 MB.
Use update_site, not deploy again: a second deploy creates a second
project at a different address and uses up another slot of your quota. Files
missing from the folder are removed from the site.
The same tools are available over HTTP at https://swigs.cloud/api/mcp, with
OAuth, for clients that cannot run a local process. That endpoint takes a list
of files instead of a folder, since it cannot read your disk.
MIT.
Permanently delete a project: the site goes offline, its address is released and its data is destroyed. This cannot be undone. Ask the user to confirm before calling it.
Inputs: id (required).
Create a new project on Swigs Cloud and put it online over HTTPS, hosted in Switzerland. Two ways to provide the code, use exactly one: repo for a public git repository, or directory to send a folder from this machine (defaults to the current folder). Static sites (plain HTML, Vite, React, Vue, Angular, Svelte) and Node apps are detected automatically; a site exported from Lovable, v0 or Bolt deploys as is, with no build configuration. The project name becomes the subdomain unless slug says otherwise. Returns immediately with the final URL: the build then takes one to two minutes, poll project_status to know when it is live. To change a site you already deployed, use update_site — calling deploy again would create a second project and use up another slot of the quota.
Inputs: name (required), env, port, repo, +3 more.
List your Swigs Cloud projects: name, state, address and identifier.
Inputs: no named parameters.
Build log of the latest deployment. Call it when project_status reports failed.
Inputs: id (required).
State of one project. running means the site is live, failed means the build did not succeed — call logs to see why. Any other state means the build is still working.
Inputs: id (required).
Build and deploy the project again from its current source. Use it after fixing something in the repository, or to retry a failed build. The address does not change.
Inputs: id (required).
Set or remove environment variables on a project, then redeploy so they take effect. Variables you do not mention are kept; an empty value removes one. Never returns the values, only the names.
Inputs: id (required), env (required).
Replace the content of a project you already deployed and build the new version. The address does not change and no new project is created, so it does not use up a slot of your quota. Prefer it over calling deploy again whenever you are changing an existing site. Files missing from the folder are removed from the site.
Inputs: id (required), directory.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 8 tools
Each tool targets a distinct operation: listing, deploying, updating, checking status, fetching logs, redeploying, setting environment variables, and deleting. Even though deploy, update_site, and redeploy all build projects, their descriptions make the boundaries clear (new project vs. existing vs. rebuild).
All tool names use snake_case and follow a consistent verb-first pattern (list_projects, update_site, delete_project) or a clear noun-based query (project_status, logs). No mixed styles or vague verbs.
8 tools is well-scoped for a deployment platform, covering the full lifecycle without redundancy. Each tool earns its place, and the count is within the ideal 3-15 range.
The surface covers the complete CRUD lifecycle: list (read), deploy (create), update_site/redeploy (update), delete_project (delete), plus status, logs, and env var management. No obvious gaps that would block typical workflows.
Build, deploy, and host full-stack web apps from any MCP client. DB, auth, storage, cron included.
Create website projects, deploy GitHub sites and read logs/usage via remote OAuth MCP.
Create, edit, preview, and deploy full-stack web apps to a live URL from any MCP client.
Deploy AI-generated HTML/CSS/JS to instant public HTTPS URLs from any MCP-compatible agent.
