AI Agents Shouldn't Stop at Code: Introducing DCC-MCP for Creative Software

Hal — Tue, 04 Aug 2026 18:12:19 +0000

Most AI agents are becoming remarkably capable inside an IDE. They can understand a repository, edit code, run tests, inspect logs, and help ship software.

But a large part of digital production happens after the IDE.

A game, film, animation, advertising, or virtual-production pipeline may move through Maya, Blender, Houdini, ZBrush, Substance 3D, Unreal Engine, Unity, Nuke, Photoshop, Wwise, OpenUSD, production tracking systems, profilers, and internal studio tools.

These applications already contain years of production knowledge. The missing layer is a consistent way for agents to discover and operate that knowledge without inventing a new integration—or regenerating a fragile script—on every turn.

That is why we are building DCC-MCP.

What is DCC-MCP?

DCC-MCP stands for Digital Content Creation Model Context Protocol.

It is open infrastructure that connects AI agents, command-line automation, CI jobs, and studio applications to real creative software through a shared set of contracts:

MCP and REST entry points
a machine-level Gateway
typed tools and structured results
application-specific adapters
reusable, versioned Skills
capability discovery and a Marketplace
routing, policy checks, diagnostics, logs, traces, and request IDs

DCC-MCP is not another AI model, and it does not require teams to adopt one specific agent. It is the connective and operational layer between an agent and the creative applications that already do the work.

Agent / CLI / CI / Studio application
                 │
            MCP or REST
                 │
          DCC-MCP Gateway
  discovery · routing · policy · diagnostics
                 │
      adapters · Skills · services
                 │
 Maya · Blender · Houdini · Unreal · Photoshop · ...

The same typed capability can be called by an AI agent, a developer from the CLI, a CI pipeline, or an internal application through REST.

Why not just ask the model to write a script?

Asking an agent to generate and execute a mayapy, hython, Blender Python, MEL, or MaxScript snippet is useful for exploration. It can also produce impressive demos.

However, repeated production work exposes several problems.

The model keeps rebuilding the workflow

If the model recreates the task logic on every turn, the result depends on the current model, prompt, context window, and generated code. The knowledge disappears when the conversation ends.

Production knowledge should be versioned, tested, reviewable, and reusable.

DCC applications have host-specific execution rules

Many creative applications require work to run on the main thread. They have startup states, modal dialogs, active documents, scene ownership, plug-in lifecycles, and APIs that are only safe in specific contexts.

A successful process exit does not prove that the intended scene changed correctly.

Multiple open applications make the target ambiguous

A workstation may have several Maya scenes, Blender processes, Unreal projects, or Photoshop documents open at once. The agent needs to identify the correct instance and preserve that context throughout the operation.

Creative work is often long-running

Simulation, baking, rendering, importing, remeshing, publishing, and asset generation may need progress reporting, cancellation, checkpoints, retries, and artifact hand-off.

A simple request/response function is not always enough.

Failures need evidence

When something fails, teams need more than an error sentence. They need the typed input, selected instance, request ID, logs, traces, observed state, and a clear indication of whether the problem belongs to Core, an adapter, a Skill, or the host application.

DCC-MCP moves these repeated engineering concerns into shared infrastructure instead of forcing every adapter—and every generated script—to solve them again.

You can read the longer design rationale in Why DCC-MCP exists.

A small agent interface instead of a giant tool list

A creative application can expose hundreds or thousands of operations. Sending every schema to an agent at once wastes context and makes tool selection less reliable.

DCC-MCP uses progressive discovery:

list → search → load/describe → call

At the MCP layer, the Gateway can remain intentionally small with canonical operations such as:

search
load_skill
describe
call

The agent searches for the capability required by the task, loads or inspects only the relevant Skill, validates its arguments, and then calls the selected tool.

This is important because the goal is not to make the model memorize an entire DCC API. The goal is to help it find the smallest correct production capability at the moment it is needed.

Skills preserve workflow knowledge

Connectivity alone is not enough.

A studio workflow contains conventions such as:

naming and directory rules
scene and document checks
asset preparation
export settings
publish gates
validation criteria
review hand-offs
recovery and cleanup steps

In DCC-MCP, this knowledge can be packaged as a Skill: a versioned, typed, distributable capability with validated inputs, safety metadata, examples, and implementation scripts.

That creates a useful ownership boundary:

Core and adapters own connectivity, host safety, routing, lifecycle, policy, and observability.
TDs, TAs, and pipeline teams own project-specific production logic.
Agents select a documented capability and provide validated arguments instead of inventing the complete workflow again.

Skills can use Python, MEL, MaxScript, Bash, PowerShell, and other host-appropriate implementations. For supported workflows, a SKILL.md plus scripts can expose a capability without writing another layer of Python registration glue.

The DCC-MCP Marketplace is designed to distribute focused Skills, asset providers, studio integrations, and shared infrastructure without turning every extension into a new runtime.

One ecosystem across creative applications

At the time of writing, the official site lists 20 released adapter identifiers, plus a public Wwise adapter and showcase. The wider project directory contains more than 50 public projects.

The ecosystem covers areas including:

3D and DCC applications

Maya, Blender, Houdini, 3ds Max, ZBrush, Marmoset Toolbag, MotionBuilder, Katana, Substance 3D Designer, and Substance 3D Painter.

Game engines and authoring tools

Unreal Engine, Unity, Godot, Wwise, Tiled, and other content-authoring tools.

2D, compositing, and editing

Photoshop, After Effects, Premiere Pro, Nuke, GIMP, Krita, and related creative workflows.

