·

Kubernetes MCP With Cursor

Set up Kubernetes MCP in Cursor so your AI agent can inspect and manage clusters, pods, and deployments right from your editor.

Cursor's advantage in a Kubernetes MCP workflow is proximity — the agent has your application source open in the same context window it uses to inspect live pod behavior, so it can correlate a stack trace in a log line against the actual function in your repo without you copy-pasting anything between tools. This topic covers wiring Kubernetes MCP into Cursor's Agent mode, the code-to-cluster correlation workflows that make Cursor distinctive here, manifest editing against a live cluster, and the safety boundaries you need to set explicitly because Cursor's defaults are more permissive than you'd want for production.

Connecting Kubernetes MCP to Cursor Agent Mode

Cursor reads MCP server definitions from .cursor/mcp.json (project-scoped) or the global Cursor settings MCP panel. Project-scoped is strongly preferred for a Kubernetes server, since it lets you commit a shared, reviewed config without individual developers hand-wiring their own:

{
  "mcpServers": {
    "kubernetes": {
      "command": "kubernetes-mcp-server",
      "args": ["--kubeconfig", "${KUBECONFIG}", "--read-only"]
    }
  }
}

Cursor's variable substitution for ${KUBECONFIG} pulls from your shell environment at the time Cursor launches the MCP process — confirm it resolved correctly by checking Cursor's MCP settings panel (Settings → MCP), which lists each server's status and tool count.

Enable Agent mode in the composer/chat panel (the mode selector, not "Ask") — Kubernetes MCP tools are only invocable when the agent has tool-use permission, which "Ask" mode restricts. Within Agent mode, Cursor will prompt for per-tool-call approval by default unless you've added the tool to an auto-run allowlist in settings; leave mutating Kubernetes tools off that allowlist deliberately.

{
  "cursor.composer.autoRunAllowlist": [
    "kubernetes__resources_get",
    "kubernetes__resources_list",
    "kubernetes__pods_log",
    "kubernetes__events_list"
  ]
}

Notice this allowlist contains only read-only tools. Anything with create, delete, patch, scale, or exec in its name should stay off the allowlist, forcing a manual approval click every time — that click is your last line of defense against an agent misreading intent from an ambiguous prompt.

Tips
- Use project-scoped .cursor/mcp.json with an environment-variable kubeconfig reference, committed to the repo, so the whole team gets identical Kubernetes MCP access without sharing raw credentials.
- Build your auto-run allowlist from only read-only tool names — treat any tool name containing create/delete/patch/scale/exec as requiring a manual click, permanently.
- Confirm the server actually loaded via Settings → MCP before starting a debugging session — a misresolved ${KUBECONFIG} variable fails silently rather than throwing a visible error in some Cursor versions.

Correlating Application Code with Live Pod Behavior in Cursor

This is where Cursor genuinely differentiates itself from a terminal-only agent. A prompt that spans both the cluster and the repo:

The order-processor pod is crash-looping with a panic in its logs. Get
the previous container logs, find the panic's stack trace, then locate
the corresponding function in this repo and tell me what's wrong.

The agent pulls logs via pods_log(previous=true), extracts something like:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x47a2e1]
goroutine 1 [running]:
main.processOrder(...)
    /app/internal/order/processor.go:142 +0x1a1

and because your repo is open in the same Cursor workspace, it can jump straight to internal/order/processor.go:142, read the surrounding code, and reason about what's nil at that line — no manual translation of a container path (/app/internal/order/processor.go) to your local repo path is needed as long as your go.mod/Docker build path convention matches your source layout, which is worth confirming once per project. This is meaningfully faster than the same investigation split across a terminal and an editor, where you'd manually copy the stack trace and go find the file yourself.

A second, equally useful pattern: correlating a config-related crash against recent code changes.

The pricing-service pod is failing with "missing required env var
PRICING_TAX_RATE". Check the Deployment's env vars, then check git log
for recent changes to the pricing config or Helm values that might have
removed it.

git log --oneline -5 -- deploy/pricing-service/values.yaml

Cursor can run that git command itself and cross-reference the diff against the live Deployment's spec.containers[].env list, often spotting exactly which commit dropped the variable — a genuinely fast root-cause path for config-drift incidents.

