AI-powered SRE observability for Kubernetes/OpenShift with 40+ Tekton debugging tools
AI-powered SRE observability for Kubernetes/OpenShift with 40+ Tekton debugging tools
Valid MCP server (1 strong, 3 medium validity signals). 5 known CVEs in dependencies Package registry verified. Imported from the Official MCP Registry.
3 files analyzed Β· 6 issues found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
Set these up before or after installing:
Environment variable: KUBECONFIG
Add this to your MCP configuration file:
{
"mcpServers": {
"io-github-geored-lumino": {
"env": {
"KUBECONFIG": "your-kubeconfig-here"
},
"args": [
"lumino-mcp-server"
],
"command": "uvx"
}
}
}From the project's GitHub README.
An open source MCP (Model Context Protocol) server empowering SREs with intelligent observability, predictive analytics, and AI-driven automation across Kubernetes, OpenShift, and Tekton environments.
LUMINO MCP Server transforms how Site Reliability Engineers (SREs) and DevOps teams interact with Kubernetes clusters. By exposing 39 specialized tools through the Model Context Protocol, it enables AI assistants to:
Get started with LUMINO in under 2 minutes:
Simply ask Claude Code to provision the Lumino MCP server for you by pasting this prompt:
Provision the Lumino MCP server as a project-local MCP integration:
1. Clone the repository:
git clone https://github.com/spre-sre/lumino-mcp-server.git
2. Install Python dependencies using uv:
cd lumino-mcp-server && uv sync
3. Create .mcp.json in the current project root (NOT inside lumino-mcp-server) with this configuration.
IMPORTANT: Replace <ABSOLUTE_PATH_TO_LUMINO> with the actual absolute path to the cloned lumino-mcp-server directory:
{
"mcpServers": {
"lumino": {
"type": "stdio",
"command": "<ABSOLUTE_PATH_TO_LUMINO>/.venv/bin/python",
"args": ["<ABSOLUTE_PATH_TO_LUMINO>/main.py"],
"env": {
"PYTHONUNBUFFERED": "1"
}
}
}
}
4. After creating .mcp.json, inform the user to:
- Exit Claude Code completely
- Connect to their Kubernetes or OpenShift cluster (kubectl/oc login)
- Restart Claude Code in this project directory
- They will see a prompt to approve the Lumino MCP server
- Once approved, Lumino tools will be available (check with /mcp command)
Choose your preferred installation method:
mcpm install @spre-sre/lumino-mcp-serverOnce installed, test with a simple query:
"List all namespaces in my Kubernetes cluster"
# Clone the repository
git clone https://github.com/spre-sre/lumino-mcp-server.git
cd lumino-mcp-server
# Install dependencies
uv sync
# Run the server
uv run python main.py
# Clone the repository
git clone https://github.com/spre-sre/lumino-mcp-server.git
cd lumino-mcp-server
# Create virtual environment
python -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activate
# Install dependencies
pip install -e .
# Run the server
python main.py
By default, the server runs in local mode using stdio transport, suitable for direct integration with MCP clients:
python main.py
When running inside Kubernetes, set the namespace environment variable to enable HTTP streaming:
export KUBERNETES_NAMESPACE=my-namespace
python main.py
The server automatically detects the environment and switches transport modes.
Investigate and diagnose complex failures with automated analysis:
"Generate a comprehensive RCA report for the failed pipeline run 'build-api-pr-456' in namespace ci-cd"
"Analyze what caused pod crashes in namespace production over the last 6 hours and correlate with resource events"
"Investigate the TLS certificate issues affecting services in namespace ingress-nginx"
Anticipate problems before they impact your systems:
"Predict resource bottlenecks across all production namespaces for the next 48 hours"
"Analyze historical pipeline performance and detect anomalies in build times for the last 30 days"
"Check cluster certificate health and alert me about any certificates expiring in the next 60 days"
"Use predictive log analysis to identify potential failures in namespace monitoring before they occur"
Test changes safely before applying them to production:
"Simulate the impact of increasing memory limits to 4Gi for all pods in namespace backend-services"
"Run a what-if scenario for scaling deployments to 10 replicas and analyze resource consumption"
"Simulate configuration changes for nginx ingress controller and assess risk to existing traffic"
Understand system architecture and component relationships:
"Generate a live topology map of all services, deployments, and their dependencies in namespace microservices"
"Map the complete dependency graph for the payment-service including all connected resources"
"Show me the topology of components affected by the cert-manager service"
Deep-dive into complex issues with multi-faceted analysis:
"Perform an adaptive namespace investigation for production - analyze logs, events, and resource patterns"
"Create a detailed investigation report for resource constraints and bottlenecks in namespace data-processing"
"Trace pipeline execution for commit SHA abc123def from source to deployment across all namespaces"
"Search logs semantically for 'authentication failures related to expired tokens' across the last 24 hours"
Optimize and troubleshoot your continuous delivery pipelines:
"Establish performance baselines for all Tekton pipelines and flag runs deviating by more than 2 standard deviations"
"Trace the complete pipeline flow for image 'api:v2.5.3' from build to production deployment"
"Analyze failed pipeline runs in namespace tekton-pipelines and identify common failure patterns"
"Compare current pipeline run times against 30-day baseline and highlight performance degradation"
Multi-level event investigation from overview to deep-dive:
"Start with an overview of events in namespace kube-system, then drill down into critical issues"
"Perform advanced event analytics with ML pattern detection for namespace monitoring over the last 12 hours"
"Correlate events with pod logs to identify the root cause of CrashLoopBackOff in namespace applications"
Stay informed about cluster health and pipeline status:
"Show me the status of all Tekton pipeline runs cluster-wide and highlight long-running pipelines"
"List all failed TaskRuns in the last hour with error details and recommended actions"
"Monitor OpenShift cluster operators and alert on any degraded components"
"Check MachineConfigPool status and show which nodes are being updated"
Ensure cluster security and certificate management:
"Scan all namespaces for expiring certificates and generate a renewal schedule"
"Investigate TLS certificate issues causing handshake failures in namespace istio-system"
"Audit all secrets and configmaps for sensitive data exposure patterns"
Leverage machine learning for pattern detection:
"Use streaming log analysis to process large log volumes from namespace data-pipeline with error pattern detection"
"Detect anomalies in log patterns using ML analysis with medium severity threshold for namespace api-gateway"
"Analyze resource utilization trends using Prometheus metrics and forecast capacity needs"
The server automatically detects Kubernetes configuration:
~/.kube/config)| Variable | Description | Default | When to Use |
|---|---|---|---|
KUBERNETES_NAMESPACE | Namespace for K8s mode | - | When running server inside a Kubernetes pod |
K8S_NAMESPACE | Alternative namespace variable | - | Alternative to KUBERNETES_NAMESPACE |
PROMETHEUS_URL | Prometheus server URL for metrics | Auto-detected | Custom Prometheus endpoint or non-standard port |
KUBECONFIG | Path to kubeconfig file | ~/.kube/config | Multiple clusters or custom kubeconfig location |
LOG_LEVEL | Logging verbosity (DEBUG, INFO, WARNING, ERROR) | INFO | Debugging issues or reducing log noise |
MCP_SERVER_LOG_LEVEL | MCP framework log level | INFO | Troubleshooting MCP protocol issues |
PYTHONUNBUFFERED | Disable Python output buffering | - | Recommended for MCP clients to see real-time logs |
KUBEARCHIVE_HOST | Explicit KubeArchive API endpoint URL | Auto-detected | Custom KubeArchive endpoint or non-standard deployment |
KUBEARCHIVE_ENABLED | Enable/disable KubeArchive integration | true | Set to false to disable KubeArchive queries entirely |
THANOS_URL | Thanos Query endpoint URL (highest priority for metrics) | Auto-detected | Custom Thanos Query endpoint; takes precedence over PROMETHEUS_URL |
PROMETHEUS_TOKEN | Bearer token for Prometheus/Thanos authentication | Auto-detected | Explicit auth token when auto-detection fails |
OPENSHIFT_TOKEN | OpenShift bearer token for Prometheus/Thanos | Auto-detected | Alternative to PROMETHEUS_TOKEN for OpenShift clusters |
OC_TOKEN | OpenShift CLI token fallback | Auto-detected | Last-resort token fallback for Prometheus/Thanos auth |
The predictive_log_analyzer tool persists trained ML models and training data locally in ~/.lumino/. This enables model reuse across server restarts and incremental learning from historical failure patterns.
~/.lumino/
βββ models/ # Trained ML models
β βββ {model_id}.joblib # Serialized model (e.g. IsolationForest via joblib)
β βββ {model_id}.meta.json # Model metadata (created, last used, performance metrics)
β βββ model_index.json # Index tracking all models and the current active model
βββ training_data/ # Training data store
βββ training_data.db # SQLite database
Model IDs follow the pattern predictive_log_v1_YYYYMMDD_HHMMSS.
The SQLite database (training_data.db) contains four tables:
| Table | Purpose |
|---|---|
log_samples | Preprocessed log samples with extracted features, namespace, pod name, error indicators, and message entropy |
failure_labels | Failure events collected from Kubernetes events, failed PipelineRuns, and unhealthy pod statuses. Failure types include: oom, crash, image, scheduling, storage, config, health, network, timeout, pipeline_failure, permission, resource_limits, general, pod_failure |
log_failure_correlations | Time-proximity correlations between log samples and failure events (scored 0.5--1.0 based on temporal distance within a 30-minute window) |
training_runs | Training run history recording model_id, samples used, labels used, performance metrics, and completion status |
All four tables define a cluster_id column for multi-cluster support. Currently, only log_samples and failure_labels actively populate it during writes; log_failure_correlations and training_runs leave it NULL. The cluster ID is derived from the active kubeconfig context name (e.g. api-stone-prod-p02-hjvn-p1-openshiftapps-com:6443) or falls back to in-cluster-{KUBERNETES_SERVICE_HOST} when running inside a pod.
Programmatic cleanup via the manage_prediction_training_data tool (action cleanup):
cleanup_old_models(max_age_days=30, keep_min=3) -- removes models older than 30 days, always keeping the 3 most recentcleanup_old_data(max_age_days=90) -- removes log samples, failure labels, and correlations older than 90 daysManual cleanup:
rm -rf ~/.lumino/ # Clear everything (models + training data)
rm -rf ~/.lumino/models/ # Clear just models
rm -rf ~/.lumino/training_data/ # Clear just training data (SQLite DB)
Disk usage note: Models accumulate over time. The default cleanup keeps models up to 30 days old with a minimum of 3 retained. Training data is kept for 90 days. Run the manage_prediction_training_data tool with action cleanup periodically to reclaim disk space.
KubeArchive stores Kubernetes resources off-cluster and provides a REST API for historical resource states and logs. LUMINO uses KubeArchive as a fallback when pods, PipelineRuns, or TaskRuns have been garbage-collected from the live cluster. The query_kubearchive tool queries this archive transparently.
The endpoint is discovered automatically using a 5-step chain (first match wins):
KUBEARCHIVE_HOST environment variable (highest priority)kubearchive-api-server in namespaces: kubearchive, product-kubearchive, defaultkubearchive-api-server in the same namespaceskubearchive-api-server (in-cluster DNS: https://kubearchive-api-server.<namespace>.svc.cluster.local:<port>)https://kubearchive-api-server-{namespace}.apps.{cluster-domain}) and probes /livezResults are cached at startup. On connection failure, the cache is cleared and re-probed on the next request.
When running outside the cluster, if an in-cluster Service endpoint is discovered (step 4), LUMINO automatically sets up kubectl port-forward:
kubectl port-forward -n {namespace} svc/kubearchive-api-server {local_port}:{remote_port}
kubectl is not available, LUMINO logs a manual fallback command for the userKubeArchive authentication uses the following priority chain:
/var/run/secrets/kubernetes.io/serviceaccount/token)oc whoami -t token (for OpenShift clusters)kubectl create token, 1-hour duration, Kubernetes only)See the Configuration section above for KUBEARCHIVE_HOST and KUBEARCHIVE_ENABLED environment variables.
LUMINO auto-discovers Prometheus or Thanos Query endpoints for the prometheus_query, resource_bottleneck_forecaster, and ci_cd_performance_baselining_tool tools. Thanos Query implements the Prometheus HTTP API and is preferred when available since it provides a unified, deduplicated view across replicas.
| Priority | Source | Endpoint Type |
|---|---|---|
| 0 | THANOS_URL env var | thanos |
| 1 | PROMETHEUS_URL env var | prometheus |
| 2 | Predefined cluster endpoints (in code) | varies |
| 3 | 5-minute TTL cache | cached |
| 4 | Auto-discovery chain (see below) | detected |
| 5 | Predefined fallback endpoints | varies |
Auto-discovery order depends on runtime environment:
OpenShift Routes: Searches the openshift-monitoring namespace. Prefers the thanos-querier route over prometheus-k8s. Falls back to any route with prometheus in the name. Detects protocol from TLS termination config.
Thanos Services: Searches namespaces openshift-monitoring, monitoring, thanos, observability, kube-prometheus. Priority service names: thanos-query-frontend, thanos-querier, thanos-query. Also searches via label selectors: app.kubernetes.io/name=thanos-query, app.kubernetes.io/component=query,app.kubernetes.io/name=thanos, app=thanos-query, app=thanos-querier.
Prometheus Services: Searches namespaces openshift-monitoring, monitoring, prometheus, kube-prometheus, observability. Priority service names: prometheus-server, prometheus-k8s, prometheus. Also searches via label selectors: app=prometheus, app.kubernetes.io/name=prometheus, app.kubernetes.io/component=prometheus.
Prometheus Operator CRD: Discovers via monitoring.coreos.com/v1 Prometheus custom resources and their associated services (pattern: prometheus-{name} in the same namespace).
Authentication for Prometheus/Thanos uses the following 5 methods in priority order:
oc whoami -t -- fresh OpenShift token (most reliable for OpenShift)/var/run/secrets/kubernetes.io/serviceaccount/token)PROMETHEUS_TOKEN, OPENSHIFT_TOKEN, OC_TOKEN (checked in that order){
"env": {
"THANOS_URL": "https://thanos-querier.example.com",
"PROMETHEUS_TOKEN": "your-bearer-token"
}
}
Note: The endpoint cache has a 5-minute TTL. If you change THANOS_URL or PROMETHEUS_URL at runtime, the new value takes effect on the next query.
| Tool | Description |
|---|---|
list_namespaces | List all namespaces in the cluster |
list_pods_in_namespace | List pods with status and placement info |
get_kubernetes_resource | Get any Kubernetes resource with flexible output |
search_resources_by_labels | Search resources across namespaces by labels |
query_kubearchive | Query archived Kubernetes resources from KubeArchive with optional log retrieval |
| Tool | Description |
|---|---|
list_pipelineruns | List PipelineRuns with status and timing |
list_taskruns | List TaskRuns, optionally filtered by pipeline |
get_pipelinerun_logs | Retrieve pipeline logs with optional cleaning |
list_recent_pipeline_runs | Recent pipelines across all namespaces |
find_pipeline | Find pipelines by pattern matching |
get_tekton_pipeline_runs_status | Cluster-wide pipeline status summary |
| Tool | Description |
|---|---|
analyze_logs | Extract error patterns from log text |
smart_summarize_pod_logs | Intelligent log summarization |
stream_analyze_pod_logs | Streaming analysis for large logs |
analyze_pod_logs_hybrid | Combined analysis strategies |
detect_log_anomalies | Anomaly detection with severity levels |
semantic_log_search | NLP-based semantic log search |
templatize_pod_logs | Cluster logs into unique structural templates using Drain3 (requires optional logan dependency) |
deep_analyze_pod_logs | Classify log templates into golden signals and fault categories using zero-shot ML (requires optional logan dependency) |
| Tool | Description |
|---|---|
smart_get_namespace_events | Smart event retrieval with strategies |
progressive_event_analysis | Multi-level event analysis |
advanced_event_analytics | ML-powered event pattern detection |
| Tool | Description |
|---|---|
analyze_failed_pipeline | Root cause analysis for failed pipelines |
automated_triage_rca_report_generator | Automated incident reports |
| Tool | Description |
|---|---|
check_resource_constraints | Detect resource issues in namespace |
detect_anomalies | Statistical anomaly detection |
prometheus_query | Execute PromQL queries |
resource_bottleneck_forecaster | Predict resource exhaustion |
| Tool | Description |
|---|---|
conservative_namespace_overview | Focused namespace health check |
adaptive_namespace_investigation | Dynamic investigation based on query |
| Tool | Description |
|---|---|
investigate_tls_certificate_issues | Find TLS-related problems |
check_cluster_certificate_health | Certificate expiry monitoring |
| Tool | Description |
|---|---|
get_machine_config_pool_status | MachineConfigPool status and updates |
get_openshift_cluster_operator_status | Cluster operator health |
get_etcd_logs | etcd log retrieval and analysis |
| Tool | Description |
|---|---|
ci_cd_performance_baselining_tool | Pipeline performance baselines |
pipeline_tracer | Trace pipelines by commit, PR, or image |
| Tool | Description |
|---|---|
live_system_topology_mapper | Real-time system topology mapping |
predictive_log_analyzer | Predict issues from log patterns |
manage_prediction_training_data | Manage training data for predictive log analyzer |
| Tool | Description |
|---|---|
what_if_scenario_simulator | Simulate configuration changes |
lumino-mcp-server/
βββ main.py # Entry point with transport detection
βββ src/
β βββ server-mcp.py # MCP server with all 39 tools
β βββ helpers/
β βββ constants.py # Shared constants
β βββ event_analysis.py # Event processing logic
β βββ failure_analysis.py # RCA algorithms
β βββ kubearchive_integration.py # KubeArchive API client & discovery
β βββ log_analysis.py # Log processing
β βββ ml_persistence.py # ML model & training data storage
β βββ resource_topology.py # Topology mapping
β βββ semantic_search.py # NLP search
β βββ utils.py # Utility functions
βββ pyproject.toml # Project configuration
LUMINO acts as a bridge between AI assistants and your Kubernetes infrastructure through the Model Context Protocol:
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β AI Assistant Layer β
β (Claude Desktop, Claude Code CLI, Gemini CLI) β
ββββββββββββββββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββ
β
β Natural Language Queries
β "Analyze failed pipelines"
β "Predict resource bottlenecks"
βΌ
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Model Context Protocol β
β (MCP Communication) β
ββββββββββββββββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββ
β
β Tool Invocations & Results
β
βΌ
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β LUMINO MCP Server β
β ββββββββββββββββ ββββββββββββββββ ββββββββββββββββ β
β β Log Analysis β β Event Intel β β Predictive β β
β β (6 tools) β β (3 tools) β β (2 tools) β β
β ββββββββββββββββ ββββββββββββββββ ββββββββββββββββ β
β ββββββββββββββββ ββββββββββββββββ ββββββββββββββββ β
β β Pipeline β β Simulation β β Topology β β
β β (6 tools) β β (1 tool) β β (2 tools) β β
β ββββββββββββββββ ββββββββββββββββ ββββββββββββββββ β
ββββββββββββββββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββ
β
β Kubernetes API Calls
β Prometheus Queries
β
βΌ
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β Kubernetes/OpenShift Cluster β
β β
β ββββββββββββ ββββββββββββ ββββββββββββ ββββββββββββ β
β β Pods β β Services β β Tekton β βetcd/Logs β β
β ββββββββββββ ββββββββββββ βPipelines β ββββββββββββ β
β ββββββββββββ ββββββββββββ ββββββββββββ ββββββββββββ β
β β Events β β Configs β ββββββββββββ βPrometheusβ β
β ββββββββββββ ββββββββββββ βOpenShift β ββββββββββββ β
β βOperators β β
β ββββββββββββ β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
~/.lumino/ for predictive analytics (see ML Model Persistence)The easiest way to install LUMINO MCP Server for Claude Code CLI or Gemini CLI is using MCPM - an MCP server package manager.
# Clone and build MCPM
git clone https://github.com/spre-sre/mcpm.git
cd mcpm
go build -o mcpm .
# Optional: Add to PATH
sudo mv mcpm /usr/local/bin/
Requirements: Go 1.23+, Git, Python 3.10+, uv (or pip)
# Install from GitHub repository (short syntax)
mcpm install @spre-sre/lumino-mcp-server
# Or use full GitHub URL
mcpm install https://github.com/spre-sre/lumino-mcp-server.git
# For GitLab repositories (if hosted on GitLab)
mcpm install gl:@spre-sre/lumino-mcp-server
# Install for specific client
mcpm install @spre-sre/lumino-mcp-server --claude # For Claude Code CLI
mcpm install @spre-sre/lumino-mcp-server --gemini # For Gemini CLI
# Install globally (works with both Claude and Gemini)
mcpm install @spre-sre/lumino-mcp-server --global
Short syntax explained:
@owner/repo - Installs from GitHub (default: https://github.com/owner/repo.git)gl:@owner/repo - Installs from GitLab (https://gitlab.com/owner/repo.git)This will:
~/.mcp/servers/lumino-mcp-server/uv (or pip)# List installed servers
mcpm list
# Update LUMINO
mcpm update lumino-mcp-server
# Remove LUMINO
mcpm remove lumino-mcp-server
If you prefer manual setup or need to configure Claude Desktop / Cursor, follow these client-specific guides:
Find your config file location:
~/Library/Application Support/Claude/claude_desktop_config.json%APPDATA%\Claude\claude_desktop_config.json~/.config/Claude/claude_desktop_config.jsonAdd LUMINO configuration:
{
"mcpServers": {
"lumino": {
"command": "uv",
"args": [
"run",
"--directory",
"/path/to/lumino-mcp-server",
"python",
"main.py"
],
"env": {
"PYTHONUNBUFFERED": "1"
}
}
}
}
Restart Claude Desktop
Verify: Look for the hammer icon (π¨) in Claude Desktop to see available tools
Option A: Using MCPM (see Method 1 above)
Option B: Automatic Provisioning via Claude Code (Recommended and easiest way)
Copy and paste the provisioning prompt from the Quick Start section above into Claude Code. Claude will clone the repository, install dependencies, and configure the MCP server for your project.
Option C: Manual Configuration
git clone https://github.com/spre-sre/lumino-mcp-server.git
cd lumino-mcp-server
uv sync # Creates .venv with all dependencies
.mcp.json in your project root (for project-local config) or update ~/.claude.json (for global config):{
"mcpServers": {
"lumino": {
"type": "stdio",
"command": "/absolute/path/to/lumino-mcp-server/.venv/bin/python",
"args": ["/absolute/path/to/lumino-mcp-server/main.py"],
"env": {
"PYTHONUNBUFFERED": "1"
}
}
}
}
Important: Replace /absolute/path/to/lumino-mcp-server with the actual absolute path where you cloned the repository (e.g., /Users/username/projects/lumino-mcp-server).
# Check MCP servers
claude mcp list
# Test with a query
claude "List all namespaces in my cluster"
Option A: Using MCPM (Recommended - see Method 1 above)
Option B: Manual Configuration
Find your config file location:
~/.config/gemini/mcp_servers.json%APPDATA%\gemini\mcp_servers.jsonAdd LUMINO configuration:
{
"mcpServers": {
"lumino": {
"command": "uv",
"args": [
"run",
"--directory",
"/path/to/lumino-mcp-server",
"python",
"main.py"
],
"env": {
"PYTHONUNBUFFERED": "1"
}
}
}
}
# Check MCP servers
gemini mcp list
# Test with a query
gemini "Show me failed pipeline runs"
Open Cursor Settings:
Cmd+, (macOS) or Ctrl+, (Windows/Linux)Add MCP Server Configuration:
In Cursor's MCP settings, add:
{
"mcpServers": {
"lumino": {
"command": "uv",
"args": [
"run",
"--directory",
"/path/to/lumino-mcp-server",
"python",
"main.py"
],
"env": {
"PYTHONUNBUFFERED": "1"
}
}
}
}
Alternative - Using Cursor's settings.json:
Cmd+Shift+P or Ctrl+Shift+P){
"mcp.servers": {
"lumino": {
"command": "uv",
"args": [
"run",
"--directory",
"/path/to/lumino-mcp-server",
"python",
"main.py"
],
"env": {
"PYTHONUNBUFFERED": "1"
}
}
}
}
Restart Cursor IDE
Verify: Open Cursor's AI chat and check if LUMINO tools are available
Replace /path/to/lumino-mcp-server with the actual path where you cloned the repository:
# Example paths:
# macOS/Linux: /Users/username/projects/lumino-mcp-server
# Windows: C:\Users\username\projects\lumino-mcp-server
# If installed via MCPM:
# ~/.mcp/servers/lumino-mcp-server/
Environment Variables (optional):
Add these to the env section if needed:
{
"env": {
"PYTHONUNBUFFERED": "1",
"KUBERNETES_NAMESPACE": "default",
"PROMETHEUS_URL": "http://prometheus:9090",
"LOG_LEVEL": "INFO"
}
}
{
"command": "python",
"args": [
"/path/to/lumino-mcp-server/main.py"
]
}
Note: Ensure you've activated the virtual environment first:
cd /path/to/lumino-mcp-server
python -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activate
pip install -e .
{
"command": "poetry",
"args": [
"run",
"python",
"main.py"
],
"cwd": "/path/to/lumino-mcp-server"
}
After configuring any client, test the connection:
Check if tools are loaded:
claude mcp listgemini mcp listTest a simple query:
"List all namespaces in my Kubernetes cluster"
# Run server manually to see errors
cd /path/to/lumino-mcp-server
uv run python main.py
Expected output:
MCP Server running in stdio mode
Available tools: 39
Waiting for requests...
Configure multiple LUMINO instances for different clusters:
{
"mcpServers": {
"lumino-prod": {
"command": "uv",
"args": ["run", "--directory", "/path/to/lumino-mcp-server", "python", "main.py"],
"env": {
"KUBECONFIG": "/path/to/prod-kubeconfig.yaml"
}
},
"lumino-dev": {
"command": "uv",
"args": ["run", "--directory", "/path/to/lumino-mcp-server", "python", "main.py"],
"env": {
"KUBECONFIG": "/path/to/dev-kubeconfig.yaml"
}
}
}
}
{
"env": {
"LOG_LEVEL": "DEBUG",
"MCP_SERVER_LOG_LEVEL": "DEBUG"
}
}
The server automatically detects the appropriate transport:
KUBERNETES_NAMESPACE is set)LUMINO is designed to handle clusters of any size efficiently:
| Cluster Size | Recommendation | Tool Strategy |
|---|---|---|
| Small (< 50 pods) | Use default settings | All tools work optimally |
| Medium (50-500 pods) | Use namespace filtering | Leverage adaptive tools with auto-sampling |
| Large (500+ pods) | Specify time windows and namespaces | Use conservative and streaming tools |
| Very Large (1000+ pods) | Combine filters and pagination | Progressive analysis with targeted queries |
LUMINO automatically manages AI context limits:
Use Namespace Filtering
β
"Analyze logs for pods in namespace production"
β "Analyze all pod logs in the cluster"
Documentation truncated β see the full README on GitHub.
Be the first to review this server!
Added support for streaming responses and improved error handling for rate-limited requests.
Major release: new tool registration API, breaking changes to configuration format. See migration guide.
Added OAuth 2.0 support and improved connection pooling.
Initial stable release.