Octopus Deploy Official MCP Server

[!WARNING] Obsolète : Ce serveur MCP est obsolète. Le serveur MCP distant est disponible dans Octopus Server 2026.3 et versions ultérieures. Voir la documentation du serveur MCP distant.

Octopus Deploy Official MCP Server

Octopus facilite la livraison de logiciels vers Kubernetes, le multi-cloud, l'infrastructure sur site, et partout ailleurs. Automatisez la publication, le déploiement et les opérations de vos logiciels et charges de travail d'IA avec un outil capable de gérer la livraison continue (CD) à grande échelle d'une manière qu'aucun autre outil ne peut égaler.

Model Context Protocol (MCP) permet aux assistants IA que vous utilisez au quotidien, comme Claude Code ou ChatGPT, de se connecter aux systèmes et services que vous possédez de manière standardisée, leur permettant d'extraire des informations de ces systèmes et services pour répondre à des questions et effectuer des tâches.

Le serveur MCP Octopus fournit à votre assistant IA des outils puissants qui lui permettent d'inspecter, d'interroger et de diagnostiquer les problèmes au sein de votre instance Octopus, le transformant en votre allié DevOps ultime. Pour une liste des cas d'utilisation pris en charge et des exemples de prompts, consultez notre documentation.

Compatibilité avec Octopus Server

La plupart des outils exposés par le serveur MCP utilisent des API stables disponibles depuis au moins la version 2021.1 d'Octopus Server. Les outils plus récents spécifieront la version minimale prise en charge dans la documentation. Vous pouvez également utiliser l'argument de ligne de commande --list-tools-by-version pour vérifier comment des outils spécifiques se rapportent aux versions d'Octopus.

🚀 Installation

Installation via Docker

Les informations d'identification doivent être fournies via des variables d'environnement pour éviter de les exposer dans la liste des processus de l'hôte (ps aux / /proc/<pid>/cmdline). L'URL du serveur Octopus peut toujours être fournie via le drapeau --server-url.

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

Exemple de configuration complète (pour Claude Desktop, Claude Code et 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"
      }
    },
  }
}

Pour les utilisateurs d'Apple Mac, vous devrez peut-être ajouter les arguments suivants dans la configuration pour forcer Docker à utiliser la plateforme Linux :

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

Nous prévoyons de publier prochainement une version native ARM afin que ces arguments ne soient plus nécessaires.

Installation via Node

Prérequis

• Node.js >= v20.0.0
• Instance Octopus Deploy accessible par le serveur MCP via HTTPS
• Clé API ou jeton d'accès Octopus Deploy (voir Authentification ci-dessous)

Configuration

Exemple de configuration complète (pour Claude Desktop, Claude Code et Cursor) :

Outils d'écriture activés (par défaut) :

{
  "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"
      }
    }
  }
}

Mode lecture seule (recommandé pour la production) :

{
  "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"
      }
    }
  }
}

Le serveur MCP Octopus est généralement configuré dans le client IA de votre choix.

Il est empaqueté en tant que package npm et exécuté via la commande npx de Node. Les informations d'identification (clé API ou jeton d'accès) doivent être fournies via des variables d'environnement — elles ne sont pas acceptées comme arguments de ligne de commande pour éviter d'exposer les secrets dans la liste des processus. L'URL du serveur Octopus peut être fournie via la variable d'environnement OCTOPUS_SERVER_URL ou le drapeau --server-url.

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

Ou avec l'URL du serveur sur la ligne de commande :

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

Authentification

Le serveur MCP prend en charge deux méthodes d'authentification. Les deux sont fournies via des variables d'environnement — les informations d'identification ne sont pas acceptées sur la ligne de commande car les drapeaux sont visibles dans la liste des processus de l'hôte pour tout utilisateur local.

Clé API (recommandée pour une utilisation interactive)

Les clés API sont la méthode d'authentification standard pour Octopus Deploy. Vous pouvez en générer une à partir de votre profil utilisateur Octopus Deploy.

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

Jeton d'accès / Jeton Bearer (scénarios automatisés uniquement)

Le serveur prend également en charge les jetons d'accès à courte durée de vie (jetons Bearer) comme alternative aux clés API. Cette méthode d'authentification est destinée uniquement aux scénarios automatisés où un système externe émet un jeton à courte durée de vie au serveur MCP (par exemple, pipelines CI/CD, orchestration automatisée ou flux machine à machine). N'utilisez pas de jetons Bearer à longue durée de vie — utilisez plutôt des clés API pour les sessions interactives ou de longue durée.

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

Exemple de configuration complète avec un jeton d'accès :

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

Si une clé API et un jeton d'accès sont tous deux fournis, le jeton d'accès a priorité. La méthode d'authentification active est enregistrée dans le fichier journal (configurable avec --log-file) afin que les opérateurs puissent confirmer quelle information d'identification est utilisée.

Options de configuration

Le serveur MCP Octopus prend en charge plusieurs options de ligne de commande pour personnaliser les outils disponibles.

Si vous n'êtes pas sûr des outils dont vous avez besoin, nous recommandons d'exécuter sans options de ligne de commande supplémentaires et d'utiliser les valeurs par défaut fournies.

Ensembles d'outils

Utilisez le paramètre --toolsets pour activer des groupes spécifiques d'outils :

# 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

Ensembles d'outils disponibles :

• core - Opérations de base (toujours activé)
• projects - Opérations de projet
• deployments - Opérations de déploiement
• releases - Gestion des publications
• runbooks - Découverte et exécution de runbooks
• tasks - Opérations de tâches
• tenants - Opérations de multi-tenant
• kubernetes - Opérations Kubernetes
• machines - Opérations de cibles de déploiement
• certificates - Opérations de certificats
• accounts - Opérations de comptes
• interruptions - Opérations d'intervention manuelle et d'approbation
• featureToggles - Inspecter et ajuster les bascules de fonctionnalités client
• context - Contexte de l'utilisateur authentifié et du projet (utilisateur actuel, branches Git)

Mode lecture seule

Le serveur s'exécute avec les outils d'écriture activés par défaut. Passez --read-only pour désactiver tous les outils d'écriture et bloquer POST/PUT/PATCH/DELETE via le filet de sécurité execute. La plupart des outils organisés sont déjà en lecture seule ; seul un petit ensemble effectue des écritures.

Outils avec écriture activée (toujours en écriture) :

• create_release - Créer de nouvelles publications
• deploy_release - Déployer des publications vers des environnements et des locataires
• run_runbook - Exécuter un runbook sur un ou plusieurs environnements (et locataires facultatifs)
• update_feature_toggle - Ajuster l'état par environnement et les pourcentages de déploiement sur une bascule de fonctionnalité existante

Outil avec écriture conditionnelle : execute est un filet de sécurité REST structuré dont le niveau (lecture / écriture / suppression) est déterminé par la méthode HTTP qui lui est passée. Voir la section Catalogue API et filet de sécurité pour plus de détails.

Les outils d'écriture sont contrôlés par une invite d'élicitation MCP : les clients qui prennent en charge l'élicitation seront invités à confirmer avant que l'appel ne se poursuive. Les clients sans prise en charge de l'élicitation doivent passer confirm: true dans les arguments de l'outil — sinon l'outil s'arrête avec une erreur. Définissez OCTOPUS_SKIP_ELICITATION=true pour contourner complètement le contrôle (destiné à l'automatisation sans surveillance).

Le serveur utilise une classification à trois niveaux lecture/écriture/suppression, appliquée côté serveur en fonction de la méthode HTTP (l'agent ne peut pas contourner cela en mentant sur l'intention) :

• lecture — toujours autorisée. Requêtes GET via execute, plus tous les outils find_* / get_* / list_*.
• écriture — POST/PUT/PATCH via execute et les outils toujours en écriture ci-dessus. Bloquée lorsque --read-only est défini.
• suppression — DELETE via execute. Nécessite --allow-deletes et est bloquée lorsque --read-only est défini. Un petit ensemble de chemins de suppression catastrophiques (par exemple DELETE /api/spaces/{id}, DELETE /api/users/{id}) et les points de terminaison de clé API sont sur une liste de blocage sensible stricte qui ignore les deux drapeaux.

# 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

Note de sécurité : Utilisez une clé API avec des autorisations appropriées et de moindre privilège — les opérations d'écriture peuvent créer des publications et déclencher des déploiements dans votre instance Octopus. Pour la production, envisagez de passer --read-only sauf si vous avez un cas d'utilisation spécifique et contrôlé pour les écritures. --allow-deletes est désactivé par défaut ; activez-le uniquement lorsque l'agent doit émettre des requêtes DELETE via execute. Si vous passez --allow-deletes avec --read-only, le serveur imprime un avertissement de démarrage sur stderr — les requêtes DELETE restent bloquées par le contrôle de lecture seule.

Exemples complets

Tous les exemples ci-dessous supposent que OCTOPUS_API_KEY est défini dans l'environnement. Le drapeau --server-url est affiché pour plus de clarté mais peut également être fourni via OCTOPUS_SERVER_URL.

# 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

Autres arguments de ligne de commande

• --read-only - Activer le mode lecture seule : désactiver tous les outils d'écriture organisés et bloquer POST/PUT/PATCH/DELETE via execute. Les écritures sont activées par défaut ; ce drapeau les désactive. Voir Mode lecture seule.
• --allow-deletes - Autoriser les requêtes DELETE via l'outil execute. Ignoré (avec un avertissement de démarrage) lorsque --read-only est défini. Par défaut false.
• --log-level <level> - Niveau de journalisation minimal (info, error)
• --log-file <path> - Chemin ou nom de fichier du journal. S'il n'est pas spécifié, les journaux sont écrits uniquement sur la console
• -q, --quiet - Désactiver la journalisation par fichier, ne journaliser que les erreurs sur la console
• --list-tools-by-version - Lister tous les outils enregistrés par leur version prise en charge d'Octopus Server et quitter

🔨 Outils

Outils basés sur les URL

Démarrage rapide : Collez les URL Octopus directement pour enquêter sur les problèmes sans extraction manuelle des ID.

• get_deployment_from_url : Obtenir les détails du déploiement à partir de l'URL de déploiement (renvoie taskId pour le suivi)
• get_task_from_url : Obtenir les détails et les journaux de la tâche à partir de l'URL de la tâche

Flux de travail d'enquête de déploiement :

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 })

Enquête de tâche (URL de tâche directe) :

get_task_from_url with task URL
→ Returns task details and logs immediately

Ces outils éliminent l'extraction manuelle des ID en :

• Analysant les URL automatiquement
• Résolvant les ID d'espace en noms d'espace
• Validant les formats d'ID
• Fournissant des messages d'erreur clairs

Exemples d'URL :

• Déploiement : https://your-octopus.com/app#/Spaces-1/projects/my-app/deployments/Deployments-123
• Tâche : https://your-octopus.com/app#/Spaces-1/tasks/ServerTasks-456

Voir Travailler avec les URL pour des flux de travail détaillés, des exemples et les meilleures pratiques.

Outils de base

• list_spaces : Lister tous les espaces dans l'instance Octopus Deploy
• list_environments : Lister tous les environnements dans un espace donné

Catalogue API et filet de sécurité

Ces outils et ressources permettent à l'agent d'atteindre les points de terminaison REST Octopus qui n'ont pas d'outil organisé dédié, avec un contrôle strict côté serveur entre les opérations de lecture, d'écriture et de suppression.

• grep_llms_txt : Rechercher dans le catalogue d'API Octopus (octopus://api/llms.txt) avec une sémantique de type grep (version minimale d'Octopus prise en charge : 2026.2.3916). Le corps du catalogue est volumineux (généralement plus de 300 Ko) — appelez cette fonction plutôt que de lire directement le corps de la ressource. Les paramètres reflètent GNU grep (pattern, caseInsensitive, invertMatch, fixedString, beforeContext, afterContext, maxCount). Utile pour découvrir des points de terminaison (POST /releases), énumérer les points de terminaison de suppression (DELETE ), ou trouver le type de corps pour une opération d'écriture (Body: Create.*Command).
• execute : Filet de sécurité REST structuré. Atteint n'importe quel point de terminaison REST Octopus sous /api. La méthode HTTP est le classificateur autoritaire de lecture/écriture/suppression — jamais un indicateur isWrite que le LLM peut définir. Le contrôle de méthode est codé en dur côté serveur :
  • GET est toujours autorisé (sous réserve de la vérification de la forme du chemin + de la liste de blocage sensible).
  • POST/PUT/PATCH sont bloqués lorsque --read-only est défini ; sinon, ils nécessitent une confirmation de l'utilisateur via une sollicitation.
  • DELETE nécessite --allow-deletes (et est bloqué lorsque --read-only est défini) plus un message de sollicitation « IRRÉVERSIBLE » plus fort.
  • La liste de blocage sensible (points de terminaison de clé API, DELETE /api/spaces/{id}, DELETE /api/users/{id}) est appliquée même avec les deux indicateurs activés.
  • Le chemin doit être /api ou commencer par /api/ — les URL absolues, les chemins ~/api/... relatifs au SDK, et les chemins relatifs à l'hôte en dehors de /api (par exemple /octopus/portal/...) sont rejetés dès le départ, donc execute reste limité à la surface de l'API REST Octopus.
  • La liste d'autorisation de chemins par ensemble d'outils s'applique uniquement lorsque --toolsets a été restreint. Avec chaque ensemble d'outils activé (par défaut, ou --toolsets all explicite), la liste d'autorisation est contournée et tout chemin sous /api est accessible sous réserve des contrôles ci-dessus. Lorsque --toolsets est restreint, la liste d'autorisation devient l'interrupteur d'arrêt : les chemins ne se résolvent que si leur ensemble d'outils propriétaire est activé, donc la désactivation d'un ensemble d'outils (par exemple certificates) rend ses chemins inaccessibles via execute même sur GET.

