ZenML

Serveur MCP pour ZenML

Ce projet implémente un serveur Model Context Protocol (MCP) permettant d’interagir avec l’API ZenML.

Qu’est-ce que MCP ?

Le Model Context Protocol (MCP) est un protocole ouvert qui standardise la manière dont les applications fournissent du contexte aux grands modèles de langage (LLM). Il agit comme un « port USB-C pour les applications d’IA » : il fournit un moyen standardisé de connecter les modèles d’IA à différentes sources de données et à différents outils.

MCP suit une architecture client-serveur où :

• Hôtes MCP : programmes comme Claude Desktop ou des IDE qui souhaitent accéder aux données via MCP
• Clients MCP : clients du protocole qui maintiennent des connexions 1:1 avec les serveurs
• Serveurs MCP : programmes légers qui exposent des fonctionnalités spécifiques via le protocole standardisé
• Sources de données locales : fichiers, bases de données et services de votre ordinateur auxquels les serveurs MCP peuvent accéder de manière sécurisée
• Services distants : systèmes externes accessibles sur Internet auxquels les serveurs MCP peuvent se connecter

Qu’est-ce que ZenML ?

ZenML est une plateforme open source permettant de créer et de gérer des pipelines de ML et d’IA. Elle fournit une interface unifiée pour gérer les données, les modèles et les expériences.

Pour en savoir plus, consultez le site Web de ZenML et notre documentation.

Fonctionnalités

Le serveur fournit des outils MCP permettant d’accéder aux principales fonctionnalités de lecture du serveur ZenML et d’obtenir des informations à jour sur :

Entités principales

• Utilisateurs - comptes utilisateur et autorisations
• Stacks - configurations d’infrastructure
• Composants de stack - éléments constitutifs individuels d’une stack
• Flavors - types de composants disponibles
• Connecteurs de service - authentification cloud

Exécution des pipelines

• Pipelines - définitions de pipelines
• Exécutions de pipeline - historique et état des exécutions
• Étapes de pipeline - détails, code et journaux de chaque étape
• Planifications - planifications automatisées des exécutions
• Artefacts - métadonnées sur les artefacts de données (pas les données elles-mêmes)

Déploiement et service

• Snapshots - configurations de pipeline figées (l’artefact « à exécuter/à servir »)
• Déploiements - instances de service à l’exécution avec état, URL et journaux
• Services - points de terminaison de service de modèles

Organisation et découverte

• Projets - conteneurs organisationnels pour les ressources ZenML
• Tags - étiquettes de métadonnées transversales pour la découverte
• Builds - artefacts de build de pipeline avec informations sur l’image et le code

Modèles

• Modèles - entrées du registre de modèles de ML
• Versions de modèle - artefacts de modèle versionnés

API de compatibilité (migration recommandée)

• Les modèles d’exécution de pipeline restent disponibles dans ZenML 0.97.0, tandis que les Snapshots sont privilégiés pour les nouveaux workflows (voir le Guide de migration)

Le serveur permet également de déclencher de nouvelles exécutions de pipeline à l’aide de snapshots (méthode privilégiée) ou du paramètre de déclenchement basé sur les modèles, désormais obsolète.

Remarque : nous améliorons continuellement cette intégration en fonction des retours des utilisateurs. Rejoignez notre communauté Slack pour nous faire part de votre expérience et nous aider à l’améliorer encore !

Profils d’outils et politique d’écriture

Le profil compact par défaut annonce 16 outils. Sept outils génériques couvrent le catalogue de ressources, les lectures, les mutations courantes et les actions de cycle de vie finies :

Outil	Fonction
zenml_describe_resources	Découvrir les types de ressources pris en charge et les schémas d’opérations délimités
zenml_list_resources	Lister un type de ressource avec des filtres validés et une pagination
zenml_get_resource	Obtenir une ressource, avec le parent et le périmètre du projet lorsque nécessaire
zenml_create_resource	Créer une ressource prise en charge à partir d’une charge utile typée
zenml_update_resource	Mettre à jour un UUID de ressource précis
zenml_delete_resource	Supprimer ou archiver un UUID de ressource précis
zenml_action_resource	Exécuter une action de cycle de vie ou de relation autorisée, sans nouvelle tentative

Neuf outils spécialisés sont conservés, car ils fournissent des diagnostics, un contexte actif, des journaux ou du code en flux continu, l’exécution de pipelines ou une App interactive :

