Picture this: you're an application developer managing workloads on Red Hat OpenShift and you want to streamline your daily workflow. You need to monitor your workloads' health, detect incidents as they happen, fix them directly in your source of truth (GitHub), and have those changes automatically applied to your cluster through GitOps. All from a single platform, your OpenShift cluster, without jumping between tools.
That's exactly what I set out to build and what I will show you in this article. By connecting the GitHub MCP (Model Context Protocol) Server and the incident detection MCP server to OpenShift Lightspeed, I created a workflow where I can check my workloads' health, identify issues, push fixes to my repo, and let GitOps handle the rest, going from issue to fix in seconds, thanks to AI.
To give you some context, I'm working with an OpenShift cluster where I have the OpenShift Lightspeed instance up and running, connected to an LLM (GPT-4). I also have GitOps set up to deploy my workloads straight from my GitHub repo, so whenever I push a change, it gets applied automatically.
With that foundation in place and my sample app already deployed in the cluster, I'm ready to start exploring how to bring MCP into the mix.
Incident detection MCP server
You might know the panic of alert storms: dozens of alerts firing at once, and you're left trying to figure out which ones matter and what the root cause is. That's the problem that the incident detection feature in the cluster observability operator solves. It groups related alerts into incidents, shows them on a timeline color-coded by severity, and categorizes them by affected component. Instead of drowning in noise, you get a clear picture of what's happening.
Now, the interesting part: there's an MCP server that exposes this functionality. Here are the steps I followed to install the cluster observability operator, enable the Incidents feature, and deploy the MCP server:
1. Install Red Hat OpenShift cluster observability operator.
2. Install the Monitoring UI plug-in.
3. Deploy the incident detection MCP server directly into the OpenShift cluster.
oc apply -f https://raw.githubusercontent.com/openshift/cluster-health-analyzer/refs/heads/mcp-dev-preview/manifests/mcp/01_service_account.yamloc apply -f https://raw.githubusercontent.com/openshift/cluster-health-analyzer/refs/heads/mcp-dev-preview/manifests/mcp/02_deployment.yamloc apply -f https://raw.githubusercontent.com/openshift/cluster-health-analyzer/refs/heads/mcp-dev-preview/manifests/mcp/03_mcp_service.yaml4. A new Incidents dashboard becomes available in the OpenShift cluster under Observe → Alerting → Incidents.
For a detailed explanation on how to configure the full stack, refer to the following blog post: Incident detection for OpenShift tech preview is here
GitHub MCP server
Now that the incident detection MCP server is deployed, it's time to start with the second component: the Remote GitHub MCP Server. This MCP server will provide different toolsets to manage GitHub workflows remotely, meaning that there's no need to host the server either locally or in the cluster. However, to connect to the remote server, authentication is required. Here's the configuration needed:
1. In GitHub, navigate to Personal Access Token (PAT) settings. There, create your PAT classic token.
2. In the cluster, this PAT needs to be securely stored as a secret, so it can be used later to connect the MCP to the OpenShift Lightspeed instance:
oc create secret generic github-mcp-token --from-literal=header="Bearer <your-gh-token>" -n openshift-lightspeedThe current implementation relies on a shared GitHub token stored as a secret, effectively authenticating all users interacting with the MCP server under the same identity. This setup is viable for a proof of concept, but is not ideal for production environments. Additional solutions, such as an MCP gateway, would be required to support more granular, user-specific authentication.
OpenShift Lightspeed configuration
Now that both MCP servers are ready (the incident detection deployed in-cluster and the GitHub MCP accessible remotely), the final step is connecting them to OpenShift Lightspeed. Luckily, the custom MCP server configuration is quite simple and straightforward. I only had to add the following lines to my OLSConfig custom resource. In a matter of seconds, the operator was ready again, but this time with extended abilities, thanks to the two new MCP servers. Here you can find the lines I added:
...
spec:
featureGates:
- MCPServer
mcpServers:
- headers:
- name: Authorization
valueFrom:
secretRef:
name: github-mcp-token
type: secret
name: github-mcp-server
timeout: 30
url: 'https://api.githubcopilot.com/mcp/'
- headers:
- name: kubernetes-authorization
valueFrom:
type: kubernetes
name: cluster-health
timeout: 30
url: 'http://cluster-health-mcp-server.openshift-cluster-observability-operator.svc.cluster.local:8085/mcp'
ols:
introspectionEnabled: true
...As you can see, I only had to add two new stanzas. First, the featureGates.MCPServer to enable bringing custom MCPs into the AI assistant, and second the list of MCPs to include. Under each mcpServers item, the configuration requires specifying the name, URL, and the authorization header that can be either the Kubernetes one or a secret containing the header token.
Additionally, OpenShift Lightspeed provides a built-in MCP server enabled by default. This will allow the assistant to extract information from Kubernetes resources from the cluster.
Walking through a real incident
With all the components configured and running in 5 minutes, it's time to see the real value. Let me walk you through a practical scenario where OpenShift Lightspeed, powered by these 3 MCP servers, helps me identify, troubleshoot, and fix a production incident, all through natural language conversation.
Everything starts with a simple question such as "Are there any active incidents in my cluster?" (See Figure 1.)
Uh-oh! There's a problem with one of my workloads. But wait, how can OpenShift Lightspeed understand what's happening? Where is this information coming from? The Incident MCP server, of course, as shown in Figure 2.
Here I can see that the get_incidents tool was invoked and collected the information. OpenShift Lightspeed even provides me with a link to see the incident that is firing. Let's see it in the web console (Figure 3).
There it is. The alerting rule I configured to detect issues in my git-apps namespace has been triggered. Time to troubleshoot the issue. I'll start by identifying the failing pod by asking "Which pods are not running in the git-apps namespace?" (See Figure 4.)
Okay, there's something misconfigured in the sample-app-mcp application. It's still Pending and couldn't be assigned to any nodes. I'll check what's wrong in the web console and keep digging into the issue.
Next, I'll attach the full YAML pod configuration and enable the new troubleshooting mode. Now, let's let OpenShift Lightspeed figure out what's happening: "What's wrong with this pod?" (See Figure 5).
In just a few seconds OpenShift Lightspeed analyzes the YAML configuration and provides a response (Figure 6).
A common mistake: somebody introduced a typo in the YAML configuration. The nodeSelector is not correct and cannot be scheduled. In the same answer OpenShift Lightspeed provides the root cause and the fix.
Now, let's see what's the current structure in my source-of-truth repository to see where the fix should be placed. Without leaving my cluster, I can ask: "Can you now analyze the Git structure and contents? Use the pod annotations to find the repo info" (See Figure 7.)
How was OpenShift Lightspeed able to know what's the specific GitHub repo? Really simple. I have added that information as annotations inside the pod YAML (repo URL, path, branch, and so on).
Now I have a detailed explanation of all the components, and this is where the GitHub MCP server enters the scene for the first time. OpenShift Lightspeed invoked the get_file_contents tool to fetch the repo information.
With the root cause identified and the repository structure understood, it's time to apply the fix. I don't want to break anything, especially in production clusters, so a safe approach will be creating a new branch where the correct pod configuration will be added. All this with a simple query (Figure 8): "Open a new branch and add the fix to the nodeSelector"
The power of MCPs unchained. Three MCP tools in action to help me with my question: create_branch, get_file_contents, and create_or_update_file. The names are descriptive on what each of them do, but before merging it, I'll act as human in the loop and verify the changes with "Show me the updated file" (Figure 9).
My app manifest now contains the fixed nodeSelector. It's safe to open a new pull request (PR). I'll indicate the name of the PR and let the powerful large language model (LLM) generate the description, as shown in Figure 10: "Now, open a pull request titled 'Fix nodeSelector typo preventing pod scheduling'"
The response contains a link to the PR, but 1 of the advantages of MCP servers is being able to connect and manage different systems from a single place: my OpenShift cluster. So I prefer to check the PR from here (Figure 11): "Show me the details of the latest PR"
An accurate description. Everything is looking good: the title, the current and destination branches, the description, and of course, the correct app nodeSelector. Ready to apply the fix (Figure 12): "Please merge the PR #3"
With a simple query in natural language I have changed the configuration of my application. Easily, securely, and quickly, all my OpenShift clusters are now applying the fix automatically thanks to the GitOps magic. Finally, let's verify the app is correctly running by asking "Is the pod running now?" (See Figure 13.)
The application has been scheduled in the worker node and now it's running. The incident I detected a few minutes ago has been easily resolved, with assisted guidance, following all best practices and standards, and without leaving my cluster, where my workloads live.
Final thoughts
In this blog post, I built a workflow that traditionally requires jumping between the OpenShift console, GitHub UI, Prometheus dashboards, and oc commands. By connecting the incident detection and GitHub MCP servers to OpenShift Lightspeed, and combined with the built-in Observability MCP server, I made use of a unified OpenShift Lightspeed interface that handles the entire incident lifecycle through natural language conversation, from detection to deployment.
MCP servers transform OpenShift Lightspeed from an AI assistant into an intelligent orchestrator. The GitHub MCP provides source control management, the incident detection MCP server delivers observability insights, and the built-in MCP server enables cluster introspection. Together, they turn simple questions into sophisticated multi-system workflows, fundamentally changing how developers interact with their infrastructure.
