RHOAI MCP Server
Provides tools for managing Red Hat OpenShift AI environments, including project management, workbench operations (Jupyter), model serving with KServe, data connections, pipelines, storage, and training via Kubeflow.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@RHOAI MCP Serverlist my data science projects"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
RHOAI MCP Server
An MCP (Model Context Protocol) server that enables AI agents to interact with Red Hat OpenShift AI (RHOAI) environments. This server replicates the capabilities of the OpenShift AI Dashboard through programmatic tools.
Features
Project Management: Create, list, and manage Data Science Projects
Workbench Operations: Create, start, stop, and delete Jupyter workbenches
Model Serving: Deploy and manage InferenceServices with KServe
Data Connections: Manage S3 credentials for data access
Pipelines: Configure Data Science Pipelines infrastructure
Storage: Create and manage persistent volume claims
Training: Fine-tune models with Kubeflow Training Operator
MCP Prompts: Workflow guidance for multi-step operations (18 prompts)
Related MCP server: @morphixai/mcp-server
Technology Stack
Component | Technology | Purpose |
Runtime | Python 3.10+ | Core language |
MCP Framework | FastMCP 1.0+ | Model Context Protocol server |
Kubernetes Client | kubernetes-python 28.1+ | Cluster API interactions |
Data Validation | Pydantic 2.0+ | Type-safe models and settings |
HTTP Client | httpx 0.27+ | Async HTTP requests |
Container Base | Red Hat UBI 9 | Production container image |
Package Manager | uv | Fast Python dependency management |
Extending
Want to add your team's capabilities to rhoai-mcp? See the contributor guide for templates, documentation, and a working example domain.
Installation
For OpenShift installation, refer to OpenShift deployment.
Using uv (recommended)
# Clone the repository
git clone https://github.com/opendatahub-io/rhoai-mcp.git
cd rhoai-mcp
# Install dependencies
uv sync
# Run the server
uv run rhoai-mcpUsing pip
pip install -e .
rhoai-mcpUsing Container (Podman/Docker)
# Build the image
make build
# Run with HTTP transport
make run-http
# Run with STDIO transport (interactive)
make run-stdio
# Run with debug logging
make run-devOr run directly without Make:
# Build
podman build -f Containerfile -t rhoai-mcp:latest .
# Run with HTTP transport
podman run -p 8000:8000 \
-v ~/.kube/config:/opt/app-root/src/kubeconfig/config:ro \
-e RHOAI_MCP_AUTH_MODE=kubeconfig \
-e RHOAI_MCP_KUBECONFIG_PATH=/opt/app-root/src/kubeconfig/config \
rhoai-mcp:latest --transport sse
# Run with STDIO transport
podman run -it \
-v ~/.kube/config:/opt/app-root/src/kubeconfig/config:ro \
-e RHOAI_MCP_AUTH_MODE=kubeconfig \
-e RHOAI_MCP_KUBECONFIG_PATH=/opt/app-root/src/kubeconfig/config \
rhoai-mcp:latest --transport stdioAvailable Make targets:
Target | Description |
| Build the container image |
| Run with SSE transport on port 8000 |
| Run with streamable-http transport |
| Run with STDIO transport (interactive) |
| Run with debug logging |
| Run with token auth (requires TOKEN and API_SERVER) |
| Stop the running container |
| View container logs |
| Remove container and image |
Kubernetes Deployment
Deploy using Kustomize with environment-specific overlays:
# KIND / local development
kustomize build deploy/kustomize/overlays/kind/ | kubectl apply -f -
# OpenShift — see "OpenShift deployment" section belowThe Kustomize structure uses a shared base with per-environment overlays:
deploy/kustomize/
├── base/ # Shared resources (all environments)
│ ├── clusterrole.yaml # RBAC for RHOAI resources
│ ├── deployment.yaml # Hardened pod spec (non-root, read-only rootfs, probes)
│ ├── configmap.yaml # Default config (SSE transport, INFO logging)
│ └── ...
└── overlays/
├── kind/ # NodePort, DEBUG logging, imagePullPolicy: Never
... # other platform's overlaysThe KIND overlay enables debug logging, dangerous operations, NodePort service type, and imagePullPolicy: Never (for kind load docker-image).
OpenShift deployment
Two overlays are available, both configured with multi-user OIDC authentication:
1. MCP Lifecycle Operator (recommended)
For environments with the MCP Lifecycle Operator (MCPLO) installed.
The MCPLO operator manages the Deployment, Service, and NetworkPolicy from an MCPServer resource:
kustomize build deploy/kustomize/overlays/openshift-oidc-mcpserver | oc apply -f -2. GitOps / standalone
For environments without MCPLO, or where MCPLO is in Removed state:
kustomize build deploy/kustomize/overlays/openshift-oidc | oc apply -f -See deploy/kustomize/overlays/openshift-oidc/README.md for RBAC model, configuration details, and verification steps.
Model Catalog NetworkPolicy
When required, apply the NetworkPolicy to allow rhoai-mcp to connect to the RHOAI Model Catalog:
oc apply -f deploy/kustomize/overlays/openshift/networkpolicy.yamlConfiguration
The server can be configured via environment variables (with RHOAI_MCP_ prefix) or a .env file.
Authentication
The server supports three authentication modes for connecting to the Kubernetes API:
Auto (default): Tries in-cluster authentication first, falls back to kubeconfig
Kubeconfig: Uses a kubeconfig file
Token: Uses explicit API server URL and token
# Auto mode (default)
export RHOAI_MCP_AUTH_MODE=auto
# Kubeconfig mode
export RHOAI_MCP_AUTH_MODE=kubeconfig
export RHOAI_MCP_KUBECONFIG_PATH=/path/to/kubeconfig
export RHOAI_MCP_KUBECONFIG_CONTEXT=my-context
# Token mode
export RHOAI_MCP_AUTH_MODE=token
export RHOAI_MCP_API_SERVER=https://api.cluster.example.com:6443
export RHOAI_MCP_API_TOKEN=sha256~xxxxxFor multi-user deployments, the OpenShift OIDC overlays add caller-level authentication: each request's bearer token is validated via K8s TokenReview, a SubjectAccessReview pre-flight filters tools based on the caller's RBAC, and resource access is ultimately enforced by the K8s API against the caller's own token.
See deploy/kustomize/overlays/openshift-oidc/README.md for OIDC configuration details.
Transport
# stdio (default) - for Claude Desktop and similar tools
export RHOAI_MCP_TRANSPORT=stdio
# HTTP transports
export RHOAI_MCP_TRANSPORT=streamable-http
export RHOAI_MCP_HOST=127.0.0.1
export RHOAI_MCP_PORT=8000Safety Settings
# Enable delete of resources NOT created by rhoai-mcp (disabled by default)
export RHOAI_MCP_ENABLE_DANGEROUS_OPERATIONS=true
# Read-only mode (disable all write operations)
export RHOAI_MCP_READ_ONLY_MODE=trueBy default, delete operations are ONLY scoped to resources created by this server (labeled app.kubernetes.io/managed-by: rhoai-mcp).
Deleting resources created outside rhoai-mcp requires RHOAI_MCP_ENABLE_DANGEROUS_OPERATIONS=true.
Safety Features Summary
Feature | Description | Default |
Read-Only Mode | Disables all create/update/delete operations | Disabled |
Dangerous Operations Gate | Deletes restricted to resources created by rhoai-mcp; enable to allow deleting unmanaged resources | Disabled |
Confirmation Pattern | Delete tools require | Required |
Credential Masking | S3 secret keys are masked in all responses | Always |
RBAC-Aware | Uses OpenShift Projects API to respect user permissions | Always |
Auth Validation | Validates authentication configuration at startup | Always |
Workflow Tokens
Workflow tokens enforce ordering of multi-step MCP tool calls. When tools are decorated with @workflow_step, each step signs its output with an HMAC token that the next step must present and verify before executing. This prevents agents from skipping prerequisite steps.
# Set an explicit HMAC secret (recommended for production — tokens survive restarts)
export RHOAI_MCP_WORKFLOW_HMAC_SECRET=my-secret-key
# Adjust token time-to-live (default: 3600 seconds / 1 hour)
export RHOAI_MCP_WORKFLOW_TOKEN_TTL=1800Variable | Description | Default |
| HMAC secret for signing workflow tokens | Random per process |
| Token time-to-live in seconds |
|
If no secret is configured, a random one is generated at process startup. This means tokens are not portable across server restarts — suitable for development but not production deployments where long-running workflows may span restarts.
Model Registry
The MCP server integrates with the RHOAI Model Registry to list and query registered models. By default, it auto-discovers the Model Registry service in the cluster.
Discovery Modes
# Auto-discovery (default) - finds Model Registry in the cluster
export RHOAI_MCP_MODEL_REGISTRY_DISCOVERY_MODE=auto
# Manual - use a specific URL
export RHOAI_MCP_MODEL_REGISTRY_DISCOVERY_MODE=manual
export RHOAI_MCP_MODEL_REGISTRY_URL=https://model-registry.example.comAuthentication
When accessing the Model Registry via an external route (outside the cluster), authentication is typically required (OAuth for OAuth-proxied routes; explicit token auth is also supported):
# No authentication (default) - for in-cluster access
export RHOAI_MCP_MODEL_REGISTRY_AUTH_MODE=none
# OAuth authentication - uses your oc login token
export RHOAI_MCP_MODEL_REGISTRY_AUTH_MODE=oauth
# Explicit token authentication
export RHOAI_MCP_MODEL_REGISTRY_AUTH_MODE=token
export RHOAI_MCP_MODEL_REGISTRY_TOKEN=sha256~xxxxxAuth Mode | Description | Use Case |
| No authentication headers | In-cluster access via port 8080 |
| Uses OAuth token from kubeconfig | External route with OAuth proxy |
| Uses explicit bearer token | Service accounts, CI/CD |
External Route Access
To access the Model Registry from outside the cluster via an OpenShift Route:
# 1. Log in to OpenShift (this stores the OAuth token in kubeconfig)
oc login --server=https://api.cluster.example.com:6443
# 2. Configure the MCP server to use the external route with OAuth
export RHOAI_MCP_MODEL_REGISTRY_URL=https://model-catalog.apps.cluster.example.com
export RHOAI_MCP_MODEL_REGISTRY_DISCOVERY_MODE=manual
export RHOAI_MCP_MODEL_REGISTRY_AUTH_MODE=oauth
# 3. Optional: Skip TLS verification for self-signed certificates (not recommended)
# export RHOAI_MCP_MODEL_REGISTRY_SKIP_TLS_VERIFY=truePort-Forwarding Alternative
If no external route is available, you can use port-forwarding:
# Set up port-forwarding to the Model Registry service
kubectl port-forward -n rhoai-model-registries svc/model-catalog 8080:8443
# Configure the MCP server to use localhost
export RHOAI_MCP_MODEL_REGISTRY_URL=http://localhost:8080
export RHOAI_MCP_MODEL_REGISTRY_DISCOVERY_MODE=manualAll Model Registry Settings
Variable | Description | Default |
| Enable Model Registry integration |
|
| Model Registry service URL | Auto-discovered |
|
|
|
|
|
|
| Explicit bearer token (when auth_mode=token) | None |
| Request timeout in seconds |
|
| Skip TLS certificate verification |
|
Usage with agent harness
These examples connect an agent harness to a deployed rhoai-mcp server over HTTP.
Replace <RHOAI_MCP_ROUTE> with the Route URL of your deployment (e.g. oc get route rhoai-mcp -n rhoai-mcp -o jsonpath='{.spec.host}').
Claude Code
claude mcp add rhoai-mcp \
--scope project \
--transport http \
--url "https://<RHOAI_MCP_ROUTE>/mcp" \
--header "Authorization: Bearer \${OCP_TOKEN}"Then start Claude Code with the token:
OCP_TOKEN=$(oc whoami -t) claudeCodex
.codex/config.toml:
[mcp_servers.rhoai-mcp]
url = "https://<RHOAI_MCP_ROUTE>/mcp"
http_headers_helper = ".codex/rhoai-mcp-headers".codex/rhoai-mcp-headers (make executable with chmod +x):
#!/bin/sh
set -eu
token="$(oc whoami -t)"
printf '{"Authorization":"Bearer %s"}\n' "$token"Note: Codex caches http_headers_helper, then re-runs the helper after a same-origin 401 or 403.
Alternatively, do similar setup of exporting OCP_TOKEN, and setup config.toml to use the Env variable instead of http_headers_helper.
OpenCode
opencode.json:
{
"mcp": {
"servers": {
"rhoai-mcp": {
"type": "remote",
"url": "https://<RHOAI_MCP_ROUTE>/mcp",
"oauth": false,
"headers": {
"Authorization": "Bearer {env:OCP_TOKEN}"
}
}
}
}
}export OCP_TOKEN="$(oc whoami -t)"
opencode service restart
opencode reload
opencode mcp list
opencodePi
Install the MCP adapter first:
pi install npm:pi-mcp-adapter.mcp.json (project root):
{
"mcpServers": {
"rhoai-mcp": {
"url": "https://<RHOAI_MCP_ROUTE>/mcp"
}
}
}.pi/mcp.json (Pi-specific override for auth headers):
{
"mcpServers": {
"rhoai-mcp": {
"headers": {
"Authorization": "!.pi/oc-whoami-t-bearer"
}
}
}
}.pi/oc-whoami-t-bearer (make executable with chmod +x):
#!/bin/sh
exec printf 'Bearer %s\n' "$(oc whoami -t)"Note: the ! prefix in headers tells Pi to execute the script and use its stdout as the header value.
Local usage with agent harness
Local usage with Claude Code
Add to your project's .mcp.json file:
{
"mcpServers": {
"rhoai": {
"command": "uvx",
"args": ["--from", "git+https://github.com/opendatahub-io/rhoai-mcp", "rhoai-mcp"],
"env": {
"RHOAI_MCP_KUBECONFIG_PATH": "/home/user/.kube/config"
}
}
}
}Local usage with Claude Desktop
Add to your Claude Desktop configuration (~/.config/claude/claude_desktop_config.json):
{
"mcpServers": {
"rhoai": {
"command": "uvx",
"args": ["--from", "git+https://github.com/opendatahub-io/rhoai-mcp", "rhoai-mcp"],
"env": {
"RHOAI_MCP_KUBECONFIG_PATH": "/home/user/.kube/config"
}
}
}
}Local Development
For contributors working with a local clone:
{
"mcpServers": {
"rhoai": {
"command": "uv",
"args": ["run", "--directory", "/path/to/rhoai-mcp", "rhoai-mcp"],
"env": {
"RHOAI_MCP_KUBECONFIG_PATH": "/home/user/.kube/config"
}
}
}
}Local usage with Container Image (Podman/Docker)
First, build the container image:
make buildThen configure Claude Desktop with the container:
Podman:
{
"mcpServers": {
"rhoai": {
"command": "podman",
"args": [
"run", "-i", "--rm",
"--userns=keep-id",
"-v", "${HOME}/.kube/config:/opt/app-root/src/kubeconfig/config:ro",
"-e", "RHOAI_MCP_AUTH_MODE=kubeconfig",
"-e", "RHOAI_MCP_KUBECONFIG_PATH=/opt/app-root/src/kubeconfig/config",
"rhoai-mcp:latest"
]
}
}
}Docker:
{
"mcpServers": {
"rhoai": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-v", "${HOME}/.kube/config:/opt/app-root/src/kubeconfig/config:ro",
"-e", "RHOAI_MCP_AUTH_MODE=kubeconfig",
"-e", "RHOAI_MCP_KUBECONFIG_PATH=/opt/app-root/src/kubeconfig/config",
"rhoai-mcp:latest"
]
}
}
}Note: The container uses stdio transport by default, which is required for Claude Desktop integration.
Available Tools
Project Management (6 tools)
Tool | Description |
| List all RHOAI projects |
| Get project with resource summary |
| Create new project |
| Delete project (requires confirmation) |
| Get comprehensive project status |
| Set single vs multi-model serving |
Workbench Management (8 tools)
Tool | Description |
| List workbenches in project |
| Get workbench details |
| Create new workbench |
| Start a stopped workbench |
| Stop a running workbench |
| Delete workbench |
| List available images |
| Get OAuth-protected URL |
Model Serving (6 tools)
Tool | Description |
| List deployed models |
| Get model details |
| Create InferenceService |
| Delete deployed model |
| List available runtimes |
| Get inference endpoint URL |
Data Connections (4 tools)
Tool | Description |
| List connections in project |
| Get connection details (masked) |
| Create S3 connection |
| Delete connection |
Pipelines (3 tools)
Tool | Description |
| Get DSPA status |
| Create DSPA |
| Delete DSPA |
Storage (3 tools)
Tool | Description |
| List PVCs in project |
| Create PVC |
| Delete PVC (requires confirmation) |
MCP Resources
The server also exposes read-only resources:
Resource URI | Description |
| Cluster health and RHOAI status |
| DataScienceCluster component status |
| Available GPU profiles |
| Project resource summary |
| Workbench list with status |
| Deployed models with status |
MCP Prompts
The server provides 18 prompts that guide AI agents through multi-step workflows. Prompts are templates that provide step-by-step instructions and reference the appropriate tools for each workflow stage.
Training Workflow (3 prompts)
Prompt | Description |
| Guide through fine-tuning a model with LoRA/QLoRA |
| Monitor an active training job and diagnose issues |
| Resume a suspended or failed training job from checkpoint |
Cluster Exploration (4 prompts)
Prompt | Description |
| Discover what's available in the RHOAI cluster |
| Explore resources within a specific Data Science Project |
| Find available GPU resources for training or inference |
| Quick status check of all active workloads |
Troubleshooting (4 prompts)
Prompt | Description |
| Diagnose and fix issues with a training job |
| Diagnose and fix issues with a workbench |
| Diagnose and fix issues with a deployed model |
| Analyze and resolve Out-of-Memory issues in training |
Project Setup (3 prompts)
Prompt | Description |
| Set up a new project for model training |
| Set up a new project for model serving |
| Add an S3 data connection to an existing project |
Model Deployment (4 prompts)
Prompt | Description |
| Deploy a model for inference serving |
| Deploy a Large Language Model with vLLM or TGIS |
| Test a deployed model endpoint |
| Scale a model deployment up or down |
Example Interactions
Create a Data Science Project
User: Create a new data science project called "fraud-detection" for my ML experiments
Agent: I'll create that project for you with a descriptive display name.
[Calls create_data_science_project with name="fraud-detection",
display_name="Fraud Detection ML", description="Machine learning experiments for fraud detection"]
Result: Project 'fraud-detection' created successfullyDeploy a Model
User: Deploy my trained fraud model from S3 to the fraud-detection project
Agent: I'll deploy your model. First, let me check available serving runtimes.
[Calls list_serving_runtimes with namespace="fraud-detection"]
[Calls deploy_model with name="fraud-model", namespace="fraud-detection",
runtime="ovms", model_format="onnx",
storage_uri="s3://models/fraud-detection/model.onnx"]
Result: Model 'fraud-model' deployment initiated. It may take a few minutes to become ready.Check Project Status
User: What's the status of my fraud-detection project?
Agent: [Calls get_project_status with namespace="fraud-detection"]
Result:
- Project: fraud-detection (Fraud Detection ML)
- Workbenches: 2 total, 1 running
- Models: 1 deployed, 1 ready
- Pipeline Server: Ready
- Data Connections: 1
- Storage: 3 PVCsDevelopment
Running Tests
# Install dev dependencies
uv sync --group dev
# Run tests
uv run pytest
# Run with coverage
uv run pytest --cov=rhoai_mcpCode Quality
# Format code
uv run ruff format
# Lint
uv run ruff check
# Type check
uv run mypy src/rhoai_mcpArchitecture
┌─────────────────────────────────────────────────────────────────┐
│ MCP Transport Layer (stdio/SSE/HTTP) │
├─────────────────────────────────────────────────────────────────┤
│ FastMCP Server (server.py) │
│ - Tool registration - Resource registration │
│ - Prompt registration - Lifecycle management │
├───────────────────┬─────────────────────┬───────────────────────┤
│ Tools Layer │ Resources Layer │ Prompts Layer │
│ - projects │ - cluster.py │ - training (3) │
│ - notebooks │ - projects.py │ - exploration (4) │
│ - inference │ │ - troubleshooting (4)│
│ - connections │ │ - project setup (3) │
│ - storage │ │ - deployment (4) │
│ - pipelines │ │ │
│ - training │ │ │
├───────────────────┴─────────────────────┴───────────────────────┤
│ Clients Layer (clients/) - Business Logic │
│ - base.py (K8sClient) - projects.py - notebooks.py │
│ - inference.py - connections.py - storage.py │
│ - pipelines.py - training.py │
├─────────────────────────────────────────────────────────────────┤
│ Models Layer (models/) - Pydantic Data Structures │
│ - common.py (shared) - Domain-specific models per resource │
├─────────────────────────────────────────────────────────────────┤
│ Infrastructure Layer │
│ - K8sClient: Kubernetes API abstraction (Core + CRDs) │
│ - Configuration: Environment-based settings │
│ - Plugin Manager: Pluggy-based plugin system │
└─────────────────────────────────────────────────────────────────┘Directory Structure
Directory | Purpose |
clients/ | Kubernetes client abstractions for each resource type |
models/ | Pydantic models for type-safe resource handling |
tools/ | MCP tool definitions that wrap client operations |
resources/ | MCP resource definitions for read-only data access |
utils/ | Helper functions for annotations, labels, and errors |
Request Flow
AI Agent Request → MCP Transport → Tool Handler → Domain Client
↓
AI Agent Response ← Pydantic Model ← K8s Response ← K8sClient → Kubernetes APIKey CRDs Supported
Resource | API Group | Purpose |
Namespace | core/v1 | Data Science Projects |
Notebook | kubeflow.org/v1 | Workbenches |
InferenceService | serving.kserve.io/v1beta1 | Model serving |
ServingRuntime | serving.kserve.io/v1alpha1 | Model server configs |
DataSciencePipelinesApplication | datasciencepipelinesapplications.opendatahub.io/v1alpha1 | Pipeline infrastructure |
AcceleratorProfile | dashboard.opendatahub.io/v1 | GPU profiles |
License
MIT License - see LICENSE for details.
This server cannot be deployed
Maintenance
Related MCP Connectors
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Related MCP Servers
- FlicenseBqualityDmaintenanceAn MCP server for managing multiple OpenShift Container Platform (OCP) clusters through AI assistants.77-
- AlicenseNot gradedqualityCmaintenanceMCP server enabling AI agents to interact with workplace tools like GitHub, GitLab, Jira, Notion, and more via the Model Context Protocol.1MIT
- FlicenseBqualityDmaintenanceAn MCP server that enables AI assistants to interact with Azure DevOps projects, work items, repositories, pipelines, wikis, and more via 21 tools.21-
- AlicenseAqualityBmaintenanceA universal MCP server that provides AI agents with structured tools for filesystem, database, shell, and git operations, enabling seamless interaction with projects.19MIT