OpenClaw MCP Architecture: Tool Execution, Network Requests, and Clanker Cloud

OpenClaw is useful because it can sit between agents, channels, and real operational work. MCP is useful because it gives agents a standard way to discover and call tools. Put them together and you get a pattern that matters for infrastructure teams: agents can communicate through channels, execute controlled tools, request approvals, and query live systems without every agent inventing its own integration layer.

This article explains the architecture in plain English, then shows where Clanker Cloud and the open-source Clanker CLI fit.

The short version: OpenClaw can act as an MCP bridge for routed conversations and tool workflows. Clanker Cloud can act as the live infrastructure context layer that those conversations and tools need.

---

MCP in One Minute

The Model Context Protocol defines a standard shape for tool access.

An MCP client asks a server what tools are available with tools/list. The server returns tool names, descriptions, and input schemas. When the model decides to use a tool, the client sends tools/call with the tool name and arguments. The server returns text, structured content, resources, or an error.

The important security idea is that tool access should be visible and controllable. MCP's own docs emphasize human confirmation for sensitive operations, input validation, access controls, timeouts, rate limits, and audit logs.

For infrastructure, that is not optional. An agent that can read Kubernetes events is useful. An agent that can mutate production without a human review path is a risk.

---

What OpenClaw Adds

OpenClaw adds channel and runtime orchestration around that MCP loop.

According to OpenClaw's MCP documentation, openclaw mcp has two jobs:

1. Run OpenClaw as an MCP server with openclaw mcp serve.
2. Manage OpenClaw-owned outbound MCP server definitions with commands such as list, show, set, and unset.

That means OpenClaw can sit on both sides of the architecture.

As an MCP server, it exposes OpenClaw-backed conversations and approvals to clients such as Claude Code, Codex, or other MCP-capable tools.

As an MCP client registry, it stores definitions for other MCP servers that OpenClaw runtimes may consume later.

This is the difference between "OpenClaw is a bot" and "OpenClaw is an agent operations layer." The second version can bridge channels, tools, sessions, permissions, and network transports.

---

The OpenClaw MCP Server Flow

The openclaw mcp serve path starts a stdio MCP server. The MCP client owns that process. The bridge then connects to a local or remote OpenClaw Gateway over WebSocket.

The flow looks like this:

1. An MCP client spawns openclaw mcp serve.
2. The bridge connects to OpenClaw Gateway over WebSocket.
3. Existing routed sessions become MCP conversations.
4. The MCP client can list conversations, read messages, wait for events, send replies, fetch attachments, and respond to approvals.
5. Live events are queued in memory while the bridge is connected.

That bridge is important because it does not invent routing. It exposes sessions that the Gateway already knows how to route. If a conversation has no route metadata, it should not appear magically through MCP.

This is good architecture. Routing and trust stay where the channel is configured. MCP exposes the controlled surface.

---

What Tools Does the Bridge Expose?

OpenClaw's current MCP bridge exposes tools such as:

• conversations_list
• conversation_get
• messages_read
• attachments_fetch
• events_poll
• events_wait
• messages_send
• permissions_list_open
• permissions_respond

Those are not cloud-provider tools by themselves. They are conversation and approval tools. They let an MCP client interact with OpenClaw-backed channel sessions.

That distinction matters. OpenClaw is not automatically your AWS account, Kubernetes cluster, or database. It is a channel and execution layer. For infrastructure truth, it needs a reliable data source.

That is where Clanker Cloud fits.

---

Network Requests and Transports

OpenClaw's MCP architecture uses more than one transport depending on the job.

For openclaw mcp serve, the MCP client talks to the bridge over stdio, and the bridge talks to OpenClaw Gateway over WebSocket.

For outbound MCP server definitions, OpenClaw can store stdio, SSE/HTTP, and streamable HTTP configurations. Stdio launches a local child process and communicates through stdin/stdout. HTTP/SSE and streamable HTTP connect to remote MCP servers over network URLs with optional headers and timeouts.

For infrastructure teams, the key questions are:

• Which process can call which network endpoint?
• Where are tokens stored?
• Are sensitive headers redacted in logs?
• Does the tool call have a timeout?
• Can the human see what tool is about to run?
• Is this read-only or mutating?

Good MCP architecture is mostly about making these boundaries explicit.

---

Where Clanker Cloud Fits

Clanker Cloud gives OpenClaw and other agents live infrastructure context through a local-first app and MCP surface.

Instead of teaching OpenClaw every cloud provider separately, you connect Clanker Cloud to your providers locally:

• AWS
• Kubernetes
• GCP
• Azure
• Cloudflare
• GitHub
• Hetzner
• Railway

Then an agent can ask grounded questions through Clanker Cloud's MCP layer or through the open-source Clanker CLI engine.

That creates a cleaner split:

• OpenClaw owns channel routing, async work, events, and approvals.
• Clanker Cloud owns live infrastructure context, local credential custody, and reviewed operations.
• Clanker CLI provides the free open-source engine for terminal and MCP workflows.

The agent does not need raw cloud credentials. It needs a controlled tool surface.

---

Example Architecture

A practical setup might look like this:

Slack / Discord / Telegram
        |
        v
OpenClaw Gateway
        |
        v
openclaw mcp serve  <-->  MCP client / coding agent
        |
        v
Clanker Cloud MCP / Clanker CLI MCP
        |
        v
Local AWS, Kubernetes, GCP, Cloudflare, GitHub credentials

The OpenClaw side keeps the conversation alive. The Clanker side answers infrastructure questions.

For example, a Slack message says:

Is production healthy after the last deploy?

OpenClaw receives the message and routes it to an agent. The agent calls Clanker Cloud to inspect Kubernetes status, recent GitHub Actions runs, cloud health, and cost anomalies. OpenClaw sends the answer back to Slack.

If a restart or config change is needed, the workflow should ask for approval before changing anything.

---

Tool Execution Should Be Read-First

The safest infrastructure agent pattern is read-first, plan-second, apply-third.

Read-first means the agent can inspect state quickly:

clanker ask "what changed in production in the last hour" | cat

Plan-second means the agent can propose a change without applying it:

clanker ask --maker "draft a rollback plan for the failed deployment" | cat

Apply-third means the human explicitly approves execution. Destructive work should require even stronger intent.

That pattern maps naturally to OpenClaw approvals. The channel can ask for permission. The MCP client can surface the pending approval. Clanker Cloud can keep the infrastructure action behind a review boundary.

---

Failure Modes to Watch

OpenClaw plus MCP is powerful, but teams should design for predictable failures.

Common issues include:

• No conversations appear because Gateway route metadata is incomplete.
• events_poll misses old messages because the event queue is live-only.
• A remote MCP server is configured but not reachable.
• An agent sees a tool description but lacks permission to call it.
• A network timeout looks like an agent reasoning failure.
• A tool result includes sensitive infrastructure metadata that should not be sent to a hosted model.

Clanker Cloud helps with the last category by keeping credentials local and making model/provider choices explicit. The tool result can contain infrastructure context, but the credential path stays on the user's machine.

---

Why This Matters for AI Ops

AI Ops is not one agent. It is a harness:

• Channels for humans.
• Tools for live infrastructure.
• Memory and transcripts for continuity.
• Approvals for high-impact actions.
• Local credential custody.
• Network boundaries that can be inspected.

OpenClaw covers the channel and async side of that harness. Clanker Cloud covers the infrastructure side. Clanker CLI makes the core engine open source and scriptable.

That combination is more useful than a single agent with a pile of ad hoc shell permissions.

Start with Clanker CLI if you want the free local engine. Use Clanker Cloud MCP when OpenClaw, Claude Code, Codex, or another MCP-capable agent needs live cloud and Kubernetes context with local credentials and reviewed operations.