GitHub - Flux159/mcp-server-kubernetes: MCP Server for kubernetes management commands (original) (raw)

MCP Server Kubernetes

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

MCPKubernetesClaude.mov

Usage with Claude Desktop

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

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

The server will automatically connect to your current kubectl context. 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 asking Claude to list your pods or create a test deployment.

If you have errors open up a standard terminal and run kubectl get pods to see if you can connect to your cluster without credentials issues.

Usage with mcp-chat

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"

Features

• 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_list
  • 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
• 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
• Non-destructive mode for read and create/update-only access to clusters

Local Development

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

Development Workflow

1. Start the server in development mode (watches for file changes):
2. Run unit tests:
3. Build the project:
4. Local Testing with Inspector

npx @modelcontextprotocol/inspector node dist/index.js

Follow further instructions on terminal for Inspector link

1. Local testing with Claude Desktop

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

1. Local testing with mcp-chat

Contributing

See the CONTRIBUTING.md file for details.

Advanced

Non-Destructive Mode

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" } } } }

Commands Available in Non-Destructive Mode

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

• Resource Information: kubectl_get, kubectl_describe, kubectl_list, 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
• Connectivity: port_forward, stop_port_forward
• Context Management: kubectl_context

Commands Disabled in Non-Destructive Mode

The following destructive operations are disabled:

• kubectl_delete: Deleting any Kubernetes resources
• uninstall_helm_chart: Uninstalling Helm charts
• cleanup: Cleanup of managed resources
• kubectl_generic: General kubectl command access (may include destructive operations)

For additional advanced features, see the ADVANCED_README.md.

Architecture

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.

Request Flow

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

Loading

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

Publishing new release

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.

Not planned

Adding clusters to kubectx.