Safe-by-Default MCP Servers for Kubernetes, Kafka and Cloud Ops

Letting an AI agent touch production infrastructure is an easy way to move quickly. It's also an easy way to lose a database because a prompt was a little vague. The Model Context Protocol (MCP) makes it trivial to give an agent tools like "list the pods," "restart the deployment" and "run this query." For infrastructure, though, the same mechanism can just as easily hand over delete_topic, DROP TABLE or delete_resource_group. The standard advice is to leave out the dangerous tools, but then the server stops being useful right when you need those operations.

One answer is a family of eight MCP servers built around a single principle. Each is safe by default, and you raise its power on purpose. Here's how the design works and what the suite covers.

The policy engine

All eight servers share one policy engine, built from four ideas.

Access modes in layers. A server begins in read-only mode. Moving to read-write and then to admin takes a deliberate change to an environment variable. The key detail is that tools above the current mode are never registered at all. In read-only mode, the agent doesn't see a delete tool that it politely declines to call. The tool simply isn't in its list, and you can't misuse something that doesn't exist.

Allowlists and protected resources. A server can be restricted to named namespaces, topics, databases, projects or subscriptions. Certain resources can also be marked protected, such as the kube-system namespace, an internal Kafka topic or the master realm in Keycloak. Protected resources stay readable but are never changeable, even in admin mode.

Destructive actions behind a second switch. Deletes and other irreversible operations require admin mode plus a separate opt-in, for example KAFKA_ALLOW_DELETE=true. A fresh install can't destroy anything, even at the highest mode, until you've confirmed twice.

A visible audit trail. Every action emits a structured JSON line on stderr with secrets redacted, so what the agent did is easy to see afterward.

What you get is a dial and not a switch. Trust gets handed over in steps you control, instead of a choice between a useless server and a frightening one.

Making the safety model machine-readable

Through version 0.1.1, the safety model lived only in the README. People could read it, but the application hosting the agent (Claude Desktop, Cursor, Copilot) couldn't.

MCP already has a feature for this: tool annotations. A tool can advertise structured hints, namely readOnlyHint, destructiveHint, idempotentHint and openWorldHint, which the host uses to decide what to approve automatically and what to stop and ask about.

Those hints are now set on every tool across all eight servers, derived automatically from each tool's access level. A read tool declares itself read-only and non-destructive. A delete tool declares itself destructive. That lets the host judge a tool's blast radius before running it, using structured metadata instead of parsing an English description and hoping for the best. A test checks that every hint matches the tool it describes. The difference is between "trust us, it's safe" and a claim that can be verified by machine.

The eight servers

Every server is MIT-licensed, written in TypeScript, and installable with one npx command.

• mcp-kubernetes covers pods, logs, deployments, scaling and restarts, apply and exec.
• mcp-kafka handles topics, consumer groups and lag, plus create, alter and reset operations.
• mcp-clickhouse exposes schemas and queries, and classifies SQL as read, write or destructive to gate each statement.
• mcp-debezium manages change-data-capture connectors, including status, configuration and lifecycle.
• mcp-oci discovers Oracle Cloud resources and generates Terraform.
• mcp-azure works with Azure Resource Manager for inventory, tags, VM power state and lifecycle.
• mcp-azure-devops reaches boards, repos, pipelines and projects.
• mcp-keycloak covers realms, users, clients, roles and groups.

Trying one

Adding a server to Claude Code takes a single line, and it starts out in read-only mode:

claude mcp add kubernetes -e K8S_MODE=read-only -- npx -y @dockndevai/mcp-kubernetes

Each repository documents setup for Claude, Cursor, Codex, VS Code and Windsurf. Source code is on GitHub and the packages are published to npm.

The open question

One design choice invites debate: demanding both admin mode and a per-operation opt-in flag before a destructive action runs. Is that too strict for real workflows, or exactly the right default when infrastructure is going to an agent? Teams land in different places, from read-only forever to graduated trust that expands as confidence grows. Whichever posture fits, the core design holds up: make the safest behavior the default and require clear, deliberate steps to loosen it.