vastai-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VAST_API_KEY | Yes | Your Vast.ai API key. Create one at https://cloud.vast.ai/manage-keys/. |
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
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| doctorA | Verifies the API key, the account balance, Vast API reachability, and whether the auto-teardown reaper is running. Call this first when anything misbehaves. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| get_balanceA | Prepaid credit, cash balance, lifetime spend, and how many GPU-hours that buys at a given rate. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| list_templatesB | Ready-to-run workloads with their real VRAM, architecture and download requirements. MiniMax H3 is the best open-weight video model; LTX-2.5 is much faster and cheaper per clip. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| get_templateA | Full detail for one workload: every weight file it downloads, hardware gates, and how to drive it once online. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| list_gpusA | Live Vast offers for a workload, bucketed: ready_now, unverified, slow_link, no_ports, too_small, unsupported. Ranked by what the session actually costs (weight download time included), not by sticker $/hour. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| recommend_planA | One call from a workload to a concrete plan: the offer to rent, what the session will cost including weight download, the sticker-price trap it avoided, and the exact create_instance arguments. Never picks hardware the workload cannot run on. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| estimate_deploymentA | Exactly what create_instance would do with these arguments, including the teardown deadline and the worst-case bill. Spends nothing. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| create_instanceA | Rents the offer, starts the container, downloads the weights, and registers the instance for automatic teardown. Requires confirm=true, and you must show the user the cost estimate first. Every instance gets a hard deadline; there is no way to create one that runs forever. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| wait_for_instanceA | Polls for up to 45 seconds and returns the phase: creating, loading, downloading_weights, online, stopped or failed. Call repeatedly until online. Weight downloads take most of the boot time. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| list_instancesA | Every instance on the account with what it costs per hour, what it has spent so far, and when it is scheduled to die. Anything without a teardown entry is flagged. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| get_instanceB | Status, endpoint, SSH command, spend so far and teardown schedule for a single instance. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| get_endpoint_usageB | The ComfyUI URL, the SSH command, how to POST a workflow to /prompt, and how to pull finished renders off the box before it is destroyed. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| get_logsA | Tail of the container log, including the weight-download progress written by the setup script. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| extend_teardownA | Moves an instance’s hard teardown deadline. Use when a render needs longer than planned; it never removes the deadline entirely. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| destroy_instanceA | Destroys the instance immediately and stops all billing, then verifies it is really gone. This deletes the disk: make sure the renders have been downloaded first. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| destroy_allA | Destroys every instance on the account and confirms nothing is left billing. Requires confirm=true. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
| teardown_statusA | The teardown ledger plus the reaper process state. Restarts the reaper if it died while instances are still scheduled. Call this whenever you want proof that nothing will be left running. Returns JSON: {ok, message, next_tool, next_args, ...tool-specific fields}. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| generate_and_teardown | Rent, render, hand back the file, destroy the instance and prove it is gone. |
| deploy_minimax_h3 | MiniMax H3 in ComfyUI on the cheapest Blackwell offer that really fits. |
| stop_everything | List what is running, destroy it, verify nothing is billing. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| templates | Runnable workloads with VRAM, architecture and download requirements. |
| instances | Live instances with spend and teardown schedule. |
TDQS
Scored across 17 tools
Most tools map to distinct lifecycle stages or resources, and descriptions clearly differentiate them. The only mild ambiguity is among list_gpus, recommend_plan, and estimate_deployment, which all relate to selecting/planning a deployment but return different levels of commitment.
The overwhelming majority follow a clear verb_noun pattern like get_balance, create_instance, wait_for_instance, and destroy_instance. Two names break the pattern: doctor and teardown_status, which are less predictable but still readable.
Seventeen tools is slightly above the ideal 3-15 range, but the domain genuinely spans preflight checks, template browsing, GPU selection, cost estimation, deployment, monitoring, logs, and teardown. Each tool appears to earn its place without much redundancy.
The tool surface covers the full rental lifecycle: check account health, inspect templates and GPUs, estimate costs, create an instance, wait for it, inspect logs and endpoints, extend the deadline, destroy instances, and verify teardown. There are no obvious dead ends or missing operations for the apparent domain.