local-vitals-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
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.
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.
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.
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.