Pipeline, interchange, and diagnostics

OpenUSD, MaterialX, Autodesk Flow Production Tracking, publishing workflows, texture pipelines, RenderDoc, Tracy, cache inspection, and internal standalone services.

Generation and asset providers

Hunyuan 3D, Tripo 3D, image generation, geospatial data, Poly Haven, ambientCG, Kenney, NASA 3D, Smithsonian 3D, Objaverse, and other sources that can preserve provenance and licensing information.

Project availability changes as adapters evolve, so dcc-mcp-cli dcc-types and the ecosystem directory remain the current sources of truth.

What can an agent actually do with it?

The DCC-MCP Showcase contains prompts, outputs, source repositories, and validation records for workflows such as:

building a procedural spiral galaxy in Blender
creating an editable energy portal in Houdini
importing and validating a CC0 PBR asset in Marmoset Toolbag
creating and organizing interactive audio in Wwise
generating a 3D asset through Hunyuan 3D and importing it into a selected DCC
assembling a playable scene from licensed asset providers
processing a five-million-face model in ZBrush and verifying the remeshed result in Maya
creating publish manifests that connect DCC exports, OpenUSD, render farms, and production tracking

The important part is not only that an image or scene was produced. A production-oriented result should also report what was called, which instance was targeted, what files were created, what checks passed, and what evidence remains when something fails.

Native APIs first, UI automation only when necessary

Some creative applications expose strong Python, C++, HTTP, command-port, UXP, WAAPI, or vendor-specific APIs. Others expose only partial automation surfaces.

DCC-MCP prefers native and typed APIs whenever they exist.

UI automation is treated as a scoped fallback for operations that have no usable programmatic interface. The intended pattern is closer to:

snapshot → find → act → wait → verify

rather than giving an agent unrestricted desktop control and hoping it clicked the right thing.

This distinction matters for safety, reproducibility, and debugging.

A quick look at the workflow

The maintained public Agent Skill contains the current operating procedure and safety rules. A typical local workflow looks like this:

# Install the maintained operating Skill in OpenClaw.
openclaw skills install @loonghao/dcc-mcp

# Confirm the Gateway and connected creative applications.
dcc-mcp-cli health
dcc-mcp-cli list

# Search narrowly for the required capability.
dcc-mcp-cli search --query "create sphere" --dcc-type maya

# Follow the returned next_step. Load or describe only what is needed.
dcc-mcp-cli load-skill <skill-id> --dcc-type maya
dcc-mcp-cli describe <tool-slug>

# Call the typed tool with validated arguments.
dcc-mcp-cli call <tool-slug> --json '{"radius": 2.0}'

Do not guess tool names or blindly load an entire backend catalog. Search first and follow the next_step returned by the system.

For installation, supported agent hosts, consent rules, and diagnostics, use the current Agent guide.

It is useful without an AI agent

Although MCP provides the agent entry point, DCC-MCP is not limited to conversational use.

The same capabilities can be used through:

dcc-mcp-cli by artists, TDs, developers, and operators
REST from internal applications and smart workflow canvases
generated OpenAPI clients
CI jobs and validation pipelines
custom studio orchestration

An existing OpenAPI service can also remain a normal REST service and be mounted as agent-accessible tools. Teams do not need to rebuild every internal system around AI.

Building an adapter, service, or Skill

DCC-MCP separates four common development paths:

Connect a creative host by building or improving an application adapter.
Expose an internal API, CLI, asset database, render farm, or review system as a private standalone service.
Add a focused workflow to an existing adapter or service as a Skill.
Improve shared behavior such as Gateway routing, CLI, protocol support, policy, diagnostics, or observability in Core.

Private studio services do not need a public GitHub repository or public catalog entry. They can reuse the same runtime and typed contracts inside an existing security and deployment boundary.

The Developer guide includes starter routes for public adapters, private services, Skills, validation, local MCP Inspector testing, and production delivery.

Honest boundaries

DCC-MCP does not claim to make every creative application identical.

Native APIs and tested Skills are preferable to UI automation.
Host-specific compatibility remains the responsibility of each adapter.
Safe rollback cannot be guaranteed when an application exposes no transaction model.
Infrastructure can standardize repeatable work, but it does not replace art direction, composition, timing, taste, or human judgment.
The project provides infrastructure for agents; it does not prescribe which model or agent a team must use.

The aim is more practical: standardize the repeatable parts, expose them as controlled capabilities, and let people and agents operate the same production tools with better context and evidence.

Where we are going

We want DCC-MCP to become an open connective layer for creative production:

one discoverable entry point across heterogeneous applications
thin adapters instead of repeated infrastructure
reusable Skills instead of regenerated workflow code
typed calls instead of prompt-only conventions
explicit policies instead of unrestricted execution
inspectable evidence instead of black-box automation
an ecosystem that studios and open-source maintainers can extend together

There is still a great deal to improve, and that is exactly why we are developing it in the open.

Explore and contribute

Website: dcc-mcp.github.io
GitHub organization: github.com/dcc-mcp
Core runtime: dcc-mcp-core
Project directory: Ecosystem
Capability packages: Marketplace
Real outputs and prompts: Showcase
Agent setup: For Agents
Adapter and Skill development: For Developers

If you work with creative software, pipeline tooling, game development, VFX, animation, agent infrastructure, or MCP, we would love your feedback, experiments, issues, and contributions.

AI agents should not stop at code. They should be able to work with the real tools where digital content is created.

DEV Community: Hal