• diagnose_zenml_setup
• get_active_user et get_active_project
• trigger_pipeline
• get_step_logs, get_step_code et get_deployment_logs
• open_pipeline_run_dashboard et open_run_activity_chart

get_step_logs renvoie au maximum 50,000 entrées, de la plus ancienne à la plus récente, avec un indicateur possibly_truncated, ainsi qu’un note indiquant quelles entrées manquent et pourquoi. Passez tail pour obtenir uniquement les entrées les plus récentes. Sur les serveurs ZenML 0.97+, la pagination s’effectue dans le magasin de journaux ; sur la version 0.96, l’ancien point de terminaison à requête unique est utilisé.

Utilisez ZENML_MCP_PROFILE=legacy lorsqu’un client existant dépend encore des anciens noms spécifiques aux entités, tels que list_pipeline_runs. Cela conserve la couche de compatibilité des noms d’outils et des schémas caractérisés pour ZenML 0.97.0. Cela n’ajoute pas la prise en charge des versions antérieures du serveur ZenML. Utilisez-le uniquement pendant la migration : les formes de réponse héritées peuvent exposer davantage de métadonnées opérationnelles que les outils compacts, bien que le serveur omette les configurations contenant des identifiants et les autres champs sensibles dans les deux profils.

L’enregistrement et l’accès en écriture sont indépendants :

Profil	Politique	Outils annoncés
compact	read_write	16
compact	read_only	11
legacy	read_write	57
legacy	read_only	52

Définissez ZENML_MCP_WRITE_POLICY=read_only pour retirer les quatre outils génériques de mutation et trigger_pipeline de la découverte et de la distribution MCP. La découverte des ressources omet également les schémas de création, de mise à jour, de suppression et d’action. L’ancien paramètre ZENML_MCP_READ_ONLY=true reste accepté ; les valeurs de politique non valides entraînent un refus par défaut, en mode lecture seule. Une valeur ZENML_MCP_PROFILE non valide interrompt le démarrage avec une erreur de configuration.

La version 2.0.0 nécessite MCP Python SDK 2.2.0 et ZenML 0.96.4. Le profil compact est le nouveau profil par défaut et constitue un changement incompatible dans la découverte pour les clients qui appellent des noms d’outils spécifiques aux entités. Définissez ZENML_MCP_PROFILE=legacy pendant la migration de ces clients, puis remplacez chaque appel par les outils génériques de ressources.

Les résultats de mutation distinguent les issues completed, accepted et unknown. Le serveur ne réessaie pas une mutation après qu’elle a pu atteindre ZenML. En cas de résultat accepté ou inconnu, suivez les instructions de rapprochement de la réponse avant de décider de réessayer. Utilisez la lecture nommée lorsqu’elle est disponible. La création de webhooks et la rotation de secrets peuvent renvoyer une nouvelle clé secrète de signature une seule fois ; les lectures ultérieures ne l’incluent pas. Les schémas de suppression précisent si une opération archive les métadonnées, les supprime, déprovisionne une ressource active ou peut supprimer les données d’artefact stockées.

La première version 2.0 couvre les opérations courantes pour les projets, les stacks et leurs composants, les flavors, les services, les pipelines et leurs exécutions, les snapshots et les modèles, les déploiements, les artefacts et leurs versions, les modèles et leurs versions, les tags, les connecteurs, les dépôts de code, les webhooks, les déclencheurs, les conditions d’attente et les invocations de hooks. Les utilisateurs, les planifications, les types de connecteurs de service, les secrets et les demandes de ressources bénéficient de la couverture en lecture seule indiquée par zenml_describe_resources. Sont exclus l’administration du plan de contrôle ZenML Cloud, l’administration de Resource Manager, l’administration des utilisateurs et des identifiants, les opérations CRUD sur les valeurs secrètes, la connexion et la vérification des connecteurs, les événements webhook bruts, ainsi que les outils agrégés de débogage ou de lignage.

Pour commencer un workflow générique, découvrez le schéma précis, puis appelez-le :

zenml_describe_resources(resource_type="pipeline_run", operation="list")
zenml_list_resources(
    resource_type="pipeline_run",
    filters={"status": "completed", "sort_by": "desc:created"},
    page=1,
    size=10,
)

Les prompts et les ressources restent disponibles dans les deux profils. Les prompts d’analyse, les points de terminaison de schéma de ressource délimités et most_recent_runs sont des prompts ou des ressources MCP, et non des outils.

