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
| Tool | Job | Mutates? |
|---|---|---|
| kprompt.read | NL reads against your kubeconfig (list, describe, logs, …) → PlanResult JSON | No |
| kprompt.investigate / why / timeline / impact | AI SRE packs for a target — multi-hop RCA, cause, chronology, blast radius | No |
| kprompt.plan | Compile a mutation prompt into actions, diff, risk, blast radius — never applies | No |
| kprompt.tools / kprompt.doctor | Detected 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 planThat 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
| Surface | What MCP usually means | kprompt mcp serve |
|---|---|---|
| kubectl-ai | First-class MCP mode in the NL-CLI lane | Same reach idea; our mutate path always returns PlanResult and never applies over MCP |
| K8sGPT | MCP for scan/explain into the assistant | Complementary — we are intent → plan for day-2 ops, not a fleet scanner |
| kagent | MCP/A2A as part of an agent platform on the cluster | Different 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 serveWhat 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.
Related posts
Brownfield kprompt in 15 minutes — adopt without rebuilding the stack
Starting from zero with kind is easy. The real challenge is attaching kprompt to a cluster you already run: bind existing Prometheus, read-first insight, optional MCP — install last.
Read articleBuilding AI SRE in Public #10: Autonomous SRE — and why not yet
Why unsupervised auto-remediation is not the destination. Observe by default, Autopilot propose-only, reality anchors, and investigate → plan → approve → verify as the load-bearing loop — not a fleet of agents that apply because the model sounded sure.
Read articleBuilding AI SRE in Public #9: Knowledge Graph
Read-only service topology as typed nodes/edges — Ingress, PVC, Secret/ConfigMap names, reverse impact — not a Secret CMDB or chat “who depends on what” folklore. Honest degraded when OTel/mesh are missing.
Read article