Octopus Deploy Official MCP Server

[!WARNING] Veraltet: Dieser MCP-Server ist veraltet. Der Remote-MCP-Server ist in Octopus Server 2026.3 und später verfügbar. Siehe die Remote-MCP-Server-Dokumentation.

Octopus Deploy Official MCP Server

Octopus macht es einfach, Software an Kubernetes, Multi-Cloud, On-Premises-Infrastruktur und überall sonst auszuliefern. Automatisieren Sie Release, Deployment und Betrieb Ihrer Software- und KI-Workloads mit einem Tool, das CD in großem Maßstab auf eine Weise bewältigen kann, wie es kein anderes Tool kann.

Model Context Protocol (MCP) ermöglicht es den KI-Assistenten, die Sie in Ihrer täglichen Arbeit verwenden, wie Claude Code oder ChatGPT, sich auf standardisierte Weise mit den Systemen und Diensten zu verbinden, die Sie besitzen, sodass sie Informationen aus diesen Systemen und Diensten abrufen können, um Fragen zu beantworten und Aufgaben auszuführen.

Der Octopus-MCP-Server bietet Ihrem KI-Assistenten leistungsstarke Tools, mit denen er Probleme in Ihrer Octopus-Instanz untersuchen, abfragen und diagnostizieren kann – und wird so zu Ihrem ultimativen DevOps-Begleiter. Eine Liste der unterstützten Anwendungsfälle und Beispiel-Prompts finden Sie in unserer Dokumentation.

Octopus-Server-Kompatibilität

Die meisten vom MCP-Server bereitgestellten Tools verwenden stabile APIs, die mindestens seit Version 2021.1 des Octopus-Servers verfügbar sind. Neuere Tools geben die mindestens unterstützte Version in der Dokumentation an. Alternativ können Sie das Befehlszeilenargument --list-tools-by-version verwenden, um zu prüfen, wie bestimmte Tools mit Octopus-Versionen zusammenhängen.

🚀 Installation

Installation über Docker

Anmeldeinformationen müssen über Umgebungsvariablen bereitgestellt werden, um sie nicht in der Host-Prozessliste offenzulegen (ps aux / /proc/<pid>/cmdline). Die Octopus-Server-URL kann weiterhin über das --server-url-Flag angegeben werden.

docker run -i --rm -e OCTOPUS_API_KEY=your-key -e OCTOPUS_SERVER_URL=https://your-octopus.com octopusdeploy/mcp-server

Vollständige Beispielkonfiguration (für Claude Desktop, Claude Code und Cursor):

{
  "mcpServers": {
    "octopus-deploy": {
      "type": "stdio",
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "OCTOPUS_SERVER_URL",
        "-e",
        "OCTOPUS_API_KEY",
        "octopusdeploy/mcp-server"
      ],
      "env": {
        "OCTOPUS_SERVER_URL": "https://your-octopus.com",
        "OCTOPUS_API_KEY": "YOUR_API_KEY"
      }
    },
  }
}

Für Apple-Mac-Benutzer kann es erforderlich sein, die folgenden Argumente in der Konfiguration hinzuzufügen, um Docker zu zwingen, die Linux-Plattform zu verwenden:

"--platform",
"linux/amd64",

Wir planen, in Kürze einen nativen ARM-Build zu veröffentlichen, sodass diese Argumente nicht mehr erforderlich sein werden.

Installation über Node

Voraussetzungen

• Node.js >= v20.0.0
• Octopus-Deploy-Instanz, auf die der MCP-Server über HTTPS zugreifen kann
• Octopus-Deploy-API-Schlüssel oder Zugriffstoken (siehe Authentifizierung unten)

Konfiguration

Vollständige Beispielkonfiguration (für Claude Desktop, Claude Code und Cursor):

Schreibtools aktiviert (Standard):