Compatibilité des modèles d’exécution

ZenML 0.97.0 conserve les API CRUD des modèles d’exécution. Les snapshots sont privilégiés pour les nouveaux workflows. La création pratique de pipelines et le paramètre de déclenchement basé sur les modèles sont obsolètes. Dans le profil hérité, get_run_template et list_run_templates restent disponibles pour les clients existants.

L’entrée héritée tag reste dans list_run_templates pour assurer la compatibilité du schéma, mais ZenML 0.97.0 ne dispose d’aucun filtre équivalent côté serveur. Toute valeur non nulle est rejetée avant l’appel au SDK. Le filtrage des snapshots par tag reste disponible.

Migration : modèles d’exécution → snapshots

Pourquoi ce changement ? Les snapshots ont remplacé les modèles d’exécution comme artefact de pipeline exécutable privilégié par ZenML. Le SDK 0.97.0 prend toujours en charge les opérations CRUD sur les modèles d’exécution, tandis que le nouveau code doit utiliser les snapshots.

Guide de migration rapide

Modèle hérité (modèles)	Modèle compact (snapshots)
list_run_templates()	zenml_list_resources(resource_type="snapshot", filters={"runnable": true, "named_only": true})
get_run_template(name)	zenml_get_resource(resource_type="snapshot", resource_id=id)
trigger_pipeline(template_id=...)	trigger_pipeline(snapshot_name_or_id=...)

Exemple de workflow (priorité aux snapshots)

1. Discover project context:
   → get_active_project()

2. Find runnable snapshots:
   → zenml_list_resources(resource_type="snapshot", filters={"runnable": true, "named_only": true})

3. Trigger a run:
   → trigger_pipeline(snapshot_name_or_id="my-snapshot")

4. Check deployments:
   → zenml_list_resources(resource_type="deployment", filters={"status": "running"})
   → get_deployment_logs(name_id_or_prefix="my-deployment", tail=100)

Pour remplacer des paramètres lors du déclenchement d’un snapshot exécutable, transmettez une configuration d’exécution ZenML (le snapshot lui-même reste inchangé) :

trigger_pipeline(
    snapshot_name_or_id="my-snapshot",
    run_configuration={
        "steps": {"train": {"parameters": {"learning_rate": 0.01}}},
        "enable_cache": False,
    },
)

Pour les snapshots statiques, remplacez les paramètres des étapes comme indiqué ci-dessus. Les remplacements de run_configuration={"parameters": {...}} au niveau supérieur concernent les paramètres de la fonction de pipeline et ne sont pris en charge que pour les snapshots dynamiques ; ZenML les rejette pour les snapshots statiques.

Remarque : get_deployment_logs renvoie une sortie limitée (100 lignes par défaut, 1000 au maximum, plafonnée à 100KB) et nécessite l’installation de l’intégration de déployeur appropriée.

Configuration rapide via le tableau de bord (recommandée)

Le moyen le plus simple de configurer le serveur MCP ZenML est d’utiliser la page des paramètres MCP de votre tableau de bord ZenML.

Accédez à Paramètres → MCP dans votre tableau de bord ZenML pour obtenir :

• Des extraits préconfigurés pour l’URL et les identifiants de votre serveur
• Une installation en un clic via des liens profonds pour les IDE pris en charge
• Des configurations à copier-coller pour VS Code, Claude Desktop, Cursor, Claude Code, OpenAI Codex et plus encore
• Des options Docker et uv selon vos préférences

Utilisateurs de ZenML Pro

La page des paramètres MCP vous permet de générer un jeton d’accès personnel (PAT) en un clic. Le jeton est automatiquement inclus dans tous les extraits de configuration générés.

Utilisateurs de ZenML OSS

1. Créez d’abord un jeton de compte de service via Paramètres → Comptes de service
2. Collez le jeton dans la page des paramètres MCP
3. Copiez la configuration générée pour votre IDE

---

Vous préférez une configuration manuelle ? Consultez les instructions détaillées ci-dessous.

Apps MCP (expérimental)

Que sont les Apps MCP ? Les Apps MCP sont des interfaces HTML interactives que les serveurs MCP peuvent intégrer directement aux clients d’IA. Elles s’affichent dans des iframes isolées et peuvent appeler les outils du serveur dans les deux sens. Consultez l’annonce officielle pour tous les détails.

Ce serveur inclut deux Apps MCP expérimentales :

App	Outil	Description
Tableau de bord des exécutions de pipeline	open_pipeline_run_dashboard	Tableau interactif des exécutions de pipeline récentes, avec leur état, les détails des étapes et les journaux
Graphique d’activité des exécutions	open_run_activity_chart	Graphique à barres de l’activité des exécutions de pipeline au cours des 30 derniers jours, avec répartition par état

Ces Apps sont fournies à titre d’exemples de preuve de concept. Nous accueillons volontiers vos retours et contributions pour d’autres Apps MCP. Cette nouvelle fonctionnalité n’en est qu’à ses débuts ; il faudra voir comment elle évolue. Nous prévoyons de la prendre davantage en charge à l’avenir.

Clients pris en charge

Les Apps MCP nécessitent le transport Streamable HTTP (et non stdio). Les clients suivants prennent actuellement en charge les Apps MCP :

• ✅ VS Code (édition Insiders)
• ✅ Goose
• ✅ ChatGPT (lancement prochain)
• ⚠️ Claude Desktop — fin janvier 2026, les Apps ne s’affichent pas encore.
• ⚠️ Claude.ai (Web) — fin janvier 2026, les Apps ne s’affichent pas encore.

Remarque : Nous n’avons pas pu effectuer de tests approfondis avec Claude Desktop ou Claude.ai au moment de la rédaction. Si vous rencontrez des problèmes, veuillez nous les signaler.

Exécuter des Apps MCP avec Docker

Les Apps MCP utilisent Streamable HTTP. Laissez le port du conteneur lié à l’interface loopback et placez un proxy inverse authentifié ou un service d’accès tenant compte de l’identité devant celui-ci avant d’autoriser l’accès à distance. La validation de Host et Origin protège contre le rebinding DNS ; elle n’authentifie pas les appelants.

1. Construire et exécuter le conteneur Docker :

docker build -t mcp-zenml:apps .

docker run --rm -d --name mcp-zenml-apps -p 127.0.0.1:8001:8001 \
  -e ZENML_STORE_URL="https://your-zenml-server.example.com" \
  -e ZENML_STORE_API_KEY="your-api-key" \
  -e ZENML_MCP_PROFILE="compact" \
  -e ZENML_MCP_WRITE_POLICY="read_write" \
  -e ZENML_ACTIVE_PROJECT_ID="your-project-id" \
  mcp-zenml:apps --transport streamable-http --host 0.0.0.0 --port 8001 \
  --disable-dns-rebinding-protection

2. Configurez un accès distant authentifié :

Créez un tunnel Cloudflare nommé, un Tailscale Funnel avec des contrôles d’accès ou un proxy inverse authentifié équivalent. Faites pointer son origine privée vers http://127.0.0.1:8001, exigez une identité ou des identifiants de service pour le nom d’hôte public et ne transmettez à l’origine que les requêtes authentifiées. Configurez votre client MCP pour utiliser le flux OAuth pris en charge par le fournisseur ou des en-têtes d’autorisation.

Avant d’ajouter les identifiants ZenML au conteneur, vérifiez qu’une requête non authentifiée ne peut pas atteindre MCP :

curl -i https://mcp.example.com/mcp

La réponse doit être le 401, le 403 ou la redirection de connexion du fournisseur d’accès. Une réponse JSON-RPC ou MCP signifie que le périmètre est ouvert et doit d’abord être sécurisé.

3. Connectez votre client authentifié :

{
	"servers": {
		"ZenML": {
			"url": "https://mcp.example.com/mcp",
			"type": "http"
		}
	},
	"inputs": []
}

• Demandez à l’IA « d’ouvrir le tableau de bord des exécutions de pipeline » ou « d’afficher le graphique d’activité des exécutions »

Remarques importantes :

• ZENML_ACTIVE_PROJECT_ID est obligatoire — sans lui, les outils d’exécution de pipeline échoueront avec « No project is currently set as active »
• --disable-dns-rebinding-protection convient uniquement lorsque le proxy authentifié valide l’hôte public et que le port du conteneur reste limité à l’interface de bouclage
• Limitez la clé API ZenML aux autorisations nécessaires au client MCP ; utilisez ZENML_MCP_WRITE_POLICY=read_only pour les clients en lecture seule

Tests et assurance qualité

Ce projet comprend des tests automatisés pour garantir le bon fonctionnement du serveur MCP :

