Manage RHEL with MCP servers and Red Hat Lightspeed

What we learned connecting 3 MCP servers to RHEL, Satellite, and Red Hat Lightspeed at Red Hat Summit

October 8, 2026
John Spinks
Related topics:
Artificial intelligence
Related products:
Red Hat Enterprise LinuxRed Hat SatelliteRed Hat Lightspeed

At the 2026 Red Hat Summit, we offered a hands-on lab titled "AI-powered Red Hat Enterprise Linux management: Get hands-on with Model Context Protocol (MCP) servers for Red Hat Lightspeed, Satellite, and Red Hat Enterprise Linux."

Whether you're a sysadmin running Linux infrastructure or a platform engineer automating Red Hat Enterprise Linux management across your hosts, running multiple MCP servers lets you query and manage your entire environment from one place.

Model Context Protocol (MCP) is an open standard that acts as a bridge between AI clients and infrastructure tools. Instead of giving an AI direct root access, an MCP server exposes safe, predefined APIs that an assistant (like goose) can query on your behalf. By connecting MCP servers to Red Hat Lightspeed, Red Hat Satellite, and Red Hat Enterprise Linux, sysadmins and platform engineers can query and manage infrastructure using natural language.

Note that these Model Context Protocol (MCP) servers are not generally available:

You might be wondering how Developer Preview and Technology Preview compare. Red Hat provides an article that explains the differences. Read Developer and Technology Previews: How they compare.

The lab put 3 MCP servers on the same system so participants could ask questions across Red Hat Lightspeed, Satellite, and Red Hat Enterprise Linux hosts at once. The combined view allowed participants to query host logs, Satellite inventory, and Red Hat Lightspeed recommendations in a single prompt.

If you'd like to see it in action, check out this demo: MCP Servers & RHEL Management

Inside the lab topology: Building the multi-server environment

During the session, participants frequently asked about our architecture, model choices, and setup steps. Here's how we built it.

Let's start with the lab itself. We had to deliver it in an environment provided by the Red Hat team that runs the hands-on labs. That meant certain architectural decisions were already made for us—probably much like they are in your environment.

We simulated an enterprise datacenter topology consisting of:

  • MCP host: 1 RHEL 10.1 server with 3 MCP servers and the goose client installed. This was the primary system used during the lab.
  • Satellite server: 1 Satellite 6.18 server on RHEL 9, configured with Red Hat Lightspeed in Satellite (on premise).
  • RHEL hosts: 4 RHEL 10.1 systems
  • 2 systems connected directly to the Hybrid Cloud Console
  • 2 systems connected to Satellite

Figure 1 shows the lab environment to help visualize this.

Infinicorp network layout with front-end RHEL hosts connected to Hybrid Cloud Console and back-end hosts connected to Red Hat Satellite.
Figure 1: Infinicorp segmented test environment architecture showing front-end and back-end RHEL host connections to Red Hat Lightspeed and Red Hat Satellite.

Setting up the MCP host for multi-server orchestration

Deploying 3 MCP servers on one system is remarkably straightforward: install the goose CLI, then follow the install instructions for each MCP server.

Prerequisites

You need a few packages on the system before you set up the MCP servers.

The most important is Podman. The MCP server for Red Hat Lightspeed and the MCP server for Red Hat Satellite both run as Podman containers, so you need Podman tools on the host.

The MCP server for Red Hat Enterprise Linux (RHEL) recommends installation with uv, which installs Python and other dependencies. You can also run the MCP server for RHEL as a Podman container if you prefer.

Install goose

You can install goose from the RHEL Extensions repository on RHEL 9.8 and RHEL 10.2 or later systems. For more details, see Supercharge RHEL troubleshooting with agentic AI: Introducing goose.

MCP server for Red Hat Lightspeed

Deploying the Red Hat Lightspeed MCP container requires minimal command-line work, though you'll need an organization administrator to create the required Hybrid Cloud Console service account.

The most complicated part of the setup is authentication. On the Hybrid Cloud Console, you need to create a service account, then assign a group of roles to that account. That's only complicated because you need an organization administrator, or a user with the User Access administrator role, to perform those steps. The steps themselves are well documented in the MCP server for Red Hat Lightspeed README.

