Dcc Mcp Core

dcc-mcp-core

[](https://pypi.org/project/dcc-mcp-core/) [](https://pypi.org/project/dcc-mcp-server/) [](https://www.python.org/) [](https://opensource.org/licenses/MIT) [](https://github.com/dcc-mcp/dcc-mcp-core/actions/workflows/ci.yml) [](https://codecov.io/gh/dcc-mcp/dcc-mcp-core) [](https://github.com/dcc-mcp/dcc-mcp-core/releases) [](https://github.com/dcc-mcp/dcc-mcp-core/releases) [](https://pypistats.org/packages/dcc-mcp-core) [](https://pepy.tech/project/dcc-mcp-core) [](https://pypistats.org/packages/dcc-mcp-server) [](https://github.com/dcc-mcp/dcc-mcp-core/releases/latest) [](https://github.com/dcc-mcp/dcc-mcp-core/releases/latest) [](https://github.com/dcc-mcp/dcc-mcp-core/releases/latest) [](http://makeapullrequest.com)

[中文](README_zh.md) | English

Agent-first DCC control plane: one CLI, one gateway, every live creative host.

dcc-mcp-core turns Maya, Blender, Houdini, Photoshop, and custom studio tools into discoverable, routable MCP endpoints. Agents stop guessing from shell output and start working with live scene state, scoped tool catalogs, structured results, viewport diagnostics, audit logs, and workflows that can survive real production constraints.

The default operator path is dcc-mcp-cli: local agent-control commands ensure the loopback gateway is available for Admin UI and IDE MCP clients, then use live DCC sessions from the shared FileRegistry and each selected instance's direct MCP endpoint; remote profiles route through a selected gateway. Endpoint/admin/update commands also ensure the local gateway when needed, so agents and CI scripts do not need a fragile preflight dance. The same stack powers the browser Admin UI, marketplace skill installs, package updates, Sentry/webhook/OTLP integration settings, and evidence panels for traces, calls, logs, and runtime health.

Under the hood it combines MCP 2025-03-26 Streamable HTTP, a zero-code Skills system built on agentskills.io 1.0, and a Rust gateway for discovery, routing, installation, linting, updates, and operations. The Python package keeps zero third-party Python library dependencies for embedded DCC hosts and depends on the companion dcc-mcp-server wheel so daemon-backed gateway startup has a packaged binary even when PATH is empty. Standalone dcc-mcp-cli and dcc-mcp-server binaries also ship through GitHub Releases for workstation-style installs. Supports Python 3.7–3.14.

---

What You Get

| Need | dcc-mcp-core gives you | |---|---| | Let agents operate real DCC sessions | MCP + REST endpoints for Maya, Blender, Houdini, Photoshop, and custom hosts | | Keep tool context small | CLI discovery: search -> describe, then call; no giant first-page tools/list scrape | | Start reliably from an agent shell | dcc-mcp-cli list/search/describe/call auto-ensure the local gateway, then use local registry + direct MCP or remote gateway profiles | | Add and update tools without framework glue | SKILL.md + sibling YAML/scripts, marketplace install/update, aligned with agentskills.io | | Debug live workstation state | Admin UI, viewport diagnostics, audit logs, traces, logs, metrics, Sentry/webhook integration state | | Survive production constraints | Main-thread dispatch, async jobs, sidecar/server binaries, workflow and artefact primitives |

Product Surfaces

| Surface | What operators see | Why it matters | |---|---|---| | dcc-mcp-cli | health, list, search, describe, call, load-skill, reload-skills, marketplace, and update commands | Agent and CI entry point; local DCC control works from registry defaults, remote control works through gateway profiles | | Gateway Admin UI | Instances, server versions, one-click update actions, skill paths, marketplace packages, integrations, calls, traces, logs, and health | One browser surface for live workstation operations | | Skills Marketplace | Catalog search, install, uninstall, outdated checks, and package updates | Teams can distribute DCC capabilities without rebuilding adapters | | Integrations | Sentry DSN, webhook config, WeCom message push, and OTLP endpoint visibility with pending-restart state | Observability settings are editable, masked, and backed by real gateway APIs |

Runtime Architecture

Use the process names this way:

• DCC startup hook runs inside Maya, Houdini, 3ds Max, or another host and

should only launch the service path without blocking the UI/main thread.

• Per-DCC service is one registered runtime row for one concrete DCC

instance.

• Sidecar is the dcc-mcp-sidecar child launched by

dcc-mcp-server sidecar; it bridges host RPC to MCP/REST and watches the DCC process.

• Gateway daemon is the one machine-wide routing/Admin process.
• Guardian is the live service loop that probes gateway /health and

re-ensures the daemon through gateway-launch.lock.

• Service heartbeat keeps registry rows fresh; it is not the gateway restart

trigger.

The intended plugin experience is: open DCC -> startup hook launches a per-DCC service/sidecar -> that service ensures the machine-wide gateway daemon exists -> it registers and heartbeats one instance row -> the gateway routes across every live DCC instance.

Why This Matters

Generic MCP servers and CLI wrappers expose commands. dcc-mcp-core exposes a live DCC control plane built for production sessions:

• Agents can reason from active scenes, documents, selections, viewport captures,

output streams, and host-published resources instead of blind shell output.

• Progressive discovery keeps context small: search compact capability records

first, inspect only the selected schema, then load or call the chosen tool.

• One gateway can route across many DCC instances, versions, scenes, and custom

studio hosts without merging every backend action into one huge tools/list.

• Main-thread dispatch, readiness probes, async jobs, cancellation, persistence,

and artefact hand-off match the constraints of embedded desktop hosts.

• Skills are packages: SKILL.md, tools.yaml, scripts, reference docs, and

Rez/context bundles can travel through normal studio distribution workflows.

• Audit logs, security annotations, diagnostics, telemetry, and Admin UI panels

give operators enough evidence to trust what agents did.

Recommended Agent Workflow

1. Start from the CLI path when the agent can run shell: use the bundled

dcc-cli-gateway skill, then run dcc-mcp-cli list for local inventory or dcc-mcp-cli list --gateway for a remote workstation.

1. Search compactly with dcc-mcp-cli search; local mode talks directly to the

registered DCC MCP endpoint, while remote profiles route through the selected gateway.

1. Inspect before loading or calling with dcc-mcp-cli describe .

Load only what the task needs with dcc-mcp-cli load-skill when the selected tool depends on an unloaded skill.

1. Call the typed tool with dcc-mcp-cli call, then inspect structured results,

job updates, resources, prompts, diagnostics, and follow-up hints.

1. Use marketplace commands to search, install, and update community or studio

skill packages; use IDE MCP only when the host already has an MCP connector configured.

tools/list is MCP-compatible and paginated. Treat it as a transport listing, not as a complete search index; never assume the first page contains every loaded or discoverable tool.

Quick Start

Install the standalone CLI

Use the release binary when you want the operator/CI control plane without a Python environment:

# Linux/macOS
curl -fsSL https://raw.githubusercontent.com/dcc-mcp/dcc-mcp-core/main/scripts/install-cli.sh | bash

# Windows PowerShell
powershell -c "irm https://raw.githubusercontent.com/dcc-mcp/dcc-mcp-core/main/scripts/install-cli.ps1 | iex"

After install:

dcc-mcp-cli list
dcc-mcp-cli doctor
dcc-mcp-cli search --query "create sphere" --dcc-type maya --limit 20
dcc-mcp-cli describe 
dcc-mcp-cli call  --json '{"radius":2.0}'
dcc-mcp-cli marketplace search --query rigging --dcc maya --limit 20
dcc-mcp-cli health
dcc-mcp-cli update check --binary dcc-mcp-server --current-version 

Default operator flow:

1. Run dcc-mcp-cli list first for local inventory. It auto-ensures the

machine-wide loopback gateway, then reads the local FileRegistry. Register remote machines with dcc-mcp-cli gateway register https://host:19293 --name pcA, then use dcc-mcp-cli gateway list, dcc-mcp-cli list --gateway pcA, or dcc-mcp-cli gateway set pcA. Agent-control commands (list, search, describe, call, load-skill, wait-ready, reload-skills, and stop-instance) plus endpoint/admin/update commands auto-start only loopback gateway targets when needed; pass --no-auto-gateway for a single no-launch invocation. If startup state is ambiguous, dcc-mcp-cli doctor reports the selected profile, registry path/inventory, gateway daemon status, and server binary diagnostics without starting or downloading services.

1. If list returns live instances, use search -> describe -> call; in the

local profile the CLI talks to the selected instance's MCP endpoint directly. Keep tools/list as a compatibility listing, not the primary discovery surface.

1. Open http://127.0.0.1:9765/admin for browser operations: instance health,

server-version checks, one-click server update staging, skill paths, marketplace package updates, integrations, traces, logs, and token activity.

1. Use the Instances panel update button to stage dcc-mcp-server updates for

a running backend. Use dcc-mcp-cli update apply only for the CLI binary itself.

Once any gateway-backed command succeeds, the Admin UI is available at http://127.0.0.1:9765/admin by default. The CLI can be pointed at another gateway with --base-url or DCC_MCP_BASE_URL.

Install the Python core

pip install dcc-mcp-core

Or build from source with the repo's canonical feature set:

git clone https://github.com/dcc-mcp/dcc-mcp-core.git
cd dcc-mcp-core
vx just dev

Serve a DCC over MCP — Skills-First

create_skill_server wires up progressive discovery, skill loading, routing, and structured results:

from dcc_mcp_core import create_skill_server, McpHttpConfig

server = create_skill_server("maya", McpHttpConfig(port=8765))
handle = server.start()
print(handle.mcp_url())   # "http://127.0.0.1:8765/mcp"

Agents then search compactly before they load or call tools. On a direct per-DCC server, use search_tools for active tools, search_skills for unloaded skill candidates, get_skill_info for schema inspection, then load_skill and tools/call. Through the gateway, use MCP search -> describe -> load_skill if needed -> call, or the REST twin POST /v1/search -> /v1/describe -> /v1/call.

---

The Problem & Our Solution

Why Not Just Use CLI?

CLI tools are blind to DCC state. They can't see the active scene, selected objects, or viewport context. They execute in isolation, forcing the AI to:

• Make multiple roundtrips to gather context
• Rebuild state from CLI outputs (fragile, slow)
• Lack visual feedback from the viewport
• Scale poorly with context explosion as requests grow

Why MCP (Model Context Protocol)?

MCP is AI-native, but stock MCP lacks two critical capabilities for DCC automation:

1. Context Explosion — MCP has no mechanism to scope tools to specific sessions or instances, causing request bloat with multi-DCC setups.
2. No Lifecycle Control — Can't discover instance state (active scene, documents, process health) or control startup/shutdown.

Our Approach: MCP + Skills System

We reuse and extend the existing MCP ecosystem, adding:

| Capability | Benefit | |---|---| | Gateway Election & Version Awareness | Multi-instance load balancing; automatic handoff when a newer DCC launches | | Session Isolation | Each AI session talks to its own DCC instance; prevents context bleeding | | Skills System (Zero-Code) | Define tools as SKILL.md + sibling YAML/scripts — no Python glue code needed | | Progressive Discovery | Scope tools by DCC type, instance, scene, product; prevents context explosion | | Instance Tracking | Know active documents, PIDs, display names; enable smart routing | | Structured Results | Every tool returns (success, message, context, prompt) for AI reasoning | | Workflow Primitive | Declarative multi-step workflows with retry / timeout / idempotency / approval gates | | Artefact Hand-off | Content-addressed (SHA-256) file passing between tools and workflow steps | | Job Lifecycle + SSE | tools/call opt-in async dispatch, $/dcc.jobUpdated notifications, SQLite persistence |

This isn't reinventing MCP — it's solving MCP's blind spots for desktop automation.

For production pipelines, skills can be distributed as Rez packages and composed into context bundles before a DCC starts. A resolved launch context sets DCC_MCP_* environment variables for project, task, asset, provenance, and skill paths; the adapter records those values in gateway metadata so clients discover only the active project/task/asset surface instead of every studio tool. See [Context Bundles](docs/guide/context-bundles.md) and [Rez Skill Packages](docs/guide/rez-skill-packages.md).

---

Why dcc-mcp-core Over Alternatives?

| Aspect | dcc-mcp-core | Generic MCP | CLI Tools | Browser Extensions | |---|---|---|---|---| | DCC State Awareness | Scenes, docs, instance IDs | No | No | Partial | | Multi-Instance Support | Gateway election + session isolation | Single endpoint | No | No | | Context Scoping | By DCC / scene / product | Global tools | No | Limited | | Zero-Code Tools | SKILL.md + sibling files | Full Python required | Scripts only | No | | Performance | Rust + zero-copy + IPC | Python overhead | Process overhead | Network overhead | | Security | Sandbox + audit log | Manual | Manual | None | | Cross-Platform | Windows / macOS / Linux | Yes | Limited | Browser only |

AI-friendly docs: [AGENTS.md](AGENTS.md) · [docs/guide/agents-reference.md](docs/guide/agents-reference.md) · [.agents/skills/dcc-mcp-core/SKILL.md](.agents/skills/dcc-mcp-core/SKILL.md)

---

Architecture: The Current Stack

Gateway Admin UI

The elected gateway ships with a built-in admin console for operators who need to inspect live DCC sessions, server versions, routing health, audit calls, traces, logs, skill paths, marketplace packages, one-click update actions, integration settings, and token activity without leaving the browser. The examples below use representative demo data to show the range of panels available in a busy multi-DCC workstation.

Admin highlights:

• Command Center: separates agent prompt handoff from human CLI recipes, so

agents get a concise search -> describe -> call path while operators still have copy-ready dcc-mcp-cli commands. Local instance-control commands use the FileRegistry and direct MCP by default; gateway-backed endpoint/admin commands can still auto-ensure the local gateway when needed.

• Instances: row-based live/stale/unhealthy inventory with server version,

adapter version, dispatch readiness, one-click update checks, direct update actions, and restart-required status after staging.

• Skills and Marketplace: list-first skill inventory, custom skill paths,

loaded skill details, marketplace browse/installed/source tabs, force reinstall, package updates, and API-backed error messages when a package endpoint returns HTML instead of JSON.

• Integrations: Sentry, webhooks, WeCom message push, and OTLP settings

backed by gateway APIs, with editable local config under ~/dcc-mcp/etc and clear pending-restart state when the server must reload startup integrations. WeCom templates ca

…

Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: dcc-mcp
• Source: dcc-mcp/dcc-mcp-core
• License: MIT
• Homepage: https://dcc-mcp.github.io/dcc-mcp-core/

Install and usage instructions live in the source repository linked above.