dcc-mcp-core

中文 | English

Website · Marketplace · Showcase · For Agents · Ecosystem

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.

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 effective when selecting a well-described tool and supplying validated arguments. Studios can distribute different Skill sets by project and production stage, reducing repeated code generation, token use, and model-dependent variance.

This is also the practical customization boundary for studio TDs and TAs. Core and adapters keep ownership of host connectivity, main-thread execution, routing, safety, and observability. A TD or TA can encode the actual project flow—naming and scene checks, asset preparation, publish gates, cache/export rules, and review hand-offs—as a Skill made from SKILL.md, tools.yaml, and the studio's existing scripts. Those Skills can be tested, scoped to a project or team, and distributed through a public or private marketplace without forking the control plane or rebuilding an adapter.

One contract, a growing ecosystem

The same Skill and runtime contract now spans much more than the original DCC adapters:

Browse every integration in the ecosystem directory, or use the official Marketplace to discover optional Skills without changing an adapter.

The Admin UI closes the feedback loop. Calls, traces, logs, health, statistics, and usage data show which tools agents selected and where they failed. Teams can improve a description, schema, or implementation, then verify the result against real calls instead of treating tool use as a black box.

The boundaries remain explicit. Core cannot safely preempt arbitrary code already running on a DCC main thread, guarantee rollback for host APIs without transactions, or define one lossless mesh/rig/material model for every application. Host semantics still belong in adapters and pipeline Skills.

Quick start: operate a DCC

dcc-mcp-cli is the preferred control path for every shell-capable agent. If it is missing, obtain the user's consent, install the public dcc-mcp Skill below, and run its bundled verified helper from the Skill directory:

python scripts/check_cli.py --ensure-cli --pretty

Without the Skill, download the official installer to a local file, inspect it, and only then execute that file:

# Linux/macOS
curl -fL https://raw.githubusercontent.com/dcc-mcp/dcc-mcp-core/main/scripts/install-cli.sh -o install-cli.sh
cat install-cli.sh
# After reviewing the file:
sh ./install-cli.sh

# Windows PowerShell
Invoke-WebRequest https://raw.githubusercontent.com/dcc-mcp/dcc-mcp-core/main/scripts/install-cli.ps1 -OutFile .\install-cli.ps1
Get-Content -Raw .\install-cli.ps1
# After reviewing the file and subject to the current execution policy:
& .\install-cli.ps1

Both paths accept only the official dcc-mcp/dcc-mcp-core release, validate the platform update manifest and CLI SHA-256, and leave any existing binary untouched if validation or download fails. This is an integrity check, not a digital signature. Never pipe a remote installer directly into a shell or bypass the machine's script execution policy.

Install the Agent Skill you need

The three public Skills have separate jobs. Start with dcc-mcp for live DCC work; install a creator Skill only when the task reaches that boundary:

OpenClaw installs into the active workspace by default; add --global only when every local OpenClaw agent should share the Skill:

openclaw skills install @loonghao/dcc-mcp
openclaw skills install @loonghao/dcc-mcp-creator
openclaw skills install @loonghao/dcc-mcp-skills-creator

For a Codex-compatible project, install into the standard project Skill root:

npx --yes clawhub@0.23.1 install @loonghao/dcc-mcp
npx --yes clawhub@0.23.1 install @loonghao/dcc-mcp-creator
npx --yes clawhub@0.23.1 install @loonghao/dcc-mcp-skills-creator

Other Agent Skills hosts should install the same ClawHub package into their configured Skill root. Start a new agent turn after installation. Natural DCC requests should trigger dcc-mcp; hosts with explicit Skill invocation can use $dcc-mcp, $dcc-mcp-creator, or $dcc-mcp-skills-creator respectively.

All three packages carry Codex agents/openai.yaml metadata while preserving their DCC-MCP and ClawHub contracts. Their source, vendor manifests, immutable versions, and publication workflows now live in dcc-mcp-agent-plugins. The copies under this repository's skills/ directory remain frozen compatibility mirrors for existing Core consumers.

Keep an official build current through the release manifest:

dcc-mcp-cli update check
dcc-mcp-cli update apply

update apply downloads and stages the latest CLI for the next launch. It does not update a running dcc-mcp-server; update that server in its own environment.