There are no other installation steps. When you configure your client, it pulls the latest container image and authenticates using Podman commands.

MCP server for Red Hat Satellite

Continuing the pattern, the MCP server for Red Hat Satellite is also a simple install.

In addition to Podman, you need a successful login to registry.redhat.io. On the machine running the MCP server, you also need a copy of the CA bundle from the Satellite server.

Once you're logged in to registry.redhat.io and the CA bundle is on the host, you pull the container and run it.

To connect your client—in this case, goose—to the MCP server, you also need a personal access token (PAT). The MCP client uses that token to connect to the MCP server for Red Hat Satellite.

You generate the PAT from the Satellite user interface:

  1. Log in to Satellite.
  2. Select Administer → Users, select a user, then Personal Access Tokens → Add Personal Access Token.
  3. Name the token and select Confirm.
  4. Copy the token to a safe place. You'll need it when you configure the client.

MCP server for Red Hat Enterprise Linux

The MCP server for RHEL is also simple to install. The recommended path is to install and use uv, but the documentation offers a few options.

The key to getting it working is SSH. The MCP server for RHEL requires working SSH keys for every system you plan to manage.

The MCP server for RHEL also has an experimental feature called guarded command execution, which we used in the lab. Guarded command execution lets the client run approved scripts on the target system. You configure this entirely in the client—nothing extra is required at install time.

Summary of MCP server installation

Installing the MCP servers was straightforward. The real challenge lay in client configuration and model selection.

goose (client) configuration

With 3 MCP servers installed, you need to configure the client. How you do that varies a lot depending on the client and the MCP server. With goose, we primarily used the standard input/output (stdio) install type. Some MCP servers, such as Red Hat Lightspeed, have one-click setup options for certain clients. Those are documented with the MCP server.

Before configuring goose, pick an initial model to route your requests. While model evaluation deserves its own section later in this article, you'll need a provider API key ready during client setup.

goose lets you configure interactively, or you can edit the configuration file by hand. Editing the file is the path I recommend.

Each MCP server needs its own section in ~/.config/goose/config.yaml.

Here's the complete file from the lab environment, with the MCP server configurations and the model:

extensions:
  lightspeedmcp:
    enabled: true
    type: stdio
    name: Lightspeed MCP
    description: Lightspeed MCP
    cmd: /usr/bin/podman
    args:
    - run
    - --env
    - LIGHTSPEED_CLIENT_ID
    - --env
    - LIGHTSPEED_CLIENT_SECRET
    - --interactive
    - --rm
    - ghcr.io/redhatinsights/red-hat-lightspeed-mcp:latest
    envs: {}
    env_keys:
    - LIGHTSPEED_CLIENT_ID
    - LIGHTSPEED_CLIENT_SECRET
    timeout: 300
    bundled: null
    available_tools: []
  rhel-mcp-server:
    enabled: true
    type: stdio
    name: rhel-mcp-server
    description: RHEL MCP Server developer preview
    cmd: /home/lab-user/.local/bin/linux-mcp-server
    args: []
    envs:
      LINUX_MCP_ALLOWED_LOG_PATHS: /var/log/messages,/var/log/lastlog
      LINUX_MCP_TOOLSET: both
      LINUX_MCP_GATEKEEPER_MODEL: openai/minimax-m2
      OPENAI_API_BASE: [URL]
      OPENAI_API_KEY: [KEY]
    env_keys: []
    timeout: 30
    bundled: null
    available_tools: []
  satellitemcp:
    enabled: true
    type: streamable_http
    name: Satellite MCP
    description: satellite
    uri: http://0.0.0.0:8080/mcp/
    envs: {}
    env_keys: []
    headers:
      FOREMAN_TOKEN: [Personal Access Token]
      FOREMAN_USERNAME: [User]
    timeout: 300
    bundled: null
    available_tools: []
 
GOOSE_PROVIDER: [ADD PROVIDER]
GOOSE_TELEMETRY_ENABLED: false
GOOSE_MODEL: [ADD MODEL]
LITELLM_HOST: [ADD URL]
LITELLM_BASE_PATH: v1/chat/completions

