Polycrate MCP: KI-Assistenten mit Live-Infrastruktur-Kontext verbinden | Blog

TL;DR

Das Model Context Protocol (MCP) ist ein offener Standard: KI-Clients sprechen per JSON-RPC mit Hilfsprogrammen über stdin/stdout (stdio).
polycrate mcp startet genau solch einen MCP-Endpunkt: Er wird vom Client bei Bedarf als Subprozess gestartet – kein separater Dienst, den Sie im Workspace-Root mit cd … „hochfahren“, und nicht der Befehl polycrate mcp server (den es so nicht gibt).
Die mitgelieferten Tools liefern u. a. Polycrate Hub (Blöcke suchen, inspizieren, Versionen), offizielle Dokumentation (docs_get), Schema-Hilfen für workspace.poly / block.poly / CHANGELOG.poly / secrets.poly, Guides (Ansible, Registry, Debugging, Best Practices) sowie CLI-Metadaten (Versionen, Artefakte).
Lokale Workspace-Dateien (Playbooks, inventory.yml, Logs) spiegelt Polycrate MCP nicht automatisch. Dort hilft die IDE (z. B. Cursor), die Ihr Projekt ohnehin einliest – in Kombination mit den MCP-Tools entsteht der volle Kontext.
Vollständige Referenz: MCP Server Integration.

Warum reine KI ohne Polycrate-Kontext an Grenzen stößt

KI-Assistenten sind stark bei allgemeinen Ansible- oder YAML-Fragen – aber schwach, wenn es um Ihre Plattform-Standards, freigegebene Blöcke im Hub und korrekte *.poly-Strukturen geht. Ohne Zugriff auf aktuelle Dokumentation und Hub-Daten raten Modelle leicht daneben.

Polycrate MCP füllt genau diese Lücke: kuratierte Quellen (Hub, Docs, eingebettete Guides und Schemas) statt nur „Internetwissen“.

Wie MCP technisch funktioniert (und was `polycrate mcp` tut)

Stdio-Prozess, kein Dauer-Server im Projektverzeichnis

Der Polycrate-MCP-Prozess kommuniziert per stdio (JSON-RPC). Typischer Ablauf:

Sie tragen in Cursor, Claude Desktop oder VS Code / Copilot ein, dass der Befehl polycrate mit dem Argument mcp gestartet werden soll.
Wenn die KI ein MCP-Tool braucht, startet der Client diesen Prozess, spricht mit ihm, und beendet die Sitzung wieder – Sie müssen keinen MCP-Prozess manuell in einem Terminal laufen lassen und nicht „ins Workspace-Verzeichnis wechseln“, damit MCP funktioniert (Polycrate muss nur im PATH liegen oder mit vollem Pfad konfiguriert sein).

Die offizielle Doku formuliert: Sie müssen den Server in der Regel nicht manuell starten – die Clients tun das anhand der Konfiguration. Siehe MCP Server Integration.

Was Polycrate MCP nicht ist

Kein Ersatz für Ihr Inventory oder Ihre Playbooks: Es gibt keine Tools, die „den gesamten Workspace“ wie ein Dateisystem exportieren.
Kein Kanal, über den polycrate run … aus der KI heraus ausgeführt wird – Ausführung bleibt bei Ihnen im Terminal (oder CI).

Welche Tools Polycrate bereitstellt

Die genaue Liste steht in der Dokumentation; kurz die Kategorien:

Kategorie	Beispiele	Zweck
Hub	`hub_info`, `hub_list_blocks`, `hub_inspect_block`, `hub_list_versions`	Blöcke im Hub finden, README/Metadaten, Versionen
CLI	`cli_get_latest_version`, `cli_list_versions`, `cli_get_artifacts`	Release-Infos, Download-URLs, Docker-Tags
Spec	`spec_workspace`, `spec_block`, `spec_changelog`, `spec_secrets`	Korrekte Struktur für `*.poly`-Dateien
Guides	u. a. `guide_create_workspace`, `guide_ansible_patterns`, `guide_registry_workflow`, `guide_debugging`, `guide_best_practices`	Eingebettete Best Practices für Assistenten
Dokumentation	`docs_get` mit `topic`	Abruf ausgewählter Seiten der Polycrate-Doku (konfigurierbare Basis-URL)

Für docs_get gibt es eine feste Liste von Topics (u. a. workspaces, blocke, best-practices, ansible, registry, mcp) – siehe die Tabelle in der MCP-Dokumentation.

Eigene Doku-URL: In ~/.polycrate/polycrate.yml können Sie hub.docs_url setzen (z. B. lokales mkdocs serve oder eine interne Spiegelung). Standard ist die öffentliche Dokumentation.

Einrichtung: Cursor, Claude Desktop, GitHub Copilot

