Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
VAST_API_KEYYesYour 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

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription
generate_and_teardownRent, render, hand back the file, destroy the instance and prove it is gone.
deploy_minimax_h3MiniMax H3 in ComfyUI on the cheapest Blackwell offer that really fits.
stop_everythingList what is running, destroy it, verify nothing is billing.

Resources

Contextual data attached and managed by the client

NameDescription
templatesRunnable workloads with VRAM, architecture and download requirements.
instancesLive instances with spend and teardown schedule.

TDQS

A3.9/5.0

Scored across 17 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues