Mimiops MCP Server

Motivation

Es gibt viele Möglichkeiten, Kubernetes-Workloads zu verwalten, aber auch viele Möglichkeiten, sie versehentlich zu beschädigen. Wir haben bereits Fälle gesehen, in denen KI-Agenten etwas getan haben, das wir nicht erwartet haben. Einem KI-Agenten vollen Zugriff auf Kubernetes zu geben, kann riskant sein, insbesondere wenn er Ressourcen direkt erstellen, aktualisieren oder löschen kann.

Meiner Meinung nach müssen wir sichere und klar definierte Werkzeuge für KI-Agenten bereitstellen. Diese Werkzeuge sollten einschränken, was ein Agent tun kann, Änderungen validieren, bevor sie angewendet werden, und helfen, gefährliche Operationen zu verhindern.

Wir brauchen auch Werkzeuge, die helfen, Workload-Probleme zu untersuchen und zu beheben. Viele Workloads werden bereits von bekannten Tools wie Argo CD, FluxCD, Helm und anderen GitOps- oder Bereitstellungssystemen verwaltet. Ein KI-Agent sollte verstehen, wer eine Ressource verwaltet, und direkte Änderungen vermeiden, die mit diesen Tools in Konflikt geraten könnten.

Das Ziel ist nicht, KI die volle Kontrolle über Kubernetes zu geben. Das Ziel ist es, KI eine sichere Schnittstelle zu geben, die es ermöglicht, Probleme zu verstehen, Änderungen vorzuschlagen und nur kontrollierte Operationen durchzuführen.

Related MCP server: mcp-devops-server

Übersicht

Mimi OPS ist nicht dafür ausgelegt, KI-Agenten uneingeschränkten Kubernetes-Zugriff zu geben. Stattdessen bietet es eine kleine Menge bekannter und kontrollierter Operationen.

Der Agent kann beobachten, untersuchen und eine begrenzte Anzahl sicherer Wiederherstellungsaktionen durchführen. Gefährlichere Operationen wie das Bearbeiten beliebiger Ressourcen, das Anwenden von YAML, das Ändern von Geheimnissen oder das Löschen persistenter Daten sind stark eingeschränkt.

Das macht Mimi OPS zu einer eigenen Schnittstelle zwischen KI-Agenten und Kubernetes: leistungsstug genug für häufige Fehlerbehebung, aber begrenzt genug, um das Risiko unerwarteter Änderungen zu verringern.

Kubernetes-Basiswerkzeuge:

• Pods

  • list — Pods und ihren aktuellen Status auflisten.

  • get — detaillierte Informationen über einen Pod abrufen.

  • describe — Pod-Status, Bedingungen, Ereignisse und zugehörige Informationen untersuchen.

  • logs — Container-Logs zur Fehlerbehebung lesen.

  • delete — einen Workload sicher neu starten, indem ein Pod gelöscht wird und sein Controller ihn neu erstellen kann.

• CronJobs und Jobs

  • list — CronJobs und Jobs auflisten.

  • get — Informationen über eine bestimmte Ressource abrufen.

  • describe — Status, Bedingungen, Ereignisse und Fehler untersuchen.

• Deployments, StatefulSets und DaemonSets

  • list — Workloads und ihren aktuellen Status auflisten.

  • get — Informationen über einen bestimmten Workload abrufen.

  • describe — Replikate, Rollout-Status, Bedingungen und zugehörige Ereignisse untersuchen.

Helm-Integration

Mimi OPS kann Helm-verwaltete Workloads untersuchen und helfen, sie wiederherzustellen, wenn eine Bereitstellung fehlschlägt:

• list — Helm-Releases auflisten.

• describe — Release-Informationen, Status, Revision und zugehörige Ressourcen anzeigen.

• rollback — ein Release auf eine frühere funktionierende Revision zurücksetzen, wenn das aktuelle Release in einem defekten Zustand ist.

FluxCD-Integration

Mimi OPS kann mit FluxCD-verwalteten Ressourcen arbeiten, ohne Ressourcen direkt zu ändern, die von GitOps kontrolliert werden:

• Flux-Quellressourcen abgleichen, um die neueste Konfiguration abzurufen.

• HelmRelease-Ressourcen abgleichen, um den erwarteten Helm-Zustand erneut zu versuchen oder anzuwenden.

• Abgleichstatus und Fehler untersuchen, um zu verstehen, warum eine Bereitstellung nicht bereit ist.

Installation

Ein Kubernetes-MCP (Model Context Protocol)-Server, geschrieben in Go. Er stellt MCP-Clients (Claude Desktop, Cursor, VS Code usw.) Kubernetes-Operationen über zwei Transports bereit:

• mimiops-mcp mcp — stdio, für Desktop-MCP-Clients.

• mimiops-mcp server — HTTP/SSE, für Web-/Remote-MCP-Clients.

Betrieb

Allgemeine Flags

Flags sind global (persistent) und werden von beiden Unterbefehlen akzeptiert:

Flags pro Befehl:

Beispiele

# stdio against a specific context
./bin/mimiops-mcp mcp --kubeconfig ~/.kube/dev.yaml --context prod-east

# SSE server scoped to a namespace, with destructive tools enabled
./bin/mimiops-mcp server --namespace default --allow-destructive --port 8080

Entwicklung

make lint       # golangci-lint
make unit       # unit tests (build tag `unit`)
make test       # lint + unit
make licenses   # license audit (forbidden/restricted/unknown)
make docs       # (Docker image docs targets are also available; see `make help`)

Verwenden Sie make help für eine vollständige Zielliste.

Lizenz

Apache-2.0