Glances: one Python process for TUI, web, REST and MCP system monitoring

The gap Glances fills between top and a full metrics pipeline

Running top or htop answers one question well: what is happening on this machine right now. The moment you need the same numbers from a second host, or from a container, or from a script, or from an AI assistant, you either open another SSH session or you stand up a metrics pipeline. Glances sits in the middle. The README describes it as an open-source cross-platform monitoring tool that covers CPU, memory, disk and network usage, plus running processes, logged-in users, temperatures, voltages and fan speeds, and container (Docker, Podman, LXD) and virtual machine (Multipass, libvirt) monitoring. The intended audience is the engineer who wants those numbers available through several front ends without installing several agents. The same process can print a dashboard in a terminal, serve a browser page, answer REST calls, expose an MCP endpoint on Glances 4.5.1 and higher, and stream selected fields to stdout. That last part matters more than it sounds: it means a shell script can consume live metrics without a client library.

Plugin architecture and the four ways data leaves the process

Glances is written in Python and, per the README, uses libraries to grab information from the system. The stated design is an open architecture where developers add new plugins or export modules. That single sentence explains most of the behaviour you will observe: each monitored area is a plugin that produces a dict of fields, and each output channel is a consumer of those dicts. The Python API example in the README makes the shape concrete. Importing glances.api and instantiating GlancesAPI gives you attributes such as gl.cpu, which returns a dictionary with keys like total, user, system, idle, iowait, cpucore and ctx_switches. Calling gl.cpu.get("total") returns a single value, and gl.auto_unit(gl.mem.get("used")) converts a byte count into a human-readable string such as 11.6G. Plugins that return collections are keyed by name: the README shows gl.network.keys() returning interface names like wlp0s20f3 and veth33b370c. That is a deliberate boundary, and it is the line where most adoption decisions get made.

Running the TUI, the web server and the MCP endpoint

Standalone mode is a single command with no arguments: glances. That opens the terminal dashboard shown in the README's summary screenshot. Web mode is glances -s (-w is an alias), and the README says to open http://localhost:61208 in a browser; the server listens on 127.0.0.1 by default, so reaching it from another machine needs -B 0.0.0.0 and the URL http://<ip>:61208. The same server exposes an HTTP/RESTful API. To add the Model Context Protocol server for AI assistants, the command is glances -s --enable-mcp, and the MCP endpoint is at http://<ip>:61208/mcp (Streamable HTTP) and http://<ip>:61208/mcp/sse (SSE, for older clients). The README points to McpApi documentation for client configuration. Service discovery is built in: glances --browser finds Glances servers on the network or defined in the configuration file, and glances -w --browser does the same for the web UI. For scripting, the stdout exporters are the useful part. glances --stdout cpu.user,mem.used,load emits one labelled line per field per refresh, and the README shows load arriving as a nested dict with cpucore, min1, min5 and min15. glances --stdout-csv now,cpu.user,mem.used,load flattens nested keys into columns such as load.min1 and prefixes a timestamp column. glances --stdout-json cpu,mem emits a JSON object per field, and the README notes that attributes are not supported in this mode so the output stays a real JSON object. There is also glances --fetch for a one-shot snapshot, and a client/server mode in which glances -s -B 0.0.0.0 runs on the server and glances -c <server_ip> on the client, reading stats from the server REST API; XML-RPC is no longer used.

What Glances does not do, and where it becomes the wrong tool

The README lists export to files, external time/value databases, CSV and direct STDOUT output, which means retention, downsampling and querying are somebody else's problem. If your requirement is a graph of last Tuesday at 03:00, Glances alone will not answer it. The second constraint is the client/server model. In web or client/server mode the monitored host runs a Python process that exposes port 61208,. The server listens on 127.0.0.1 by default, and the README says the RESTful API is not protected by default and points to its Advanced usage section for setting a password. The third constraint is platform variance. Glances advertises GNU/Linux, BSD, macOS and Windows, but sensors, container runtimes and per-process detail depend on what the host exposes. The only reliable check is running glances on the target and confirming the plugins you care about return values rather than empty dicts. Finally, GitHub's licence metadata reports NOASSERTION, but pyproject.toml declares LGPL-3.0-only and the repository has a COPYING file and a LICENSES directory. If you plan to redistribute Glances inside a product, read those terms first.

