Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
ALLOWNoWhat clients may do, comma-separated: read, trace, inspect, dump, record, end, control, services, network, startup, or all. Reading only when not set.

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
{}
prompts
{}
resources
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
block_programC

Blocking a program from the network is not possible on Linux, whose firewalls filter by address, port and user rather than by program: this always refuses there.

close_connectionA

Closes one TCP connection (IPv4) of a process, as TCPView does: the process is not opened; the program usually reconnects if it wants to.

control_service

Starts, stops or restarts a systemd service (systemd services cannot be paused). Stopping one that others depend on fails unless with_dependents=true.

end_processA

Ends a process (SIGTERM, then SIGKILL if it has not ended within two seconds), or with tree=true it and every process under it (those first). Unsaved work in it may be lost. The system's critical processes (init, the kernel, the session's compositor) and Anabolic are refused; a game or anti-cheat program needs force=true after the user agreed.

get_cpuA

CPU: total and per logical processor (user, kernel, DPC, interrupt, clock), interrupt and context switch rates, the processor's name and topology. With trace_seconds > 0, also who ran on each core (threads and processes with their share), from a context switch trace.

get_disksA

Disks: every physical disk with its partitions (type, file system, where mounted, space) and volumes, activity, throughput, IOPS, response time, queue and temperature. With trace_seconds > 0, also which processes read and write each disk and which files, from a disk I/O trace.

get_displaysB

Monitors: each one's own name, GPU, connection, position, mode and refresh rate against the best it offers, native resolution, HDR and scaling. Points out a monitor left below its refresh rate or resolution.

get_gpusB

GPUs: each adapter's usage, engines (3D, copy, video...), dedicated and shared memory, temperature, and the processes using the GPU most.

get_hardwareB

Hardware: the processor (model, cores, caches, clocks, features, virtualisation), the board and BIOS, memory modules (size, speed and configured speed, maker, part number) and the core topology.

get_historyA

What happened at a time: the history's samples for a day (or part of one), each with CPU, memory, commit, disk and network totals, the GPU, the processes that led, and the processes that started, exited or hung. Answers "why was the PC slow at 14:32".

get_leaksB

Processes whose handles, private memory or threads keep growing in a straight line (sampled every minute for two hours, flagged after ten minutes or more): the usual sign of a leak.

get_memoryB

Memory: used, available, commit charge and limit, file cache, pools, the standby/modified/free lists, page files, and the processes with the most private memory.

get_network_usageA

Who uses the network: each program's receive and send rates and totals, and (after trace_seconds of the network trace) where the traffic goes, by destination name, with the programs talking to each.

get_processA

One process in full: every counter (CPU, memory in detail, I/O, disk, network, open files), its file, command line, package, version, user and rights; who started it and their parents (named even after they exited) and how it was most likely started; the processes it started; the services it runs; its connections and listening ports; and whether its open files, memory or threads keep growing. Nothing is injected; its files in /proc are only read.

get_process_treeA

The process tree: who started whom, with CPU and private memory, from a process down (or the whole machine). Parents that exited are left out; a reused PID does not make a false parent.

get_sensorsA

