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
}

Tools

Functions exposed to the LLM to take actions

NameDescription
get_system_vitalsA

Returns available system RAM, CPU load percentage, thermals (if accessible), and threshold guardrails (>85% RAM, >90% CPU warnings). Use before launching heavy compilation or container builds.

get_gpu_vramA

Checks GPU health, total/used/free VRAM allocation, and utilization. Parses nvidia-smi with graceful fallback for Apple Silicon / integrated display controllers. Use before starting local LLM/CUDA workloads.

inspect_portA

Finds which process PID, process name, and command line is binding a specified TCP port across Windows, macOS, and Linux. Essential for diagnosing EADDRINUSE conflicts.

kill_port_processA

Terminates the process currently occupying a specific TCP port to resolve EADDRINUSE errors without manual hunting. Terminate whole process tree on Windows/Linux.

clean_orphan_processesB

Scans and cleans orphaned/zombie background processes commonly abandoned by AI agents (e.g. headless Playwright/Chrome instances, zombie test workers, orphaned Vite/Node daemons).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: inspecting a port, killing a port's owner, sweeping orphaned processes, reading system vitals, and reading GPU/VRAM stats. The only potential overlap is between kill_port_process and clean_orphan_processes, but one is port-targeted and the other is orphan-scan-based, and the descriptions make that boundary explicit.

Naming Consistency5/5

All five names are snake_case with a leading verb (kill_, clean_, get_, get_, inspect_) and a clear object. The pattern is predictable and readable throughout, with no mixed conventions.

Tool Count5/5

Five tools is a tight, well-scoped surface for a local dev-ops diagnostics server; every tool maps to a real workflow (diagnose conflict, resolve conflict, clean up, pre-flight resource check). Nothing feels redundant or missing at the count level.

Completeness4/5

The core lifecycle for port conflicts and resource pre-flight checks is fully covered, including cleanup and GPU/CPU/RAM visibility. Minor gaps remain, such as disk space or a general process-list/inspect-by-name operation, which would round out the 'vitals' promise but are workable around.