MCP Server that can connect to a Kubernetes cluster and manage it. Supports loading kubeconfig from multiple sources in priority order.

Before using this MCP server with any tool, make sure you have:

1. kubectl installed and in your PATH
2. A valid kubeconfig file with contexts configured
3. Access to a Kubernetes cluster configured for kubectl (e.g. minikube, Rancher Desktop, GKE, etc.)
4. Helm v3 installed and in your PATH (no Tiller required). Optional if you don't plan to use Helm.

You can verify your connection by running kubectl get pods in a terminal to ensure you can connect to your cluster without credential issues.

By default, the server loads kubeconfig from ~/.kube/config. For additional authentication options (environment variables, custom paths, etc.), see ADVANCED_README.md.

Add the MCP server to Claude Code using the built-in command:

claude mcp add kubernetes -- npx mcp-server-kubernetes

This will automatically configure the server in your Claude Code MCP settings.

Add the following configuration to your Claude Desktop config file:

{
  "mcpServers": {
    "kubernetes": {
      "command": "npx",
      "args": ["mcp-server-kubernetes"]
    }
  }
}

For VS Code integration, you can use the MCP server with extensions that support the Model Context Protocol:

1. Install a compatible MCP extension (such as Claude Dev or similar MCP clients)
2. Configure the extension to use this server:

{
  "mcpServers": {
    "kubernetes": {
      "command": "npx",
      "args": ["mcp-server-kubernetes"],
      "description": "Kubernetes cluster management and operations"
    }
  }
}

Cursor supports MCP servers through its AI integration. Add the server to your Cursor MCP configuration:

{
  "mcpServers": {
    "kubernetes": {
      "command": "npx",
      "args": ["mcp-server-kubernetes"]
    }
  }
}

The server will automatically connect to your current kubectl context. You can verify the connection by asking the AI assistant to list your pods or create a test deployment.

mcp-chat is a CLI chat client for MCP servers. You can use it to interact with the Kubernetes server.

npx mcp-chat --server "npx mcp-server-kubernetes"

Alternatively, pass it your existing Claude Desktop configuration file from above (Linux should pass the correct path to config):

Mac:

npx mcp-chat --config "~/Library/Application Support/Claude/claude_desktop_config.json"

Windows:

npx mcp-chat --config "%APPDATA%\Claude\claude_desktop_config.json"

• Connect to a Kubernetes cluster
• Unified kubectl API for managing resources
  • Get or list resources with kubectl_get
  • Describe resources with kubectl_describe
  • List resources with kubectl_get
  • Create resources with kubectl_create
  • Apply YAML manifests with kubectl_apply
  • Delete resources with kubectl_delete
  • Get logs with kubectl_logs
  • Manage kubectl contexts with kubectl_context
  • Explain Kubernetes resources with explain_resource
  • List API resources with list_api_resources
  • Scale resources with kubectl_scale
  • Update field(s) of a resource with kubectl_patch
  • Manage deployment rollouts with kubectl_rollout
  • Execute any kubectl command with kubectl_generic
  • Verify connection with ping
• Advanced operations
  • Scale deployments with kubectl_scale (replaces legacy scale_deployment)
  • Port forward to pods and services with port_forward
  • Run Helm operations
    • Install, upgrade, and uninstall charts
    • Support for custom values, repositories, and versions
    • Template-based installation (helm_template_apply) to bypass authentication issues
    • Template-based uninstallation (helm_template_uninstall) to bypass authentication issues
  • Pod cleanup operations
    • Clean up problematic pods (cleanup_pods) in states: Evicted, ContainerStatusUnknown, Completed, Error, ImagePullBackOff, CrashLoopBackOff
  • Node management operations
    • Cordoning, draining, and uncordoning nodes (node_management) for maintenance and scaling operations
• Troubleshooting Prompt (k8s-diagnose)
  • Guides through a systematic Kubernetes troubleshooting flow for pods based on a keyword and optional namespace.
• Non-destructive mode for read and create/update-only access to clusters
• Secrets masking for security (masks sensitive data in kubectl get secrets commands, does not affect logs)

The MCP Kubernetes server includes specialized prompts to assist with common diagnostic operations.

This prompt provides a systematic troubleshooting flow for Kubernetes pods. It accepts a keyword to identify relevant pods and an optional namespace to narrow the search. The prompt's output will guide you through an autonomous troubleshooting flow, providing instructions for identifying issues, collecting evidence, and suggesting remediation steps.

Make sure that you have bun installed. Clone the repo & install dependencies:

git clone https://github.com/Flux159/mcp-server-kubernetes.git
cd mcp-server-kubernetes
bun install

1. Start the server in development mode (watches for file changes):

bun run dev

2. Run unit tests:

bun run test

3. Build the project:

bun run build

4. Local Testing with Inspector

npx @modelcontextprotocol/inspector node dist/index.js
# Follow further instructions on terminal for Inspector link

5. Local testing with Claude Desktop

