DCC-MCP Core

dcc-mcp-core

中文 | English

Website · Marketplace · Showcase · For Agents · Ecosystem

One MCP control plane for every DCC: an AI agent turns one prompt into a finished Blender material in 60 seconds.

pip install dcc-mcp-core

Try this → Blender material 60s Showcase: the shortest path from one prompt to a rendered material in a live Blender session, powered by dcc-mcp-blender. See Quick start: operate a DCC for the full CLI path.

Skill-first, Rust-powered control plane for a growing creative-tool ecosystem.

dcc-mcp-core connects agents to desktop DCCs, game engines, 2D tools, production systems, asset providers, profilers, and custom studio hosts through discoverable MCP and REST capabilities. It provides the gateway, Skills, structured results, main-thread dispatch, diagnostics, IPC, workflows, and packaged CLI/server binaries needed to operate real sessions.

One protocol, across every registered host. Every host adapter in this ecosystem implements the same MCP protocol and the same tool contract. The registry is the source of truth, and the count is reproducible from a checkout:

rg -c '^    tags: \[.*"adapter".*\]' dcc-mcp-catalog.yml

That reports 48 adapter entries in dcc-mcp-catalog.yml. See the complete generated host list for every current entry and its install metadata. The count includes experimental discovery-only PhotoCraft; it does not establish release-qualified support or automatic installation for every entry. Selected examples include:

The full list, with install metadata, is published in the ecosystem directory.

Three shared contracts keep it one matrix. Host coverage is only useful if the adapters stay interchangeable. Three contracts published by core are what stop host adapters from becoming unrelated servers:

How to compare us. Compare host coverage and contract completeness — both reproducible from the commands and files above. We do not claim a ranking, and we do not compare on stars or tool counts.

Features

• Bundled agent skill. Every checkout and every release ships llms.txt — a compact index — and llms-full.txt, the full API reference. Both are machine-readable, so an agent can read them straight from the repository and start working without installing a Skill, browsing the marketplace, or scraping rendered docs.
• Skills as the production unit. Ship capability as a versioned SKILL.md package with tools.yaml, progressive discovery, lint and schema validation, and hot reload (DccSkillHotReloader).
• Main-thread dispatch. Actions are queued onto the DCC's main thread, so calls are safe against applications that crash when scripted off-thread.
• Structured results and postconditions. Every call returns typed results, and the shared postcondition contract writes then reads back so a tool has to prove its own effect.
• Multi-instance routing. One gateway fronts every live DCC session and publishes gateway://instances, so an agent talks to one endpoint no matter how many hosts are running.
• UI Control as a fallback. For tools with no API at all, bounded screenshot-and-click automation brings them into the same control plane (DCC UI Control).

Choose your entry point

The current contract

The default agent path is CLI + REST:

dcc-mcp-cli dcc-types (when adapter support is unclear)

-> list -> search -> describe -> load-skill (only when needed) -> call

The gateway keeps tools/list bounded. It advertises the canonical discovery/dispatch wrappers (search, describe, load_skill, and call) instead of fanning every backend tool into one large list. Backend capabilities are discovered by search, inspected by describe, and invoked through the wrapper or the REST twin (POST /v1/search, /v1/describe, /v1/call).

When a concrete DCC session is needed, read gateway://instances; each entry already includes its mcp_url. Do not 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.

For direct per-DCC MCP connections, the compatibility discovery names (search_tools, describe_tool, and call_tool) remain available where the server exposes them. New gateway integrations should use the canonical names above.

Why dcc-mcp-core exists

The shortest DCC agent demo asks a model to write and run a mayapy, hython, or Blender Python script. A production pipeline cannot depend on getting the right script from the model on every turn. Repeated code generation costs tokens, varies with the 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:

This project provides the infrastructure for agents to control DCC applications; it does not build or prescribe the agent itself. Agents and models will change, while studio interfaces, permission boundaries, and pipeline knowledge still need to be maintained. The framework turns those investments into reusable engineering assets.

Existing tools need AI access too

Adding an AI-facing interface to a new tool is usually straightforward. The harder problem is making years of existing tools usable by agents when they 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 the bounded Computer Use-style DCC UI Control capability. It combines exact-window screenshots, semantic controls when available, scoped actions, waits, recording, policy checks, audit, and result verification. Native Skills/APIs remain the preferred path; UI Control lets legacy and interface-only workflows join the same agent control plane without pretending that every application has a clean programmable API.

MCP is an entry point, not the ceiling

MCP is the industry-standard agent interface we reuse, not the limit of the framework. A stable Python, C++, HTTP, command-port, or native plugin interface can be integrated under the same discovery, execution, safety, and operations contracts.

We also include useful vendor capabilities instead of replacing them. 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. Vendor tools, DCC-MCP tools, and studio tools can share one agent-facing workflow.

Skills are the production unit

A Skill turns 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 remain effecti