MCP for AIOps Agents: How Clanker CLI Bridges Open Source and Clanker Cloud

AI agents are becoming good at writing code, editing infrastructure files, and planning changes. They are still weak at one thing that matters most in operations: knowing what is actually running right now.

That gap is why MCP matters for AIOps. The Model Context Protocol gives agents a standard way to call tools instead of guessing from memory. The open-source Clanker CLI uses MCP to expose live infrastructure context through a local tool surface, and Clanker Cloud builds a full desktop workspace around that same idea.

The result is simple: agents can ask grounded infrastructure questions without receiving raw cloud credentials.

---

The Agent Context Problem

A coding agent can read your repository and infer a deployment shape. It might see a Helm chart, Terraform module, Dockerfile, or GitHub Actions workflow. That is useful, but it is not live state.

The agent still does not know:

• Whether the deployment succeeded.
• Which pods are crash-looping.
• Which cloud resource is costing money.
• Whether the production config drifted from Terraform.
• Which IAM role currently has broad permissions.
• Whether the service is healthy after the last deploy.

Without live context, an agent guesses. In infrastructure, guesses become incidents.

MCP gives agents a way to ask tools for current state. Clanker CLI provides the AIOps tool surface.

---

Clanker CLI as an MCP Server

The CLI can run an MCP server over HTTP:

clanker mcp --transport http --listen 127.0.0.1:39393 | cat

Or over stdio for clients that launch tools directly:

clanker mcp --transport stdio | cat

The standalone server exposes tools such as:

• clanker_version for health checks.
• clanker_route_question for seeing how a prompt would route.
• clanker_run_command for running local Clanker commands through MCP.

That last tool is the bridge. An agent can ask Clanker to inspect infrastructure, but Clanker still runs locally with the user's configured provider context.

---

Why Localhost Matters

The operational boundary matters more than the protocol.

An MCP server that runs on localhost and calls local credentials has a different trust model from a hosted agent service that stores cloud keys. With Clanker CLI, the provider credentials live where the operator already keeps them: AWS profiles, kubeconfig, environment variables, provider CLIs, and local config.

The agent does not need to hold those credentials directly. It calls a tool. The tool runs locally. The operator can inspect the command path, use debug output, and keep approval gates where they belong.

This is the same boundary described in the Clanker Cloud MCP page and for-agents guide. MCP is the interface. Local execution is the security property.

---

Route Before You Run

A good AIOps agent needs to know what it is about to do before it touches production. Clanker CLI exposes route inspection for that reason.

clanker ask --route-only "use clanker cloud mcp to show my saved settings" | cat

Through MCP, an agent can call clanker_route_question and see how Clanker would classify the request. That is useful for tool selection, debugging, and policy enforcement.

For example, a platform team can distinguish between:

• Read-only cluster inspection.
• Cost investigation.
• Security scan.
• Maker plan generation.
• Apply request.
• Destructive request.

That route visibility makes AI operations less magical and more inspectable.

---

The CLI-to-Cloud Bridge

Clanker Cloud adds a richer local app layer on top of the open-source engine:

• Saved provider and model configuration.
• App-aware session state.
• Multi-cloud topology and resource context.
• Deep Research across connected infrastructure.
• Human review surfaces for findings and plans.
• Local MCP access for coding agents and internal automation.

The reason this works cleanly is that the CLI already speaks the language agents need: commands, routing, local context, and MCP.

For a terminal-first agent workflow, run the CLI MCP server directly. For a broader human-and-agent workspace, run Clanker Cloud and let the app provide the same local-first context with a UI around it.

---

Example Agent Workflow

Imagine a coding agent finishing a pull request that changes a deployment manifest.

Without MCP, it can only inspect repository files. It might say the YAML looks valid and stop there.

With Clanker CLI or Clanker Cloud exposed through MCP, the agent can ask better questions:

What version is currently deployed in production?
Are any pods unhealthy in the target namespace?
Did the last rollout produce warning events?
What services depend on this deployment?
Would scaling this workload increase node pressure?

The answers come from live infrastructure, not from static repo assumptions. The agent can then explain risk inside the PR or suggest a reviewed plan for the operator.

That is the difference between code assistance and operations assistance.

---

MCP Does Not Mean Autopilot

The best AIOps agent workflows are not fully autonomous by default. They are review-first.

Clanker CLI supports that through maker mode and explicit apply flags. Clanker Cloud surfaces the same model visually. Agents can gather context and propose changes, but high-impact operations still require the human to approve execution.

That is especially important when MCP makes tools easier to call. Easier access should not mean weaker control.

The safe pattern is:

1. Agent asks for live context.
2. Clanker returns grounded evidence.
3. Agent proposes a plan.
4. Human reviews the plan.
5. Clanker applies only after explicit approval.

That is AIOps with agency and boundaries.

---

Build on the Open-Source Surface

If you are building internal agents, start with the open-source CLI:

git clone https://github.com/bgdnvk/clanker
make install
clanker mcp --transport http --listen 127.0.0.1:39393 | cat

Then connect your MCP-capable agent to the local endpoint.

If you want the same capability inside a full operations workspace, use Clanker Cloud. It is the desktop layer around the open-source Clanker engine: live infrastructure context, local credential custody, MCP agents, and review-before-execution workflows.

The future of AIOps is not a giant black-box bot with production keys. It is composable local tools, explicit context, and human-controlled execution.