MimiOps mcp server for Kubernetes

Mimiops MCP Server

Motivation

There are many ways to manage Kubernetes workloads, but there are also many ways to break them by accident. We have already seen cases where AI agents did something that we did not expect. Giving an AI agent full access to Kubernetes can be risky, especially when it can create, update, or delete resources directly.

In my opinion, we need to provide safe and well-defined tools for AI agents. These tools should limit what an agent can do, validate changes before applying them, and help prevent dangerous operations.

We also need tools that can help investigate and fix workload issues. Many workloads are already managed by well-known tools such as Argo CD, FluxCD, Helm, and other GitOps or deployment systems. An AI agent should understand who manages a resource and avoid making direct changes that can conflict with these tools.

The goal is not to give AI full control of Kubernetes. The goal is to give AI a safe interface that allows it to understand problems, suggest changes, and perform only controlled operations.

Overview

Mimi OPS is not designed to give AI agents unrestricted Kubernetes access. Instead, it provides a small set of well-known and controlled operations.

The agent can observe, investigate, and perform a limited number of safe recovery actions. More dangerous operations, such as editing arbitrary resources, applying YAML, changing secrets, or deleting persistent data are strongly restricted.

This makes Mimi OPS an opinionated interface between AI agents and Kubernetes: powerful enough for common troubleshooting, but limited enough to reduce the risk of unexpected changes.

Keep your AI on the leash.

Kubernetes core tools

Core tools are always registered. The names below are the MCP tool names exposed by the server:

• Clusters: clusterslist (multi-cluster configurations only), clustersdescribe.
• Pods: podslist, podsget, podsdescribe, podslog.
• Jobs: jobslist, jobsget, jobsdescribe, jobslog, jobs_create.
• CronJobs: cronjobslist, cronjobsget, cronjobs_describe.
• Nodes: nodeslist, nodesget, nodes_describe.
• Namespaces: namespaceslist, namespacesdescribe.
• Resource configuration: resourcequotaslist, resourcequotasdescribe, limitrangeslist, limitrangesdescribe, storageclasseslist, persistentvolumeclaimslist, persistentvolumeclaimsdescribe, priorityclasseslist.
• Events: events_get.
• Workloads (Deployments, StatefulSets, and DaemonSets): workloadslist, workloadsget, workloads_describe.
• Autoscaling: hpalist, hpadescribe.
• Services: serviceslist, servicesdescribe.

The following additional recovery tools are registered only when --allow-destructive is enabled:

• pods_delete — delete a pod so its controller can recreate it.
• jobs_delete — delete a Job.
• cronjobssuspend, cronjobsresume — suspend or resume scheduled runs.
• workloads_scale — scale a Deployment, StatefulSet, or DaemonSet.

Helm extension

Helm tools are enabled by default with --extensions helm:

• helm_list — list Helm releases.
• helm_status — inspect release status, revision, and related information.
• helm_rollback — roll back a release to its previous revision; available only with --allow-destructive.

FluxCD extension

Enable FluxCD tools with --extensions fluxcd (or --extensions all). Read-only inspection tools include:

• GitRepository: fluxgitrepositorieslist, fluxgitrepositoriesdescribe.
• OCIRepository: fluxocirepositorieslist, fluxocirepositoriesdescribe.
• HelmRelease: fluxhelmreleaseslist, fluxhelmreleasesdescribe.
• Kustomization: fluxkustomizationslist, fluxkustomizationsdescribe.

With --allow-destructive, Flux also exposes:

• flux_reconcile — trigger an immediate reconciliation of a GitRepository, HelmRelease, or Kustomization.
• flux_reconciliation — suspend or resume a Flux HelmRelease or Kustomization.

Shortened. The full README is on GitHub.