Tips
- Keep your repo's build path convention (container path vs. local source path) documented somewhere the agent can see it (a CLAUDE.md/AGENTS.md/project README) — mismatched paths break the auto-jump-to-file behavior silently.
- For config-related crashes, explicitly prompt the agent to check git log on the relevant Helm values or manifest file — it won't automatically think to correlate a live cluster failure against recent git history unless asked.
- Stack-trace-to-source correlation is Cursor's strongest Kubernetes MCP use case — lean on it for crash triage specifically, more than for broad cluster-state exploration where a terminal agent is equally capable.

Editing Manifests and Validating Against the Live Cluster

Cursor's manifest-editing workflow benefits from the same code-plus-cluster context: it can open your actual Kustomize overlay or Helm chart, propose a change, and then verify the change's effect against the live cluster state before you commit.

Open deploy/order-processor/base/deployment.yaml. The pod is OOMKilling
at the current 256Mi limit — propose a new limit based on what you can
see, and after I approve, apply a dry-run to confirm it's valid.

resources:
  requests:
    memory: "256Mi"
    cpu: "150m"
  limits:
    memory: "768Mi"
    cpu: "750m"

After you approve the diff in Cursor's inline editor view, have it validate before any real apply:

kubectl apply -f deploy/order-processor/base/deployment.yaml --dry-run=server -n order-prod
kubectl apply -k deploy/order-processor/overlays/prod --dry-run=server

If your cluster runs an admission controller (OPA Gatekeeper, Kyverno) enforcing resource-limit policies, a server-side dry-run is the only way to catch a policy rejection before a real apply — client-side dry-run only validates schema, not policy. Ask the agent to run the server-side variant specifically:

Run this as a server-side dry-run, not client-side — I want to catch
any admission policy violations, not just schema errors.

Once validated, commit the manifest change through your normal PR flow rather than applying directly if the cluster is GitOps-managed — same caveat as the other tools in this module.

Tips
- Always specify --dry-run=server explicitly when you need admission-policy validation (OPA/Kyverno) — client-side dry-run silently misses policy rejections.
- Let Cursor open and edit the actual source-of-truth manifest file (not a scratch YAML) so the diff you review is the diff that will actually ship through your PR process.
- Re-verify against the live cluster after any manifest change that was meant to fix a specific symptom (OOMKill, CrashLoop) — confirm the new pod actually stabilized, don't just trust that the YAML change was correct.

Known Limitations and Safety Guardrails for Kubernetes MCP in Cursor

Cursor's agent defaults are tuned for fast iteration on code, which is a mismatch for a tool surface where mistakes have cluster-wide blast radius. Set these guardrails explicitly rather than trusting defaults:

  • Auto-run allowlists are per-workspace, easy to forget. If you clone the same MCP config into a new workspace, verify the allowlist came with it and still excludes mutating tools — it's a JSON settings value, not something re-derived from the server's own read-only flag.
  • No built-in distinction between staging and production kubeconfig in the UI. Cursor shows the MCP server as connected with no visual indicator of which cluster/context it's pointed at. Rely on separate kubeconfig files per environment (Topic 1) rather than trusting the interface to warn you.
  • Long agent sessions can lose track of an in-progress mutation's context. If you approve a scale call early in a long chat and then continue with unrelated code work, the agent may not automatically follow up on whether that scale operation actually stabilized the workload — always explicitly ask it to confirm outcomes of any mutation you approved.
  • pods_exec through Cursor's approval UI is workable for simple commands but unreliable for interactive shells. Stick to single, non-interactive exec commands (cat /app/config.yaml style checks) rather than expecting a usable interactive shell session.
  • No first-class rollback confirmation UI. Unlike a kubectl rollout undo you'd run and watch directly, Cursor's tool-call result for a rollback is just the API response — always follow up with an explicit status check.

Tips
- Verify your auto-run allowlist excludes mutating tools every time you set up Kubernetes MCP in a new Cursor workspace — it doesn't inherit safety from the server's own flags automatically.
- Use visually distinct kubeconfig filenames (config-prod, config-staging) since Cursor's UI won't warn you which cluster a session is pointed at.
- After approving any mutating tool call, explicitly prompt the agent to confirm the outcome — don't assume a long session will circle back on its own.

Tips

Tips
- Cursor's biggest edge in this module is stack-trace-to-source-line correlation — use it specifically for crash triage where the panic message points into your own codebase.
- Keep the auto-run allowlist strictly read-only and re-verify it on every new workspace — this is the guardrail most likely to silently drift.
- For anything GitOps-managed or policy-gated (OPA/Kyverno), route changes through source manifests and server-side dry-run, never a direct live-cluster apply from the IDE.

Next Real World Workflow Incident Triage And Rollback