Les données du catalogue sont également exposées en tant que ressources MCP :

• octopus://api/llms.txt — catalogue Markdown de chaque point de terminaison REST Octopus (méthode HTTP, chemin, paramètres de requête, types de requête/réponse). Nécessite Octopus Server 2026.2.3916 ou ultérieur. Cache en mémoire de 5 minutes basé sur l'URL du serveur configuré. Préférez grep_llms_txt à la lecture directe du corps.
• octopus://api/capabilities — JSON décrivant la session en cours : version du serveur, ensembles d'outils activés, outils disponibles (avec leurs minimumOctopusVersion), et si --read-only / --allow-deletes est activé. Utile pour que l'agent découvre ce qui est accessible dans cette session.

Projets

• list_projects : Lister tous les projets dans un espace donné

Déploiements

• deploy_release : Déployer une version dans des environnements (prend en charge les déploiements avec et sans locataire)
• list_deployments : Lister les déploiements dans un espace avec filtrage optionnel

Versions

• create_release : Créer une nouvelle version pour un projet
• find_releases : Trouver des versions dans un espace (peut obtenir une version spécifique par ID, ou lister/filtrer les versions par projet)

Les détails de la version sont également disponibles en tant que ressource MCP à octopus://spaces/{spaceName}/releases/{releaseId} — récupérez via resources/read (ou l'outil de secours read_resource) pour obtenir le corps complet de la version, y compris les notes de version et les packages sélectionnés.

Runbooks

• find_runbooks : Trouver des runbooks dans un projet (peut obtenir un runbook spécifique par ID, ou lister/filtrer les runbooks par nom partiel). Chaque résumé inclut l'ID de snapshot publié, le mode de multi-location et la portée de l'environnement afin que les appelants puissent choisir des cibles valides avant l'exécution.
• run_runbook : Exécuter un runbook sur un ou plusieurs environnements. Prend en charge les exécutions avec locataire (par nom de locataire ou étiquette de locataire), les variables invitées, le mode de défaillance guidée, les fenêtres d'exécution planifiées, et l'inclusion/exclusion d'étapes ou de machines. Par défaut, utilise le snapshot publié du runbook si runbookSnapshotId est omis.

