SideFX is bringing Model Context Protocol (MCP) support to Houdini 22, letting AI assistants tap a curated library of Apex Script syntax and examples to help artists write procedural character-rigging code. Announced alongside Nvidia’s broader push to make creative software agent-ready, the feature debuted at the Houdini 22 keynote as a sneak peek headed to SideFX Labs, not yet a finished production tool. Here is what is real today, what is not, and what artists should watch for next.
Illustration of Houdini interface with MCP-connected tools helping an artist rig one of JPR’s popular feline friends. (Source: JPR)
Artificial intelligence has been circling the media and entertainment industry for several years, mostly as a set of stand-alone generative tools sitting outside the pipelines artists actually use. That is starting to change. At Siggraph 2026, Nvidia and a wide swath of the creative-software industry—including Adobe Firefly, Express and Creative Cloud, Affinity by Canva, Blender, Boris FX Silhouette, Foundry Griptape, SideFX Houdini, and Epic Games Unreal Engine—described a shift toward AI agents that live inside digital content creation (DCC) applications rather than beside them. The mechanism behind that shift is the Model Context Protocol (MCP), an open standard that lets an AI assistant connect to an application’s own commands, documentation, and data. This article covers the general implications of MCP-connected tools, with deep dives into Houdini’s implementation.
MCP-connected tools are the next obvious step to SideFX Houdini GPU-accelerated features. (Source: JPR)
The pitch from every vendor is consistent, and it addresses a real fear in creative studios. It is not about generating final art from a text prompt and cutting the artist out of the loop. It is about giving an agent access to the tool an artist already uses, then asking it to handle the parts of the job that are tedious rather than creative, or supporting ideation in early stages of the workflow or artistic what-if scenarios.
“The inclusion of MCP-connected tools to industry-standard 3D, video, and VFX applications gives artists the control and productivity they want, creating a human+AI dynamic that turns power users into super users!” –Hernan Quijano, Workstation Analyst, JPR
According to Nvidia, MCP-connected tools let a technical director ask an agent to inspect a scene for missing textures, flag inconsistent color management, prepare export variants, or validate a shot against pipeline rules, all while creative decisions stay with the human.
That framing matters for three reasons across nearly every MCP integration announced at Siggraph this year. First, productivity: Agents can execute multistep production tasks in seconds rather than manual passes. Second, easier access to documentation: An artist can ask a natural-language question and get an answer grounded in the actual application programming interface (API) rather than a general-purpose model’s guesswork. Third, faster prototyping: Agents can generate a first pass at code, a rig, or a scene setup that an artist then refines, rather than starting from a blank graph or scene.
MCP-connected tools mark the fourth phase of DCC applications evolution:
Apex Script gets an MCP server
Inside that broader wave, SideFX’s contribution is narrow and specific. Houdini 22, the company’s 30th-anniversary release, gets MCP support through what SideFX calls the Apex Script Comfort Package. Apex is Houdini’s procedural rigging and animation system, and Apex Script is the code layer underneath it. According to Nvidia, the package gives AI assistants a curated collection of Apex Script syntax, functions, documentation, and examples aimed squarely at one job: helping artists generate and refine procedural character-rigging code.
The Houdini 22 keynote, delivered in London on June 22, filled in the mechanics. SideFX vice president of product, Cristin Barghiel, introduced AI as one of two “groundbreaking technologies” for the release, alongside 3D Gaussian splatting, describing a hybrid pipeline in which Houdini’s procedural tools coexist with homegrown machine learning and third-party models such as Detectron, SAM, and MoGe.
The Apex-specific piece came later in the presentation. The Apex Script Comfort Package bundles a Visual Studio Code extension for autocomplete, a Python panel inside Houdini, and an Apex Script MCP server. The server connects a large language model to a token-efficient library covering syntax, style guidelines, and code snippets, and it ships with a validator that checks generated code before it runs.
In the Houdini 22 keynote demo, an artist typed requests such as building six S-shaped splines or looking up how to implement a look-at function, and the assistant returned working Apex Script pulled from real examples rather than invented syntax. SideFX said the result, in one case more than 300 lines of a functional rig component, carries no ongoing dependency on the LLM once generated. The artist owns a plain script, not a black box.
That is an important, genuinely new distinction worth flagging: SideFX introduced the Apex Script Comfort Package on stage as a “sneak peek,” adding that users would potentially find it later in Labs, SideFX’s channel for experimental, pre-production tools. Readers evaluating whether MCP is “in” Houdini 22 today should treat it as a feature in active rollout through Labs, not a toggle in the main application for every studio out of the box. Both the Houdini keynote and Nvidia also note that community-developed MCP servers already offer broader, if less officially supported, ways for agents to interact with Houdini outside the Apex Script scope.
MCP connected to Houdini to rig a character with Apex. (Source: SideFX keynote)
Where MCP could go next in Houdini
Writer’s note: Neither SideFX nor Nvidia has published a roadmap for MCP beyond rigging, so the following is JPR’s own reading of where the same approach could extend, based on how Houdini is structured today, and should be read as analysis rather than a confirmed feature list.
Simulation setup is an obvious candidate: Houdini’s dynamics networks, such as Pyro, Vellum, and the newer Copernicus-based GPU solver, involve dozens of interdependent parameters that artists currently tune through trial and error, and an agent grounded in solver documentation could plausibly propose starting values or flag likely instability. Solaris and USD scene assembly is another candidate, since the keynote’s own layout and scattering tools already lean on procedural masks and rules an agent could apply. Lookdev and shading inside Karma, and asset validation against studio pipeline standards, are two further areas where the rigging pattern could extend with comparatively little new plumbing.
Not an Nvidia exclusive, yet you want Nvidia
On hardware, both the keynote and Nvidia’s own materials are consistent: Houdini’s MCP implementation is a software layer, not an Nvidia locked-in feature. The Apex Script MCP server talks to a large language model and a documentation library, work that does not require Nvidia’s rendering or AI stack. Nvidia’s messaging positions its own RTX Pro, DGX Spark, and DGX Station hardware as accelerating local AI agents and inference generally, not as a requirement specific to Houdini’s MCP server.
In principle, an Apex Script MCP workflow should run on any workstation capable of hosting or connecting to a large language model, regardless of whether its GPU comes from Nvidia, AMD, Intel, or newcomers like Bolt Graphics. However, other Houdini 22 features, such as Karma XPU and the Vulkan-based viewport, are more GPU-vendor-sensitive than the MCP layer itself, making Nvidia the obvious choice until other vendors do the enablement Nvidia has done for years; it would be a major uphill battle if they decide to enable their GPUs for all Houdini-accelerated and AI-based tools.
Could a DGX Spark run alongside an artist’s workstation?
Nvidia’s own materials describe DGX Spark as a deskside system meant to bring AI performance closer to artists without sending data to external services, which makes it a reasonable fit for teams that want to keep an Apex Script MCP workflow, or any other local agent, off the public cloud.
Running inference on the artist’s own workstation keeps latency lowest, needs no new hardware budget, and adds another layer of security, but it competes for GPU memory and compute with Houdini’s viewport, simulation, and rendering, which can matter on a busy shot. A shared DGX Spark sitting alongside one or more workstations avoids that contention and can serve multiple artists at once, at the cost of new infrastructure to purchase, network, and maintain, plus a little added network latency.
Whether that pairing is practical today depends on software readiness neither company has fully documented. The Apex Script MCP server is described as lightweight and token-efficient, suggesting it was designed with modest local hardware in mind rather than a dedicated inference box. Studios weighing a DGX Spark pairing should confirm with SideFX exactly how the MCP server and its target LLM are meant to be deployed—whether fully local, a remote endpoint, or some mix—before assuming a DGX Spark slots in without extra configuration work. It would be more than exciting to see it in action. (We are currently testing DGX Spark on multiple workflows and will have a report soon; reach out to us if you are interested.)
Conclusions
MCP’s arrival in Houdini 22 is real, narrow, and by SideFX’s own description, still a preview. It targets one high-value, well-bounded problem, generating and explaining Apex Script code for character rigging in a way that keeps the artist in control of the output. That is a sensible, conservative first step for a procedural tool in which trust in generated code matters as much as speed. The bigger question is less whether this particular feature works and more how quickly SideFX moves it from Labs into the core product, and how far the same MCP pattern eventually reaches into simulation, lookdev, and scene assembly.
What do we think?
JPR sees SideFX’s approach as notably disciplined compared with some of the more sweeping AI announcements coming out of Siggraph 2026. Scoping the first MCP implementation to Apex Script and character rigging, a domain where output can be validated as working code rather than judged on subjective creative merit, is a sensible way to earn artist trust before expanding further. It is also consistent with SideFX’s historical pattern of introducing new technology through Labs before folding it into the core product; Gaussian splatting followed the same path, arriving as a limited tool in Houdini 21 before maturing into a first-class citizen in Houdini 22.
The bigger story is the ecosystem pattern this fits into. Adobe, Blender, Boris FX, Foundry, and Epic Games are all making the same architectural bet at roughly the same time: Instead of building isolated AI features, they are opening standardized doors for AI agents to work inside existing tools. If these companies coordinate around a shared protocol, MCP could do for creative software what USD did for scene interchange, though it is far too early to call that outcome certain. For now, Houdini 22 artists should treat MCP-assisted Apex Script coding as a promising, well-scoped experiment worth trying in Labs, not yet a pipeline dependency.
—The Workstation Cavalry
AND IF YOU LIKED WHAT YOU READ HERE, DON’T BE STINGY, SHARE IT WITH YOUR FRIENDS.
Disclaimer: This article is not financial advice. The content is for informational purposes only. The author may own shares in companies mentioned, and readers should not consider this article a recommendation to buy, sell, or hold any assets.