ZenML

Serveur MCP pour ZenML

Ce projet implémente un serveur Model Context Protocol (MCP) pour 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 IA » — offrant une manière standardisée de connecter les modèles IA à différentes sources de données et outils.

MCP suit une architecture client-serveur où :

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

Qu'est-ce que ZenML ?

ZenML est une plateforme open-source pour construire et gérer des pipelines ML et IA. Elle fournit une interface unifiée pour gérer les données, les modèles et les expériences.

Pour plus d'informations, consultez le site web ZenML et notre documentation.

Fonctionnalités

Le serveur fournit des outils MCP pour accéder aux fonctionnalités de lecture principales du serveur ZenML, offrant un moyen d'obtenir des informations en direct sur :

Entités principales

• Utilisateurs — comptes utilisateurs et permissions
• Stacks — configurations d'infrastructure
• Composants de stack — blocs de construction individuels du stack
• Flavors — types de composants disponibles
• Connecteurs de services — authentification cloud

Exécution des pipelines

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

Déploiement et service

• Instantanés — configurations de pipeline figées (l'artefact « quoi exécuter/servir »)
• Déploiements — instances de service d'exécution avec statut, URL et journaux
• Services — points de terminaison de service de modèles

Organisation et découverte

• Projets — conteneurs organisationnels pour les ressources ZenML
• Étiquettes — étiquettes de métadonnées transversales pour la découverte
• Builds — artefacts de build de pipeline avec informations d'image et de code

Modèles

• Modèles — entrées du registre de modèles ML
• Versions de modèles — artefacts de modèles 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 instantanés sont préférés pour les nouveaux workflows (voir Guide de migration)

Le serveur vous permet également de déclencher de nouvelles exécutions de pipeline en utilisant les instantanés (recommandé) ou le paramètre de déclenchement basé sur les modèles, désormais déprécié.

Remarque : nous améliorons continuellement cette intégration en fonction des retours des utilisateurs. Rejoignez notre communauté Slack pour partager 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 ordinaires et les actions de cycle de vie finies :

Outil	Objectif
zenml_describe_resources	Découvrir les types de ressources pris en charge et les schémas d'opérations bornés
zenml_list_resources	Lister un type de ressource avec filtres validés et pagination
zenml_get_resource	Obtenir une ressource, avec portée parent et projet si 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 exact
zenml_delete_resource	Supprimer ou archiver un UUID de ressource exact
zenml_action_resource	Exécuter une action de cycle de vie ou de relation sur liste blanche sans nouvelles tentatives

Neuf outils ciblés restent car ils fournissent des diagnostics, un contexte actif, des journaux ou du code en flux continu, l'exécution de pipelines ou une application 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 plus 50 000 entrées, des plus anciennes aux plus récentes, avec un indicateur possibly_truncated, plus 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+, il parcourt le magasin de journaux ; sur 0.96, il utilise l'ancien point de terminaison à requête unique.

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 pour ZenML 0.97.0. Cela n'ajoute pas de prise en charge pour les versions plus anciennes du serveur ZenML. Utilisez-le uniquement pendant la migration : les formes de réponse héritées peuvent exposer plus de métadonnées opérationnelles que les outils compacts, bien que le serveur omette la configuration contenant des informations d'identification et d'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 supprimer les quatre outils de mutation génériques et trigger_pipeline de la découverte et de la répartition MCP. La découverte de ressources omet également les schémas de création, mise à jour, suppression et action. L'ancien paramètre ZENML_MCP_READ_ONLY=true reste accepté ; les valeurs de politique invalides échouent en mode lecture seule. Un ZENML_MCP_PROFILE invalide arrête le démarrage avec une erreur de configuration.

La version 2.0.0 nécessite le SDK Python MCP 2.2.0 et ZenML 0.96.4. Le profil compact est le nouveau défaut et constitue un changement de découverte majeur 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 déplacez chaque appel vers les outils de ressources génériques.

Les résultats de mutation distinguent les résultats completed, accepted et unknown. Le serveur ne réessaie pas une mutation après qu'elle a pu atteindre ZenML. Pour un résultat accepté ou inconnu, suivez les instructions de réconciliation dans la réponse avant de décider de rappeler. Utilisez la lecture nommée lorsqu'elle est disponible. La création de webhooks et la rotation de secrets peuvent renvoyer un nouveau secret de signature une seule fois ; les lectures ultérieures l'omettent. Les schémas de suppression indiquent si une opération archive des métadonnées, supprime des métadonnées, déprovisionne une ressource en direct ou peut supprimer des données d'artefact stockées.

La première version 2.0 couvre les opérations ordinaires pour les projets, les stacks et composants, les flavors, les services, les pipelines et exécutions, les instantanés et modèles, les déploiements, les artefacts et versions, les modèles et versions, les étiquettes, les connecteurs, les dépôts de code, les webhooks, les déclencheurs, les conditions d'attente et les invocations de hooks. Les utilisateurs, planifications, types de connecteurs de services, secrets et demandes de ressources ont la couverture en lecture seule indiquée par zenml_describe_resources. Cela exclut l'administration du plan de contrôle ZenML Cloud, l'administration du gestionnaire de ressources, l'administration des utilisateurs et des informations d'identification, la CRUD des valeurs de secrets, la connexion et la vérification des connecteurs, les événements de webhook bruts et les outils de débogage ou de lignage agrégés.

Démarrez un workflow générique en découvrant le schéma précis, puis en l'appelant :

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 invites et ressources restent disponibles dans les deux profils. Les invites d'analyse, les points de terminaison de schéma de ressources bornés et most_recent_runs sont des invites ou ressources MCP plutôt que des outils.

Compatibilité des modèles d'exécution

ZenML 0.97.0 conserve les API CRUD des modèles d'exécution. Les instantanés sont préférés pour les nouveaux workflows. La création pratique de pipelines et le paramètre de déclenchement basé sur les modèles sont dépréciés. 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 la compatibilité des schémas, mais ZenML 0.97.0 n'a pas de filtre côté serveur équivalent. Une valeur non nulle est rejetée avant l'appel SDK. Le filtrage par étiquette d'instantané reste disponible.

Migration : modèles d'exécution → instantanés

Pourquoi ce changement ? Les instantanés ont remplacé les modèles d'exécution comme artefact de pipeline exécutable préféré de ZenML. Le SDK 0.97.0 prend toujours en charge la CRUD des modèles d'exécution, tandis que le nouveau code devrait utiliser les instantanés.

Guide de migration rapide

Modèle hérité (modèles)	Modèle compact (instantanés)
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 (instantanés d'abord)

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)

Remarque : get_deployment_logs renvoie une sortie bornée (100 lignes par défaut, 1000 maximum, plafonnée à 100 Ko) et nécessite que l'intégration de déploiement appropriée soit installée.

Configuration rapide via le tableau de bord (recommandé)

La manière la plus simple de configurer le serveur MCP ZenML est via la page Paramètres MCP de votre tableau de bord ZenML.

Naviguez vers Paramètres → MCP dans votre tableau de bord ZenML pour obtenir :

• Extraits préconfigurés pour votre URL de serveur et vos informations d'identification spécifiques
• Installation en un clic via des liens profonds pour les IDE pris en charge
• Configurations copier-coller pour VS Code, Claude Desktop, Cursor, Claude Code, OpenAI Codex, et plus
• Options Docker et uv selon votre préférence

Utilisateurs ZenML Pro

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

Utilisateurs 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 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.

Applications MCP (expérimental)

Que sont les applications MCP ? Les applications MCP sont des interfaces HTML interactives que les serveurs MCP peuvent servir directement dans les clients IA. Elles s'affichent dans des iframes sandboxées et peuvent appeler les outils du serveur de manière bidirectionnelle. Consultez l'annonce officielle pour plus de détails.

Ce serveur inclut deux applications MCP expérimentales :

Application	Outil	Description
Tableau de bord des exécutions de pipelines	open_pipeline_run_dashboard	Tableau interactif des exécutions de pipelines récentes avec statut, détails des étapes et journaux
Graphique d'activité des exécutions	open_run_activity_chart	Graphique à barres de l'activité des exécutions de pipelines sur les 30 derniers jours avec répartition par statut

Ces applications sont incluses comme exemples de preuve de concept. Nous accueillons les retours et contributions pour plus d'applications MCP. Cette nouvelle fonctionnalité en est encore à ses débuts, nous devrons donc voir comment elle évolue. Nous prévoyons de la prendre en charge plus complètement à l'avenir.

Clients pris en charge

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

• ✅ VS Code (édition Insiders)
• ✅ Goose
• ✅ ChatGPT (lancement prochain)
• ⚠️ Claude Desktop — à la fin janvier 2026, ne rend pas encore les applications.
• ⚠️ Claude.ai (web) — à la fin janvier 2026, ne rend pas encore les applications.

Remarque : Nous n'avons pas pu tester en profondeur avec Claude Desktop ou Claude.ai au moment de la rédaction. Si vous rencontrez des problèmes, veuillez les signaler.

Exécution d'applications MCP avec Docker

Les applications MCP utilisent Streamable HTTP. Gardez le port du conteneur lié à loopback et placez un proxy inverse authentifié ou un service d'accès conscient de l'identité devant avant d'autoriser l'accès à distance. La validation de l'hôte et de l'origine protège contre le rebinding DNS ; elle n'authentifie pas les appelants.

1. Construisez et exécutez 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 l'accès distant authentifié : Créez un tunnel Cloudflare nommé, un Funnel Tailscale avec contrôles d'accès, ou un proxy inverse authentifié équivalent. Pointez son origine privée vers http://127.0.0.1:8001, exigez une identité ou un identifiant de service pour le nom d'hôte public, et transmettez uniquement les requêtes authentifiées à l'origine. Configurez votre client MCP pour utiliser le flux OAuth pris en charge par le fournisseur ou les 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 du fournisseur d'accès, ou une redirection de connexion. Une réponse JSON-RPC ou MCP signifie que le périmètre est ouvert et doit être corrigé en premier.

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 requis — sans lui, les outils d'exécution de pipeline échoueront avec « Aucun projet n'est actuellement défini comme actif »
• --disable-dns-rebinding-protection n'est approprié que lorsque le proxy authentifié valide l'hôte public et que le port du conteneur reste en boucle locale uniquement
• Restreignez la clé API ZenML aux autorisations dont le client MCP a besoin ; utilisez ZENML_MCP_WRITE_POLICY=read_only pour les clients en lecture seule

Tests et assurance qualité

Ce projet inclut des tests automatisés pour garantir que le serveur MCP reste fonctionnel :

• 🔄 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 problèmes : Les tests échoués créent automatiquement des problèmes GitHub avec des informations de débogage détaillées
• ⚡ CI rapide : Utilise UV avec mise en cache pour une installation et des tests rapides des dépendances
• 🧪 Tests manuels : Vous pouvez exécuter le test de fumée localement en utilisant uv run scripts/test_mcp_server.py server/zenml_server.py

Les tests automatisés vérifient :

• La connexion et la poignée de main du protocole MCP
• L'initialisation du serveur et la découverte des outils
• La fonctionnalité de base des outils (lorsque le serveur ZenML est accessible)
• L'énumération des ressources et des invites
• 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 OSS ZenML 0.97.0 sur une adresse de boucle locale et exécute des reçus CRUD persistants et d'isolation de projet de même nom. Le serveur utilise une configuration et une base de données temporaires qui sont supprimées à la sortie du travail ; aucun environnement de dépôt, exécuteur auto-hébergé ou identifiant ZenML n'est requis.

Le serveur OSS local de ZenML désactive l'authentification et son magasin SQL ne prend pas en charge la relecture de pipeline ou l'infrastructure de déploiement externe. L'accès restreint et les reçus de déclenchement, relecture, déploiement, condition d'attente et demande de ressource activés par fonctionnalité restent donc des portes d'opt-in séparées. Ils nécessitent ZENML_MCP_RESTRICTED_INTEGRATION=1 avec ZENML_MCP_RESTRICTED_API_KEY, ou ZENML_MCP_ACTION_INTEGRATION=1 avec les UUID de fixture jetables exacts dans ZENML_MCP_ACTION_FIXTURE, respectivement. Un saut conditionnel n'est pas une preuve que ces capacités ont réussi. Un opérateur peut définir ZENML_MCP_REQUIRE_COMPLETE_INTEGRATION=1 pour transformer une porte d'opt-in manquante en échec. Le provisionnement d'infrastructure cloud ne fait jamais partie de l'exécution de test par défaut.

Débogage avec MCP Inspector

Pour un débogage interactif, utilisez le MCP Inspector — un outil basé sur le 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

Cela ouvre une interface web avec vos identifiants pré-remplis — cliquez simplement sur Connecter et utilisez l'onglet Outils pour tester n'importe quel outil de manière interactive.

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

Confidentialité et analytique

Le serveur MCP ZenML collecte des analytiques d'utilisation anonymes pour nous aider à améliorer le produit.

Nous suivons :

• Quels outils sont utilisés et à quelle fréquence
• Les taux et types d'erreurs (type d'erreur uniquement, pas de messages)
• Les informations de base sur l'environnement (système d'exploitation, version Python, et si exécuté dans Docker/CI)
• La durée de session et les modèles d'utilisation des outils

