Snaphost MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SNAPHOST_API_KEY | Yes | Your Snaphost API key (looks like sk_...). Mint one in the dashboard under API keys. | |
| SNAPHOST_API_URL | No | The Snaphost API base URL. | https://api.snaphost.ru |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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. |
| snaphost_statusA | Get the status (and URL when running) of a Snaphost deploy. |
| snaphost_logsA | Fetch build/runtime logs for a Snaphost deploy. Pass next_since from a previous call to page. |
| snaphost_listC | List recent Snaphost deploys for the authenticated user. |
| snaphost_deleteB | Stop and delete a Snaphost deploy (frees its URL). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.