• 🔄 Tests de fumée automatisés : un test de fumée complet s’exécute tous les 3 jours via GitHub Actions
• 🚨 Création de tickets : les tests échoués créent automatiquement des tickets GitHub contenant des informations détaillées pour le débogage
• ⚡ CI rapide : utilise UV avec mise en cache pour accélérer l’installation des dépendances et les tests
• 🧪 Tests manuels : vous pouvez exécuter le test de fumée localement avec uv run scripts/test_mcp_server.py server/zenml_server.py

Les tests automatisés vérifient :

• la connexion au protocole MCP et la négociation initiale
• l’initialisation du serveur et la découverte des outils
• le fonctionnement de base des outils (lorsque le serveur ZenML est accessible)
• l’énumération des ressources et des prompts
• diagnose_zenml_setup renvoie des diagnostics structurés, même dans des environnements contraints

La CI sans identifiants couvre chaque adaptateur via le protocole MCP. La CI des PR et des versions démarre également un nouveau serveur ZenML OSS 0.97.0 sur une adresse de bouclage et exécute des tests de reçus CRUD persistants et d’isolation de projets portant le même nom. Le serveur utilise une configuration et une base de données temporaires, supprimées à la fin du travail ; aucun environnement du dépôt, runner auto-hébergé ou identifiant ZenML n’est nécessaire.

Le serveur OSS local de ZenML désactive l’authentification et son magasin SQL ne prend pas en charge la relecture de pipeline ni l’infrastructure de déploiement externe. Les tests de reçus d’accès restreint et de déclenchement, relecture, déploiement, condition d’attente et demande de ressources avec fonctionnalités activées restent donc des contrôles facultatifs distincts. Ils nécessitent ZENML_MCP_RESTRICTED_INTEGRATION=1 avec ZENML_MCP_RESTRICTED_API_KEY, ou ZENML_MCP_ACTION_INTEGRATION=1 avec les UUID exacts des fixtures jetables dans ZENML_MCP_ACTION_FIXTURE, respectivement. Un test ignoré en raison d’un contrôle facultatif ne prouve pas que ces fonctionnalités ont réussi. Un opérateur peut définir ZENML_MCP_REQUIRE_COMPLETE_INTEGRATION=1 pour transformer l’absence d’un contrôle facultatif en échec. Le provisionnement de l’infrastructure cloud ne fait jamais partie de l’exécution des tests par défaut.

Débogage avec MCP Inspector

Pour le débogage interactif, utilisez MCP Inspector — un outil Web qui vous permet de tester les outils MCP en temps réel :

# Using .env.local (recommended for development)
cp .env.local.example .env.local  # Then edit with your credentials
source .env.local && npx @modelcontextprotocol/inspector \
  -e ZENML_STORE_URL=$ZENML_STORE_URL \
  -e ZENML_STORE_API_KEY=$ZENML_STORE_API_KEY \
  -- uv run server/zenml_server.py

Une interface Web s’ouvre avec vos identifiants préremplis — cliquez simplement sur Connect et utilisez l’onglet Tools pour tester interactivement n’importe quel outil.

Consultez CLAUDE.md pour des instructions de débogage plus détaillées.

Confidentialité et analyses

Le serveur MCP ZenML collecte des données d’utilisation anonymes pour nous aider à améliorer le produit.

Nous suivons :

• les outils utilisés et leur fréquence d’utilisation
• les taux et types d’erreurs (type d’erreur uniquement, sans messages)
• des informations de base sur l’environnement (système d’exploitation, version de Python et exécution dans Docker/CI ou non)
• la durée des sessions et les habitudes d’utilisation des outils

Nous ne collectons PAS :

• l’URL de votre serveur ZenML ni votre clé API
• les noms de pipelines, de modèles ou toute donnée commerciale
• les messages d’erreur ou les traces de pile
• toute information permettant de vous identifier personnellement

Pour désactiver les analyses :

# Option 1
export ZENML_MCP_ANALYTICS_ENABLED=false

# Option 2
export ZENML_MCP_DISABLE_ANALYTICS=true

Pour le débogage et les tests (consigne les événements dans stderr au lieu de les envoyer) :

export ZENML_MCP_ANALYTICS_DEV=true