Nous ne collectons PAS :

• Votre URL de serveur ZenML ou clé API
• Les noms de pipelines, noms de modèles, ou toute donnée métier
• Les messages d'erreur ou traces de pile
• Toute information personnellement identifiable

Pour désactiver l'analytique :

# Option 1
export ZENML_MCP_ANALYTICS_ENABLED=false

# Option 2
export ZENML_MCP_DISABLE_ANALYTICS=true

Pour le débogage/les tests (journalise les événements sur stderr au lieu de les envoyer) :

export ZENML_MCP_ANALYTICS_DEV=true

Pour les utilisateurs Docker : Vous pouvez définir ZENML_MCP_ANALYTICS_ID (doit être un UUID valide) pour maintenir un ID anonyme cohérent entre les redémarrages de conteneurs. Si vous ne le définissez pas et que le système de fichiers du conteneur ne peut pas persister le fichier d'ID analytique, le serveur revient à 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 analytiques supplémentaires :

• ZENML_MCP_ANALYTICS_SHUTDOWN_TIMEOUT_S — temps maximum (secondes) pour vider l'analytique de manière synchrone pendant l'arrêt (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 borné pour une meilleure fiabilité de livraison. Cependant, si un conteneur est tué avec SIGKILL (par exemple, docker kill), les gestionnaires d'arrêt ne peuvent pas se déclencher — c'est une limitation de Docker/OS, pas un bug.

Validation au démarrage

Vous pouvez activer un contrôle de 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 cela via une 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 lorsque le SDK ZenML n'est pas installé ou que les variables d'environnement sont manquantes.

Configuration manuelle

Prérequis

Vous devrez avoir accès à un serveur ZenML déployé. Si vous n'en avez pas, vous pouvez vous inscrire pour un essai gratuit sur ZenML Pro et nous gérerons le déploiement pour vous.

Astuce : Une fois que vous avez un serveur ZenML, consultez la page Paramètres MCP dans votre tableau de bord pour l'expérience de configuration la plus simple.

Compatibilité : La version actuelle est testée contre ZenML 0.97.0. Si vous exécutez une version plus ancienne de ZenML, veuillez utiliser une version antérieure de ce serveur MCP.

Vous aurez également (probablement) besoin d'avoir uv installé localement. Pour plus d'informations, consultez la documentation uv. Nous recommandons l'installation via leur script d'installation ou via brew si vous utilisez un Mac. (Techniquement, vous n'en avez pas besoin, mais cela facilite l'installation et la configuration.)

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

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. Différents clients MCP l'utiliseront ou le spécifieront différemment. Deux clients MCP couramment utilisés sont Claude Desktop et Cursor, pour lesquels nous fournissons des instructions d'installation ci-dessous.

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

Il y a quatre valeurs factices que vous devrez remplacer :

• le chemin vers votre uv installé localement (le chemin listé ci-dessus est où il serait sur un Mac si vous l'avez installé via brew)
• le chemin vers le fichier zenml_server.py (c'est le fichier qui sera exécuté lorsque vous vous connectez au serveur MCP). Ce fichier est situé dans ce dépôt à la racine. Vous devrez spécifier le chemin complet exact vers ce fichier.
• l'URL du serveur ZenML (c'est l'URL de votre serveur ZenML. Vous pouvez la trouver dans l'interface ZenML Cloud). Elle ressemblera à quelque chose comme https://d534d987a-zenml.cloudinfra.zenml.io.
• la clé API du serveur ZenML (c'est la clé API pour votre serveur ZenML. Vous pouvez la trouver dans l'interface ZenML Cloud ou lire ces documents sur comment en créer une. Pour les besoins du serveur MCP ZenML, nous recommandons d'utiliser un compte de service.)

Vous êtes libre de changer la façon dont vous exécutez le fichier Python du serveur MCP, mais utiliser uv sera probablement l'option la plus simple car il gère l'environnement et l'installation des dépendances pour vous.

Installation pour utilisation avec Claude Desktop

Alternative rapide : Utilisez la page Paramètres MCP dans votre tableau de bord ZenML (Paramètres → MCP) pour obtenir des instructions d'installation pré-configurées et des liens profonds pour Claude Desktop.

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

Vous pouvez simplement ouvrir le menu Paramètres et faire glisser le fichier mcp-zenml.mcpb depuis la racine de ce dépôt sur le menu et il vous guidera à travers le processus d'installation et de configuration. Vous devrez ajouter votre URL de serveur ZenML et votre clé API.

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

Optionnel : Améliorer l'affichage de la sortie des outils ZenML

Pour une meilleure expérience avec les résultats des outils ZenML, vous pouvez configurer Claude pour afficher les réponses JSON dans un format plus lisible. Dans Claude Desktop, allez dans Paramètres → Profil, et dans la section « Quelles préférences personnelles Claude devrait-il prendre en compte dans les réponses ? », ajoutez quelque chose comme ce qui suit (ou utilisez ces mots exacts !) :

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 encouragera Claude à formater les sorties des outils ZenML comme des tableaux markdown, rendant l'information beaucoup plus facile à lire et à comprendre.

Installation pour utilisation avec Cursor

Alternative rapide : La page Paramètres MCP dans votre tableau de bord ZenML (Paramètres → MCP) peut générer le contenu exact de mcp.json avec vos identifiants pré-remplis.

Vous devrez avoir Cursor installé.

Cursor fonctionne légèrement différemment de Claude Desktop en ce sens que vous spécifiez le fichier de configuration par dépôt. Cela signifie que si vous voulez 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 pour un seul dépôt, vous devrez :

• créer un dossier .cursor à la racine de votre dépôt
• à l'intérieur, créer un fichier mcp.json avec le contenu ci-dessus
• aller dans vos paramètres Cursor et cliquer sur le serveur ZenML pour l'« activer ».

D'après notre expérience, il affiche parfois un indicateur d'erreur rouge même si cela fonctionne. Vous pouvez l'essayer en discutant dans la fenêtre de chat Cursor. Il vous fera savoir s'il peut accéder aux outils ZenML ou non.

Image Docker

Vous pouvez exécuter le serveur comme un conteneur Docker. Le processus communique via stdio, donc il attendra une connexion client MCP. Passez vos identifiants ZenML via des variables d'environnement.

Images pré-construites (Docker Hub)

Tirez la dernière image multi-architecture :

docker pull zenmldocker/mcp-zenml:latest

Les versions versionnées sont étiquetées comme X.Y.Z :

docker pull zenmldocker/mcp-zenml:2.0.0

Exécutez 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 utilisant 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"
      ]
    }
  }
}