Glances against node_exporter: snapshot tool versus scrape target

The closest functional alternative for Linux fleet monitoring is Prometheus node_exporter. The difference in approach is not cosmetic. node_exporter is a stateless HTTP endpoint that Prometheus scrapes on an interval, and every scraped sample lands in a time-series database with a query language and an alerting layer on top. Glances is an application you look at, with a RESTful API and export modules bolted onto the same process that renders the dashboard. If you already run Prometheus, adding Glances as a second collector duplicates work unless you specifically want the interactive TUI or the MCP endpoint on the same hosts. If you do not run Prometheus and do not want to, Glances gives you the live view and the raw feed with one pip install and no server to operate. The honest framing is that they overlap on data collection and diverge on everything after it.

Release cadence, upgrade cost and the developing branch

The repository's default branch is develop, not main, and the last push recorded is 2026-11-01, and the README says that branch contains Glances 5.0.0 in beta while the current stable release is 4.5.8. Recent releases are v4.5.8 on 2026-10-11, v4.5.7 on 2026-09-26 and v4.5.6 on 2026-08-01, so the gap between tags ranges from about two to eight weeks. That pace is fast enough that pinning a version is worth doing if you depend on the RESTful API or the stdout field names, because both are the kind of surface that moves between minor releases. Upgrading is a pip install away, but the cost is not zero: the plugin field set is the API, and a renamed key breaks a script that parses glances --stdout-json cpu,mem. The MCP server is a recent addition, available in Glances 4.5.1 and higher per the README, so anything below that version simply does not have the endpoint regardless of configuration. On the licensing side, GitHub's metadata says NOASSERTION, but pyproject.toml declares LGPL-3.0-only; read the COPYING file and LICENSES directory in the source tree before you ship Glances inside anything.

Who should install it, and what to check on the first host

Glances earns its place on a workstation or a small set of servers where you want an interactive view and a scriptable feed from the same tool, and where you are willing to run a Python process on each monitored machine. It is also a reasonable choice if you are wiring an AI assistant into live system state, since the MCP server is a documented feature rather than a side project, though it requires --enable-mcp and Glances 4.5.1 or later. It is the wrong tool if your first requirement is retention and alerting, or if you cannot expose port 61208 on an internal network, or if the host is locked down to the point where installing Python packages is a change-control event. The first things to verify on a real host are mundane and specific. Run glances and confirm the plugins you need are populated. Run glances --stdout-json cpu,mem and check that the field names match what your parser expects. Run glances -w --enable-mcp and confirm http://<ip>:61208/mcp (or /mcp/sse for older clients) responds before pointing an assistant at it. Then decide whether the export target you need is a file, a time/value database or a pipe, because that choice, not the dashboard, determines how much of Glances you actually keep.

Editorial conclusion

Adopt Glances if you want a single Python package that gives you an interactive terminal view, a browser dashboard, a RESTful API and an MCP endpoint for AI assistants on GNU/Linux, BSD, macOS or Windows, and you are comfortable with the machine that collects the data also holding it in memory. Do not adopt it as a replacement for a time-series database and alerting stack, because the documented export targets are files, CSV, stdout and external time/value databases, not a query language or a rule engine. Before rolling it out, verify three things on your own hosts: that the plugins you need actually return data on your platform, that port 61208 is reachable and secured in client/server mode, and that the licence terms in the repository match how you intend to redistribute it, since GitHub's metadata reports NOASSERTION although pyproject.toml declares LGPL-3.0-only.

Frequently asked questions

Official sources

1. Issues
2. nicolargo/glances on GitHub
3. Project website
4. README
5. Releases