Pour les utilisateurs de Docker : vous pouvez définir ZENML_MCP_ANALYTICS_ID (doit être un UUID valide) pour conserver un identifiant anonyme cohérent entre les redémarrages du conteneur. Si vous ne le définissez pas et que le système de fichiers du conteneur ne peut pas conserver le fichier d’identifiant d’analyse, le serveur utilise un UUID anonyme déterministe dérivé d’un hachage de ZENML_STORE_URL (l’URL elle-même n’est jamais envoyée comme propriété d’événement).

Options d’analyse supplémentaires :

• ZENML_MCP_ANALYTICS_SHUTDOWN_TIMEOUT_S — durée maximale (en secondes) pour vider les données d’analyse de manière synchrone à l’arrêt (valeur par défaut : 1.0)

Remarque sur le suivi à l’arrêt : les événements d’arrêt sont envoyés de manière synchrone avec un délai d’attente limité afin d’améliorer la fiabilité de leur transmission. Toutefois, si un conteneur est arrêté avec SIGKILL (par exemple, docker kill), les gestionnaires d’arrêt ne peuvent pas s’exécuter — il s’agit d’une limitation de Docker/du système d’exploitation, et non d’un bogue.

Validation au démarrage

Vous pouvez activer un diagnostic léger au démarrage :

# Print warnings but start normally
uv run server/zenml_server.py --startup-validation warn

# Exit non-zero if required setup is missing (useful in Docker/CI)
uv run server/zenml_server.py --startup-validation strict

Vous pouvez également définir cette option via la variable d’environnement : ZENML_MCP_STARTUP_VALIDATION=warn.

L’outil diagnose_zenml_setup est également disponible comme outil MCP pour le dépannage à l’exécution — il fonctionne même si le SDK ZenML n’est pas installé ou si des variables d’environnement sont manquantes.

Configuration manuelle

Prérequis

Vous devez avoir accès à un serveur ZenML déployé. Si vous n’en avez pas, vous pouvez vous inscrire à un essai gratuit de ZenML Pro et nous nous chargerons du déploiement.

Conseil : une fois votre serveur ZenML disponible, consultez la page des paramètres MCP de votre tableau de bord pour profiter de la configuration la plus simple.

Compatibilité : la version actuelle est testée avec ZenML 0.97.0. Si vous utilisez une version plus ancienne de ZenML, veuillez utiliser une version antérieure de ce serveur MCP.

Vous devrez également (probablement) installer uv localement. Pour plus d’informations, consultez la documentation de uv. Nous recommandons de l’installer à l’aide de son script d’installation ou de brew si vous utilisez un Mac. (Techniquement, ce n’est pas indispensable, mais cela facilite l’installation et la configuration.)

Vous devrez également cloner ce dépôt quelque part en local :

git clone https://github.com/zenml-io/mcp-zenml.git

Votre fichier de configuration MCP

Le fichier de configuration MCP est un fichier JSON qui indique au client MCP comment se connecter à votre serveur MCP. Les différents clients MCP utilisent ou définissent ce fichier de différentes manières. Deux clients MCP couramment utilisés sont Claude Desktop et Cursor, pour lesquels nous fournissons ci-dessous des instructions d’installation.

Vous devrez spécifier votre serveur MCP ZenML au format suivant :

{
    "mcpServers": {
        "zenml": {
            "command": "/usr/local/bin/uv",
            "args": ["run", "path/to/server/zenml_server.py"],
            "env": {
                "LOGLEVEL": "WARNING",
                "NO_COLOR": "1",
                "ZENML_LOGGING_COLORS_DISABLED": "true",
                "ZENML_LOGGING_VERBOSITY": "WARN",
                "ZENML_ENABLE_RICH_TRACEBACK": "false",
                "ZENML_MCP_PROFILE": "compact",
                "ZENML_MCP_WRITE_POLICY": "read_write",
                "PYTHONUNBUFFERED": "1",
                "PYTHONIOENCODING": "UTF-8",
                "ZENML_STORE_URL": "https://your-zenml-server-goes-here.com",
                "ZENML_STORE_API_KEY": "your-api-key-here"
            }
        }
    }
}

Lorsque ZENML_STORE_API_KEY est fourni, le serveur MCP conserve les identifiants ZenML en mémoire et ne lit ni ne met à jour les identifiants enregistrés par zenml login. Cela s’applique aux exécutions Python directes, aux extensions MCPB et à Docker. Les connexions sans clé API peuvent toujours utiliser votre session de terminal enregistrée. Redémarrez le serveur MCP après avoir modifié sa clé API ; une nouvelle conversation peut réutiliser le processus du serveur déjà en cours d’exécution.

