os-control-mcp

os-control-mcp is an MCP server — usable by any agent or MCP client (Claude Code, Cursor, Cline, Goose, Continue, your own MCP host, …) — that gives a model sanctioned control of a Linux host: manage systemd services and timers, query journald, read host resources and processes, send desktop notifications, drive the D-Bus buses, and manage power — all through the host's structured interfaces (systemctl, loginctl, journalctl, busctl), never raw kill/PID hacks. It is the system-service counterpart to screen-mcp's GUI control. Pure standard library, zero pip runtime deps. Linux + systemd.

Quickstart

Install the plugin in Claude Code:

/plugin marketplace add 88plug/os-control-mcp
/plugin install os-control-mcp@os-control-mcp

Then confirm the server loaded and its tools are available:

/mcp

No setup needed — it uses the host's existing systemd/D-Bus tooling. Run the os_diag tool first; it reports your privilege level and which backends are present.

⚠️ Treat this plugin as privileged. It can stop services and power off the machine. The guards below make that hard to do by accident, but install it deliberately and disable it via /plugin when you're not using it.

Use from any MCP client

It's a plain stdio MCP server — no Claude-Code lock-in. Point any MCP client at the launcher (or python3 server.py directly):

// e.g. Cursor / Cline / Goose / your own MCP host
{
  "mcpServers": {
    "os": { "command": "python3", "args": ["/path/to/os-control-mcp/server.py"] }
  }
}

It speaks MCP 2025-11-25 over stdio; the tools appear like any other MCP server.

Tools

Observe (read-only)

Tool	What
os_diag	health: privilege, backends, manager state, bus reachability, safety status
os_services	inspect units — list/status/show/cat/deps/files (system or user)
os_journal	journald — unit/since/until/priority/grep (server-side regex)/-k dmesg/boots/match
os_resources	load + memory + disk (+ optional per-unit accounting)
os_processes	top processes by cpu/mem
os_pressure	PSI from /proc/pressure — the real "is the box starving" signal
os_net	network — sockets (ss), ip addr/links/routes, wifi, NetworkManager
os_disk	storage — df, du (largest dirs), lsblk, mounts
os_containers	Docker/Podman — ps/logs/inspect/stats/images/compose
os_hardware	cpu/pci/usb/gpu (nvidia-smi + DRM) inventory
os_sensors	thermal-zone temperatures (+ lm_sensors if present)
os_session	logind sessions / users / inhibitors

Act (guarded)

Tool	What	Safety
os_service	start/stop/restart/reload/enable/disable/mask/kill/reset-failed/daemon-reload (single or batch)	hard floor + self-preservation guard; dry_run
os_wait	block until a unit is active/inactive/failed (or timeout)	—
os_power	suspend/hibernate/reboot/poweroff/halt	needs confirm=true; dry_run
os_time / os_hostname / os_locale	machine settings (timezone/NTP, hostname, locale/keymap)	writes need force=true; dry_run
os_dbus	list/tree/introspect/get-property/set-property/call (system or session bus)	writes need force=true; dry_run
os_notify	desktop notification to the logged-in user	—
os_reload	hot-reload the server in place	—

The guards (the whole point)

Human-in-the-loop, not model-in-the-loop. Every destructive action — severing a service (stop/kill/restart/disable/mask), power (reboot/poweroff/…), and D-Bus / machine-setting writes — is gated for a human's approval, in this order: