mcp-local-telemetry
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": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_system_metricsA | Returns current CPU, RAM, and Disk utilisation for the local machine. Useful for pre-flight checks before launching heavy builds, containers, or model inference. |
| get_top_processesC | Returns the N processes with the highest CPU usage. |
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 2 tools
get_system_metrics returns aggregate machine-level stats while get_top_processes returns per-process ranking, so their purposes are clearly distinct. An agent can trivially choose between them with no overlap.
Both tools follow a consistent get_<noun> snake_case verb_noun pattern. Naming is predictable and idiomatic throughout.
Two tools is on the thin side for a telemetry server; while each earns its place, the surface feels minimal and could reasonably include a couple more monitoring dimensions without bloat.
Core CPU/RAM/Disk and top-CPU-process coverage exists, but network I/O, memory-heavy process ranking, disk I/O, and any historical/sampling data are missing. Agents can perform basic pre-flight checks but hit dead ends for richer diagnostics.