Snaphost MCP
# 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
Scored across 5 tools
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.
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.
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.
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.