dcc-mcp-3dsmax-setup

dcc-mcp-3dsmax setup

Use this skill when a user wants an agent to prepare a machine so any MCP host can use dcc-mcp-3dsmax with Autodesk 3ds Max.

This is an operator skill, not a 3ds Max runtime skill. Do not load it through the 3ds Max MCP server. Run it from the repository checkout or copy its steps into another agent's instructions.

3ds Max is Windows-only, so discovery and paths below assume Windows.

If the user asks an agent to install dcc-mcp/dcc-mcp-3dsmax, first clone or locate the repository and resolve its absolute path as REPO_ROOT. Read <REPO_ROOT>\install.md and this skill at <REPO_ROOT>\skills\dcc-mcp-3dsmax-setup\SKILL.md, then follow the workflow below.

Goal

End with:

• dcc-mcp-3dsmax and its pip dependencies installed into the target 3ds Max 3dsmaxpy environment.
• A 3ds Max startup hook installed into userStartupScripts when the directory can be resolved, so opening or restarting 3ds Max starts the runtime automatically.
• An MCP host config snippet that points to the 3ds Max gateway.
• A generated fallback startup script under .dcc-mcp/agent-setup/ for machines where the startup directory cannot be auto-detected.
• A live smoke prompt that proves the agent can discover and call 3ds Max tools.

Fast Path

Install the public lifecycle CLI, then plan with explicit paths before any mutation:

python -m pip install --upgrade dcc-mcp-3dsmax
dcc-mcp-3dsmax install --json --dry-run `
  --dcc-path "C:\Program Files\Autodesk\3ds Max 2025" `
  --python "C:\Program Files\Autodesk\3ds Max 2025\Python\python.exe"

Inspect the one-object Install SOP v1 report. With user consent, execute the same plan using --yes, preserve the receipt, follow a restart next step if present, and run dcc-mcp-3dsmax verify --json with the same paths. Only verify.directly_usable=true proves the typed sidecar probe succeeded.

The standard CLI:

1. exposes install, status, verify, upgrade, and uninstall;
2. records the selected host and interpreter in the plan and receipt;
3. stages the startup hook and receipt before commit, restores and reads back their exact presence, bytes, digests, and independent identity when commit fails, rejects symlink/reparse/hardlink or same-bytes identity swaps, and still attempts package reconciliation if either file cannot be verified;
4. runs compatibility and receipt-ownership preflight during --dry-run, and fails closed when a receipt belongs to another hook or when status/verify observes a symlink, reparse point, hardlink alias, or independent same-bytes replacement of the identity-bound receipt or hook;
5. captures startup failures before MCP exists and performs bounded typed readiness verification with stable public reasons rather than probe values or exception text;
6. checks host, target Python, and installed Core compatibility before any mutation, and verifies exact package provenance plus dependency state after rollback instead of assuming that a matching version means recovery.