# dcc-mcp-core: A Rust control plane for turning studio pipelines into agent-callable skills > dcc-mcp-core is a skill-first control plane that wraps desktop creative tools behind MCP and REST, with a gateway, CLI, marketplace, and safety features. It targets studios that want reusable, versioned operations instead of letting a model generate DCC scripts on every turn. **dcc-mcp/dcc-mcp-core** — Skill-first control plane for creative tools: shared MCP/REST runtime, gateway, CLI, marketplace, safety, and observability across studio pipelines. - Repository: https://github.com/dcc-mcp/dcc-mcp-core - Website: https://dcc-mcp.github.io/dcc-mcp-core/ - Stars: 70 · Forks: 7 - Language: Rust - License: MIT - Published: 2026-08-24 · Updated: 2026-08-24 · Language: en - Canonical page: https://hysenlabs.com/projects/dcc-mcp-dcc-mcp-core ## The problem: DCC automation is not a code-generation problem The README's shortest demo asks a model to write and run a mayapy, hython, or Blender Python script. That works once, but a production pipeline cannot depend on the model producing the right script every turn. Repeated code generation costs tokens, varies with model and context, and leaves every adapter to rebuild transport, main-thread dispatch, validation, process lifecycle, routing, and diagnostics. dcc-mcp-core moves that common engineering into one reusable control plane. The intended users are studio TDs and TAs who want to encode project flow as Skills, and teams that need agents to control desktop DCCs without per-adapter reinvention. ## The skill-first contract: SKILL.md and tools.yaml as the production unit A Skill is a package made from SKILL.md, tools.yaml, and the studio's existing scripts. The README calls Skills the production unit: they turn proven pipeline knowledge into a versioned, typed, testable, and distributable operation. A lower-cost model may struggle to invent scene-editing logic from scratch but can select a well-described tool and supply validated arguments. This is the practical customization boundary. Core and adapters keep ownership of host connectivity, main-thread execution, routing, safety, and observability. A TD or TA encodes naming and scene checks, asset preparation, publish gates, cache/export rules, and review hand-offs without forking the control plane. ## How the gateway keeps the tool list bounded The gateway does not fan every backend tool into one large tools/list. Instead it advertises canonical discovery and dispatch wrappers: search, describe, load_skill, and call. Backend capabilities are discovered by search, inspected by describe, and invoked through the wrapper or the REST twin at POST /v1/search, /v1/describe, and /v1/call. For a concrete DCC session, you read gateway://instances; each entry already includes its mcp_url. The README explicitly says not to use the removed legacy instance tools (list_dcc_instances, get_dcc_instance, or connect_to_dcc). Wrapper inputs belong inside arguments; do not put backend fields beside tool_slug. This design trades a flat list for a two-step discovery flow, which is a deliberate choice to keep the agent context small. ## Getting started: CLI, REST, and the default agent path The default agent path is CLI plus REST. The README shows the sequence: dcc-mcp-cli dcc-types (when adapter support is unclear), then list, search, describe, load-skill only when needed, and call. For exposing a DCC adapter over MCP/REST, you start with create_skill_server. Adding tools without Python registration code is done through SKILL.md and tools.yaml. The CLI reference is in docs/guide/cli-reference.md, and the REST surface is documented in rest-api-surface.md. For new gateway integrations, use the canonical names search, describe, load_skill, and call. Compatibility names (search_tools, describe_tool, call_tool) remain available where the server exposes them, but the README steers new work to the canonical set. ## UI Control: the bounded approach for legacy and interface-only tools Many existing tools have no API, cannot be modified, or expose part of a workflow only through a window or modal dialog. For that gap, dcc-mcp-core provides a bounded Computer Use-style capability called DCC UI Control. It combines exact-window screenshots, semantic controls when available, scoped actions, waits, recording, policy checks, audit, and result verification. The README is clear that native Skills and APIs remain the preferred path. UI Control is a fallback that lets legacy workflows join the same agent control plane without pretending every application has a clean programmable API. The bounded qualifier matters: it is not a general-purpose autonomous browser agent, but a scoped action set with policy checks and audit. ## Vendor integration: bridging Unreal's official MCP without redistribution The project does not replace vendor capabilities. Unreal Engine 5.8 introduced an experimental built-in MCP server and Toolset Registry. The Unreal Official MCP Bridge enables and calls those official toolsets through DCC MCP without redistributing them. That means vendor tools, DCC-MCP tools, and studio tools can share one agent-facing workflow. This is a pragmatic position: rather than reimplementing Unreal's toolset, the bridge calls the official one. The README frames MCP as an entry point, not the ceiling, and says a stable Python, C++, HTTP, command-port, or native plugin interface can be integrated under the same discovery, execution, safety, and operations contracts. ## Operational layers: what the control plane actually provides The README lists four layers of reused capability. Integration covers MCP and REST endpoints, Host RPC/IPC, typed schemas, resources, prompts, and structured results. The DCC runtime layer includes main-thread affinity, readiness, multi-instance routing, async jobs, cancellation, checkpoints, workflows, artefacts, and UI Control. Skill delivery covers SKILL.md packages, progressive discovery, lint and schema validation, hot reload, persistence, marketplace distribution, and project or team scopes. Operations includes CLI, gateway, Admin UI, policies, audit records, traces, logs, metrics, health checks, and VRS replay. That is a wide surface. The presence of hot reload and VRS replay suggests a focus on long-running studio sessions where you need to inspect or replay what an agent did. ## Limitations and the wrong-tool cases The README does not claim to build or prescribe the agent itself. It provides infrastructure only. That is a real boundary: if your team expects an out-of-the-box agent that decides when to call tools, this is not it. The default agent path assumes you already have an agent that can follow the CLI or REST sequence. Another limitation is the removed legacy instance tools. Existing integrations that relied on list_dcc_instances or connect_to_dcc will break and must migrate to gateway://instances. The README also warns against mixing backend fields beside tool_slug in wrapper inputs; that is a failure mode for sloppy clients. For a single DCC with a clean API, the full control plane is overkill. A direct MCP adapter would be lighter and simpler. ## Alternatives and how they differ The obvious alternative is a per-DCC MCP server that exposes that tool's API directly. That approach has no gateway, no skill packaging, and no marketplace. Each adapter must implement its own transport, main-thread dispatch, validation, and diagnostics. dcc-mcp-core centralizes those concerns, but it also imposes its discovery contract. Another alternative is using the vendor's built-in MCP, like Unreal's experimental server. That gives you the vendor tools but only for that one application, and you lose the unified gateway, safety, and observability across multiple DCCs. The README's own bridge shows a hybrid: call vendor tools through dcc-mcp-core rather than replacing them. The difference in approach is centralization versus point solutions. ## Maintenance, licensing, and upgrade cost The project is under the MIT license, which is permissive and does not restrict redistribution or modification. The repository shows active releases, with v0.20.22 pushed in August 2026, shortly after v0.20.20. That cadence implies ongoing maintenance, but it also means you should track the changelog for breaking changes like the removal of legacy instance tools. The README does not give a migration guide for that removal, so upgrading may require adapting existing gateway integrations. The skill-first model means your studio's Skills are versioned and testable, which should reduce the cost of changing core behavior: you can update a Skill without rebuilding the adapter. But the core itself will evolve, and you need to budget for that. ## Conclusion Adopt dcc-mcp-core if you run a studio pipeline with multiple DCCs and want to package proven workflows as versioned, typed Skills distributed through a marketplace. Skip it if you only need a single direct MCP bridge for one tool, where a lightweight adapter is simpler. Before committing, verify how the gateway's bounded tool list fits your agent's discovery pattern, and check that your DCC adapters support the canonical search/describe/call wrappers. Test the main-thread dispatch and multi-instance routing on your actual hosts, since those are the core runtime guarantees. ## FAQ ### What does DCC stand for in dcc-mcp-core? In this project DCC means a desktop creative application. The README talks about controlling a running DCC from an agent or a CI job, and names mayapy, hython and Blender Python as the scripting entry points, with the package keywords listing Maya, Blender and Houdini. ### How does the dcc-mcp-core gateway keep the tool list bounded? It advertises canonical discovery and dispatch wrappers, search, describe, load_skill and call, rather than fanning every backend tool into one large list. Capabilities are found by search, inspected by describe, and invoked through the wrapper or the REST twin at POST /v1/search, /v1/describe and /v1/call. ### How do I pair dcc-mcp-core with dcc-mcp-server? The two ship from one release, so a deployment must pair them at the same major.minor. The Python floor is deliberately older because Maya 2022 and Blender 2.83 embed Python 3.7: the py37-lite wheel ships pure-Python code only, and dcc-mcp-server is installed separately when the platform provides a compatible binary wheel. ### What files make up a Skill in dcc-mcp-core? A Skill is built from SKILL.md, tools.yaml and the studio's existing scripts, and it is the customization boundary for technical directors and technical assistants. Skills can be tested, scoped to a project or a team, and distributed through a public or private marketplace without forking the control plane or rebuilding an adapter. ## Sources - [Official documentation](https://dcc-mcp.github.io/dcc-mcp-core/) - [Official README](https://github.com/dcc-mcp/dcc-mcp-core#readme) - [Project repository](https://github.com/dcc-mcp/dcc-mcp-core) - [Release notes](https://github.com/dcc-mcp/dcc-mcp-core/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dcc-mcp-dcc-mcp-core