InstaServer
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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_presetsA | List the runtime presets InstaServer can deploy (static/nginx, nodejs, python) and what each expects. |
| create_podA | Create a new empty pod (a persistent Docker container + volume) without deploying app files yet. Usually you can skip this and call deploy_pod directly. |
| deploy_podA | Deploy files to a pod. Creates the pod if it doesn't exist, uploads the given files, installs dependencies, (re)starts the app, opens a public HTTPS URL via a Cloudflare quick tunnel, and checks it answers. This is the main tool — one call to go from source files to a live URL. |
| list_podsA | List all pods and their status. |
| get_podB | Get details for one pod, including its public URL and status. |
| manage_podB | Start, stop, restart, or reload (alias for restart) a pod's container. |
| delete_podA | Permanently delete a pod: removes its container, volume, and tunnel. |
| exec_commandA | Run a shell command inside a pod's container and return stdout/stderr/exit code. |
| get_logsB | Get the recent stdout/stderr logs from a pod's app process. |
| list_filesB | List files under a path inside a pod's app root. |
| read_fileB | Read a text file from inside a pod's app root. |
| write_fileA | Write (or overwrite) a single file inside a pod's app root without a full redeploy. |
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 12 tools
Most tools have clearly distinct purposes, but create_pod overlaps with deploy_pod since deploy_pod can also create the pod. The descriptions explicitly call this out, so an agent can still choose correctly, but the boundary is slightly fuzzy.
All tool names follow a consistent verb_noun snake_case pattern: list_, create_, get_, manage_, delete_, exec_, read_, write_. The naming style is uniform and predictable across the entire set.
12 tools is well-scoped for a deployment and pod-management server. Each tool maps to a distinct lifecycle operation or inspection task, and none feel redundant or unnecessary.
The tool surface covers the full pod lifecycle: deploy, list, inspect, manage, delete, execute, log, and file operations. There are no obvious dead ends, and the provided tools are sufficient to go from source files to a live managed URL.