Vous devrez remplacer quatre valeurs fictives :

• le chemin vers votre installation locale de uv (le chemin indiqué ci-dessus correspond à celui d’un Mac si vous l’avez installé via brew)
• le chemin vers le fichier zenml_server.py (ce fichier sera exécuté lors de la connexion au serveur MCP). Il se trouve à la racine de ce dépôt. Vous devrez indiquer son chemin complet exact.
• l’URL du serveur ZenML (l’URL de votre serveur ZenML, que vous trouverez dans l’interface ZenML Cloud). Elle ressemblera à https://d534d987a-zenml.cloudinfra.zenml.io.
• la clé API du serveur ZenML (la clé API de votre serveur ZenML, que vous trouverez dans l’interface ZenML Cloud ou en lisant cette documentation pour savoir comment en créer une. Pour le serveur MCP ZenML, nous recommandons d’utiliser un compte de service.)

Vous pouvez modifier la manière dont vous exécutez le fichier Python du serveur MCP, mais uv sera probablement l’option la plus simple, car il gère l’environnement et l’installation des dépendances à votre place.

Installation pour Claude Desktop

Alternative rapide : utilisez la page des paramètres MCP de votre tableau de bord ZenML (Settings → MCP) pour obtenir des instructions d’installation préconfigurées et des liens directs pour Claude Desktop.

Vous devez avoir installé la dernière version de Claude Desktop.

Vous pouvez simplement ouvrir le menu Settings et faire glisser le fichier mcp-zenml.mcpb depuis la racine de ce dépôt vers le menu ; il vous guidera tout au long du processus d’installation et de configuration. Vous devrez ajouter l’URL de votre serveur ZenML et sa clé API.

Remarque : les bundles MCP (.mcpb) remplacent l’ancien format Desktop Extensions (.dxt) ; les fichiers .dxt existants fonctionnent toujours dans Claude Desktop.

Facultatif : améliorer l’affichage des résultats des outils ZenML

Pour mieux afficher les résultats des outils ZenML, vous pouvez configurer Claude afin qu’il présente les réponses JSON dans un format plus lisible. Dans Claude Desktop, accédez à Settings → Profile, puis, dans la section « What personal preferences should Claude consider in responses? », ajoutez un texte similaire à celui-ci (ou utilisez exactement ces mots !) :

When using zenml tools which return JSON strings and you're asked a question, you might want to consider using markdown tables to summarize the results or make them easier to view!

Cela incitera Claude à présenter les résultats des outils ZenML sous forme de tableaux Markdown, ce qui rendra les informations beaucoup plus faciles à lire et à comprendre.

Installation pour Cursor

Alternative rapide : la page des paramètres MCP de votre tableau de bord ZenML (Settings → MCP) peut générer le contenu exact de mcp.json avec vos identifiants préremplis.

Vous devez avoir installé Cursor.

Cursor fonctionne légèrement différemment de Claude Desktop : le fichier de configuration est défini pour chaque dépôt. Cela signifie que si vous souhaitez utiliser le serveur MCP ZenML dans plusieurs dépôts, vous devrez spécifier le fichier de configuration dans chacun d’eux.

Pour le configurer dans un seul dépôt, vous devrez :

• créer un dossier .cursor à la racine de votre dépôt
• y créer un fichier mcp.json contenant le texte ci-dessus
• accéder aux paramètres de Cursor et cliquer sur le serveur ZenML pour l’« activer ».

D’après notre expérience, un indicateur d’erreur rouge peut parfois s’afficher alors que le serveur fonctionne. Vous pouvez le vérifier en discutant dans la fenêtre de chat de Cursor. Cursor vous indiquera s’il peut accéder aux outils ZenML.

Image Docker

Vous pouvez exécuter le serveur dans un conteneur Docker. Le processus communique via stdio et attend donc une connexion d’un client MCP. Transmettez vos identifiants ZenML via des variables d’environnement.

Images précompilées (Docker Hub)

Récupérez la dernière image multi-architecture :

docker pull zenmldocker/mcp-zenml:latest

Les versions publiées sont étiquetées sous la forme X.Y.Z :

docker pull zenmldocker/mcp-zenml:2.0.0

Exécutez le serveur avec vos identifiants ZenML (mode stdio) :

docker run -i --rm \
  -e ZENML_STORE_URL="https://your-zenml-server.example.com" \
  -e ZENML_STORE_API_KEY="your-api-key" \
  zenmldocker/mcp-zenml:latest

