Problem
Claude Code can inspect the repo, but it cannot see the running cluster, failing pods, ingress state, or cloud context without a controlled tool surface.
Use case
Claude Code MCP infrastructure context
A developer wants Claude Code or another MCP agent to reason from live infrastructure context instead of only repository files.
This page is short on purpose: problem, app query, required context, sample output, and safety boundary before the CTA.
Use Clanker Cloud when an agent needs live cloud and Kubernetes evidence through a local MCP surface, not raw credentials or a hosted privileged bridge.
Concrete workflow
Problem, query, context, output, and safety boundary
App workflow/query
Clanker Cloud app:
1. Open the app on the machine with kubeconfig and cloud credentials already configured.
2. Use the app as the trusted local context workspace, then connect Claude Code to the local Clanker MCP runtime.
3. Ask the agent:
Why are prod-api pods CrashLoopBackOff, and what cluster evidence supports the answer?Open-source CLI equivalent
clanker mcp --transport stdio
# Example MCP server config shape:
{
"mcpServers": {
"clanker": {
"command": "clanker",
"args": ["mcp", "--transport", "stdio"]
}
}
}Input context
Clanker Cloud app installed or local Clanker runtime available, kubeconfig already trusted on the machine, cloud provider credentials already configured locally, and an MCP-capable agent that can launch a stdio server.
Output example
Agent answer: prod-api pods are CrashLoopBackOff after commit 4f2c1b because the container expects REDIS_URL but the live secret still exposes REDIS_HOST and REDIS_PORT. No cluster write was run. Suggested next step: update the app config or generate a reviewed secret migration plan.Safety boundary
MCP runs locally through the same runtime that powers the app. Read-only tools expose version, routing, and provider queries through the Clanker safety model. Apply-style changes still require an explicit approved plan.
Supported providers
Next step
Let the agent draft a patch or plan from the evidence, then review the diff or maker plan before applying anything to the cluster.
Buyer query
A developer wants Claude Code or another MCP agent to reason from live infrastructure context instead of only repository files.
Read-only first
MCP runs locally through the same runtime that powers the app. Read-only tools expose version, routing, and provider queries through the Clanker safety model. Apply-style changes still require an explicit approved plan.
Proof artifact
The workflow below includes the app query, local context required, example output, supported providers, and next step.
Next step
Let the agent draft a patch or plan from the evidence, then review the diff or maker plan before applying anything to the cluster.
Related proof
Read the supporting pages
Full example workflow
Open the longer proof page with the same app-first workflow pattern.
Local credentials
Read what stays local, what can go to model providers, and how read-only/maker/apply differ.
Example library
Browse all proof workflows for cost, security, Kubernetes, MCP, and review-before-apply.
FAQ
Common questions
Does this use case require write access first?
MCP runs locally through the same runtime that powers the app. Read-only tools expose version, routing, and provider queries through the Clanker safety model. Apply-style changes still require an explicit approved plan.
Why is this separate from the example page?
The use-case page answers the high-intent buyer query directly. The example page is the deeper proof artifact with the same concrete workflow format.
Next step
Run the read-first workflow
Download the desktop app, connect the existing local context, and start with inspection before reviewed plans.