Write tools are off until you set `UYUNI_MCP_WRITE_TOOLS_ENABLED`, which means the safe configuration is the one you get without reading the documentation — the right way round for a server that can reboot production machines. Two combinations to avoid: write tools plus HTTP transport, which lets anything on the network act on your fleet, and HTTP transport without `UYUNI_AUTH_SERVER`, which runs with no authentication at all. Give it a Uyuni account with the minimum role rather than `admin`, and put a TLS-terminating proxy in front of the HTTP mode. The summary tools exist because fleet-wide answers are large — reach for those first and expand only where you need detail.
An MCP server for Uyuni, the configuration and infrastructure management platform. It exposes the questions a system administrator asks daily — which machines exist, what patches are pending, which systems are exposed to a given CVE, what needs a reboot — plus the actions that follow, gated behind a setting that is off by default.
- The fleet enumerated and searched: active systems with names and ids, detail on one system, its event history and any single event, and lookup by hostname or IP — `list_systems`, `get_system_details`, `get_system_event_history`, `get_system_event_details`, `find_systems_by_name`, `find_systems_by_ip`
- Pending updates for one system in full, as low-token summary counts, or paginated with optional CVE expansion and an advisory-type filter — `get_system_updates`, `summarize_system_updates`, `query_system_updates`
- The same question across the whole fleet, in full or as a paginated summary — `check_all_systems_for_updates`, `summarize_fleet_updates`
- Exposure answered directly: which systems need a security update for a named CVE, which need a reboot, and which patches are applicable but not yet scheduled — `list_systems_needing_update_for_cve`, `list_systems_needing_reboot`, `get_unscheduled_errata`
- System groups listed with their members, created, and systems added or removed — `list_system_groups`, `list_group_systems`, `create_system_group`, `add_systems_to_group`, `remove_systems_from_group`
- Actions scheduled and unscheduled: all pending updates on a system, one specific erratum, a reboot, and cancellation of anything already queued — `schedule_pending_updates_to_system`, `schedule_specific_update`, `schedule_system_reboot`, `cancel_action`, `list_all_scheduled_actions`
- New machines bootstrapped with an activation key, and decommissioned systems removed from management — `list_activation_keys`, `add_system`, `remove_system`
A Uyuni server reachable at `UYUNI_SERVER`, and credentials for it: `UYUNI_USER` and `UYUNI_PASS` for local deployments, or an OAuth 2.0 identity provider named in `UYUNI_AUTH_SERVER` for HTTP deployments — which additionally requires Uyuni's own OIDC support to be configured. Everything that changes state is disabled until `UYUNI_MCP_WRITE_TOOLS_ENABLED` is set to true. Stdio is the default transport; `UYUNI_MCP_TRANSPORT=http` with `UYUNI_MCP_HOST`, `UYUNI_MCP_PORT` and `UYUNI_MCP_PUBLIC_URL` runs it as a network server. Bootstrapping new systems needs an SSH private key in `UYUNI_SSH_PRIV_KEY`, as a single line with newlines written as `\n`. The package is `mcp-server-uyuni` (0.6.1 in pyproject) or the container at `ghcr.io/uyuni-project/mcp-server-uyuni`. Licensed Apache 2.0.
One command plus a key — docker run --env-file /path/to/uyuni-config.env -p 8080:8080 ghcr.io/uyuni-project/mcp-server-uyuni:latest, then supply credentials