Then discover a live capability before calling it:

dcc-mcp-cli dcc-types
dcc-mcp-cli list
dcc-mcp-cli search --query "create sphere" --dcc-type maya --limit 20
dcc-mcp-cli describe <tool-slug>
dcc-mcp-cli call <tool-slug> --json '{"radius": 2.0}' \
  --meta-json '{"agent_context":{"session_id":"task-42"}}'

--query "create sphere" is compatible with released CLI builds. Builds that contain the unified search parser also accept unquoted positional words.

dcc-types is an offline, catalog-backed capability query. It reports canonical adapter identifiers and install-plan availability; list remains the source of truth for live instances.

Replace the placeholder with the slug returned by search. For remote workstations, register a gateway profile and select it:

dcc-mcp-cli gateway register https://workstation.example:19293 --name pcA
dcc-mcp-cli gateway set pcA
dcc-mcp-cli list

Use dcc-mcp-cli doctor when startup or readiness is unclear. Open the local Admin UI at http://127.0.0.1:9765/admin after the gateway is available.

When a call fails, preserve its request_id, run doctor or a failure-filtered stats query, and use gateway-owned dcc-mcp-cli feedback. A live adapter's dcc_feedback__report is only a thin Core forwarder to the same endpoint. Gateway-routed failures also expose a public-safe /v1/debug/issue-reports/<request_id> payload for a reviewed bug report; raw bundles must never be uploaded automatically.

After a task is accepted, agents can inspect bounded gateway evidence with dcc-mcp-cli stats --range 24h --session-id task-42. A zero call count means no telemetry evidence, and direct local calls may not be represented. Feed the result plus short task and validation summaries to the review_skill_improvement prompt. The prompt defaults to no change, prefers improving an existing skill, and never grants authority to edit or publish outside the task scope.

Quick start: expose skills from Python

pip install dcc-mcp-core

Point the server at a skill directory and start the MCP endpoint:

import os

from dcc_mcp_core import McpHttpConfig, create_skill_server

os.environ["DCC_MCP_MAYA_SKILL_PATHS"] = "/path/to/skills"

server = create_skill_server("maya", McpHttpConfig())
handle = server.start()
print(handle.mcp_url())

Local DCC instances bind an OS-assigned port by default. The resolved URL is registered automatically, so the gateway and CLI discover it without a hardcoded per-instance port. Pass port=<number> only for an explicit fixed listener requirement.

For manual handler registration, use McpHttpServer and ToolRegistry. For adapter lifecycle, readiness, gateway registration, and hot reload, use DccServerBase as described in the adapter guides.

Add a skill without framework glue

The project follows the agentskills.io frontmatter contract. Put dcc-mcp-core extensions under metadata.dcc-mcp and keep tool declarations in a sibling file:

my-skill/
├── SKILL.md
├── tools.yaml
└── scripts/
    └── do_thing.py

# SKILL.md
---
name: my-skill
description: "Does a useful Maya task. Use when the user asks for it."
metadata:
  dcc-mcp:
    dcc: maya
    tools: tools.yaml
    search-hint: "geometry, scene task"
---

# tools.yaml
tools:
  - name: do_thing
    description: Do the task in the active Maya scene.
    source_file: scripts/do_thing.py
    execution: sync
    affinity: main
    annotations:
      read_only_hint: false
      destructive_hint: true

Run the same production validator used by CI with dcc-mcp-cli lint path/to/skills. See Skills for schemas, groups, dependencies, testing, and migration rules.

DCC UI Control

Desktop application automation for cases where native DCC APIs cannot observe or drive the interface state directly. Agents use ui_control__snapshot, ui_control__find, ui_control__act, ui_control__wait_for, ui_control__recording_start, ui_control__recording_state, ui_control__recording_stop, and ui_control__stop_computer_use to observe, find, act on, and record exact target applications.

Use UI Control as a bounded fallback, not as the default DCC integration:

• Prefer structured adapter tools for scene, asset, render, and project work.
• Use UI Control for controls that have no API, incomplete adapter coverage, and end-to-end GUI acceptance tests.
• Do not treat every image in an agent task as UI Control evidence. DCC-native captures, RenderDoc exports, ImageGen output, and video frames have different provenance.

