Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
alertsA

Check resource alerts for CPU, memory, and disk usage against configured thresholds. It reads and compares; nothing is sent anywhere and nothing is recorded, which is what a running watcher does instead

alerts_historyA

Show recorded alert and remediation history. Entries are only written while a watcher is running, so an empty list means nothing was recording rather than nothing went wrong

backup_createA

Create a Docker compose backup archive for all services or one service. Volumes are read while the containers run, so a database mid-write can land inconsistent; an archive is not evidence it restores, which is what backup_drill answers

backup_drillA

Verify a backup by booting an app in an isolated Docker environment and checking that it responds. A second copy runs beside the live one on a network and port of its own, and everything it made is removed either way. A pass means the archive is not corrupt and the app starts on it, not that every row is there

backup_listA

List existing backup archives in the configured backup directory. It reads names, sizes and dates — that an archive is here says nothing about whether it restores, which is what backup_drill answers

backup_restoreA

Restore Docker volumes from a backup archive, overwriting the data the app is running on. Destructive: confirm intent before calling. Bind mounts declared by the archive are always refused here, because an agent has no way to name a host path it may write to

config_validateA

Check the config file this server is running on: which file was used, which rule selected it, what was read from each section, and anything wrong or silently ignored

docker_inspectA

Summarize a Docker container's image, state, restart policy, ports, mounts, networks, and health. Environment variable values are never included

docker_listA

List Docker containers with their status, image, and ports. Stopped containers are included, so a name appearing here is not a name that is running — read state

docker_logsA

Get logs from a Docker container: the last lines only, 50 by default, and it returns rather than following the stream

docker_restartA

Restart a Docker container by name. It goes down and comes back, and the result says the restart command succeeded, not that the app inside is serving again. Read the logs first if you do not know why it needs restarting

docker_statsB

Get resource usage statistics (CPU, memory, network, block I/O) for all running Docker containers

docker_stopA

Stop a Docker container by name. Nothing here starts it again: there is no start tool, so the operator brings it back themselves

docker_topA

List the processes running inside a Docker container, read from the host. Nothing runs in the container: no exec, no TTY. Each process's command is the kernel's name for it (ps comm, at most 15 characters), never read from its command line, because a token passed on a command line would otherwise be in the result

doctorA

Run a read-only diagnosis for resource pressure, stopped containers, public ports, backup hygiene, notifications, and report baseline readiness

install_appA

Install a self-hosted app via docker compose. Pre-checks docker, ports, and duplicates automatically, and a refusal comes back as a result with the reasons rather than as an error. warning is present when an earlier install of the app left state in Docker volumes this install could not carry over

install_listA

List available self-hosted apps that can be installed. The catalogue is compiled into the binary, so this reaches no network and answers the same on any machine

install_purgeA

Stop an installed app and delete all data including containers, config, and volumes. Nothing here restores it and no backup is taken first: take one before calling if the data matters. A volume that still exists afterwards (external, or used by another container) is listed in kept_volumes, and one Docker could not be asked about in unchecked_volumes

install_statusA

Check the status of an installed app, as its containers report it. An app homebutler did not install is not known here

install_uninstallA

Stop an installed app and remove its containers. The app directory and its volumes stay on disk; install_purge is the one that deletes them. warning is present when part of the app's state is in Docker volumes outside the app directory, left there by an earlier install

inventory_exportA

Export server inventory/topology as a Mermaid diagram locally, or JSON locally/remotely. Inside a container a local export is refused, because a container cannot see the machine it is on

inventory_scanB

Collect server inventory/topology including system status, Docker containers, app ports, and system ports

network_scanA

Scan the local network to discover devices (IP, MAC, hostname). It probes every address on the subnet and takes up to 30 seconds, so it is an answer to a question somebody asked rather than a way to begin. Inside a container it refuses, because the subnet it would scan is the container's own

notify_testA

Send one test notification through every configured channel and report which ones arrived. A real message goes out to each, so anyone reading those channels sees it

open_portsA

List open network ports with associated process information. The process behind a port is not always readable without privilege, and missing_process says so rather than leaving the field quietly empty

processesA

List the top processes by CPU or memory, with a total count and any zombies broken out separately

proxmox_guest_rebootA

Reboot one explicitly targeted Proxmox guest after confirmation and return the accepted task UPID

