🚀 Update (Sep 8): the suite is now 11 servers (added Grafana) and is live on Product Hunt today → https://www.producthunt.com/products/dockndevai-mcp-server-suite — feedback + support very welcome!
Giving an AI agent access to production infrastructure is a great way to move fast — and a great way to have it drop a database because a prompt was ambiguous. I wanted the upside without the footguns, so I built a family of Model Context Protocol servers that share one safe-by-default governance model.
The problem
MCP lets an agent call tools. For infra, those tools can be delete_topic, DROP TABLE, delete_resource_group. The usual answer is "just don't expose the dangerous ones" — but then the server isn't useful when you do need them. I wanted graduated, explicit control instead.
The governance model
Every server shares the same layered policy engine:
-
Access modes —
read-only→read-write→admin. Tools above the current mode are never even registered, so the model can't call what it can't see. - Allowlists — scope to specific realms / namespaces / topics / databases / projects / subscriptions.
-
Protected resources — system/prod resources (kube-system, the
systemDB, internal Kafka topics, the master realm) are readable but never mutable. -
Destructive gating — deletes need an explicit
ALLOW_DELETEflag on top of admin mode. -
Typed confirmation — high-impact ops (delete a project / resource group) require a
confirmvalue that echoes the exact target name. A boolean isn't enough. - Secret redaction — credentials are stripped before anything reaches the model.
- Dry-run + audit — preview writes without executing; every guarded op emits a JSON audit line to stderr.
The servers
All MIT-licensed, TypeScript, published on npm as @dockndevai/mcp-*:
- mcp-kubernetes — pods, logs, deployments, scale/restart, apply, exec
- mcp-kafka — topics, consumer groups + lag, create/alter/reset
- mcp-clickhouse — schema, queries, SQL-classified read/write/destructive gating
- mcp-debezium — CDC connector status, config, lifecycle
- mcp-oci — Oracle Cloud discovery + Terraform generation
- mcp-azure — Azure Resource Manager inventory, tags, VM power, lifecycle
- mcp-azure-devops — boards, repos, pipelines, projects
- mcp-keycloak — realms, users, clients, roles, groups
Try one
npx -y @dockndevai/mcp-kubernetes
Or in Claude Code:
claude mcp add kubernetes -e KUBECONFIG_PATH=~/.kube/config -e K8S_MODE=read-only -- npx -y @dockndevai/mcp-kubernetes
Every repo has per-client setup for Claude, Cursor, Codex, VS Code, and Windsurf.
Repos: https://github.com/dockndevai
I'd love feedback — especially on whether the mode + typed-confirmation split is the right default for infrastructure MCP servers.
Update — v0.1.1: machine-readable safety
Every tool across all 8 servers now ships MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint), derived automatically from each tool's access capability. The safe-by-default model is no longer just documented in the README — the host can read it and decide what to auto-approve versus prompt on. A test keeps every hint consistent with its tool's capability. Live now on npm and the official MCP registry.
Top comments (1)
Author here 👋 The design call I went back and forth on most: should destructive ops (delete, DROP, apply) need admin mode plus an explicit opt-in flag, or just admin mode? I landed on both — a fresh install can't delete anything, even in admin, until you set e.g. KAFKA_ALLOW_DELETE=true. And as of v0.1.1 every tool now advertises readOnlyHint/destructiveHint so the host knows before it runs. Curious what your default posture is when handing infra to an agent — read-only forever, or graduated trust?