When you look at the preceding file, you'll see a section for:

  • lightspeedmcp
  • rhel-mcp-server
  • satellitemcp

Those sections are taken almost directly from the installation docs with a few values updated that will be specific to your environment.

goose also has a secrets file for API keys and other secrets: ~/.config/goose/secrets.yaml.

LIGHTSPEED_CLIENT_ID: [ADD CLIENT ID]

LIGHTSPEED_CLIENT_SECRET: [ADD SECRET]

LINUX_MCP_ALLOWED_LOG_PATHS: /var/log/messages,/var/log/lastlog

LITELLM_API_KEY: [ADD API KEY]

You might notice both files mention the model and include LiteLLM entries. Let's talk about the model next.

What model should you use?

The biggest challenge for this lab was choosing a model. Model selection depends heavily on your latency tolerances, privacy requirements, and API throughput. Here's how our evaluation process led to our choices.

The models available to me were offered through LiteLLM. Running a model locally wasn't a good option in this environment. I tried early on, but the local models I was permitted to run didn't produce good results across the various MCP servers.

I think I tested close to 12 models across the 3 MCP servers. Some produced better results than others with specific servers. I used versions of Granite, Llama, Qwen, GPT-OSS, and a handful of others before landing on MiniMax M2 as the preferred model for this environment.

To evaluate model accuracy, we designed a diagnostic benchmark using queries where we already knew the proper answers:

  • What MCP servers do you have access to?
  • How many systems are in my Red Hat Lightspeed inventory?
  • How many systems are in my Satellite inventory?
  • What is the performance profile of rhel3?

These seem like basic questions, and they are. I knew the answers, which helped me spot misinformation or hallucinations.

One of the models told me how to form the API calls for the Red Hat Lightspeed inventory, but it wouldn't run the calls and give me an answer.

One of the models gave sample answers without running the query. The answers looked convincing, but the hostnames it returned didn't match anything in my environment. I eventually got it to admit the results were simulated. If I hadn't known better, I might have thought they were real.

Some models worked very well for 1 MCP server and poorly for others—because of performance, or because the responses weren't in line with what I expected.

Designing a deterministic lab experience around non-deterministic large language models (LLMs) is a fascinating engineering puzzle. Systems management requires exact, predictable outputs, whereas language models naturally explore probabilistic paths. Finding a model that consistently picked the right MCP tool without hallucinating hostnames took rigorous testing.

Finally, I landed on MiniMax M2 as the best model for this experience. Keep reading, because the model changes later in the story.

From testing to validation to Late Night Labs

Status check: The environment is set up and working. Three MCP servers are installed. One model is being used across all 3. A lab guide has been written, and we have a variety of exercises across all of the MCP servers. This is going well.

The lab is tested and validated, and we get to the main event: Red Hat Summit.

Tuesday night at Red Hat Summit, we host Late Night Labs, a room of people trying out various labs. Roughly 12 people took this lab throughout the night, and the feedback was great. They started at different times, picked whatever lab interested them, and asked really good questions.

This is where people started asking about how to install, what model to use, and the rest of the setup. Late Night Labs didn't have a presentation beforehand—only the guide.

The lab looked to be in great shape. Wednesday morning was the first offering to a full room of 60 participants.

Token limits: Learning a hard lesson, fast

For the first session, we had a full room: approximately 60 people plus our presenters. We got through the presentation—features, the model, the architecture—and turned participants loose on the lab. Five minutes into the session, hands shot up across the room as participants hit cryptic tool errors. After a flawless run at Late Night Labs, our team scrambled to inspect API gateway logs and figure out why 60 simultaneous prompts had suddenly paralyzed the environment.

Token limits are what happened.

The model we were using was hosted through Google on Vertex AI. That model had a token limit of 250 to 350 tokens per minute. With 60 people in the room all typing the same commands at the same time, we ran out of tokens really fast.

Some of the prompts were complex and consumed a large number of tokens. Others were simple and consumed less. The 12 or so people at Late Night Labs didn't have any trouble, because they were more spread out.

