All posts
Muhtalip Dede profile photoMuhtalip Dede · Founder of kprompt3 min read

kprompt as an MCP tool provider — plan-gated ops from your editor

kprompt mcp serve exposes read and plan tools to Cursor, Claude Desktop, and other IDE assistants over stdio. Mutations return a PlanResult and never auto-apply. IDE interop, not an agent platform.

IDE assistants now speak MCP. Cursor, Claude Desktop, Windsurf, and friends spawn local tool servers and call them mid-conversation. That is the right distribution surface for cluster ops — if the tool refuses to become a silent apply path.

We shipped kprompt mcp serve as a read/plan-only Model Context Protocol tool provider. Your editor can investigate a CrashLoop, ask why a Deployment is pending, and compile a mutate into a typed PlanResult. It cannot approve. It cannot apply. Approval stays a human action you run yourself in a terminal.

Tool provider, not agent platform

The word MCP is overloaded. Some products use it as a control plane for Agents-as-CRDs, A2A meshes, and marketplaces. That is a real lane — it is not ours. kprompt is The AI Runtime for Kubernetes: observe, reason, emit a reviewable plan, then approve before execute. MCP here is reach into the editor, not a new authority model.

  • One binary: kprompt mcp serve — no separate kprompt-mcp release
  • stdio JSON-RPC for the local operator — no network listener by default
  • Same PlanResult wire artifact as CLI --output json
  • Same Safety Engine: wipe-class / namespace-delete intents hard-deny
  • No --approve over MCP — an assistant cannot pass approval through the protocol

If you need a multi-agent platform on the cluster, look at kagent. If you need plan-gated day-2 ops from the editor you already live in, this surface is for you.

What the tools do

ToolJobMutates?
kprompt.readNL reads against your kubeconfig (list, describe, logs, …) → PlanResult JSONNo
kprompt.investigate / why / timeline / impactAI SRE packs for a target — multi-hop RCA, cause, chronology, blast radiusNo
kprompt.planCompile a mutation prompt into actions, diff, risk, blast radius — never appliesNo
kprompt.tools / kprompt.doctorDetected integrations + environment health (no API keys printed)No

Reasoning tools need a configured LLM provider (BYOK or local). They honor your kubeconfig RBAC. Cluster credentials stay on your machine — stdio is scoped to the operator who launched the editor.

Wire it up

Cursor (~/.cursor/mcp.json or project .cursor/mcp.json)

{
  "mcpServers": {
    "kprompt": {
      "command": "kprompt",
      "args": ["mcp", "serve"]
    }
  }
}

Claude Desktop (claude_desktop_config.json)

{
  "mcpServers": {
    "kprompt": {
      "command": "kprompt",
      "args": ["mcp", "serve"]
    }
  }
}

Use an absolute path to the binary if the editor’s PATH does not see kprompt. Human-readable logs go to stderr so stdout stays clean for the protocol.

A real loop: assistant proposes, human applies

Say checkout is CrashLoopBackOff in payments. Inside the editor you ask the assistant to investigate. It calls kprompt.investigate or kprompt.why with target checkout. You get structured evidence — Events, previous logs, dependency hops — as JSON the assistant can narrate. Still no mutate.

When you are ready to change something, the assistant calls kprompt.plan with a bounded prompt. You review the PlanResult: actions, risk, blast radius. If it looks right, you leave the chat and apply yourself:

Apply stays out-of-band

# Assistant showed you a PlanResult via kprompt.plan — review it.
# Then, in your own terminal:

kprompt "rollback orders config to last good" -n payments
# Approve? [y/N]   or   ... --approve after you trust the plan

That split is deliberate. Convenience that lets an IDE agent pass --approve over MCP would dissolve the contract we spent a series arguing for: typed plans, fail-closed safety, humans on the mutate path.

How this compares

SurfaceWhat MCP usually meanskprompt mcp serve
kubectl-aiFirst-class MCP mode in the NL-CLI laneSame reach idea; our mutate path always returns PlanResult and never applies over MCP
K8sGPTMCP for scan/explain into the assistantComplementary — we are intent → plan for day-2 ops, not a fleet scanner
kagentMCP/A2A as part of an agent platform on the clusterDifferent product — we are tool provider for ops, not Agents-as-CRDs

The head-to-head with kubectl-ai still holds: same natural-language CLI neighborhood for day-2, different contract when something must change the cluster. MCP does not erase that fork — it makes the fork visible inside the editor.

Safety invariants (locked)

  • No remote auto-apply — the MCP server never executes a mutation
  • No --approve exposed over the protocol
  • Hard-denies intact for wipe-class and unscoped deletes
  • Existing RBAC boundary — reads use your kubeconfig, no credential upload
  • Local trust by default — stdio only; HTTP/SSE stays off unless you opt in later

MCP adds reach, not authority. That sentence is the whole product bet.

Quick manual check

Smoke the protocol without an editor

printf '%s\n' \
  '{"jsonrpc":"2.0","id":1,"method":"initialize"}' \
  '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
  | kprompt mcp serve

What we are not claiming

  • Not a hosted multi-tenant MCP endpoint
  • Not an MCP/A2A control plane or agent marketplace
  • Not silent Autopilot from the editor
  • Not a replacement for running kprompt in CI — PlanResult JSON gates stay the pipeline path

Experimental, as the rest of the CLI. Prefer non-production contexts first. Read every plan. If the assistant proposes delete namespace, trust the hard-deny — then ask why that prompt ever left your mouth.