Skip to main content
Glama

Snaphost MCP server

Deploy the project you are working on straight from your AI agent (Claude Code, Cursor, any MCP client) and get a public URL back.

No Dockerfile required: if the project does not ship one, Snaphost generates it. The folder is packed locally, uploaded, built, and run — the agent gets back a URL it can hand you.

Install

npm install -g @snaphost/mcp

Or skip the install and let your agent run it through npx (see below).

Related MCP server: antideploy-mcp

Setup

  1. Mint an API key in the Snaphost dashboard under API keys, or POST /api/v1/keys. It is shown once and looks like sk_....

  2. Register the server with your agent.

    Claude Code:

    claude mcp add snaphost \
      --env SNAPHOST_API_KEY=sk_... \
      -- npx -y @snaphost/mcp

    Cursor (.cursor/mcp.json) — or any client using the same format:

    {
      "mcpServers": {
        "snaphost": {
          "command": "npx",
          "args": ["-y", "@snaphost/mcp"],
          "env": { "SNAPHOST_API_KEY": "sk_..." }
        }
      }
    }
  3. Tell the agent to deploy: "deploy this project to Snaphost".

Environment

Variable

Required

Default

SNAPHOST_API_KEY

yes

—

SNAPHOST_API_URL

no

https://api.snaphost.ru

Tools

Tool

What it does

snaphost_deploy

Pack the folder, upload, build, wait, return the public URL.

snaphost_status

Deploy status; URL when running.

snaphost_logs

Build/runtime logs (paged via next_since).

snaphost_list

Recent deploys.

snaphost_delete

Stop and delete a deploy.

What gets uploaded

snaphost_deploy packs the folder into a tar.gz in memory, honouring .gitignore and .snaphostignore. These are dropped unconditionally, whatever the ignore files say:

.git  node_modules  .env  .env.*  *.local.env  .DS_Store
dist  build  .next  .nuxt  coverage  __pycache__  *.pyc  .venv  venv

Symlinks are skipped — the server rejects them. The upload is capped at 50 MB compressed by default; the ignore rules keep a typical project far below that.

Add a .snaphostignore to exclude more. .env files never leave your machine, so anything the deployed app needs at runtime has to be configured on the platform side.

If the project ships its own Dockerfile

The runtime injects a PORT environment variable and invokes the container on it. A server hard-bound to a fixed port builds and deploys fine but never receives traffic. Make it listen on process.env.PORT (or the equivalent), falling back to a local default.

Development

npm install
npm run build     # tsc -> dist/
npm run typecheck

Requires Node 20+.

License

MIT

Available Tools

5 tools
snaphost_deleteB

Stop and delete a Snaphost deploy (frees its URL).

Inputs: deploy_id (required).

snaphost_deployA

Deploy a local project folder to Snaphost. Packs the folder (respecting .gitignore/.snaphostignore, dropping node_modules/.git/.env), uploads it, starts the build, waits, and returns the public URL. Costs vibecoins. No Dockerfile is needed: if the project has none, the platform generates one automatically — do NOT create a Dockerfile before deploying. If the project ships its own Dockerfile, the server inside it MUST listen on the PORT environment variable, otherwise the deployed URL will not respond.

Inputs: path (required), wait.

snaphost_listC

List recent Snaphost deploys for the authenticated user.

Inputs: limit.

snaphost_logsA

Fetch build/runtime logs for a Snaphost deploy. Pass next_since from a previous call to page.

Inputs: deploy_id (required), since.

snaphost_statusA

Get the status (and URL when running) of a Snaphost deploy.

Inputs: deploy_id (required).

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.6/5.0

    Scored across 5 tools

    Disambiguation5/5

    Each tool targets a distinct resource+action pair: deploy, logs, delete, status, and list. There is no overlap or ambiguity — deploy creates, logs fetches, delete removes, status checks, and list enumerates. An agent can clearly distinguish which tool to invoke.

    Naming Consistency5/5

    All tools follow a consistent snaphost_ prefix followed by a clear verb naming the action (deploy, logs, delete, status, list). The action verbs are simple and unambiguous, maintaining a uniform style throughout.

    Tool Count5/5

    Five tools is well-scoped for a deployment lifecycle server. Each tool earns its place covering deploy, monitor (logs/status), clean up (delete), and discovery (list) without bloat or deficiency.

    Completeness4/5

    The core deploy lifecycle is well covered: deploy, status, logs, list, and delete. Minor gaps include the absence of an update/redeploy operation to replace an existing deploy, and no ability to manage env variables post-deploy, but these are workaround-able gaps for the primary use case.

    Maintenance

    ActivityInactive
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      B
      maintenance
      Enables AI agents to deploy code to any hosting provider by creating PRs, building, and verifying health checks, all from a single natural language command.
      62 npm
      1
      MIT
    • A
      license
      A
      quality
      B
      maintenance
      Enables AI assistants to deploy and manage SnapDeploy containers and resources—including builds, logs, environment variables, databases, and custom domains—directly through natural language.
      15
      53 npm
      MIT
    • A
      license
      Not graded
      quality
      C
      maintenance
      Deploys the current folder or a GitHub repo to a live HTTPS URL on Dockhold, and lets AI tools read status/logs, set variables, and resize apps and managed databases.
      MIT