Le corps complet du runbook (y compris les champs de politique d'exécution) est disponible en tant que ressource MCP à octopus://spaces/{spaceName}/runbooks/{runbookId}.

Tâches

Les données de tâches sont principalement exposées en tant que ressources MCP. Utilisez resources/read (ou l'outil de secours read_resource) avec l'un des éléments suivants :

• octopus://spaces/{spaceName}/tasks/{taskId} — métadonnées légères (état, synchronisation, indicateurs d'achèvement)
• octopus://spaces/{spaceName}/tasks/{taskId}/details — ServerTaskDetails complet (Progress, arborescence ActivityLogs, etc.)

Pour la recherche dans les journaux, utilisez l'outil grep_task_log plutôt qu'une ressource /log :

• grep_task_log : Rechercher dans le journal d'activité d'une tâche sans récupérer le corps complet. Les paramètres reflètent GNU grep (pattern, caseInsensitive, invertMatch, fixedString, beforeContext, afterContext, maxCount). Renvoie les lignes correspondantes avec lineNumber indexé à partir de 1, des tableaux de contexte avant/après optionnels, et un compte totalMatches sur l'ensemble du journal.

Il n'y a intentionnellement pas de ressource /log : les journaux d'activité peuvent faire plusieurs mégaoctets, et une ressource adressable inciterait les appelants à récupérer tout le corps alors que grep est presque toujours la primitive appropriée.

Locataires

• find_tenants : Trouver des locataires dans un espace (peut obtenir un locataire spécifique par ID ou lister/rechercher des locataires avec des filtres)
• get_tenant_variables : Obtenir les variables de locataire par type (toutes, communes ou projet)
• get_missing_tenant_variables : Obtenir les variables de locataire qui ont des valeurs manquantes

Kubernetes

• get_kubernetes_live_status : Obtenir le statut en direct des ressources Kubernetes pour un projet et un environnement (version minimale prise en charge : 2025.3)

Machines (cibles de déploiement)

• find_deployment_targets : Trouver des cibles de déploiement dans un espace (peut obtenir une cible spécifique par ID ou lister/rechercher des cibles avec des filtres)

Certificats

• find_certificates : Trouver des certificats dans un espace (peut obtenir un certificat spécifique par ID ou lister/rechercher des certificats avec des filtres)

Comptes

• find_accounts : Trouver des comptes dans un espace (peut obtenir un compte spécifique par ID ou lister/rechercher des comptes avec des filtres)

Interruptions

• find_interruptions : Trouver des interruptions en attente ou historiques (interventions manuelles, approbations, invites de défaillance guidée) dans un espace, éventuellement filtrées par tâche, projet, environnement, document concerné, responsabilité ou état en attente. Renvoie des résumés succincts ; déréférencez la ressource octopus://spaces/{spaceName}/interruptions/{interruptionId} pour la définition complète du formulaire (types de contrôles, instructions Markdown, options de boutons, Form.Values soumis).

Interrupteurs de fonctionnalités

• find_feature_toggles : Lister les interrupteurs de fonctionnalités client dans un projet. Chaque résumé inclut l'état par environnement (isEnabled, rolloutPercentage, clientRolloutPercentage) plus un resourceUri afin que « où X est activé » soit répondable à partir de la réponse de la liste.
• update_feature_toggle : Ajuster un interrupteur existant. Surface étroite — activer/désactiver un environnement, modifier les pourcentages de déploiement progressif, ou mettre à jour la description au niveau de l'interrupteur / l'état par défaut. En interne, récupère l'interrupteur actuel, applique vos correctifs en mémoire et envoie (PUT) le corps fusionné, donc les environnements non mentionnés et les champs non mentionnés sont préservés. Les correctifs qui référencent un environnement non déjà configuré sur l'interrupteur sont rejetés.

Le corps complet de l'interrupteur (description, locataires, segments, versions minimales) est disponible en tant que ressource MCP à octopus://spaces/{spaceName}/projects/{projectId}/featuretoggles/{slug}. Les corps de groupes de déploiement progressif sont adressables à octopus://spaces/{spaceName}/projects/{projectId}/rolloutgroups/{rolloutGroupId} pour une inspection en lecture seule.

Hors de portée (utilisez l'interface Octopus) : création de nouveaux interrupteurs de fonctionnalités, suppression d'interrupteurs, renommage ou réétiquetage, attachement/détachement de groupes de déploiement progressif, ciblage de locataires, segments, filtres de version minimale, et gestion des groupes de déploiement progressif / identifiants de client SDK.

Outils supplémentaires

• get_deployment_process : Obtenir le processus de déploiement par ID pour les projets ou les versions
• get_variables : Obtenir toutes les variables de projet et les variables d'ensemble de variables de bibliothèque pour un projet (prend en charge les projets config-as-code via gitRef)
• get_branches : Obtenir les branches Git pour un projet sous contrôle de version (version minimale prise en charge : 2021.2)
• get_current_user : Obtenir des informations sur l'utilisateur authentifié actuel

🔒 Considérations de sécurité

Le serveur MCP Octopus inclut des opérations de lecture et d'écriture. Considérations de sécurité importantes :

Opérations de lecture

• Peut lire les journaux de déploiement complets, qui pourraient inclure des secrets de production s'ils n'ont pas été marqués comme secrets
• Accès aux données de configuration sensibles et aux variables
• Faites preuve de prudence lors de la connexion à des outils et des modèles auxquels vous ne faites pas entièrement confiance

Opérations d'écriture

Par défaut, les opérations d'écriture suivantes sont disponibles :

• Création de versions : Peut créer de nouvelles versions pour des projets
• Déploiement de versions : Peut déclencher des déploiements vers des environnements (y compris la production)
• Exécution de runbooks : Peut exécuter des runbooks sur des environnements et des locataires
• Mise à jour des interrupteurs de fonctionnalités : Peut basculer l'état par environnement et modifier les pourcentages de déploiement progressif sur les interrupteurs existants
• POST/PUT/PATCH arbitraires via le filet de sécurité execute : Limité aux chemins sous /api, avec une liste de blocage sensible toujours active. La liste d'autorisation de chemins par ensemble d'outils s'applique uniquement lorsque --toolsets a été restreint ; avec tous les ensembles d'outils activés (par défaut), les seuls contrôles de chemin sont la limite /api et la liste de blocage sensible.

Passez --read-only pour désactiver tout ce qui précède. Les requêtes DELETE via execute nécessitent un indicateur supplémentaire --allow-deletes — une adhésion délibérée pour les opérations irréversibles — et restent bloquées lorsque --read-only est défini.

Mesures de sécurité critiques :

1. Moindre privilège : Utilisez des clés API avec les permissions minimales nécessaires pour votre cas d'utilisation
2. Adhésion au mode lecture seule : Les écritures sont activées par défaut. Pour la production, passez --read-only sauf si vous avez un cas d'utilisation spécifique et contrôlé pour les opérations d'écriture. DELETE nécessite toujours l'adhésion supplémentaire --allow-deletes.
3. Le contrôle de méthode est côté serveur et codé en dur : La méthode HTTP passée à execute est le classificateur autoritaire. L'agent ne peut pas contourner le contrôle en déformant ce que fait l'appel — les requêtes POST/PUT/PATCH/DELETE reçoivent un contrôle spécifique au niveau quel que soit le texte dans le corps de la requête.
4. Le filtrage des ensembles d'outils sert également d'interrupteur d'arrêt : La restriction de --toolsets supprime à la fois les outils organisés des ensembles d'outils désactivés et leurs chemins de la liste d'autorisation execute. (La liste d'autorisation n'est consultée que lorsque les ensembles d'outils sont restreints ; avec tous les ensembles d'outils activés, execute est limité par la vérification de forme /api et la liste de blocage sensible à la place.)
5. Risque d'injection d'invite : Exécuter des agents de manière entièrement automatisée pourrait vous rendre vulnérable aux attaques par injection d'invite

Recommandation : Pour les environnements de production, passez --read-only sauf si vous avez un cas d'utilisation spécifique et contrôlé pour les opérations d'écriture. Laissez --allow-deletes désactivé sauf si vous avez spécifiquement besoin de la sémantique DELETE via execute.

⚠️ Limitations

Analyse de données

La nature des outils de chat IA actuels et du protocole MCP lui-même rend peu pratique l'analyse de grandes quantités de données. La plupart des clients MCP ne prennent actuellement pas en charge le chaînage des appels d'outils (utiliser la sortie d'un outil comme entrée du suivant) et se rabattent plutôt sur la copie des résultats jeton par jeton, ce qui conduit fréquemment à des hallucinations. Si vous cherchez à traiter des données historiques de votre instance Octopus à des fins d'analyse, nous recommandons d'utiliser l'API directement ou d'écrire votre propre client MCP capable de traiter les résultats des appels d'outils par programmation.

Performance

Le serveur MCP est techniquement juste une couche mince au-dessus de l'API existante du serveur Octopus. En tant que tel, il est capable de récupérer de grandes quantités de données (par exemple, demander des milliers de déploiements). De telles requêtes peuvent avoir un effet significatif sur les performances de votre instance. Demandez à vos modèles de ne récupérer que l'ensemble minimal de données dont ils ont besoin (la plupart des modèles sont très bons à cela dès le départ).

🤝 Contributions

Les contributions sont les bienvenues ! :heart: Veuillez consulter notre Guide de contribution pour savoir comment participer à ce projet.

Nous sommes impatients de savoir comment vous prévoyez d'utiliser Octopus MCP Server et quelles fonctionnalités vous souhaiteriez voir incluses dans les versions futures.

Veuillez utiliser Issues pour fournir des commentaires ou demander des fonctionnalités.

Si vous êtes un client Octopus actuel, veuillez signaler tout problème rencontré avec notre serveur MCP à notre équipe d'assistance. Cela garantira une réponse rapide dans le cadre de nos garanties de support standard.

🙋 FAQ

Prévoyez-vous de publier un serveur MCP distant ?

Nous travaillons à l'intégration d'un serveur MCP directement dans Octopus Server. Cela nous ouvrira la possibilité de créer des outils MCP plus complexes, ainsi que :

• Donner aux administrateurs Octopus un contrôle plus granulaire sur les clients MCP
• Prendre en charge nativement OAuth pour l'authentification des clients
• Intégrer des outils d'analyse de sécurité dans la sortie MCP

Si cela vous intéresse, veuillez enregistrer votre intérêt sur notre élément de feuille de route.

Licence

Ce projet est sous licence open source Mozilla Public License 2.0.