dcc-mcp-core 0.19.24

Foundational library for the DCC Model Context Protocol (MCP) ecosystem

dcc-mcp-core

中文 | English

Rust-first control plane for connecting AI agents to live DCC sessions.

dcc-mcp-core turns Maya, Blender, Houdini, Photoshop, and custom studio hosts into 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 desktop sessions.

Choose your entry point

You want to…	Start with
Control a running DCC from an agent or CI job	dcc-mcp-cli
Expose a DCC adapter over MCP/REST	create_skill_server
Add tools without Python registration code	SKILL.md + tools.yaml
Build a new DCC adapter	new-adapter-onboarding.md
Understand routing and multi-instance behavior	gateway.md
Integrate from any HTTP client	rest-api-surface.md

The current contract

The default agent path is CLI + REST:

dcc-mcp-cli 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.

Quick start: operate a DCC

Install the standalone CLI when you need the operator/CI control plane without setting up Python:

# 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"

Then discover a live capability before calling it:

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}'

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.

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(port=8765))
handle = server.start()
print(handle.mcp_url())

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.

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.