Houdini MCP connecte Claude Desktop à SideFX Houdini avec une architecture locale en deux parties : un plugin Python chargé dans Houdini, puis un script passerelle MCP lancé côté client. Le dépôt capoomgit/houdini-mcp indique que le plugin écoute par défaut sur localhost:9876 et que la passerelle communique avec Claude en stdio tout en parlant à Houdini par TCP. Lors de la vérification GitHub du 26 août 2026, le dépôt était sous licence MIT, comptait 282 étoiles et 41 forks, et son pyproject déclarait Python 3.12 ou plus récent.
Pour Educasium, ce connecteur est intéressant parce qu'il cible un logiciel de création procédurale utilisé en VFX, motion, visualisation et workflows techniques. Les outils exposés couvrent la lecture de scène, la création de nœuds, les connexions, les paramètres, les wrangles, les données de géométrie et plusieurs rendus de viewport. Il faut toutefois le présenter avec prudence : il peut exécuter du code Houdini, il dépend d'un serveur local actif, et l'intégration OPUS nécessite une clé RapidAPI et un abonnement séparé.
Sommaire
- Ce que fait Houdini MCP
- Architecture et installation
- Outils exposés dans Houdini
- OPUS, assets et rendu
- Comparaison avec Blender, Cinema 4D et Rhino
- Sécurité, limites et usage responsable
- Position Educasium
Ce que fait Houdini MCP
À retenir : Houdini MCP rend une session Houdini pilotable par un client MCP, avec des commandes pour créer, connecter, inspecter et cuire des réseaux de nœuds. Ce n'est pas un service cloud. Le dépôt décrit une connexion locale entre Claude Desktop, le serveur MCP et Houdini.
Un pont pour les réseaux procéduraux
Houdini est particulièrement adapté aux workflows procéduraux : au lieu de modifier uniquement des objets isolés, l'utilisateur construit des graphes de nœuds qui produisent géométrie, effets, matériaux ou rendus. Houdini MCP se place dans cette logique. La passerelle ne promet pas de remplacer la maîtrise de Houdini, mais elle permet de demander des opérations structurées en langage naturel : créer un nœud, le connecter, régler des paramètres, poser du code dans un wrangle, puis lire le résultat.
Le fichier houdini_mcp_server.py expose notamment get_scene_info, create_node, execute_houdini_code, connect_nodes, disconnect_node_input, delete_node, set_parameters, get_parameter_schema, set_node_flags, layout_network, find_error_nodes et cook_node. Ces noms sont importants parce qu'ils montrent la couverture réelle du connecteur. Il s'agit d'un outil orienté construction et diagnostic de réseau, pas d'un assistant générique qui comprendrait automatiquement chaque pipeline de studio.
Différence avec une simple macro
Une macro répète une séquence figée. Un connecteur MCP expose des actions à un client conversationnel qui peut raisonner sur les étapes et demander des informations intermédiaires. Dans Houdini, cette différence compte : une opération utile peut demander d'abord les informations de scène, ensuite le schéma des paramètres d'un nœud, puis une modification et une cuisson du nœud.
Pour un cours Educasium, ce fonctionnement est pédagogique. On peut montrer comment l'assistant propose un réseau, vérifie les paramètres disponibles, puis documente ses choix. Pour un usage professionnel, le même flux doit rester contrôlé : la personne qui connaît Houdini doit valider la structure, les paramètres et le rendu obtenu.
Architecture et installation
À retenir : l'installation combine un package Python dans le dossier scripts/python de Houdini et un serveur MCP lancé par uv ou par un Python explicite. Une seule partie manquante suffit à couper la chaîne entre Claude et Houdini.
Deux composants vérifiés
Le README décrit d'abord le plugin Houdini. Il s'agit d'un package Python à placer dans un chemin utilisateur Houdini, par exemple sous Documents/houdini19.5/scripts/python/houdinimcp sur Windows. Ce plugin écoute sur un port local, par défaut localhost:9876, puis traite les commandes liées aux nœuds, à la scène, au code et aux rendus.
Le deuxième composant est le script houdini_mcp_server.py. Il est lancé par uv ou par Python depuis la configuration du client MCP. Côté Claude Desktop, l'exemple de configuration utilise la commande uv, les arguments run et python, puis le chemin du script serveur. Le README précise aussi que si uv fonctionne dans un terminal mais échoue depuis Claude, il faut vérifier le chemin de l'exécutable Python et éventuellement remplacer python par un chemin absolu.
Prérequis et packaging
Le README liste SideFX Houdini, uv et une version récente de Claude Desktop comme prérequis. Le pyproject vérifié déclare le projet houdinimcp en version 0.1.0, une description centrée sur le contrôle de SideFX Houdini par langage naturel, requires-python >=3.12, et des dépendances incluant mcp[cli] >=1.4.1, requests, python-dotenv, langchain et langchain-classic.
Cette exigence Python 3.12 doit être vérifiée avant une formation ou une démonstration. Beaucoup de postes de création 3D ont plusieurs Pythons installés, parfois liés à des applications différentes. Le bon diagnostic n'est donc pas seulement "Claude ne voit pas Houdini" : il faut vérifier le Python lancé par la passerelle, le PYTHONPATH du package Houdini et l'état du serveur local.
Outils exposés dans Houdini
À retenir : la couverture utile se concentre sur les nœuds, les paramètres, les wrangles, les informations de géométrie et les rendus de viewport. Cette portée correspond bien à Houdini, mais elle doit être testée sur des scènes réelles avant d'être intégrée dans un pipeline client.
Nœuds, paramètres et réseau
La passerelle MCP expose create_node pour créer un nœud dans un chemin Houdini, connect_nodes pour établir une connexion, disconnect_node_input pour retirer une entrée, delete_node pour supprimer, set_parameters pour régler plusieurs paramètres, get_parameter_schema pour inspecter les paramètres disponibles, set_node_flags pour piloter des drapeaux de nœud et layout_network pour organiser le graphe. Le serveur plugin contient aussi des handlers internes tels que modify_node, get_node_info, cook_node et layout_children.
Dans un workflow de design technique, cela peut accélérer les opérations répétitives : préparer une structure de réseau, créer des variantes, poser un premier niveau de paramètres, puis nettoyer visuellement le graphe. Mais la valeur vient de la vérification. Houdini accepte des graphes complexes, et une construction plausible peut rester fausse pour une simulation, une échelle de projet ou une convention de studio.
Wrangles et géométrie
Les outils create_wrangle et set_wrangle_code montrent que le connecteur peut manipuler du code de wrangle. C'est puissant, car les wrangles sont souvent au cœur des workflows Houdini. C'est aussi une zone à encadrer : le code généré doit être relu, testé sur une copie et documenté avant d'être appliqué à une scène importante.
Le dépôt expose aussi get_geometry_info et get_geometry_data. Ces outils peuvent servir à lire ce que la scène produit : attributs, informations de géométrie ou données nécessaires au diagnostic. Pour Educasium, c'est intéressant pour enseigner une boucle complète : demander une construction, cuire le nœud, lire la géométrie, corriger la structure, puis seulement produire une sortie visuelle.
OPUS, assets et rendu
À retenir : Houdini MCP inclut des outils de rendu et une intégration OPUS optionnelle, mais OPUS n'est pas active sans clé RapidAPI et abonnement. La distinction entre connecteur Houdini et asset library externe reste essentielle.
Rendus de viewport
Le fichier houdini_mcp_server.py expose render_single_view, render_quad_views et render_specific_camera. Le fichier HoudiniMCPRender.py contient des helpers comme find_displayed_geometry, calculate_bounding_box, setup_camera_rig, rotate_camera_center, adjust_camera_to_fit_bbox et setup_render_node. Ces noms indiquent une orientation vers des captures et rendus de contrôle, pas vers une promesse de rendu final artistique.
Dans une formation, c'est suffisant pour vérifier visuellement une scène ou comparer une variation. Dans un pipeline client, le rendu final reste soumis aux moteurs, aux matériaux, aux lumières, aux licences, aux plugins et aux conventions de sortie du studio. Le MCP peut aider à préparer ou vérifier, mais il ne doit pas masquer la validation artistique.
OPUS en option
Le README décrit OPUS comme une intégration optionnelle pour des assets procéduraux de mobilier et d'environnement. Les outils exposés incluent opus_get_model_names, opus_get_model_params_schema, opus_create_model, opus_variate_model, opus_check_job_status et opus_import_model_url. Côté plugin, le serveur contient aussi get_asset_categories, search_assets et import_asset.
Le même README précise que l'intégration demande une clé RapidAPI et un abonnement OPUS API, à placer dans un fichier urls.env issu de urls.env.example. Sans clé, le serveur peut démarrer mais les outils OPUS sont désactivés. Cette nuance doit rester visible dans une page Educasium : l'absence de clé n'empêche pas forcément Houdini MCP de fonctionner, mais elle limite la partie bibliothèque d'assets.
Comparaison avec Blender, Cinema 4D et Rhino
À retenir : Houdini MCP n'a pas le même rôle qu'un connecteur généraliste de modélisation. Il est plus naturel lorsque le travail porte sur graphes, procédural, simulation, effets ou génération technique.
| Option | Usage naturel | Force principale | Limite à surveiller |
|---|---|---|---|
| Houdini MCP | Réseaux Houdini, nœuds, wrangles, géométrie procédurale | Contrôle du graphe, cuisson, rendu de viewport | Code exécutable et serveur local à sécuriser |
| Blender MCP | Formation 3D, prototypage, assets open source | Gratuit, très accessible, écosystème large | Télémetrie et exécution Python à encadrer |
| Cinema4D MCP Server | Motion design, MoGraph, caméras, Redshift | Aligné avec les studios déjà équipés C4D | Compatibilité et wrappers à tester |
| Rhino MCP | NURBS, architecture, Grasshopper | Géométrie de conception et paramétrique | Moins centré sur VFX et simulation procédurale |
Quand choisir Houdini
Houdini MCP est pertinent si l'équipe pense déjà en réseaux. Un studio VFX, une équipe motion technique ou un formateur Houdini peut y trouver un bon support d'exploration. L'assistant peut poser une première structure, inspecter les paramètres et expliquer le graphe produit.
Pour une initiation 3D généraliste, le MCP Blender reste souvent plus accessible. Pour un environnement C4D existant, Cinema4D MCP Server parle plus directement aux habitudes Maxon. Pour des projets NURBS ou Grasshopper, les MCP Rhino sont plus proches du besoin.
Sécurité, limites et usage responsable
À retenir : le point sensible de Houdini MCP est l'exécution de code dans une application de création locale. Les gains d'automatisation doivent être mis en balance avec la protection des fichiers, des scènes et du poste de travail.
Code et scènes de travail
L'outil execute_houdini_code indique clairement que le connecteur peut faire exécuter du code dans Houdini. C'est utile pour automatiser une opération que les outils structurés ne couvrent pas encore. C'est aussi le type de capacité à exclure d'une démonstration non surveillée ou d'un environnement contenant des fichiers client sensibles.
La règle pratique est simple : ouvrir une copie, sauvegarder avant modification, lire le code proposé, limiter les chemins accessibles et vérifier le résultat après chaque étape. L'assistant n'a pas une compréhension parfaite de la scène. Il agit par commandes, inspecte ce qu'il peut voir, puis dépend du jugement humain.
Dépendances et maintenance
Le dépôt est sous licence MIT et actif au moment de la vérification, mais cela ne transforme pas automatiquement le connecteur en produit supporté. L'installation demande des chemins Houdini précis, uv, Python 3.12 ou plus récent et un client MCP compatible. Les équipes doivent prévoir un test sur leur version Houdini, leur politique de plugins et leur configuration de sécurité.
Le dépôt indique qu'il a été construit en suivant Blender MCP. C'est une bonne indication d'inspiration technique, mais pas une garantie de maturité identique. Pour un article Educasium, la formulation responsable est donc : connecteur prometteur, utile à expérimenter, à intégrer seulement après tests internes et règles de sécurité.
Position Educasium
À retenir : Educasium peut présenter Houdini MCP comme un exemple avancé d'IA connectée à un logiciel procédural, sans prétendre l'avoir validé en production. La valeur pédagogique est forte si l'on montre les capacités, les garde-fous et la méthode de test.
Formation et démonstration
Un bon module Educasium ne devrait pas commencer par un résultat spectaculaire. Il devrait commencer par la chaîne de connexion : serveur local, scène test, get_scene_info, création d'un nœud simple, connexion, paramètre, cuisson, lecture de géométrie, puis rendu de viewport. Cette progression rend l'outil compréhensible et évite l'illusion d'un assistant magique.
Ensuite, la formation peut comparer trois niveaux. Niveau débutant : demander une structure simple et lire la scène. Niveau intermédiaire : générer un petit réseau procédural et documenter les paramètres. Niveau avancé : utiliser wrangles, données géométriques et rendu de contrôle, toujours sur copie.
Suite logique
La suite utile serait une page ou un atelier dédié aux tests de connecteurs MCP 3D : comment isoler une scène, vérifier les commandes exposées, mesurer les erreurs, documenter les limites et décider si le connecteur mérite une place dans un pipeline. C'est cette méthode, plus que la liste brute d'outils, qui crée de la valeur pour les studios et les écoles.