Luckily, the lab guide was full of screenshots and had good detail on what to expect. Participants got to play with goose, and some used the time to troubleshoot. Some people were able to progress through the lab, but most weren't.

I share this so you're aware of the hard lesson: know your model's token limits. If you're using a shared model, this isn't just what you're consuming. It can be what your team, department, or company is consuming.

We had to pivot before the next lab. Luckily, we had a little time.

Pivot to a new model

Once the lab concluded, I sat with the lab team and reviewed what happened and the best way to move forward. Because the MiniMax M2 model was on Vertex AI, we needed to work with Google to raise the tokens-per-minute limits. We put in a request, but we didn't have the ability to increase those limits ourselves.

We decided to change to a new model with a higher tokens-per-minute limit. We moved to Claude Opus 4.6, which has a 12-million-token-per-minute rate.

Because I had already done extensive testing on MiniMax M2 to make sure the lab worked across all 3 MCP servers, I had to retest the lab with the new model to verify everything still worked.

More lessons learned

During retesting, I encountered a second constraint: API budget limits.

The lab team had my API key limited to a $30 budget, which I exceeded during testing. Since we had already raised the tokens-per-minute limits, we also had to raise the budget limits.

The cost per token was significantly higher with Claude Opus 4.6 than with MiniMax M2—almost 10 times.

I also noticed Claude Opus 4.6 did more analysis than MiniMax M2. It pulled deeper details on the system, especially with the MCP server for RHEL, but that also meant responses took longer.

After completing the lab with a full set of testing, we decided it was ready for participants the next day.

As expected, the lab took a little longer to complete with the new model, but overall participants had a good experience and were able to finish with limited issues in subsequent sessions.

Summary

Running 3 MCP servers on one host isn't the hard part. In this lab, the MCP server for Red Hat Lightspeed, the MCP server for Red Hat Satellite, and the MCP server for RHEL all installed cleanly. The real work was authentication, client configuration, and choosing a model that behaved well across all 3 servers at once.

A few things to take into your own environment:

  • Installation is straightforward. Podman covers Red Hat Lightspeed and Satellite. The RHEL server is simplest with uv, and SSH keys must already work to every host you want to query. Follow each server's documentation rather than reinventing the setup.
  • Authentication requires the most setup work. Red Hat Lightspeed needs a Hybrid Cloud Console service account and the right roles. Satellite needs a registry.redhat.io login, the Satellite CA bundle, and a personal access token. RHEL needs working SSH keys. None of that is difficult, but each one has something that it needs that is different from the others.
  • The model matters as much as the servers. I'm not recommending a specific model for your environment. I landed on MiniMax M2 after testing about a dozen options, then had to move to Claude Opus 4.6 when a shared Vertex AI token limit collapsed the first full session.
  • Validate with questions you already know the answer to. Watch for models that explain the API instead of calling it, or that return convincing hostnames that aren't in your inventory.
  • Capacity is a lab and a production concern. Token-per-minute limits and API budgets aren't just your consumption. They are whatever your team, department, or company is already drawing from the same model. A setup that works for 12 people can fail for 60. A more capable model can also cost more and take longer per prompt.

Put together, these servers let you ask questions that span Hybrid Cloud Console inventory, Satellite, and the hosts themselves. The path to getting there is documented. Start with the install guides, then spend your time on the model and the limits—not on the containers.

Try this in your own environment

You don't need the Summit lab to get value from these servers. Install them, point your MCP client at them, and ask questions you already know the answers to.

  1. Install the MCP servers:
  2. Read the setup docs before you invent a config. Red Hat Lightspeed has a walkthrough on the Red Hat Developer blog. Satellite's procedure is in the product documentation linked previously. RHEL's usage guide covers client configuration and guarded command execution.
  3. Configure your client and a model, then test with known answers. Start with inventory counts and a single host profile. Confirm the servers are being called before you trust a longer analysis.
  4. Check token and budget limits up front—especially if more than 1 person will use the same model.

Ready to query your infrastructure with natural language? Explore the Red Hat Lightspeed MCP repository, follow the Satellite MCP configuration guide, or deploy the MCP server for RHEL on a test host to see what your inventory looks like through an MCP client.