@snapdeploy/mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SNAPDEPLOY_API_KEY | Yes | Scoped token (sd_pat_…) or legacy API key. Required. | |
| SNAPDEPLOY_BASE_URL | No | Base URL of SnapDeploy API. | https://snapdeploy.dev |
| SNAPDEPLOY_READ_ONLY | No | Set to '1' to expose only read tools. | 0 |
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 |
|---|---|
| list_appsA | List the user's SnapDeploy containers with status and URL, plus plan, deploy-limit and free-hours state. Start here to find container ids/names. |
| get_statusA | Full status of one container (by name or id): state, URL, port, detected technology, resources. Env-var VALUES are never returned — names only. |
| get_logsA | Recent RUNTIME logs of a container (CloudWatch, up to 1000 lines). For BUILD logs of a deployment use get_deployments with a deployment_id. |
| get_deploymentsA | Deployment history of a container, or one deployment in detail (status, error code/message and build-log tail — use this to diagnose a failed build). |
| check_quotaA | Can the user deploy and run apps right now? Merges the deploy limit (5 per rolling 12h — ONLY for accounts without an Always-On/Sprint entitlement; failed attempts count) and the free-hours cap (containers refuse to start at 402 when exhausted), plus any unassigned Always-On subscriptions. |
| list_reposA | List (or search) the GitHub repositories connected to this SnapDeploy account. If GitHub is not connected yet, returns the connect link for the user. |
| detect_env_varsA | Scan a repo for the environment variables it needs (import.meta.env / process.env usage). For known keys (Supabase etc.) the reply says where the user finds the value. Do this BEFORE the first deploy of a Lovable/Bolt/v0 export. |
| deployA | Deploy a connected GitHub repo to SnapDeploy: creates the container if needed, links the repo, builds, and waits for the result. Reply includes the live URL or, on failure, the error and build-log tail. On accounts without an Always-On/Sprint entitlement this uses one unit of the deploy limit (failed attempts count); Always-On accounts are uncapped. |
| set_envA | Set/replace a container's environment variables (rolling restart, no rebuild). Values are accepted but NEVER echoed back. Public build-time names (VITE_*, NEXT_PUBLIC_*, REACT_APP_*) only take effect in the bundle after the next deploy. |
| start_containerA | Start a stopped container. May answer 402 when free hours are exhausted — relay that message and link, do not retry. |
| stop_containerA | Stop a running container (safe, reversible — deletion is NOT possible through this connector by design). |
| wake_containerA | Wake a sleeping free-plan container so its URL serves again. |
| create_databaseA | Create a managed add-on: PostgreSQL, MySQL, MariaDB, MongoDB, Redis or RabbitMQ. Requires a purchased add-on subscription — without one this returns the purchase link (relay it, don't retry). Credentials are provisioned server-side and shown to the user in the SnapDeploy UI, never through this connector. |
| add_domainA | Attach a custom domain to a container. Returns the DNS records the user must create; verification then runs from the SnapDeploy UI. |
| assign_always_onA | Attach an UNASSIGNED Always-On subscription to a container (keeps it running 24/7 and lifts the deploy limit). Only call this after the user explicitly confirms — check_quota lists any unassigned subscriptions. |
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 15 tools
Tools are mostly separated by resource and action: list/get for reads, deploy/set_env for writes, and lifecycle verbs for container states. The only real overlap is start_container vs wake_container, but their descriptions (stopped vs sleeping free-plan) make the distinction usable.
Names follow a consistent snake_case verb_noun convention such as list_apps, get_status, start_container, and add_domain. The one-word deploy action is a minor deviation, but the overall pattern is predictable and easy to navigate.
15 tools is at the upper end of the typical range but each maps to a distinct platform operation, from deployment and env config to quota and add-ons. There is no filler; the size is well-scoped for the server's purpose.
The core workflow is well covered: connect repo, detect env vars, deploy, monitor logs/deployments, manage container state, set env, add domain, and check quota. Gaps like container deletion, database listing/removal, and domain removal are intentionally deferred to the SnapDeploy UI or noted as by-design limitations.