Houdini MCP conecta Claude Desktop con SideFX Houdini mediante una arquitectura local en dos partes: un plugin Python cargado dentro de Houdini y un script puente MCP ejecutado del lado del cliente. El repositorio capoomgit/houdini-mcp indica que el plugin escucha por defecto en localhost:9876 y que el puente se comunica con Claude por stdio mientras habla con Houdini por TCP. En la verificación de GitHub del 26 de agosto de 2026, el repositorio tenía licencia MIT, 282 estrellas y 41 forks, y su pyproject declaraba Python 3.12 o superior.
Para Educasium, este conector es interesante porque apunta a un software de creación procedural usado en VFX, motion, visualización y flujos técnicos. Las herramientas expuestas cubren lectura de escena, creación de nodos, conexiones, parámetros, wrangles, datos de geometría y varios renders de viewport. Aun así, conviene presentarlo con prudencia: puede ejecutar código en Houdini, depende de un servidor local activo y la integración OPUS requiere una clave RapidAPI y una suscripción separada.
Índice
- Qué hace Houdini MCP
- Arquitectura e instalación
- Herramientas expuestas en Houdini
- OPUS, assets y render
- Comparación con Blender, Cinema 4D y Rhino
- Seguridad, límites y uso responsable
- Posición Educasium
Qué hace Houdini MCP
Resumen: Houdini MCP permite que una sesión de Houdini sea controlada por un cliente MCP, con comandos para crear, conectar, inspeccionar y cocinar redes de nodos. No es un servicio cloud. El repositorio describe una conexión local entre Claude Desktop, el servidor MCP y Houdini.
Un puente para redes procedurales
Houdini está especialmente adaptado a flujos procedurales: en vez de modificar solo objetos aislados, el usuario construye grafos de nodos que producen geometría, efectos, materiales o renders. Houdini MCP encaja en esa lógica. El puente no promete reemplazar el dominio de Houdini, pero permite pedir operaciones estructuradas en lenguaje natural: crear un nodo, conectarlo, ajustar parámetros, insertar código en un wrangle y leer el resultado.
El archivo houdini_mcp_server.py expone, entre otras, 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 y cook_node. Estos nombres importan porque muestran la cobertura real del conector. Es una herramienta orientada a construcción y diagnóstico de redes, no un asistente genérico que entienda automáticamente cada pipeline de estudio.
Diferencia con una macro simple
Una macro repite una secuencia fija. Un conector MCP expone acciones a un cliente conversacional que puede razonar sobre pasos y pedir información intermedia. En Houdini, esa diferencia pesa: una operación útil puede requerir primero información de escena, después el esquema de parámetros de un nodo, luego una modificación y una cocción.
Para un curso de Educasium, este funcionamiento es pedagógico. Se puede mostrar cómo el asistente propone una red, verifica los parámetros disponibles y documenta sus decisiones. Para un uso profesional, el mismo flujo debe mantenerse controlado: la persona que conoce Houdini debe validar la estructura, los parámetros y el render obtenido.
Arquitectura e instalación
Resumen: la instalación combina un paquete Python en la carpeta scripts/python de Houdini y un servidor MCP lanzado con uv o con un Python explícito. Si falta una sola parte, se corta la cadena entre Claude y Houdini.
Dos componentes verificados
El README describe primero el plugin de Houdini. Es un paquete Python que se coloca en una ruta de usuario de Houdini, por ejemplo bajo Documents/houdini19.5/scripts/python/houdinimcp en Windows. Este plugin escucha en un puerto local, por defecto localhost:9876, y procesa comandos relacionados con nodos, escena, código y renders.
El segundo componente es el script houdini_mcp_server.py. Se lanza con uv o con Python desde la configuración del cliente MCP. Del lado de Claude Desktop, el ejemplo de configuración usa el comando uv, los argumentos run y python, y luego la ruta del script servidor. El README también precisa que si uv funciona en una terminal pero falla desde Claude, hay que revisar la ruta del ejecutable Python y, si hace falta, reemplazar python por una ruta absoluta.
Requisitos y empaquetado
El README lista SideFX Houdini, uv y una versión reciente de Claude Desktop como requisitos. El pyproject verificado declara el proyecto houdinimcp en versión 0.1.0, una descripción centrada en controlar SideFX Houdini por lenguaje natural, requires-python >=3.12 y dependencias que incluyen mcp[cli] >=1.4.1, requests, python-dotenv, langchain y langchain-classic.
Ese requisito de Python 3.12 debe verificarse antes de una formación o demostración. Muchos equipos de creación 3D tienen varios Pythons instalados, a veces vinculados a aplicaciones distintas. Por eso, el buen diagnóstico no es solo "Claude no ve Houdini": hay que comprobar el Python lanzado por el puente, el PYTHONPATH del paquete Houdini y el estado del servidor local.
Herramientas expuestas en Houdini
Resumen: la cobertura útil se concentra en nodos, parámetros, wrangles, información de geometría y renders de viewport. Ese alcance encaja bien con Houdini, pero debe probarse sobre escenas reales antes de integrarlo en un pipeline cliente.
Nodos, parámetros y red
El puente MCP expone create_node para crear un nodo en una ruta de Houdini, connect_nodes para crear una conexión, disconnect_node_input para retirar una entrada, delete_node para eliminar, set_parameters para ajustar varios parámetros, get_parameter_schema para inspeccionar parámetros disponibles, set_node_flags para controlar flags de nodo y layout_network para organizar el grafo. El servidor plugin también contiene handlers internos como modify_node, get_node_info, cook_node y layout_children.
En un flujo de diseño técnico, esto puede acelerar operaciones repetitivas: preparar una estructura de red, crear variantes, fijar un primer nivel de parámetros y limpiar visualmente el grafo. Pero el valor real viene de la verificación. Houdini acepta grafos complejos, y una construcción plausible puede seguir siendo falsa para una simulación, una escala de proyecto o una convención de estudio.
Wrangles y geometría
Las herramientas create_wrangle y set_wrangle_code muestran que el conector puede manipular código de wrangle. Es potente, porque los wrangles suelen estar en el centro de muchos flujos Houdini. También es una zona que debe limitarse: el código generado tiene que revisarse, probarse sobre una copia y documentarse antes de aplicarlo a una escena importante.
El repositorio expone también get_geometry_info y get_geometry_data. Estas herramientas sirven para leer lo que produce la escena: atributos, información de geometría o datos necesarios para el diagnóstico. Para Educasium, es interesante para enseñar una vuelta completa: pedir una construcción, cocinar el nodo, leer la geometría, corregir la estructura y solo después producir una salida visual.
OPUS, assets y render
Resumen: Houdini MCP incluye herramientas de render y una integración OPUS opcional, pero OPUS no está activa sin clave RapidAPI y suscripción. La distinción entre conector Houdini y biblioteca externa de assets sigue siendo esencial.
Renders de viewport
El archivo houdini_mcp_server.py expone render_single_view, render_quad_views y render_specific_camera. El archivo HoudiniMCPRender.py contiene helpers como find_displayed_geometry, calculate_bounding_box, setup_camera_rig, rotate_camera_center, adjust_camera_to_fit_bbox y setup_render_node. Estos nombres indican una orientación hacia capturas y renders de control, no una promesa de render final artístico.
En una formación, esto alcanza para verificar visualmente una escena o comparar una variación. En un pipeline cliente, el render final sigue dependiendo de motores, materiales, luces, licencias, plugins y convenciones de salida del estudio. El MCP puede ayudar a preparar o comprobar, pero no debe ocultar la validación artística.
OPUS como opción
El README describe OPUS como una integración opcional para assets procedurales de mobiliario y entorno. Las herramientas expuestas incluyen opus_get_model_names, opus_get_model_params_schema, opus_create_model, opus_variate_model, opus_check_job_status y opus_import_model_url. Del lado del plugin, el servidor contiene también get_asset_categories, search_assets e import_asset.
El mismo README precisa que la integración requiere una clave RapidAPI y una suscripción OPUS API, que se coloca en un archivo urls.env derivado de urls.env.example. Sin clave, el servidor puede arrancar pero las herramientas OPUS quedan desactivadas. Esta diferencia debe aparecer en una página de Educasium: no tener clave no impide necesariamente que Houdini MCP funcione, pero limita la parte de biblioteca de assets.
Comparación con Blender, Cinema 4D y Rhino
Resumen: Houdini MCP no cumple el mismo rol que un conector generalista de modelado. Es más natural cuando el trabajo trata de grafos, procedural, simulación, efectos o generación técnica.
| Opción | Uso natural | Fuerza principal | Límite a vigilar |
|---|---|---|---|
| Houdini MCP | Redes Houdini, nodos, wrangles, geometría procedural | Control del grafo, cocción, render de viewport | Código ejecutable y servidor local a proteger |
| Blender MCP | Formación 3D, prototipado, assets open source | Gratuito, muy accesible, ecosistema amplio | Telemetría y ejecución Python a limitar |
| Cinema4D MCP Server | Motion design, MoGraph, cámaras, Redshift | Alineado con estudios ya equipados con C4D | Compatibilidad y wrappers a probar |
| Rhino MCP | NURBS, arquitectura, Grasshopper | Geometría de diseño y paramétrica | Menos centrado en VFX y simulación procedural |
Cuándo elegir Houdini
Houdini MCP es pertinente si el equipo ya piensa en redes. Un estudio VFX, un equipo motion técnico o un formador Houdini pueden encontrarlo útil como soporte de exploración. El asistente puede proponer una primera estructura, inspeccionar parámetros y explicar el grafo producido.
Para una iniciación 3D generalista, el MCP Blender suele ser más accesible. Para un entorno C4D existente, Cinema4D MCP Server habla más directamente a las costumbres Maxon. Para proyectos NURBS o Grasshopper, los MCP de Rhino están más cerca de la necesidad.
Seguridad, límites y uso responsable
Resumen: el punto sensible de Houdini MCP es la ejecución de código dentro de una aplicación creativa local. Los beneficios de automatización deben equilibrarse con la protección de archivos, escenas y estaciones de trabajo.
Código y escenas de trabajo
La herramienta execute_houdini_code indica claramente que el conector puede hacer ejecutar código en Houdini. Es útil para automatizar una operación que las herramientas estructuradas todavía no cubren. También es el tipo de capacidad que conviene excluir de una demostración sin supervisión o de un entorno que contiene archivos cliente sensibles.
La regla práctica es simple: abrir una copia, guardar antes de modificar, leer el código propuesto, limitar las rutas accesibles y verificar el resultado después de cada paso. El asistente no entiende perfectamente la escena. Actúa mediante comandos, inspecciona lo que puede ver y luego depende del juicio humano.
Dependencias y mantenimiento
El repositorio tiene licencia MIT y estaba activo en el momento de la verificación, pero eso no lo convierte automáticamente en un producto con soporte. La instalación requiere rutas Houdini precisas, uv, Python 3.12 o superior y un cliente MCP compatible. Los equipos deben prever una prueba sobre su versión de Houdini, su política de plugins y su configuración de seguridad.
El depósito indica que fue construido siguiendo Blender MCP. Es una buena pista de inspiración técnica, pero no una garantía de madurez idéntica. Para un artículo de Educasium, la formulación responsable es: conector prometedor, útil para experimentar, integrable solo después de pruebas internas y reglas de seguridad.
Posición Educasium
Resumen: Educasium puede presentar Houdini MCP como un ejemplo avanzado de IA conectada a un software procedural, sin afirmar que ya se haya validado en producción. El valor pedagógico es fuerte si se muestran capacidades, límites y método de prueba.
Formación y demostración
Un buen módulo de Educasium no debería empezar por un resultado espectacular. Debería empezar por la cadena de conexión: servidor local, escena de prueba, get_scene_info, creación de un nodo simple, conexión, parámetro, cocción, lectura de geometría y render de viewport. Esa progresión vuelve el conector comprensible y evita la ilusión de un asistente mágico.
Luego, la formación puede comparar tres niveles. Nivel inicial: pedir una estructura simple y leer la escena. Nivel intermedio: generar una pequeña red procedural y documentar los parámetros. Nivel avanzado: usar wrangles, datos geométricos y render de control, siempre sobre una copia.
Siguiente paso lógico
El siguiente paso útil sería una página o taller dedicado a probar conectores MCP 3D: cómo aislar una escena, verificar comandos expuestos, medir errores, documentar límites y decidir si el conector merece un lugar en un pipeline. Esa metodología, más que la lista bruta de herramientas, es lo que crea valor para estudios y escuelas.