MCP Infrastructure Workspace: Give Your AI Agents a Live View of Your Infrastructure

The Agent Context Gap

An AI agent writing a deployment script knows your codebase, its training data, and whatever you typed in the prompt. It does not know that your redis cluster is currently DEGRADED, that orders-postgres is handling 2,100 queries per second, or that checkout-api has been running hot since the last deploy. It has no access to the current state of your infrastructure — none at all.

This is the agent context gap: the distance between what an agent was trained on and the actual live state of your systems. It is not a reasoning failure. It is an information failure. When Claude Code generates a scale-up plan for a pod that is already over-provisioned, or when a Hermes agent approves a deploy to a cluster where a dependency is degraded, the agent is not being careless — it is operating with the only information it has.

The gap causes confident, wrong actions. The agent generates a complete, syntactically valid deployment script that makes a bad infrastructure decision because it was missing one piece of live context.

The fix is not to prompt the agent more carefully. It is to give the agent a reliable source of live infrastructure truth it can query at any point in a task.

That is what a Model Context Protocol infrastructure workspace provides.

---

What an MCP Infrastructure Workspace Is

Most discussions of MCP focus on the protocol mechanics: tools, transports, JSON-RPC, server registration. The for-agents documentation covers that ground. This article is about something different — what happens when an MCP server is not a per-session connection but a persistent local workspace that agents register against once and query continuously.

The difference matters:

• Ad-hoc MCP calls give an agent access to a tool for the duration of a session. The connection is ephemeral. Context resets.
• A persistent MCP workspace is a running local process. Agents connect to it, query it at any point in a workflow, and the workspace accumulates context across sessions. An agent can ask the same question at 9:00 am and again at 9:30 am and detect state changes between the two answers.

Clanker Cloud acts as a persistent MCP infrastructure workspace. When you start it locally, it reads your existing credentials — ~/.aws/credentials, ~/.kube/config, cloud provider tokens — and exposes a structured, live surface that any MCP-compatible agent can query. No credentials leave your machine. No data flows through a vendor proxy. The workspace is the trust boundary.

What the workspace provides:

• Live data — not cached, not from documentation. Actual current resource state from AWS, GCP, Azure, Kubernetes (EKS, GKE, AKS), Cloudflare, Hetzner, DigitalOcean, and GitHub.
• Multi-provider coverage — one workspace answers questions across all connected providers simultaneously.
• Approval gates — agents can read freely. Writes require explicit Maker Mode approval from a human operator.
• Local trust — the MCP server runs on 127.0.0.1. No cloud egress, no third-party relay.

The demo shows this in practice: a live workspace where session-cache is DEGRADED, orders-postgres is running at 2,100 qps, and checkout-api is fielding the overflow — all surfaced in a single query.

---

The Three MCP Tools

Clanker Cloud exposes three MCP tools. Each has a distinct role in how agents interact with the workspace.

clanker_version

A health check. Before starting a task that requires live infrastructure context, an agent calls clanker_version to confirm the workspace is running and reachable. If the workspace is down, the agent knows immediately — before it proceeds with stale assumptions — and can surface that fact rather than continuing blind.

This is the first tool any agent integration should call. It costs nothing and prevents a class of silent failures where an agent assumes infrastructure context it never actually received.

clanker_route_question

The primary query tool. An agent passes any natural-language infrastructure question, and the workspace returns a live answer. The agent does not need to know which cloud API to call, which kubectl command to run, or how to parse the output. It asks a question in the same way a human would ask a colleague.

Example queries that clanker_route_question handles:

• "What instance type is prod-cluster running?"
• "Are all services in the production namespace healthy?"
• "What changed in the last deployment?"
• "Why is checkout-api latency elevated right now?"
• "Which pods are using more than 80% of their memory limit?"

The workspace routes each question to the appropriate provider API or kubectl command, runs the query against live data, and returns a structured answer. The agent receives actual infrastructure state — not a generated guess based on training data.

clanker_run_command

Executes infrastructure commands in Maker Mode. This tool is the write surface. An agent can propose a command — scale a deployment, apply a Terraform plan, modify a resource — and the workspace surfaces it for explicit operator approval before anything executes. No command runs autonomously. The approval gate is enforced at the workspace level, not by agent design.

This three-tool surface covers the full agent interaction pattern: verify the workspace is live, query infrastructure state, and optionally propose actions for human approval.

The full tool reference is in the Clanker Cloud documentation.

---

Multi-Agent Workspace: One Surface, Three Agents

The persistent workspace model becomes most useful when multiple agents share the same infrastructure context. Consider a scenario where three agents are running simultaneously against a single Clanker Cloud MCP workspace:

Simultaneously registered against the same MCP workspace:

- Claude Code: writing a deploy script, calls clanker_route_question:
  "What instance type is prod-cluster using?"
  → Returns: r6g.2xlarge, 3 nodes, 62% memory utilization

- OpenClaw HEARTBEAT.md: running every 30 minutes, calls clanker_route_question:
  "Are all services in production healthy?"
  → Returns: session-cache DEGRADED, all others nominal

- Hermes: triggered by GitHub Actions post-deploy, calls clanker_route_question:
  "What changed in the last deployment?"
  → Returns: checkout-api scaled from 2 to 3 pods, image tag updated to v1.4.2

Three agents. Three different workflows. All receiving live infrastructure answers from a single local workspace. None holds credentials. None can make changes without Maker Mode approval. None requires a custom integration — any MCP-compatible agent connects with one command.

Claude Code generates a deploy script that accounts for actual instance type and memory pressure. OpenClaw's HEARTBEAT.md knows the cache is degraded before deciding whether to alert. Hermes correlates the deployment event with pod state before filing an incident report. Each agent makes a better decision because it has live context.

This is what teams building on AI DevOps for teams and vibe-coding-to-production workflows need: infrastructure truth that agents can access on demand, without custom integrations for each agent type.

---

Workspace Persistence: Continuous Monitoring via Repeated Queries

A persistent MCP workspace enables a monitoring pattern that ad-hoc connections cannot support: state-change detection across time.

OpenClaw's HEARTBEAT.md is the clearest example. Every 30 minutes, a HEARTBEAT task runs and calls clanker_route_question with a health query. Because the workspace is persistent — not re-initialized each session — the agent can compare the current response to the previous one. A service that was healthy at 9:00 am and degraded at 9:30 am produces a detectable state change. The agent can then decide whether to alert, investigate further, or call clanker_run_command with a remediation proposal for operator review.

This is the foundation of deep research via the workspace as well. An agent-triggered one-pass scan fans out across all connected providers — AWS, GCP, Azure, Kubernetes, Cloudflare, Hetzner — running parallel queries and returning severity-graded findings: CRITICAL exposures, HIGH waste signals (an idle worker pool burning $140/month across 4 replicas at 3% CPU average), MEDIUM reliability gaps (single-AZ cache, no failover). The workspace does not require a new authentication flow for each scan. It reads local credentials, runs the scan, and returns structured findings.

Persistence also matters for context accumulation. An agent that queries the workspace multiple times within a complex task — checking health before deployment, confirming pod state after rollout, verifying that no services degraded during the change — is doing something qualitatively different from an agent that makes one isolated API call. It is maintaining a live thread of infrastructure awareness throughout the task lifecycle.

---

Setup and Configuration

Starting the MCP workspace takes one command:

# Start the MCP workspace (HTTP transport)
clanker mcp --transport http --listen 127.0.0.1:39393

The workspace listens on loopback only. No remote connections. No cloud relay.

Register OpenClaw:

openclaw mcp set clanker-cloud --url http://127.0.0.1:39393

OpenClaw (68,000+ GitHub stars, MIT license) connects immediately. HEARTBEAT.md tasks can reference the clanker_route_question tool from that point forward.

Claude Desktop (stdio transport):

Add to ~/.claude/claude_desktop_config.json:

{
    "mcpServers": {
        "clanker-cloud": {
            "command": "clanker",
            "args": ["mcp", "--transport", "stdio"]
        }
    }
}

Claude Desktop will launch the MCP workspace in stdio mode when Claude starts. No separate process to manage.

Install the CLI:

brew tap clankercloud/tap && brew install clanker

The open-source CLI (Go, MIT, github.com/bgdnvk/clanker) is the executable behind the desktop app's MCP surface and clanker ask. Your account and download are on the Free Beta tier at no cost. AI model costs are BYOK — billed directly by your provider, no markup.

---

Security: Loopback-Only, Local Credentials, Maker Mode Gates

Three properties define the workspace's security model:

Loopback-only binding. The MCP server binds to 127.0.0.1:39393. Connections from external hosts or remote agents are rejected at the network layer. Only processes on the same machine can reach the workspace.

Local credential custody. The workspace reads your existing credential files (~/.aws/credentials, ~/.kube/config, provider tokens) directly. Credentials are not uploaded to any service or relayed through a cloud proxy. The query path is: agent → local workspace → cloud provider API. There is no intermediate hop that holds your credentials.

Maker Mode approval gates. The clanker_run_command tool does not execute autonomously. Every write operation surfaces a reviewed plan and waits for explicit operator approval before anything runs. This is enforced at the workspace level regardless of which agent calls the tool.

