Skip to main content
Glama
README.md
# 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

```bash
npm install -g @snaphost/mcp
```

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

## Setup

1. Mint an API key in the [Snaphost dashboard](https://snaphost.ru) 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:**

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

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

   ```json
   {
     "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

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

Requires Node 20+.

## License

MIT

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

ActivitySlowing
ResponsivenessNo issues