proxmox_guest_shutdownA

Gracefully shut down one explicitly targeted Proxmox guest after confirmation and return the accepted task UPID

proxmox_guest_startA

Start one explicitly targeted Proxmox guest after confirmation and return the accepted task UPID

proxmox_guestsA

List Proxmox QEMU and LXC guests, optionally filtered by node, status, or type

proxmox_nodeC

Get detailed Proxmox node status

proxmox_script_commandA

Render the pinned install command for one Proxmox VE Community Script. Never fetches or runs it; the caller reviews and runs it themselves on the Proxmox host

proxmox_script_listA

List the curated Proxmox VE Community Scripts catalog (community-scripts/ProxmoxVE)

proxmox_statusA

Get Proxmox VE version, cluster status, and resources

proxmox_task_statusA

Inspect one asynchronous Proxmox task by node and opaque UPID

proxmox_tasksA

Get the 50 most recent Proxmox tasks for a node

reportA

Generate a butler-style health report with snapshot comparison, warnings, notable changes, and suggested actions. It saves a snapshot unless no_save is set, which moves the window every later comparison is measured from — so a loop that calls this leaves nothing to compare against

system_statusA

Get system status including CPU, memory, disk usage, and uptime, for the machine this binary runs on. Inside a container it refuses rather than describe the container as the host; name a server to read a machine over SSH

wakeA

Send a Wake-on-LAN magic packet to wake a machine. The packet is fire-and-forget: a successful result means it was sent, not that anything woke up

watch_addA

Add a Docker container, systemd unit, or PM2 app to the watch list. This writes the list and nothing begins watching it — a supervisor has to be installed separately, which only the operator can do. Adding a target twice is reported as added=false rather than an error

watch_checkA

Run a one-shot restart check on watched targets and report restarts detected since the last check. Only docker targets can be inspected this way; systemd and pm2 targets are reported as skipped rather than assumed healthy

watch_historyA

List recorded restart incidents, newest first. Captured logs are excluded unless include_logs is set, because every incident carries a hundred lines of output twice over

watch_listA

List the targets being watched, with their kind and what the last check recorded

watch_removeA

Remove a target from the watch list, leaving its recorded incidents in place. Only the list changes: whatever was supervising it keeps running until the operator stops it

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.4/5.0

Scored across 44 tools

Disambiguation4/5

Tools are organized into clear families (docker_, install_, backup_, watch_, proxmox_, inventory_) with distinct resource+action targets, and the descriptions go out of their way to explain boundaries such as install_uninstall vs install_purge and backup_list vs backup_drill. The main soft spots are the diagnostics cluster — alerts, alerts_history, doctor, report, and to a lesser degree system_status — which all answer overlapping "is my server healthy" questions and require reading descriptions carefully to choose. Docker_stop vs install_uninstall also overlap conceptually, though the descriptions disambiguate them.

Naming Consistency4/5

Nearly all tools follow a namespace_action pattern (docker_list, backup_create, watch_add, proxmox_guest_start, install_status), giving a predictable, scannable surface. The deviations are a handful of bare noun names (alerts, doctor, report, processes, wake, system_status, open_ports, proxmox_status, proxmox_node) that break the verb_noun expectation but stay readable and non-colliding. No camelCase/snake_case mixing.

Tool Count3/5

44 tools is heavy for a single server and pushes past what an agent can hold in working context comfortably, even though the families are well organized and most tools earn a distinct place. There is real consolidation potential in the diagnostics area (alerts, alerts_history, doctor, report) and in the Proxmox read tools (proxmox_status, proxmox_node, proxmox_tasks, proxmox_task_status, proxmox_guests). The breadth is defensible given the domain spans Docker, Proxmox, backups, app installs, and monitoring, so it is not arbitrary bloat.

Completeness4/5

Coverage is unusually thorough: full lifecycle for app installs (install/status/uninstall/purge), backups (create/list/restore/drill), watch targets (add/remove/list/check/history), Docker inspection and control, and Proxmox guest and node operations. The one acknowledged gap is the absence of a docker_start to pair with docker_stop, which forces operators to bring containers back manually; other omissions (no docker exec, no config write, no supervisor install) appear deliberate and are documented as such. Minor gaps only, most with stated rationale.

Maintenance

ActivityActive
ResponsivenessUsually handled