{
  "mcpServers": {
    "octopusdeploy": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@octopusdeploy/mcp-server"],
      "env": {
        "OCTOPUS_SERVER_URL": "https://your-octopus.com",
        "OCTOPUS_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

Nur-Lese-Modus (für die Produktion empfohlen):

{
  "mcpServers": {
    "octopusdeploy": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@octopusdeploy/mcp-server", "--read-only"],
      "env": {
        "OCTOPUS_SERVER_URL": "https://your-octopus.com",
        "OCTOPUS_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

Der Octopus-MCP-Server wird normalerweise in Ihrem KI-Client Ihrer Wahl konfiguriert.

Er ist als npm-Paket verpackt und wird über den npx-Befehl von Node ausgeführt. Anmeldeinformationen (API-Schlüssel oder Zugriffstoken) müssen über Umgebungsvariablen bereitgestellt werden – sie werden nicht als Befehlszeilenargumente akzeptiert, um Geheimnisse nicht in der Prozessliste offenzulegen. Die Octopus-Server-URL kann entweder über die OCTOPUS_SERVER_URL-Umgebungsvariable oder das --server-url-Flag angegeben werden.

OCTOPUS_API_KEY=API-KEY \
OCTOPUS_SERVER_URL=https://your-octopus.com \
npx -y @octopusdeploy/mcp-server

Oder mit der Server-URL in der Befehlszeile:

OCTOPUS_API_KEY=API-KEY \
npx -y @octopusdeploy/mcp-server --server-url https://your-octopus.com

Authentifizierung

Der MCP-Server unterstützt zwei Authentifizierungsmethoden. Beide werden über Umgebungsvariablen bereitgestellt – Anmeldeinformationen werden nicht in der Befehlszeile akzeptiert, da Flags in der Host-Prozessliste für jeden lokalen Benutzer sichtbar sind.

API-Schlüssel (für interaktive Nutzung empfohlen)

API-Schlüssel sind die Standard-Authentifizierungsmethode für Octopus Deploy. Sie können einen aus Ihrem Octopus-Deploy-Benutzerprofil generieren.

OCTOPUS_API_KEY=API-XXXXXXXXXXXXXXXXXXXXXXXXXX \
OCTOPUS_SERVER_URL=https://your-octopus.com \
npx -y @octopusdeploy/mcp-server

Zugriffstoken / Bearer-Token (nur für automatisierte Szenarien)

Der Server unterstützt auch kurzlebige Zugriffstoken (Bearer-Token) als Alternative zu API-Schlüsseln. Diese Authentifizierungsmethode ist nur für automatisierte Szenarien gedacht, in denen ein externes System ein kurzlebiges Token an den MCP-Server ausstellt (z. B. CI/CD-Pipelines, automatisierte Orchestrierung oder Machine-to-Machine-Workflows). Verwenden Sie keine langlebigen Bearer-Token – verwenden Sie stattdessen API-Schlüssel für interaktive oder langlebige Sitzungen.

OCTOPUS_ACCESS_TOKEN=your-short-lived-token \
OCTOPUS_SERVER_URL=https://your-octopus.com \
npx -y @octopusdeploy/mcp-server

Vollständige Beispielkonfiguration mit einem Zugriffstoken:

{
  "mcpServers": {
    "octopusdeploy": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@octopusdeploy/mcp-server"],
      "env": {
        "OCTOPUS_SERVER_URL": "https://your-octopus.com",
        "OCTOPUS_ACCESS_TOKEN": "YOUR_TOKEN"
      }
    }
  }
}

Wenn sowohl ein API-Schlüssel als auch ein Zugriffstoken bereitgestellt werden, hat das Zugriffstoken Vorrang. Die aktive Authentifizierungsmethode wird in der Protokolldatei aufgezeichnet (konfigurierbar mit --log-file), sodass Betreiber bestätigen können, welche Anmeldeinformationen verwendet werden.

Konfigurationsoptionen

Der Octopus-MCP-Server unterstützt mehrere Befehlszeilenoptionen, um anzupassen, welche Tools verfügbar sind.

Wenn Sie nicht sicher sind, welche Tools Sie benötigen, empfehlen wir, ohne zusätzliche Befehlszeilenoptionen auszuführen und die bereitgestellten Standardeinstellungen zu verwenden.

Toolsets

Verwenden Sie den Parameter --toolsets, um bestimmte Gruppen von Tools zu aktivieren:

# Enable all toolsets (default)
npx -y @octopusdeploy/mcp-server

# Enable only specific toolsets
npx -y @octopusdeploy/mcp-server --toolsets projects,deployments

# Enable all toolsets explicitly
npx -y @octopusdeploy/mcp-server --toolsets all

Verfügbare Toolsets:

• core – Grundlegende Operationen (immer aktiviert)
• projects – Projektoperationen
• deployments – Deployment-Operationen
• releases – Release-Verwaltung
• runbooks – Runbook-Erkennung und -Ausführung
• tasks – Aufgabenoperationen
• tenants – Multi-Tenancy-Operationen
• kubernetes – Kubernetes-Operationen
• machines – Deployment-Zieloperationen
• certificates – Zertifikatsoperationen
• accounts – Kontenoperationen
• interruptions – Manuelle Eingriffs- und Genehmigungsoperationen
• featureToggles – Kunden-Feature-Toggles untersuchen und anpassen
• context – Authentifizierter Benutzer- und Projektkontext (aktueller Benutzer, Git-Zweige)

Nur-Lese-Modus

Der Server läuft standardmäßig mit aktivierten Schreibtools. Übergeben Sie --read-only, um alle Schreibtools zu deaktivieren und POST/PUT/PATCH/DELETE über den execute-Backstop zu blockieren. Die meisten kuratierten Tools sind bereits nur lesbar; nur eine kleine Gruppe führt Schreibvorgänge aus.

Schreibaktivierte Tools (immer schreibend):

• create_release – Neue Releases erstellen
• deploy_release – Releases in Umgebungen und Tenants bereitstellen
• run_runbook – Ein Runbook gegen eine oder mehrere Umgebungen ausführen (und optionale Tenants)
• update_feature_toggle – Pro-Umgebungs-Status und Rollout-Prozentsätze für ein vorhandenes Feature-Toggle anpassen

Bedingt schreibendes Tool: execute ist ein strukturierter REST-Backstop, dessen Stufe (Lesen / Schreiben / Löschen) durch die an ihn übergebene HTTP-Methode bestimmt wird. Siehe Abschnitt API-Katalog & Backstop für Details.

Schreibtools sind durch einen MCP-Elicitation-Prompt geschützt: Clients, die Elicitation unterstützen, werden aufgefordert, zu bestätigen, bevor der Aufruf fortgesetzt wird. Clients ohne Elicitation-Unterstützung müssen confirm: true in den Tool-Argumenten übergeben – andernfalls bricht das Tool mit einem Fehler ab. Setzen Sie OCTOPUS_SKIP_ELICITATION=true, um die Sperre vollständig zu umgehen (für unbeaufsichtigte Automatisierung gedacht).

Der Server verwendet eine dreistufige Lese-/Schreib-/Lösch-Klassifizierung, die serverseitig basierend auf der HTTP-Methode erzwungen wird (der Agent kann dies nicht umgehen, indem er über die Absicht lügt):

• read – immer erlaubt. GET-Anfragen über execute, plus alle find_* / get_* / list_*-Tools.
• write – POST/PUT/PATCH über execute und die oben genannten immer schreibenden Tools. Blockiert, wenn --read-only gesetzt ist.
• delete – DELETE über execute. Erfordert --allow-deletes und wird blockiert, wenn --read-only gesetzt ist. Eine kleine Gruppe katastrophaler Löschpfade (z. B. DELETE /api/spaces/{id}, DELETE /api/users/{id}) und API-Schlüssel-Endpunkte befinden sich auf einer harten sensiblen Denylist, die beide Flags ignoriert.

# Default - write tools enabled (POST/PUT/PATCH)
npx -y @octopusdeploy/mcp-server

# Additionally permit DELETE requests through the execute tool
npx -y @octopusdeploy/mcp-server --allow-deletes

# Read-only mode - write/delete tools disabled
npx -y @octopusdeploy/mcp-server --read-only

Sicherheitshinweis: Verwenden Sie einen API-Schlüssel mit angemessenen Berechtigungen mit geringsten Rechten – Schreiboperationen können Releases erstellen und Deployments in Ihrer Octopus-Instanz auslösen. Für die Produktion sollten Sie erwägen, --read-only zu übergeben, es sei denn, Sie haben einen spezifischen, kontrollierten Anwendungsfall für Schreibvorgänge. --allow-deletes ist standardmäßig deaktiviert; aktivieren Sie es nur, wenn der Agent DELETE-Anfragen über execute senden muss. Wenn Sie --allow-deletes zusammen mit --read-only übergeben, gibt der Server eine Startwarnung an stderr aus – DELETE-Anfragen bleiben durch die Nur-Lese-Sperre blockiert.

Vollständige Beispiele

Alle Beispiele unten setzen voraus, dass OCTOPUS_API_KEY in der Umgebung gesetzt ist. Das --server-url-Flag wird zur Verdeutlichung gezeigt, kann aber auch über OCTOPUS_SERVER_URL bereitgestellt werden.

# Development setup with only core and project tools
npx -y @octopusdeploy/mcp-server --toolsets core,projects --server-url https://your-octopus.com

# Production setup with all tools and read-only enforcement
npx -y @octopusdeploy/mcp-server --toolsets all --read-only --server-url https://your-octopus.com

# Default invocation - all tools and writes enabled
npx -y @octopusdeploy/mcp-server --server-url https://your-octopus.com

Andere Befehlszeilenargumente

• --read-only – Nur-Lese-Modus aktivieren: alle kuratierten Schreibtools deaktivieren und POST/PUT/PATCH/DELETE über execute blockieren. Schreibvorgänge sind standardmäßig aktiviert; dieses Flag schaltet sie aus. Siehe Nur-Lese-Modus.
• --allow-deletes – DELETE-Anfragen über das execute-Tool zulassen. Wird ignoriert (mit einer Startwarnung), wenn --read-only gesetzt ist. Standard false.
• --log-level <level> – Minimale Protokollebene (info, error)
• --log-file <path> – Pfad oder Dateiname der Protokolldatei. Wenn nicht angegeben, werden Protokolle nur in der Konsole geschrieben
• -q, --quiet – Dateiprotokollierung deaktivieren, nur Fehler in der Konsole protokollieren
• --list-tools-by-version – Alle registrierten Tools nach ihrer unterstützten Octopus-Server-Version auflisten und beenden

🔨 Tools

URL-basierte Tools

Schnellstart: Fügen Sie Octopus-URLs direkt ein, um Probleme zu untersuchen, ohne manuelle ID-Extraktion.

• get_deployment_from_url: Deployment-Details aus der Deployment-URL abrufen (gibt taskId für Folgeaktionen zurück)
• get_task_from_url: Aufgabendetails und Protokolle aus der Aufgaben-URL abrufen

Workflow zur Deployment-Untersuchung:

1. get_deployment_from_url with deployment URL
   → Returns deployment context + taskResourceUri + grepTaskLogHint

2a. Fetch the structured activity tree via resources/read (or read_resource)
    octopus://spaces/{spaceName}/tasks/{taskId}/details

2b. Or call grep_task_log with the taskId to search the raw log without
    fetching the full body:
       grep_task_log({ spaceName, taskId, pattern: "error|fail", caseInsensitive: true })

Aufgabenuntersuchung (direkte Aufgaben-URL):

get_task_from_url with task URL
→ Returns task details and logs immediately

Diese Tools eliminieren die manuelle ID-Extraktion durch:

• Automatisches Parsen von URLs
• Auflösen von Space-IDs in Space-Namen
• Validieren von ID-Formaten
• Bereitstellen klarer Fehlermeldungen

Beispiel-URLs:

• Deployment: https://your-octopus.com/app#/Spaces-1/projects/my-app/deployments/Deployments-123
• Aufgabe: https://your-octopus.com/app#/Spaces-1/tasks/ServerTasks-456

Siehe Arbeiten mit URLs für detaillierte Workflows, Beispiele und Best Practices.

Kern-Tools

• list_spaces: Alle Spaces in der Octopus-Deploy-Instanz auflisten
• list_environments: Alle Umgebungen in einem bestimmten Space auflisten

API-Katalog & Backstop

Diese Tools und Ressourcen ermöglichen es dem Agenten, Octopus-REST-Endpunkte zu erreichen, für die es kein dediziertes kuratiertes Tool gibt, mit harter serverseitiger Trennung zwischen Lese-, Schreib- und Löschoperationen.

• grep_llms_txt: Durchsuchen Sie den Octopus-API-Katalog (octopus://api/llms.txt) mit grep-ähnlicher Semantik (mindestens unterstützte Octopus-Version: 2026.2.3916). Der Kataloginhalt ist groß (typischerweise über 300 KB) – rufen Sie dies auf, anstatt den Ressourcentext direkt zu lesen. Die Parameter spiegeln GNU grep wider (pattern, caseInsensitive, invertMatch, fixedString, beforeContext, afterContext, maxCount). Nützlich zum Entdecken von Endpunkten (POST /releases), zum Auflisten von Lösch-Endpunkten (DELETE ) oder zum Finden des Body-Typs für einen Schreibvorgang (Body: Create.*Command).
• execute: Strukturierter REST-Rückhalt. Erreicht jeden Octopus-REST-Endpunkt unter /api. Die HTTP-Methode ist der maßgebliche Lese-/Schreib-/Lösch-Klassifikator – niemals ein isWrite-Flag, das das LLM setzen kann. Die Methodensperre ist serverseitig fest codiert:
  • GET ist immer erlaubt (vorbehaltlich der Pfadformprüfung + sensiblen Denylist).
  • POST/PUT/PATCH sind blockiert, wenn --read-only gesetzt ist; andernfalls erfordern sie eine Benutzerbestätigung per Elicitation.
  • DELETE erfordert --allow-deletes (und ist blockiert, wenn --read-only gesetzt ist) plus eine stärkere „IRREVERSIBLE“-Elicitation-Nachricht.
  • Die sensible Denylist (API-Key-Endpunkte, DELETE /api/spaces/{id}, DELETE /api/users/{id}) wird auch bei beiden gesetzten Flags durchgesetzt.
  • Der Pfad muss /api sein oder mit /api/ beginnen – absolute URLs, SDK-relative ~/api/...-Pfade und host-relative Pfade außerhalb von /api (z. B. /octopus/portal/...) werden im Voraus abgelehnt, sodass execute auf die Octopus-REST-API-Oberfläche begrenzt bleibt.
  • Die Pfad-Allowlist pro Toolset gilt nur, wenn --toolsets eingeschränkt wurde. Bei jedem aktivierten Toolset (Standard oder explizit --toolsets all) wird die Allowlist umgangen und jeder Pfad unter /api ist vorbehaltlich der obigen Sperren erreichbar. Wenn --toolsets eingeschränkt ist, wird die Allowlist zum Kill-Switch: Pfade werden nur aufgelöst, wenn ihr zugehöriges Toolset aktiviert ist. Das Deaktivieren eines Toolsets (z. B. certificates) macht seine Pfade über execute unerreichbar, selbst bei GET.

Katalogdaten werden auch als MCP-Ressourcen bereitgestellt:

• octopus://api/llms.txt – Markdown-Katalog jedes Octopus-REST-Endpunkts (HTTP-Methode, Pfad, Abfrageparameter, Anfrage-/Antworttypen). Erfordert Octopus Server 2026.2.3916 oder höher. 5-Minuten-In-Memory-Cache, der auf der konfigurierten Server-URL basiert. Bevorzugen Sie grep_llms_txt gegenüber dem direkten Lesen des Texts.
• octopus://api/capabilities – JSON, das die laufende Sitzung beschreibt: Serverversion, aktivierte Toolsets, verfügbare Tools (mit ihren minimumOctopusVersion) und ob --read-only / --allow-deletes aktiviert ist. Nützlich, damit der Agent entdecken kann, was in dieser Sitzung erreichbar ist.

Projekte

• list_projects: Alle Projekte in einem bestimmten Space auflisten

Bereitstellungen

• deploy_release: Eine Version in Umgebungen bereitstellen (unterstützt sowohl mandantenfähige als auch nicht mandantenfähige Bereitstellungen)
• list_deployments: Bereitstellungen in einem Space mit optionaler Filterung auflisten

Versionen

• create_release: Eine neue Version für ein Projekt erstellen
• find_releases: Versionen in einem Space finden (kann eine bestimmte Version per ID abrufen oder Versionen nach Projekt auflisten/filtern)

Versionsdetails sind auch als MCP-Ressource unter octopus://spaces/{spaceName}/releases/{releaseId} verfügbar – rufen Sie sie über resources/read (oder das read_resource-Rückhalt-Tool) ab, um den vollständigen Versionsinhalt einschließlich Versionshinweisen und ausgewählter Pakete zu erhalten.

Runbooks

• find_runbooks: Runbooks in einem Projekt finden (kann ein bestimmtes Runbook per ID abrufen oder Runbooks nach Teilnamen auflisten/filtern). Jede Zusammenfassung enthält die veröffentlichte Snapshot-ID, den Multi-Tenancy-Modus und den Umgebungsbereich, sodass Aufrufer vor der Ausführung gültige Ziele auswählen können.
• run_runbook: Ein Runbook gegen eine oder mehrere Umgebungen ausführen. Unterstützt mandantenfähige Ausführungen (nach Mandantenname oder Mandanten-Tag), Eingabeaufforderungsvariablen, geführten Fehlermodus, geplante Ausführungsfenster sowie Schritt- oder Maschinen-Ein-/Ausschluss. Standardmäßig wird der veröffentlichte Snapshot des Runbooks verwendet, wenn runbookSnapshotId weggelassen wird.

Der vollständige Runbook-Inhalt (einschließlich Laufzeitrichtlinienfelder) ist als MCP-Ressource unter octopus://spaces/{spaceName}/runbooks/{runbookId} verfügbar.

Aufgaben

Aufgabendaten werden hauptsächlich als MCP-Ressourcen bereitgestellt. Verwenden Sie resources/read (oder das read_resource-Rückhalt-Tool) mit einem der folgenden:

• octopus://spaces/{spaceName}/tasks/{taskId} – leichtgewichtige Metadaten (Status, Zeitplanung, Abschlussflags)
• octopus://spaces/{spaceName}/tasks/{taskId}/details – vollständige ServerTaskDetails (Fortschritt, ActivityLogs-Baum usw.)

Verwenden Sie für die Logsuche das grep_task_log-Tool anstelle einer /log-Ressource:

• grep_task_log: Das Aktivitätsprotokoll einer Aufgabe durchsuchen, ohne den vollständigen Inhalt abzurufen. Die Parameter spiegeln GNU grep wider (pattern, caseInsensitive, invertMatch, fixedString, beforeContext, afterContext, maxCount). Gibt übereinstimmende Zeilen mit 1-basiertem lineNumber, optionalen Vorher-/Nachher-Kontextarrays und einer totalMatches-Zählung über das gesamte Protokoll zurück.

Es gibt bewusst keine /log-Ressource: Aktivitätsprotokolle können mehrere Megabyte groß sein, und eine adressierbare Ressource würde Aufrufer verleiten, den gesamten Inhalt abzurufen, obwohl grep fast immer das richtige Primitive ist.

Mandanten

• find_tenants: Mandanten in einem Space finden (kann einen bestimmten Mandanten per ID abrufen oder Mandanten mit Filtern auflisten/suchen)
• get_tenant_variables: Mandantenvariablen nach Typ abrufen (alle, allgemein oder projektbezogen)
• get_missing_tenant_variables: Mandantenvariablen abrufen, denen Werte fehlen

Kubernetes

• get_kubernetes_live_status: Live-Status von Kubernetes-Ressourcen für ein Projekt und eine Umgebung abrufen (mindestens unterstützte Version: 2025.3)

Maschinen (Bereitstellungsziele)

• find_deployment_targets: Bereitstellungsziele in einem Space finden (kann ein bestimmtes Ziel per ID abrufen oder Ziele mit Filtern auflisten/suchen)

Zertifikate

• find_certificates: Zertifikate in einem Space finden (kann ein bestimmtes Zertifikat per ID abrufen oder Zertifikate mit Filtern auflisten/suchen)

Konten

• find_accounts: Konten in einem Space finden (kann ein bestimmtes Konto per ID abrufen oder Konten mit Filtern auflisten/suchen)

Unterbrechungen

• find_interruptions: Ausstehende oder historische Unterbrechungen (manuelle Eingriffe, Genehmigungen, Eingabeaufforderungen im geführten Fehlermodus) in einem Space finden, optional gefiltert nach Aufgabe, Projekt, Umgebung, betreffendem Dokument, Verantwortlichkeit oder ausstehendem Status. Gibt schlanke Zusammenfassungen zurück; dereferenzieren Sie die octopus://spaces/{spaceName}/interruptions/{interruptionId}-Ressource für die vollständige Formulardefinition (Steuerelementtypen, Markdown-Anweisungen, Schaltflächenoptionen, übermittelte Form.Values).

Feature-Schalter

• find_feature_toggles: Kundenspezifische Feature-Schalter in einem Projekt auflisten. Jede Zusammenfassung enthält den Zustand pro Umgebung (isEnabled, rolloutPercentage, clientRolloutPercentage) plus ein resourceUri, sodass „Wo ist X aktiviert“ aus der Listenantwort beantwortet werden kann.
• update_feature_toggle: Einen vorhandenen Schalter anpassen. Schmale Oberfläche – eine Umgebung ein-/ausschalten, Rollout-Prozentsätze ändern oder die Beschreibung auf Schalterebene / den Standardzustand aktualisieren. Intern wird der aktuelle Schalter abgerufen, Ihre Patches werden im Speicher angewendet und der zusammengeführte Inhalt per PUT gesendet, sodass nicht erwähnte Umgebungen und nicht erwähnte Felder erhalten bleiben. Patches, die auf eine Umgebung verweisen, die nicht bereits auf dem Schalter konfiguriert ist, werden abgelehnt.

Der vollständige Schalterinhalt (Beschreibung, Mandanten, Segmente, Mindestversionen) ist als MCP-Ressource unter octopus://spaces/{spaceName}/projects/{projectId}/featuretoggles/{slug} verfügbar. Rollout-Gruppeninhalte sind unter octopus://spaces/{spaceName}/projects/{projectId}/rolloutgroups/{rolloutGroupId} für schreibgeschützte Prüfung adressierbar.

Außerhalb des Rahmens (Octopus-Benutzeroberfläche verwenden): Erstellen neuer Feature-Schalter, Löschen von Schaltern, Umbenennen oder Neubeschriften, Anhängen/Trennen von Rollout-Gruppen, Mandanten-Targeting, Segmente, Mindestversionsfilter sowie Rollout-Gruppen-/SDK-Client-Identifikatorverwaltung.

Zusätzliche Tools

• get_deployment_process: Bereitstellungsprozess per ID für Projekte oder Versionen abrufen
• get_variables: Alle Projektvariablen und Bibliotheksvariablensatzvariablen für ein Projekt abrufen (unterstützt Config-as-Code-Projekte über gitRef)
• get_branches: Git-Zweige für ein versionskontrolliertes Projekt abrufen (mindestens unterstützte Version: 2021.2)
• get_current_user: Informationen über den aktuell authentifizierten Benutzer abrufen

🔒 Sicherheitsüberlegungen

Der Octopus-MCP-Server umfasst sowohl Lese- als auch Schreibvorgänge. Wichtige Sicherheitsüberlegungen:

Lesevorgänge

• Kann vollständige Bereitstellungsprotokolle lesen, die Produktionsgeheimnisse enthalten könnten, wenn sie nicht als Geheimnisse markiert wurden
• Zugriff auf sensible Konfigurationsdaten und Variablen
• Seien Sie vorsichtig, wenn Sie sich mit Tools und Modellen verbinden, denen Sie nicht vollständig vertrauen

Schreibvorgänge

Standardmäßig sind die folgenden Schreibvorgänge verfügbar:

• Versionen erstellen: Kann neue Versionen für Projekte erstellen
• Versionen bereitstellen: Kann Bereitstellungen in Umgebungen auslösen (einschließlich Produktion)
• Runbooks ausführen: Kann Runbooks gegen Umgebungen und Mandanten ausführen
• Feature-Schalter aktualisieren: Kann den Zustand pro Umgebung umschalten und Rollout-Prozentsätze auf vorhandenen Schaltern ändern
• Beliebige POST/PUT/PATCH über das execute-Rückhalt-Tool: Begrenzt auf Pfade unter /api, mit einer immer aktiven sensiblen Denylist. Die Pfad-Allowlist pro Toolset gilt nur, wenn --toolsets eingeschränkt wurde; bei allen aktivierten Toolsets (Standard) sind die einzigen Pfadsperren die /api-Grenze und die sensible Denylist.

Übergeben Sie --read-only, um alle oben genannten Vorgänge zu deaktivieren. DELETE-Anfragen über execute erfordern ein zusätzliches --allow-deletes-Flag – ein bewusstes Opt-in für irreversible Vorgänge – und bleiben blockiert, wenn --read-only gesetzt ist.

Kritische Sicherheitsmaßnahmen:

1. Prinzip der geringsten Rechte: Verwenden Sie API-Schlüssel mit den Mindestberechtigungen, die für Ihren Anwendungsfall erforderlich sind
2. Opt-in in den Nur-Lese-Modus: Schreibvorgänge sind standardmäßig aktiviert. Für die Produktion übergeben Sie --read-only, es sei denn, Sie haben einen spezifischen, kontrollierten Anwendungsfall für Schreibvorgänge. DELETE erfordert immer das zusätzliche --allow-deletes-Opt-in.
3. Methodensperre ist serverseitig und fest codiert: Die HTTP-Methode, die an execute übergeben wird, ist der maßgebliche Klassifikator. Der Agent kann die Sperre nicht umgehen, indem er falsch darstellt, was der Aufruf tut – POST/PUT/PATCH/DELETE-Anfragen erhalten eine stufenspezifische Sperre, unabhängig vom Text im Anfragetext.
4. Toolset-Filterung dient als Kill-Switch: Das Einschränken von --toolsets entfernt sowohl die kuratierten Tools der deaktivierten Toolsets als auch deren Pfade aus der execute-Allowlist. (Die Allowlist wird nur bei eingeschränkten Toolsets konsultiert; bei allen aktivierten Toolsets ist execute durch die /api-Formprüfung und die sensible Denylist begrenzt.)
5. Prompt-Injection-Risiko: Das Ausführen von Agenten in vollautomatischer Weise könnte Sie anfällig für Prompt-Injection-Angriffe machen

Empfehlung: Für Produktionsumgebungen übergeben Sie --read-only, es sei denn, Sie haben einen spezifischen, kontrollierten Anwendungsfall für Schreibvorgänge. Lassen Sie --allow-deletes deaktiviert, es sei denn, Sie benötigen speziell DELETE-Semantik über execute.

⚠️ Einschränkungen

Datenanalyse

Die Natur aktueller KI-Chat-Tools und des MCP-Protokolls selbst macht es unpraktisch, große Datenmengen zu analysieren. Die meisten MCP-Clients unterstützen derzeit keine Verkettung von Tool-Aufrufen (Verwenden der Ausgabe eines Tools als Eingabe für das nächste) und greifen stattdessen darauf zurück, die Ergebnisse Token für Token zu kopieren, was häufig zu Halluzinationen führt. Wenn Sie historische Daten Ihrer Octopus-Instanz zu Analysezwecken verarbeiten möchten, empfehlen wir, die API direkt zu verwenden oder einen eigenen MCP-Client zu schreiben, der die Tool-Aufrufergebnisse programmatisch verarbeiten kann.

Leistung

Der MCP-Server ist technisch nur eine dünne Schicht über der vorhandenen Octopus-Server-API. Daher kann er große Datenmengen abrufen (z. B. Tausende von Bereitstellungen anfordern). Solche Abfragen können erhebliche Auswirkungen auf die Leistung Ihrer Instanz haben. Weisen Sie Ihre Modelle an, nur die Mindestmenge an Daten abzurufen, die sie benötigen (die meisten Modelle sind darin standardmäßig sehr gut).

🤝 Beiträge

Contributions are welcome! :heart: Please read our Contributing Guide for information about how to get involved in this project.

We are eager to hear how you plan to use Octopus MCP Server and what features you would like to see included in future version.

Please use Issues to provide feedback, or request features.

If you are a current Octopus customer, please report any issues you experience using our MCP server to our support team. This will ensure you get a timely response within our standard support guarantees.

🙋 FAQ

Do you have plans to release a remote MCP server?

We are working on integrating an MCP server directly into Octopus Server. This will open up the door for us to build more complex MCP tools, as well as:

• Giving Octopus Administrators more granular control over MCP clients
• Natively support OAuth for client authentication
• Integrating security scanning tools into the MCP output

If this is of interest to you, please register your interest on our roadmap item.

License

This project is licensed under the terms of Mozilla Public License 2.0 open source license.