Feature Overview

The primary goal of this requirement is to enable EASY natural language interaction with the RHACM and Kubernetes APIs using Large Language Models (LLMs) and existing OCP MCP efforts.

This will empower users to query APIs for critical fleet information and perform actions using plain language, reducing the need to utilise complex API calls.

Users may use any Agentic AI tool, such as Cursor, Claude, OpenShift LightSpeed, etc.

Because RHACM utilizes a hub and spoke model it collects large amounts of fleet data locally on the hub cluster. We anticipate that the majority of these use cases can be met with the following:

• An MCP server (such as the OpenShift MCP server) deployed onto the hub using native Kubernetes/RHACM API resources (hub side CRDs like ManagedCluster, ManagedClusterView, and ManifestWork) without requiring the hub to store or directly use individual kubeconfig files for each managed cluster.
• The presence of an RHACM search specific MCP server that works directly with search data and makes it available to the OCP MCP server on the hub.
• The ability of the OCP MCP server to natively utilize RHACM constructs such as ClusterProxy to access managed clusters securely.
• The ability to add to the OCP MCP server to ensure future RHACM-specific constructs can be added.

Working document: https://docs.google.com/document/d/13NKtY8hK_GE62kfkOJKU68FzOZUkLg3-kUltzJK9nc0/edit?usp=sharing 

Goals

Provide customers the ability to connect an agentic AI to the OpenShift MCP server and gain full fleet accessibility for the tool.

Requirements

This Section: A list of specific needs or objectives that a Feature must
deliver to satisfy the Feature.. Some requirements will be flagged as MVP.
If an MVP gets shifted, the feature shifts. If a non MVP requirement slips,
it does not shift the feature.

(Optional) Use Cases

This Section:

• See https://docs.google.com/document/d/13NKtY8hK_GE62kfkOJKU68FzOZUkLg3-kUltzJK9nc0/edit?usp=sharing 

Questions to answer

• See https://docs.google.com/document/d/13NKtY8hK_GE62kfkOJKU68FzOZUkLg3-kUltzJK9nc0/edit?usp=sharing 
• Do we need an RHACM MCP "add-on" (or something else) to do any configuration of the OCP MCP server to work on a hub and communicate with the RHACM MCP Search, observability, or other future requirements or is a standard OCP MCP Operator install enough (preferred, we are using Kube APIs so hopefully this is simple).
• What are the use cases that necessitate the use of the RHACM add-on making an enhanced “multicluster MCP” an advantage/requirement.

Out of Scope

• See https://docs.google.com/document/d/13NKtY8hK_GE62kfkOJKU68FzOZUkLg3-kUltzJK9nc0/edit?usp=sharing 

Background, and strategic fit

As per https://issues.redhat.com/browse/OCPSTRAT-2079 

Assumptions

• We will use the OCP MCP server (https://issues.redhat.com/browse/OCPSTRAT-2079) 
• We will not be building a RHACM or Fleet-capable specific MCP server
• There will be a different specific MCP implementation for RHACM search/observability/etc
• We will do work on RHACM to enable the OCP MCP server to easily integrate.

Customer Considerations

• Customers should be able to implement the same OCP MCP server on their Hub as on standard OCP deployments. It should be "Fleet-aware" out of the box for ease of use.
• Customers should have simple documentation explaining how to use the OCP MCP server for fleet-wide operations.

Documentation Considerations

• Most documentation will be part of the main OCP MCP docs.
• Additional documentation on how customers can utilise fleet-specific features when need (such as in the demo: https://www.youtube.com/watch?v=3vnT79W5xCI) may be required.
• One major element of this Feature could be the inclusion of multicluster (fleet) specific prompts and logic that we offer the customer. This adds value and relevance over the standard OCP MCP docs that is related to the fleet use case.