{
  "mcpServers": {
    "mcp-server-kubernetes": {
      "command": "node",
      "args": ["/path/to/your/mcp-server-kubernetes/dist/index.js"]
    }
  }
}

6. Local testing with mcp-chat

bun run chat

See the CONTRIBUTING.md file for details.

You can run the server in a non-destructive mode that disables all destructive operations (delete pods, delete deployments, delete namespaces, etc.):

ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS=true npx mcp-server-kubernetes

For Claude Desktop configuration with non-destructive mode:

{
  "mcpServers": {
    "kubernetes-readonly": {
      "command": "npx",
      "args": ["mcp-server-kubernetes"],
      "env": {
        "ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS": "true"
      }
    }
  }
}

All read-only and resource creation/update operations remain available:

• Resource Information: kubectl_get, kubectl_describe, kubectl_logs, explain_resource, list_api_resources
• Resource Creation/Modification: kubectl_apply, kubectl_create, kubectl_scale, kubectl_patch, kubectl_rollout
• Helm Operations: install_helm_chart, upgrade_helm_chart, helm_template_apply, helm_template_uninstall
• Connectivity: port_forward, stop_port_forward
• Context Management: kubectl_context

The following destructive operations are disabled:

• kubectl_delete: Deleting any Kubernetes resources
• uninstall_helm_chart: Uninstalling Helm charts
• cleanup: Cleanup of managed resources
• cleanup_pods: Cleaning up problematic pods
• node_management: Node management operations (can drain nodes)
• kubectl_generic: General kubectl command access (may include destructive operations)

The helm_template_apply tool provides an alternative way to install Helm charts that bypasses authentication issues commonly encountered with certain Kubernetes configurations. This tool is particularly useful when you encounter errors like:

WARNING: Kubernetes configuration file is group-readable. This is insecure.
Error: INSTALLATION FAILED: Kubernetes cluster unreachable: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1alpha1"

Instead of using helm install directly, this tool:

1. Uses helm template to generate YAML manifests from the Helm chart
2. Applies the generated YAML using kubectl apply
3. Handles namespace creation and cleanup automatically

{
  "name": "helm_template_apply",
  "arguments": {
    "name": "events-exporter",
    "chart": ".",
    "namespace": "kube-event-exporter",
    "valuesFile": "values.yaml",
    "createNamespace": true
  }
}

This is equivalent to running:

helm template events-exporter . -f values.yaml > events-exporter.yaml
kubectl create namespace kube-event-exporter
kubectl apply -f events-exporter.yaml -n kube-event-exporter

• name: Release name for the Helm chart
• chart: Chart name or path to chart directory
• repo: Chart repository URL (optional if using local chart path)
• namespace: Kubernetes namespace to deploy to
• values: Chart values as an object (optional)
• valuesFile: Path to values.yaml file (optional, alternative to values object)
• createNamespace: Whether to create the namespace if it doesn't exist (default: true)

Pod cleanup can be achieved using the existing kubectl_get and kubectl_delete tools with field selectors. This approach leverages standard Kubernetes functionality without requiring dedicated cleanup tools.

Use kubectl_get with field selectors to identify pods in problematic states:

Get failed pods:

{
  "name": "kubectl_get",
  "arguments": {
    "resourceType": "pods",
    "namespace": "default",
    "fieldSelector": "status.phase=Failed"
  }
}

Get completed pods:

{
  "name": "kubectl_get",
  "arguments": {
    "resourceType": "pods",
    "namespace": "default",
    "fieldSelector": "status.phase=Succeeded"
  }
}

Get pods with specific conditions:

{
  "name": "kubectl_get",
  "arguments": {
    "resourceType": "pods",
    "namespace": "default",
    "fieldSelector": "status.conditions[?(@.type=='Ready')].status=False"
  }
}

Use kubectl_delete with field selectors to delete pods in problematic states:

Delete failed pods:

{
  "name": "kubectl_delete",
  "arguments": {
    "resourceType": "pods",
    "namespace": "default",
    "fieldSelector": "status.phase=Failed",
    "force": true,
    "gracePeriodSeconds": 0
  }
}

Delete completed pods:

{
  "name": "kubectl_delete",
  "arguments": {
    "resourceType": "pods",
    "namespace": "default",
    "fieldSelector": "status.phase=Succeeded",
    "force": true,
    "gracePeriodSeconds": 0
  }
}

1. First, identify problematic pods using kubectl_get with appropriate field selectors
2. Review the list of pods in the response
3. Delete the pods using kubectl_delete with the same field selectors

• status.phase=Failed - Pods that have failed
• status.phase=Succeeded - Pods that have completed successfully
• status.phase=Pending - Pods that are pending
• status.conditions[?(@.type=='Ready')].status=False - Pods that are not ready

• Field selectors: Target specific pod states precisely
• Force deletion: Use force=true and gracePeriodSeconds=0 for immediate deletion
• Namespace isolation: Target specific namespaces or use allNamespaces=true
• Standard kubectl: Uses well-established Kubernetes patterns