Configuration MCP canonique avec Docker

{
  "mcpServers": {
    "zenml": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ZENML_STORE_URL=https://...",
        "-e", "ZENML_STORE_API_KEY=ZENKEY_...",
        "-e", "ZENML_ACTIVE_PROJECT_ID=...",
        "-e", "ZENML_MCP_PROFILE=compact",
        "-e", "ZENML_MCP_WRITE_POLICY=read_write",
        "-e", "LOGLEVEL=WARNING",
        "-e", "NO_COLOR=1",
        "-e", "ZENML_LOGGING_COLORS_DISABLED=true",
        "-e", "ZENML_LOGGING_VERBOSITY=WARN",
        "-e", "ZENML_ENABLE_RICH_TRACEBACK=false",
        "-e", "PYTHONUNBUFFERED=1",
        "-e", "PYTHONIOENCODING=UTF-8",
        "zenmldocker/mcp-zenml:latest"
      ]
    }
  }
}

Compilation locale

Depuis la racine du dépôt :

docker build -t zenmldocker/mcp-zenml:local .

Exécutez l’image compilée localement :

docker run -i --rm \
  -e ZENML_STORE_URL="https://your-zenml-server.example.com" \
  -e ZENML_STORE_API_KEY="your-api-key" \
  zenmldocker/mcp-zenml:local

Bundles MCP (.mcpb)

Ce projet utilise des bundles MCP (.mcpb), qui succèdent aux Desktop Extensions (DXT) d’Anthropic. Les bundles MCP regroupent un serveur MCP complet (y compris ses dépendances) dans un seul fichier avec une configuration conviviale.

Remarque sur le changement de nom : les bundles MCP remplacent l’ancien format .dxt. Claude Desktop reste rétrocompatible avec les fichiers .dxt existants, mais nous distribuons désormais mcp-zenml.mcpb et recommandons de l’utiliser à l’avenir.

Le fichier mcp-zenml.mcpb à la racine du dépôt utilise l’environnement d’exécution UV de MCPB 0.4. L’hôte installe les dépendances Python épinglées pour le système d’exploitation actuel, ce qui permet au même bundle de fonctionner sur macOS, Windows et Linux sans intégrer d’extensions natives spécifiques à une plateforme. Une connexion réseau est nécessaire lors de la première résolution de l’environnement fourni par UV. Les builds du bundle réutilisent le fichier mcpb-uv.lock validé dans le dépôt et résolvent son graphe de dépendances Python en mode hors ligne. La liste des dépendances du bundle provient de [project].dependencies dans pyproject.toml. Après avoir modifié cette liste, définissez MCPB_REFRESH_LOCK=1 pour relancer la résolution en ligne tout en conservant chaque version épinglée qui reste compatible ; MCPB_REFRESH_LOCK=upgrade met à jour toutes les versions épinglées vers leur version la plus récente.

Lorsque vous faites glisser le fichier .mcpb et le déposez dans les réglages de Claude Desktop, les opérations suivantes sont automatiquement prises en charge :

• Installation des dépendances d’exécution
• Gestion sécurisée de la configuration
• Compatibilité multiplateforme
• Processus de configuration convivial

Pour en savoir plus, consultez l’annonce d’Anthropic concernant les extensions Desktop (DXT) et les recommandations associées sur le packaging des bundles MCP dans leur documentation : https://www.anthropic.com/engineering/desktop-extensions

Publié dans le registre MCP d’Anthropic

Ce serveur MCP est publié dans le registre MCP officiel d’Anthropic et peut être découvert par les hôtes compatibles. À chaque version balisée, notre CI met à jour l’entrée du registre via le CLI mcp-publisher du registre, à l’aide de GitHub OIDC. Vous pouvez ainsi installer ou découvrir directement le ZenML MCP Server partout où le registre est pris en charge (par exemple, dans le catalogue des extensions de Claude Desktop).

• Toujours à jour : l’entrée du registre est actualisée à chaque version à partir de manifest.json et server.json du commit balisé.
• Autres méthodes d’installation : vous pouvez toujours effectuer une installation locale à l’aide du bundle .mcpb empaqueté (voir ci-dessus) ou exécuter l’image Docker.

Pour en savoir plus sur le registre :

• Registre MCP d’Anthropic (dépôt communautaire) : https://github.com/modelcontextprotocol/registry