Kubernetes MCP Server Setup for Cursor IDE (2026)

How do you set up a Kubernetes MCP server in Cursor? Point it at your existing kubeconfig — the same file kubectl already uses — add an entry to ~/.cursor/mcp.json with the command/args for the MCP package you've chosen, and restart Cursor. There's no separate Kubernetes-specific auth step: whatever context and credentials kubectl config current-context resolves to are what the MCP server uses too.

That last point is the one to sit with before you connect anything. If your current context points at a production cluster, your AI now has whatever access your kubeconfig grants there — which for a lot of engineers, by default, is more than "read-only." Treat this setup like handing someone your kubectl session, because that's functionally what it is.

What You Can Do With Kubernetes MCP in Cursor

Once connected, Cursor can typically:

Exactly which of these are available — and whether any of them are write operations (scaling a deployment, deleting a pod) — depends on the specific MCP package and the RBAC permissions attached to your kubeconfig's service account or user. Some implementations are deliberately read-only by design; others expose kubectl apply-equivalent tools if the underlying credentials allow it. Check the tool list after connecting rather than assuming either way.

Prerequisites

Step 1: Confirm Your Current kubectl Context

Before wiring this into Cursor, check which cluster you're actually pointed at:

kubectl config current-context
kubectl config get-contexts

If that context is a production cluster and you don't have a separate read-only context available, this is the point to stop and create one — see the RBAC scoping note below — rather than connecting your AI straight to prod credentials.

Step 2: Add Kubernetes to Your MCP Config

Open ~/.cursor/mcp.json and add a kubernetes entry. The general shape, consistent with how other local-process MCP servers on this site are configured, looks like:

{
  "mcpServers": {
    "kubernetes": {
      "command": "npx",
      "args": ["-y", ""],
      "env": {
        "KUBECONFIG": "/Users/you/.kube/config"
      }
    }
  }
}

If you omit KUBECONFIG, most implementations fall back to the same default path kubectl uses (~/.kube/config) and whatever context is currently active. Setting it explicitly is worth doing anyway — it makes it obvious, reading the config file later, exactly which kubeconfig your AI has access to.

As with other infrastructure-facing MCP servers on this site, there's more than one Kubernetes MCP implementation in circulation — community-maintained wrappers around kubectl/the Kubernetes API differ in exact package name and tool coverage. Check Cursor's MCP directory for the current recommended package before finalizing this block, and swap for the real one. If you're already running MCP servers via Docker for isolation — see the Docker MCP setup guide — the same containerized pattern applies here, mounting your kubeconfig read-only into the container.

Step 3: Scope Access with a Dedicated RBAC Role (Recommended)

Rather than pointing the MCP server at your full-admin kubeconfig, create a read-only ClusterRole and bind it to a dedicated service account:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: mcp-readonly
rules:
apiGroups: ["", "apps", "batch"]

    resources: ["pods", "pods/log", "deployments", "replicasets", "services", "events", "jobs"]
    verbs: ["get", "list", "watch"]

Bind it to a service account, generate a kubeconfig scoped to that account, and point KUBECONFIG at that file instead of your personal admin config. This is the single most important step in this guide if the cluster in question runs anything you'd rather not have accidentally scaled to zero by a misinterpreted prompt.

Step 4: Restart Cursor and Verify

Fully quit and reopen Cursor. In chat, try:

List all pods in the default namespace that aren't in a Running state

or

Show me the last 50 log lines for the pod behind the checkout-service deployment

A response naming real pods, namespaces, or log lines confirms the connection. An empty or generic response usually means the context your kubeconfig resolved to doesn't have anything matching — double-check kubectl config current-context matches what you expect.

Practical Workflows

Triaging a crash loop

Find every pod in CrashLoopBackOff across all namespaces, describe the first one, and tell me what the last termination reason was

Checking a rollout before you sign off on a deploy

Check the rollout status of the payments-api deployment — is the new replica set fully available, or are pods still starting?

Spotting resource pressure before it causes an incident

List pods in the production namespace where memory usage is above 85% of their limit

Correlating events with a recent change

Show me Kubernetes events from the last 30 minutes in the checkout namespace, and flag anything that looks like a scheduling failure or an eviction

When Read-Only Isn't Enough (and Why That's a Bigger Decision)

Some teams eventually want their AI to do more than observe — restart a pod, scale a deployment, roll back a bad rollout. That's a real use case, but it's a different risk profile than everything above, which is why it's worth calling out separately rather than bundling it into "setup." If you go this route, don't reuse the read-only role from Step 3 — build a second, narrowly scoped role for whichever specific write actions you actually want to allow (e.g., deployments/rollback but not pods/delete cluster-wide), and test it against a staging cluster before anything touches production. A prompt that's slightly ambiguous about which deployment it means is a much smaller problem when the worst case is a wrong kubectl get, and a much bigger one when the worst case is a wrong kubectl delete.

Troubleshooting

"Unable to connect to the server" or connection refused
Your kubeconfig's cluster endpoint may not be reachable from the machine running Cursor — common if the cluster is behind a VPN or bastion host that isn't currently connected. Run kubectl get nodes in the same terminal session first; if that fails, the MCP server will too.

Server connects but every query returns empty
Almost always a context or namespace mismatch. Confirm kubectl config current-context is the cluster you think it is, and that you're not implicitly scoped to a namespace with nothing in it — ask explicitly for --all-namespaces-equivalent queries to rule this out.

"Forbidden" on some resource types but not others
This is RBAC working as intended, not a bug. The service account or user in your kubeconfig doesn't have permission for that resource/verb combination — check the ClusterRole or Role bound to it, the same way you'd debug any other RBAC denial.

Log tailing times out on high-volume pods
Some MCP implementations don't handle unbounded log streams well. Narrow the request — specify a line count or time window — rather than asking for "all the logs," the same practice you'd use with kubectl logs --tail.

Frequently Asked Questions

Q: Does this work with any Kubernetes distribution — EKS, GKE, AKS, or a local cluster like kind?
A: Yes. The MCP server talks to whatever cluster your kubeconfig's current context points to, and kubeconfig is a standard format across distributions. The setup steps here don't change based on where the cluster is hosted.

Q: Is it safe to point this at a production cluster?
A: Only with a scoped, read-only RBAC role — see Step 3. Pointing an MCP server at a kubeconfig with cluster-admin access on production is the same risk as handing anyone else that same kubeconfig, and it's worth treating it with that level of caution rather than assuming the "AI" framing makes it different.

Q: Can it run kubectl apply or modify my cluster, or is it read-only?
A: Depends entirely on the package and the RBAC permissions attached to your kubeconfig. Some implementations are read-only by design; others expose write tools if the underlying credentials allow them. Check the tool list the server exposes after connecting, and see the write-access section above before enabling anything beyond read.

Q: How is this different from just running kubectl commands myself and pasting the output into chat?
A: Mechanically, not that different — but it removes the copy-paste loop entirely, and it lets the AI decide what to check next based on what it just saw (e.g., see a crash loop, then automatically pull the log for that specific pod) instead of you manually chaining commands.

Q: If I already use the Terraform MCP server to write my cluster's infrastructure, does this replace or overlap with it?
A: They're complementary, not overlapping. The Terraform MCP server helps you write correct HCL for provisioning infrastructure (including the cluster itself) but has no visibility into what's actually running. This Kubernetes MCP server is the other half — it sees live cluster state but knows nothing about how that cluster was provisioned.

Related Guides

---