Die Konfiguration ist in der Regel ein JSON-Snippet mit command: polycrate und args: ["mcp"].

Cursor: ~/.cursor/mcp.json – siehe MCP-Dokumentation.
Claude Desktop: plattformabhängige Pfade zu claude_desktop_config.json (macOS, Linux, Windows) – gleiche Doku.
GitHub Copilot (VS Code): .vscode/mcp.json im Workspace oder globale Einstellung github.copilot.chat.mcpServers – Doku.

Nach Änderungen: Client neu starten. Wenn polycrate nicht im PATH ist, in der Konfiguration den vollständigen Pfad zur Binary angeben (Troubleshooting in der Doku).

Workspace, Inventory und Ansible: Kontext richtig kombinieren

Das folgende Beispiel zeigt einen typischen Polycrate-Workspace mit Linux-Patching – unabhängig von MCP: So sieht workspace.poly, ein Block und ein inventory.yml im Root aus.

# workspace.poly
name: acme-corp-automation
organization: acme

blocks:
  - name: linux-patch
    from: registry.acme-corp.com/acme/linux/linux-patch:1.0.0
    config:
      target_hosts_group: linux_servers

# blocks/linux-patch/block.poly (vereinfacht, lokaler Block während der Entwicklung)
name: linux-patch
version: 0.1.0
kind: generic

config:
  target_hosts_group: linux_servers

actions:
  - name: patch
    description: "Linux-Systeme patchen"
    playbook: patch.yml

# inventory.yml (Workspace-Root)
all:
  children:
    linux_servers:
      hosts:
        server01.acme-corp.com:
          ansible_user: ubuntu
        server02.acme-corp.com:
          ansible_user: ubuntu

MCP liefert dazu z. B. per docs_get die Abschnitte zu Ansible und Best Practices; per hub_inspect_block können Sie einen öffentlichen Hub-Block prüfen, den Sie per from: einbinden. Ihre inventory.yml und Playbooks ließt die KI in Cursor über das Projekt – nicht über einen separaten „Workspace-Export“ von Polycrate MCP.

Praxis: Debugging und Design mit IDE + MCP

Fehler nach polycrate run linux-patch patch: Terminalausgabe und Dateien (inventory.yml, patch.yml, block.poly) liegen im Editor – die KI analysiert sie dort. Parallel kann sie per MCP docs_get mit Topic ansible oder troubleshooting ziehen oder guide_debugging nutzen.
Neuen Workspace planen: Assistent nutzt spec_workspace, sucht mit hub_list_blocks passende Blöcke und verifiziert mit hub_inspect_block README und Konfiguration.
CHANGELOG-Eintrag: spec_changelog liefert das erwartete Format für CHANGELOG.poly.

So ist der „Infrastruktur-Kontext“ zweigleisig: Projektdateien (IDE) + Polycrate-spezifisches Wissen (MCP).

Sicherheit und Datenfluss (laut Dokumentation)

Der MCP-Prozess läuft lokal.
Kommunikation zum Hub erfolgt über HTTPS; es werden keine Credentials an das Modell „zur Tool-Antwort“ geschickt, es werden öffentliche Hub-Daten abgerufen.
Was die KI aus Ihrem Repo sieht, steuern Sie über die IDE und Zugriffsrechte – das ist nicht identisch mit den MCP-Tool-Antworten.

Details: MCP – Sicherheit und Workspace-Verschlüsselung.

Häufige Fragen

Gibt es `polycrate mcp server`?

Nein. Der Unterbefehl heißt polycrate mcp.

Muss ich den MCP-Prozess im Workspace-Verzeichnis starten?

Nein. Sie konfigurieren nur den Aufruf von polycrate mit Argument mcp. Das aktuelle Arbeitsverzeichnis für Ihre Shell ist dafür irrelevant; wichtig ist, dass die Binary gefunden wird.

Exportiert Polycrate MCP mein lokales Inventory automatisch?

Nein. Nutzen Sie die Dateiansicht / Kontext der IDE, oder fügen Sie relevante Auszüge in den Chat ein.

Führt MCP `polycrate run` aus?

Nein. Ausführung bleibt bei Ihnen.

Weitere Fragen: FAQ.

Von der Theorie zur Umsetzung

Polycrate MCP ist kein „magischer Workspace-Spiegel“, sondern eine präzise Brücke zwischen KI-Assistenten und Hub, Dokumentation, Schemas und Guides. Gemeinsam mit der IDE wird daraus ein starker Workflow für Plattform- und Automatisierungsteams.

ayedo entwickelt Polycrate und begleitet Teams bei der Einbindung in moderne Platform-Engineering-Prozesse.

Übersicht und Termine: Workshops.