Agents can query infrastructure freely — the read surface has no approval gate. The write surface requires human approval on every action.

---

Deep Research via Workspace: Agent-Triggered One-Pass Scans

The workspace exposes Deep Research as an agent-triggerable capability. An agent — or a human — calls clanker_route_question with a broad investigation prompt:

"Scan my production infrastructure for cost waste, security gaps, and reliability issues."

The workspace fans out across all connected providers simultaneously, runs parallel analysis using your configured BYOK models, and returns severity-ranked findings:

• CRITICAL: Public database endpoint exposed
• HIGH: Idle worker pool burning compute — averages 3% CPU, 4 replicas running — save $140/mo
• HIGH: Single-AZ cache with no failover
• MEDIUM: Uncompressed S3 backups growing at current rate
• MEDIUM: API gateway has no rate limiting configured

For complex multi-provider scans, GPT-5.4 Thinking or Claude Opus 4.6 provides deeper reasoning. For routine health checks, Gemma 4 via Ollama (gemma4:31b, local, free) costs nothing to run continuously. The BYOK model selection is per-query — the FAQ covers how model switching works within a single workspace session.

---

Building Custom Agents Against the MCP Workspace

The workspace is not limited to OpenClaw, Hermes, and Claude Code. Any agent that speaks the MCP protocol can connect. Clanker Cloud provides Python and Node.js client examples in the documentation for teams building custom agents.

Python (HTTP transport):

import httpx

MCP_URL = "http://127.0.0.1:39393"

def query_infra(question: str) -> dict:
    response = httpx.post(
        f"{MCP_URL}/mcp",
        json={
            "jsonrpc": "2.0",
            "method": "tools/call",
            "params": {
                "name": "clanker_route_question",
                "arguments": {"question": question}
            },
            "id": 1
        }
    )
    return response.json()

# Agent queries live infra before making a decision
health = query_infra("Are all services in production healthy?")

Custom agents built against the workspace inherit all three security properties automatically: loopback binding, local credential custody, and Maker Mode gates on any write operations they trigger through clanker_run_command. You build the agent logic; the workspace handles infrastructure access. The trust boundary stays on your machine.

---

FAQ

What is an MCP infrastructure workspace?

An MCP infrastructure workspace is a persistent local process that exposes a Model Context Protocol interface for querying live infrastructure state. AI agents register against it once and can query current health, topology, cost, and configuration data at any point during a task, without holding cloud credentials themselves.

How does an MCP workspace differ from a standard MCP server?

A standard MCP server is often initialized per session — the agent connects, calls tools, and the connection terminates. A persistent MCP workspace runs continuously, accumulates context across sessions, and supports state-change detection over time. Agents querying a persistent workspace can detect that a service degraded between the 9:00 am and 9:30 am health checks, a pattern that ephemeral connections cannot support.

Can multiple AI agents share one MCP workspace simultaneously?

Yes. Multiple agents — Claude Code, OpenClaw, Hermes, Codex, or custom Python/Node.js agents — can connect to the same Clanker Cloud MCP workspace simultaneously. Each agent sends its own queries and receives independent responses. The workspace handles routing to the appropriate provider API for each query. None of the connected agents holds credentials or can make infrastructure changes without Maker Mode approval.

What models can I use with the MCP workspace?

The workspace uses BYOK (bring your own keys). You configure your preferred AI provider keys locally — Anthropic (Claude Opus 4.6, Sonnet 4.6), OpenAI (GPT-5.4 Thinking, GPT-5.4 Pro, gpt-oss-120b), Google (Gemini 3.1 Pro, Gemini 3 Flash), Cohere (Command A, 256K context), or local models via Ollama (Gemma 4 at gemma4:31b, Hermes 3 at hermes3:70b, both MIT licensed and free to run). Model costs are billed directly by your AI provider. No markup, no bundled token allowances.

---

Start Using the MCP Workspace

Your AI agents are operating with incomplete information today. They do not know your redis is degraded. They do not know your checkout-api is under load. They do not know what your last deployment changed. They are generating confident answers from training data and prompt context — without live infrastructure truth.

A persistent MCP infrastructure workspace closes that gap. One running process. Three MCP tools. All your providers. Any MCP-compatible agent.

Start with the Free Beta account — no cost during beta, BYOK model usage billed directly by your provider. Connect to the demo to see live infrastructure queries in action. The for-agents documentation covers the full MCP integration reference, and the Clanker Cloud docs include client examples for Python, Node.js, and every supported agent.

Teams moving fast with AI-assisted development — vibe-coding to production — need infrastructure context that moves at the same speed. The MCP workspace is that context layer. It runs on your machine, reads your credentials, and gives your agents the live infrastructure truth they need to make the right call.