Red Hat engineers connected three Model Context Protocol (MCP) servers to a single client system during a hands-on lab at the 2026 Red Hat Summit, letting participants query Red Hat Lightspeed, Red Hat Satellite, and Red Hat Enterprise Linux hosts from one place. The lab ran on a RHEL 10.1 server with the goose client and three MCP servers installed, plus a Satellite 6.18 server on RHEL 9 and four RHEL 10.1 hosts, two connected directly to the Hybrid Cloud Console and two to Satellite.
The MCP servers are not generally available. The servers for Red Hat Lightspeed and RHEL are in Developer Preview, and the Satellite server is in Technology Preview. Red Hat points to its own article explaining the difference between the two preview levels.
Setup and authentication
The MCP servers for Red Hat Lightspeed and Satellite run as Podman containers, so Podman tools are required on the host. The RHEL MCP server recommends installation with uv, which pulls in Python and dependencies, though it can also run as a container. The goose client installs from the RHEL Extensions repository on RHEL 9.8 and RHEL 10.2 or later.
Authentication is the most involved part. The Lightspeed MCP server needs a Hybrid Cloud Console service account, which an organization administrator or a user with the User Access administrator role must create and assign roles to. The Satellite MCP server requires a login to registry.redhat.io, a copy of the Satellite CA bundle on the host, and a personal access token generated from the Satellite user interface. The RHEL MCP server needs working SSH keys for every managed system.
The RHEL MCP server also has an experimental guarded command execution feature, which lets the client run approved scripts on target systems. Configuration happens entirely in the client, with nothing extra at install time.
Client configuration and model choice
The goose client configuration file at ~/.config/goose/config.yaml holds a section for each MCP server. The Lightspeed and Satellite servers use stdio and streamable_http transport types respectively, while the RHEL server uses stdio. A separate secrets file stores API keys and credentials. Red Hat recommends editing the configuration file by hand rather than using interactive setup.
Model selection was the biggest challenge in the lab. The engineers tested close to 12 models across the three MCP servers, including versions of Granite, Llama, Qwen, GPT-OSS, and others, before settling on MiniMax M2. Local models did not produce good results in that environment, so they used LiteLLM to route requests.
To evaluate accuracy, they built a diagnostic benchmark with queries where the answers were already known, such as how many systems appear in the Lightspeed inventory or what the performance profile of a specific host is. One model explained how to form API calls but would not execute them. Another returned convincing sample answers with hostnames that did not exist in the environment, and only admitted the results were simulated after being pressed. Some models worked well with one MCP server and poorly with others.
Red Hat notes that installing the MCP servers was straightforward, and the real difficulty lay in client configuration and model selection. The lab environment itself was constrained by the platform Red Hat uses for hands-on labs, so some architectural decisions were predetermined. Red Hat's article publishes the full goose configuration file from the lab, including environment variables for log paths, toolset selection, and the gatekeeper model used for guarded command execution.
Sources & references
Red Hat: Manage RHEL with MCP servers and Red Hat Lightspeed ↗Source consulted: 2026-10-15