Temperatures, fan speeds and power draw: every sensor Anabolic reads (the processor's package and cores, GPUs, disks, memory modules, network adapters, thermal zones, fans), each with the hardware's high and critical marks and how close it is to them. On Windows only drivers may read the processor's own temperature: the firmware's thermal zones stand in where it has any (many desktops have none), and the processor's power comes from its energy meter.

get_serviceA

One service in full: state, process, startup type (and whether a trigger starts it), its program and arguments, the account it runs as, its description, what it depends on and which services depend on it.

get_stuttersA

Stutters: frame rate, 1 % lows, frame times and stutter counts of every program that draws (games), the latest stutters, and DPC/ISR time per driver (LatencyMon style) with the longest spikes. Watches for watch_seconds first (default 5) if the trace was not already running. No game is opened.

get_system_overviewA

The state of the whole PC right now: CPU, memory, disks, network, GPUs, process/thread/handle counts, uptime, the busiest processes per resource, and anything that needs attention (hung windows, processes that cannot end, memory pressure, leaks). The place to start.

get_thread_stacksA

Call stacks of a process' threads (one thread, or its busiest ones), with module!function names where they can be read: where it spends its time or is stuck. OPENS THE PROCESS and SUSPENDS each thread for a few milliseconds: the first call is refused with the risks; call again with force=true only if the user agreed.

get_wait_chainA

What a process' threads wait for, across processes (Wait Chain Traversal): locks, other threads, other processes, COM and ALPC calls, deadlocks first. The answer to "why is it not responding". OPENS THE PROCESS' THREADS: the first call is refused with the risks; call again with force=true only if the user agreed. Can take seconds.

lift_limitA

Takes away the CPU and memory limit limit_process (or the user, by hand) put on a process. A rule's limit stays: the rule is the user's.

limit_processA

Holds a process, and the processes it starts from now on, to a share of the machine's CPU and to an amount of private memory (Windows job objects: a cap the scheduler keeps, whatever the priority). Past the memory limit its requests for more fail, and most programs then stop with an error. Lasts until it exits or Anabolic quits; lift_limit takes it away. Windows' core processes and anti-cheat programs are refused.

list_connectionsA

Every TCP connection and UDP endpoint with its program, the other end's address and name (from what programs looked up, else reverse DNS), ports and TCP state. With trace_seconds > 0, also each connection's traffic. Filter by process or by text.

list_dns_lookupsC

DNS lookups programs made. Not available on Linux: nothing records the names programs look up system-wide.

list_handlesA

The handles a process holds, by type, with the names of files, registry keys, events and other objects; for processes held open, which process each one is. OPENS THE PROCESS (handles are duplicated out of it to read their names): the first call is refused with the risks; call again with force=true only if the user agreed.

list_history_daysB

The days the history (flight recorder) holds: every 10 seconds while Anabolic runs, the machine's totals and the processes that led.

list_listening_portsA

The ports open on this PC for others to connect to (TCP listening, UDP bound), with the program behind each and who can reach it: every network, this computer only, or one network.

list_modulesA

The DLLs and the program a process has loaded, with their paths, base addresses and sizes. OPENS THE PROCESS to read its module list: the first call is refused with the risks; call again with force=true only if the user agreed.

list_processesA

The processes running now, one line each: PID, parent, name, CPU, private memory, disk, network and GPU rates, threads, handles, priority, user, start time, and whether it is not responding. Filter by name or PID, order by a resource.

list_servicesA

systemd services, the system's and the user's own (marked "(user)"): unit name, description, state, startup type (enabled, disabled, masked, static), the process each runs in. Filter by text and state.

list_startup_itemsA

Programs that start with the session: autostart entries, systemd user units and Plasma's scripts, with their command, whether each is on, whether its program is missing, and what it costs now if it runs.

record_activityA

Records what a process (with the processes under it), every process of a name, or the whole machine does for some seconds, step by step like Process Monitor: programs started and how they ended, shared libraries loaded, files opened, read, written, renamed and deleted (only when Anabolic has full access; Linux reports what was done, not what failed), TCP connections with the bytes they carried; with syscalls=true, every system call of a process or program like strace, with a per-call summary like strace -c (full access). Nothing is opened, stopped or injected. Reports progress every second; returns the counts and the steps kept (filter them with kinds, filter, only_failures, only_changes).

resume_processB

Resumes a suspended process.

set_affinityC

Sets which logical processors a process may run on (its affinity).

set_efficiency_modeC

Turns efficiency mode on or off for a process: it runs only when no one else wants the processor (the idle scheduling class), and its disk I/O likewise.

set_priorityA

Sets a process' priority class: idle, below_normal, normal, above_normal, high or realtime (realtime can starve the rest of the system).

set_service_startupB

Sets how a systemd service starts: automatic (enabled), manual (disabled: started on demand) or disabled (masked: cannot be started). automatic_delayed does not exist on Linux.

set_startup_itemA

Turns a startup item on or off the way the desktop's own settings do: an autostart entry is hidden (a system-wide one by an override in the user's folder), a systemd user unit disabled. Nothing is deleted.

suspend_processA

Suspends every thread of a process: it stops using the CPU until resumed (its windows stop responding meanwhile). Critical processes and Anabolic are refused; a game or anti-cheat program needs force=true.

unblock_programB

Removes the firewall rules block_program (or the Network page) made for a program.

why_process_will_not_endA

Why a process does not go away: whether it has ended and waits for its parent to collect it (a zombie, and which parent), whether it waits inside the kernel where no signal reaches it (and where), whether Anabolic may end it at all, and whether it is the system's own. The process is only read about, not opened.

write_memory_dumpA

Writes a memory dump of a process into Anabolic's dumps folder, for a debugger: small (threads, stacks, modules, handles) or full (all of its memory, which includes any passwords and keys it holds). The process is cloned first, so it pauses only for a moment. Never for lsass.exe. OPENS THE PROCESS: the first call is refused with the risks; call again with force=true only if the user agreed.

Prompts

Interactive templates invoked by user choice

NameDescription
diagnose_slownessFinds what makes the PC slow right now: CPU, memory, disk, GPU or a hung program.
why_not_respondingLooks into one program that hangs or will not close.
game_stuttersFrame times, driver latency and what runs beside the game.
what_happened_atReads the history around a moment.
network_checkWhich programs use the network, where their traffic goes, and which ports are open.
startup_cleanupReviews the startup programs and suggests which to turn off.

Resources

Contextual data attached and managed by the client

NameDescription
System overviewCPU, memory, disks, network, GPUs, the busiest processes and what needs attention.
ProcessesThe 100 busiest processes by CPU, one line each.
Network usageEach program's traffic (no trace: rates from the last refresh).
ServicesEvery service with its state, startup type and process.
Startup programsWhat starts with the computer or the session, whether it is on, and what it costs now.
Today's historyToday's samples of the flight recorder (the latest 120).

TDQS

B3.4/5.0

Scored across 43 tools

Disambiguation4/5

Descriptions are detailed and most tools have a clearly distinct resource or action. A few adjacent pairs, such as get_process vs list_processes and get_service vs list_services, require reading the descriptions carefully, and the large surface area raises misselection risk.

Naming Consistency4/5

Almost all tools use consistent snake_case with a verb_noun pattern such as get_cpu, list_processes, and set_priority. The main outlier is why_process_will_not_end, which breaks the predictable naming convention.

Tool Count2/5

43 tools is far beyond the typical well-scoped range and many could be consolidated or grouped under broader resource-oriented tools. The domain is broad enough to justify more than a handful of tools, but this surface is still excessive.

Completeness5/5

The set covers CPU, memory, disks, GPUs, network, hardware, sensors, processes, services, startup items, connections, handles, modules, dumps, history, leaks, and stutters. For system monitoring, troubleshooting, and process control, the lifecycle and diagnostic coverage is comprehensive.

Maintenance

ActivityMaintained
ResponsivenessNo issues