How screenshots and clicks work

ui_control__snapshot captures only the bound window. It preserves native resolution until either the longest edge exceeds 1600 pixels or the image exceeds 1.5 million pixels, then downsizes while preserving aspect ratio. A 1280×720 window stays 1280×720; a 1920×1080 window becomes 1600×900. Smaller text and custom-drawn icons are therefore easier to recognize when the target window is large and unobstructed.

The agent receives three complementary signals:

1. PNG pixels for visual recognition and spatial understanding.
2. A CUA accessibility tree with labels, roles, and stable element tokens when the application exposes them.
3. Observation metadata for the exact PID, HWND, DPI, source rectangle, desktop generation, session, and snapshot.

Clicks prefer a semantic control_id. For custom-drawn UI, screenshot-relative coordinates are mapped back through the source rectangle and DPI. Every action must cite the latest snapshot_id; the host revalidates the window, desktop, geometry, and generation before sending input, and rejects stale observations.

Successful snapshots include capture_provenance, including the backend, session, target PID/HWND, output and source dimensions, scaling, and native capture backend. Preserve that block with screenshots used as evidence. Older images without provenance cannot be reliably attributed to UI Control after the fact.

Capabilities

• Scoped window targeting — snapshots and actions are bound to a single process or window handle, never the whole desktop.
• Multi-instance sessions — the gateway selects the DCC instance_id, while the native host namespaces each adapter connection. Separate DCC instances may therefore reuse a logical session_id such as default without sharing capabilities or cleanup state.
• Semantic accessibility + raw input fallback — prefer stable semantic controls (button, text field, checkbox) resolved by ui_control__find, then fall back to screenshot-relative coordinates when custom-drawn controls have no semantic node.
• Bounded security model — every action is scoped by the adapter/operator-bound PID/HWND. Raw input is enabled inside that exact scope by default and can be disabled with DCC_MCP_CUA_ALLOW_RAW_INPUT=false. Hard-denied: passwords, authentication controls, LockApp, Windows Security, terminals, and credential manager windows.
• Visible control markers — the standalone CUA Host owns the target border, banner, agent cursor, and Esc stop affordance.
• One shared input safety owner — multiple exact-application sessions may remain active. The standalone Host serializes native input and broadcasts Esc, while ordinary stop releases only the selected session.
• Trajectory recording — start and stop CUA recording around the actions to preserve the finalized CUA artifacts and structured recording state.
• Audit trail — every snapshot, recording, action, wait, stop, and rejected operation appends a redacted ui_control_operation event to the shared log directory, visible in the Admin Logs panel without exposing entered text or screenshot coordinates.

Tool reference

For detailed skill reference and agent workflows, see the ui-control skill.

Architecture

The runtime has four useful layers:

1. DCC service — owns skills and executes tools inside one DCC process.
2. Sidecar/supervisor — bridges host RPC, readiness, process lifetime, and gateway registration when an adapter uses the packaged runtime.
3. Gateway daemon — aggregates live instances and owns discovery, routing, REST, Admin UI, audit, and diagnostics.
4. Client surfaces — CLI, MCP clients, REST clients, and marketplace tools.

The Rust workspace and package membership are defined by the root Cargo.toml. The Python package is a PyO3 extension with pure Python helpers and supports Python 3.7–3.14. Build-from-source requirements come from rust-toolchain.toml and package metadata; the repository does not duplicate version or package counts in this README.

Documentation map

• Getting started — install the package and start a first server.
• CLI reference — complete operator commands and flags.
• Gateway guide — daemon, registry, routing, relay, and multi-instance behavior.
• REST API surface — request envelopes, tool_slug, readiness, and error contracts.
• Skills guide — authoring, loading, validation, and persistence.
• Adapter onboarding — the supported adapter implementation and release path.
• Documentation index — the complete guide/API map.
• AI agent guide and AGENTS.md — agent workflow and repository rules.

Development

Use the repository-pinned toolchain where possible:

vx just install
vx just dev
vx just test
vx just test-rust
vx just lint
vx just docs-check

docs-check builds the VitePress site and catches documentation links and syntax errors. Markdown lint runs in the docs CI workflow. See CONTRIBUTING.md for coding, testing, and release rules.

License

MIT — see LICENSE.