Skip to Content
Connect Claude to Kubernetes with MCP

Pick the right Kubernetes MCP server for cluster visibility, troubleshooting, and safe ops. Compare options, copy a starter config, and run your first read-only checks.

First Tool Call Help
Connect Claude to Kubernetes with MCP

Connect Claude to Kubernetes with MCP

If your goal is to ask Claude about cluster state, pods, and rollout health without building custom scripts first, this is the shortest path.

ServerBest forNot ideal whenAuthPermission risk
MCP Server KubernetesGeneral Kubernetes diagnostics and day-to-day cluster checksYou only need cloud-account-level controls (not cluster-level)Kubeconfig / cluster credentialsHigh (cluster scope can include write actions)
Kubernetes MCP ServerTeams that want Kubernetes-specific tooling with direct cluster contextYou need multi-cloud inventory beyond KubernetesKubeconfig / service accountHigh (RBAC determines blast radius)
MCP K8s EyeFast visibility into workloads and cluster health snapshotsYou need deep cloud provider integrations in the same serverKubeconfig / cluster accessMedium-High (often read-focused, still verify roles)
AWS MCP ServerEKS-heavy stacks where infra + Kubernetes context should stay in one flowYour environment is not on AWSAWS credentials / IAMHigh (depends on IAM policy scope)
CLI MCP ServerPower users who need custom kubectl workflows quicklyYou need strict guardrails for non-technical operatorsLocal command executionVery High (command execution + local environment access)

Quick selection (30 seconds)

  • Pick MCP Server Kubernetes for a balanced starting point on cluster operations.
  • Pick Kubernetes MCP Server if Kubernetes is your main operating surface and you want direct cluster focus.
  • Pick MCP K8s Eye if your top priority is fast read-heavy observability.
  • Pick AWS MCP Server if you run EKS and want AWS + Kubernetes context together.
  • Pick CLI MCP Server only if your team can enforce strong command and host safeguards.

Copy-paste config (Claude Desktop)

Start with a read-only service account and a scoped kubeconfig.

{
  "mcpServers": {
    "kubernetes_readonly": {
      "command": "uv",
      "args": [
        "--directory",
        "/absolute/path/to/kubernetes_mcp_server",
        "run",
        "kubernetes_mcp_server"
      ],
      "env": {
        "KUBECONFIG": "/Users/you/.kube/mcp-readonly-config",
        "KUBE_CONTEXT": "staging-cluster",
        "MCP_READ_ONLY": "1"
      }
    }
  }
}

Environment variable checklist

VariableRequiredSensitiveNotes
KUBECONFIGYesYesUse a dedicated kubeconfig file with limited credentials
KUBE_CONTEXTOptionalNoPin to staging or a low-risk context first
MCP_READ_ONLYOptionalNoKeep enabled during initial rollout

First tool-call prompts

  • “Show all namespaces, deployments, and pods with restart counts higher than 3.”
  • “Summarize unhealthy workloads in this cluster and likely causes.”
  • “List recent rollout changes and flag high-risk services.”

Risk and permission notes

  • RBAC first: create a dedicated read-only role and bind it only to required namespaces.
  • Context pinning: avoid default context; explicitly set cluster and namespace scope.
  • Secret hygiene: never expose kubeconfig tokens in repo files or chat logs.
  • Command execution caution: treat CLI-based MCP servers as privileged endpoints.

FAQ

Which Kubernetes MCP server should I start with?

Start with the option that gives read-only visibility and matches your current ops stack. Most teams should begin with a Kubernetes-focused server and add cloud-provider servers later.

Can I enable write operations for rollouts?

Yes, but only after validating read-only workflows and adding namespace-level guardrails, approval gates, and audit logging.

What is the fastest way to reduce risk?

Use a separate staging cluster context, least-privilege RBAC, and short-lived credentials before any production connection.

Sources and freshness

  • Sources: official server pages listed above.
  • Updated: March 2, 2026.
Last updated on