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
{
  "listChanged": true
}
logging
{}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
check_inventory_healthA

Validate the inventory file: it parses and passes structural validation, every referenced environment variable (${VAR}) is set, and every SSH key / kubeconfig file it references exists and is readable. Re-reads the inventory file from disk on every call, so it reflects the file's current state — including drift since the server started — not just what's currently loaded in memory. Read-only, takes no arguments.

cisco_backupA

Fetch a Cisco device's running configuration ("show running-config"), as-is. Telnet-connected devices get "terminal length 0" sent first automatically; SSH-connected devices do not (SSH runs one command per ephemeral session, so the setting wouldn't carry over) — if an SSH-connected device paginates output, only the first page is returned unless "terminal length 0" is already configured on the device.

cisco_backup_diffA

Fetch a Cisco device's running configuration and diff it against the last snapshot taken by this tool for the same device — flags unexpected config drift. The first call for a device has nothing to diff against and just establishes the baseline.

cisco_interfacesA

List a Cisco device's interfaces with IP address, admin/link status, and line protocol state ("show ip interface brief").

cisco_inventoryA

List a Cisco device's hardware components — chassis, modules, PSUs — with PID/VID/serial number ("show inventory").

cisco_logsB

Fetch a Cisco device's buffered syslog messages ("show logging"), optionally capped to the most recent limit lines.

cisco_versionB

Get a Cisco device's software version, hostname, and uptime ("show version").

cpu_usageA

Report aggregate CPU utilization on a Linux server, sampled over a 1-second window, with a warning/critical severity and recommendation.

disk_usageA

Report per-filesystem disk usage on a Linux server, with a warning/critical severity and recommendation for filesystems running low on space.

docker_imagesC

List local Docker images on a Docker host.

docker_logsB

Fetch the most recent combined stdout/stderr log lines from a container on a Docker host.

docker_psA

List containers on a Docker host (running only, unless all is set).

docker_restartA

Restart a container on a Docker host. This is a dangerous, service-impacting action: it requires confirm: true, and returns without acting if confirmation is missing. Set dry_run: true to see the exact command that would run without needing confirm at all.

docker_statsA

Report a point-in-time CPU/memory/network/disk usage snapshot for containers on a Docker host.

failed_servicesA

List systemd services currently in the failed state on a Linux server.

grafana_alertsB

List currently firing or resolved alert instances from a Grafana instance's alerting API.

grafana_annotationsA

List annotations on a Grafana instance, optionally scoped to a time range and/or tags.

grafana_dashboardsB

Search dashboards on a Grafana instance, optionally filtered by title text or tag.

grafana_queryA

Run a raw query against one datasource on a Grafana instance. The response shape is datasource-specific (Prometheus, Loki, SQL, ...); this is a passthrough, not a normalized result.

journal_errorsB

Report the most recent systemd journal entries at error priority or higher on a Linux server.

kernel_versionA

Report the running kernel release (uname -r) of a Linux server.

kubectl_describeA

Describe a pod: its spec/status highlights plus recent events for it.

kubectl_eventsA

List recent Kubernetes events, most recent first, optionally scoped to one namespace.

kubectl_get_podsA

List pods in a Kubernetes cluster, optionally scoped to one namespace.

kubectl_logsB

Fetch log lines from a pod's container in a Kubernetes cluster.

kubectl_nodesA

List nodes in a Kubernetes cluster with readiness, roles, and capacity.

list_serversA

List servers known to the inventory, optionally filtered by tag. Never returns credentials.

memory_usageA

Report memory usage on a Linux server, with a warning/critical severity and recommendation when memory is running low.

proxmox_nodesB

List every node in a Proxmox VE cluster along with its resource usage summary.

proxmox_snapshotA

Take a snapshot of a QEMU VM or LXC container on a Proxmox node. This is a state-changing action: it requires confirm: true, and returns without acting if confirmation is missing. Snapshotting is asynchronous — the response carries a task UPID, not confirmation the snapshot has finished; check it with proxmox_tasks. Set dry_run: true to see the exact API call that would be made without needing confirm at all.

proxmox_start_vmA

Start a QEMU VM or LXC container on a Proxmox node. This is a state-changing action: it requires confirm: true, and returns without acting if confirmation is missing. Starting is asynchronous — the response carries a task UPID, not confirmation the guest has finished starting; check it with proxmox_tasks. Set dry_run: true to see the exact API call that would be made without needing confirm at all.

proxmox_stop_vmA

Force-stop (hard power-off, not a graceful shutdown) a QEMU VM or LXC container on a Proxmox node. This is a dangerous, service-impacting action: it requires confirm: true, and returns without acting if confirmation is missing. Stopping is asynchronous — the response carries a task UPID, not confirmation the guest has finished stopping; check it with proxmox_tasks. Set dry_run: true to see the exact API call that would be made without needing confirm at all.

proxmox_tasksA

List recent tasks (backups, migrations, VM actions, ...) recorded on a Proxmox node, most recent first.

proxmox_vmsB

List every QEMU VM and LXC container on a Proxmox node.

reboot_requiredA

Report whether a Linux server is pending a reboot (Debian/Ubuntu reboot-required marker, or a running kernel older than the newest installed one).

running_processesB

List the top processes on a Linux server, sorted by CPU usage descending.

uptimeB

Report how long a Linux server has been running and its 1/5/15-minute load averages.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
audit-historyThe most recent mutating tool invocations (docker_restart, proxmox_start_vm, proxmox_stop_vm, proxmox_snapshot) this server has handled, newest first. In-memory only — cleared on restart, not a durable audit trail.

TDQS

B3.4/5.0

Scored across 37 tools

Disambiguation5/5

Each tool targets a distinct resource/action within its platform (Linux, Docker, Cisco, Proxmox, Grafana, Kubernetes, inventory); overlaps like cisco_backup vs cisco_backup_diff are clearly differentiated by the diff/baseline semantics. No two tools appear to do the same thing.

Naming Consistency4/5

All names use snake_case and largely follow a domain-prefix convention (docker_, cisco_, proxmox_, grafana_, kubectl_), which aids predictable grouping. Minor deviations exist: Linux and inventory tools lack a domain prefix, and action/noun phrasing varies (docker_images vs docker_restart), but the set remains readable and predictable.

Tool Count2/5

37 tools across seven subsystems is heavy; while each subsystem is reasonably scoped, the total exceeds the 25-tool threshold and forces an agent to filter a large toolset. The breadth is plausible for a multi-platform infra server, but the count is a significant cognitive burden.

Completeness3/5

Diagnostic/read coverage is strong across Linux, Docker, Cisco, Proxmox, Grafana, and Kubernetes, with a few safe mutations (restart, start/stop, snapshot). However, no tool supports create/update/delete of core resources (containers, VMs, dashboards, Kubernetes objects, inventory entries) or config pushes, leaving significant lifecycle gaps for an infrastructure management server.

Maintenance

ActivityMaintained
ResponsivenessNo issues