The node_management tool provides comprehensive node management capabilities for Kubernetes clusters, including cordoning, draining, and uncordoning operations. This is essential for cluster maintenance, scaling, and troubleshooting.

• list: List all nodes with their status and schedulability
• cordon: Mark a node as unschedulable (no new pods will be scheduled)
• drain: Safely evict all pods from a node and mark it as unschedulable
• uncordon: Mark a node as schedulable again

1. List all nodes:

{
  "name": "node_management",
  "arguments": {
    "operation": "list"
  }
}

2. Cordon a node (mark as unschedulable):

{
  "name": "node_management",
  "arguments": {
    "operation": "cordon",
    "nodeName": "worker-node-1"
  }
}

3. Drain a node (dry run first):

{
  "name": "node_management",
  "arguments": {
    "operation": "drain",
    "nodeName": "worker-node-1",
    "dryRun": true
  }
}

4. Drain a node (with confirmation):

{
  "name": "node_management",
  "arguments": {
    "operation": "drain",
    "nodeName": "worker-node-1",
    "dryRun": false,
    "confirmDrain": true,
    "force": true,
    "ignoreDaemonsets": true,
    "timeout": "5m"
  }
}

5. Uncordon a node:

{
  "name": "node_management",
  "arguments": {
    "operation": "uncordon",
    "nodeName": "worker-node-1"
  }
}

• force: Force the operation even if there are pods not managed by controllers
• gracePeriod: Period of time in seconds given to each pod to terminate gracefully
• deleteLocalData: Delete local data even if emptyDir volumes are used
• ignoreDaemonsets: Ignore DaemonSet-managed pods (default: true)
• timeout: The length of time to wait before giving up (e.g., '5m', '1h')
• dryRun: Show what would be done without actually doing it
• confirmDrain: Explicit confirmation to drain the node (required for actual draining)

• Dry run by default: Drain operations default to dry run to show what would be done
• Explicit confirmation: Drain operations require confirmDrain=true to proceed
• Status tracking: Shows node status before and after operations
• Timeout protection: Configurable timeouts to prevent hanging operations
• Graceful termination: Configurable grace periods for pod termination

1. Cluster Maintenance: Cordon nodes before maintenance, drain them, perform maintenance, then uncordon
2. Node Scaling: Drain nodes before removing them from the cluster
3. Troubleshooting: Isolate problematic nodes by cordoning them
4. Resource Management: Drain nodes to redistribute workload

For additional advanced features, see the ADVANCED_README.md.

See this DeepWiki link for a more indepth architecture overview created by Devin.

This section describes the high-level architecture of the MCP Kubernetes server.

The sequence diagram below illustrates how requests flow through the system:

sequenceDiagram
    participant Client
    participant Transport as Transport Layer
    participant Server as MCP Server
    participant Filter as Tool Filter
    participant Handler as Request Handler
    participant K8sManager as KubernetesManager
    participant K8s as Kubernetes API

    Note over Transport: StdioTransport or<br>SSE Transport

    Client->>Transport: Send Request
    Transport->>Server: Forward Request

    alt Tools Request
        Server->>Filter: Filter available tools
        Note over Filter: Remove destructive tools<br>if in non-destructive mode
        Filter->>Handler: Route to tools handler

        alt kubectl operations
            Handler->>K8sManager: Execute kubectl operation
            K8sManager->>K8s: Make API call
        else Helm operations
            Handler->>K8sManager: Execute Helm operation
            K8sManager->>K8s: Make API call
        else Port Forward operations
            Handler->>K8sManager: Set up port forwarding
            K8sManager->>K8s: Make API call
        end

        K8s-->>K8sManager: Return result
        K8sManager-->>Handler: Process response
        Handler-->>Server: Return tool result
    else Resource Request
        Server->>Handler: Route to resource handler
        Handler->>K8sManager: Get resource data
        K8sManager->>K8s: Query API
        K8s-->>K8sManager: Return data
        K8sManager-->>Handler: Format response
        Handler-->>Server: Return resource data
    end

    Server-->>Transport: Send Response
    Transport-->>Client: Return Final Response

See this DeepWiki link for a more indepth architecture overview created by Devin.

Go to the releases page, click on "Draft New Release", click "Choose a tag" and create a new tag by typing out a new version number using "v{major}.{minor}.{patch}" semver format. Then, write a release title "Release v{major}.{minor}.{patch}" and description / changelog if necessary and click "Publish Release".

This will create a new tag which will trigger a new release build via the cd.yml workflow. Once successful, the new release will be published to npm. Note that there is no need to update the package.json version manually, as the workflow will automatically update the version number in the package.json file & push a commit to main.

Adding clusters to kubectx.

If you find this repo useful, please cite:

@software{Patel_MCP_Server_Kubernetes_2024,
author = {Patel, Paras and Sonwalkar, Suyog},
month = jul,
title = {{MCP Server Kubernetes}},
url = {https://github.com/Flux159/mcp-server-kubernetes},
version = {2.5.0},
year = {2024}
}