Construire localement

Depuis la racine du dépôt :

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

Exécutez l'image construite 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) — le successeur des extensions de bureau d'Anthropic (DXT). Les bundles MCP empaquettent un serveur MCP entier (y compris les dépendances) dans un seul fichier avec une configuration conviviale.

Remarque sur le renommage : Les bundles MCP remplacent l'ancien format .dxt. Claude Desktop reste rétrocompatible avec les fichiers .dxt existants, mais nous livrons maintenant mcp-zenml.mcpb et recommandons de l'utiliser à l'avenir.

Le fichier mcp-zenml.mcpb à la racine du dépôt utilise le runtime UV MCPB 0.4. L'hôte installe les dépendances Python épinglées pour le système d'exploitation actuel, donc le même bundle fonctionne sur macOS, Windows et Linux sans intégrer d'extensions natives spécifiques à la plateforme. L'installation nécessite un accès réseau la première fois que UV résout l'environnement groupé.

Les constructions de bundles réutilisent le mcpb-uv.lock validé 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 re-résoudre en ligne tout en conservant chaque épingle qui convient toujours ; MCPB_REFRESH_LOCK=upgrade déplace chaque épingle vers sa version la plus récente. Lorsque vous faites glisser et déposez le fichier .mcpb dans les paramètres de Claude Desktop, il gère automatiquement :

• L'installation des dépendances d'exécution
• La gestion sécurisée de la configuration
• La compatibilité multiplateforme
• Un processus d'installation convivial

Pour plus d'informations, consultez l'annonce d'Anthropic concernant les extensions de bureau (DXT) et les directives associées sur l'empaquetage des bundles MCP dans leur documentation : https://www.anthropic.com/engineering/desktop-extensions

Publié sur le registre MCP d'Anthropic

Ce serveur MCP est publié sur le registre MCP officiel d'Anthropic et est détectable par les hôtes compatibles. À chaque version étiquetée, notre CI met à jour l'entrée du registre via la CLI mcp-publisher du registre en utilisant GitHub OIDC, afin que vous puissiez installer ou découvrir le serveur MCP ZenML directement partout où le registre est pris en charge (par exemple, le catalogue d'extensions de Claude Desktop).

• Toujours à jour : l'entrée du registre est actualisée à chaque version à partir du manifest.json et du server.json du commit étiqueté.
• Chemins d'installation alternatifs : vous pouvez toujours installer localement via le bundle .mcpb empaqueté (voir ci-dessus) ou exécuter l'image Docker.

En savoir plus sur le registre ici :

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