3dsmax-mcp

3ds Max MCP — Agent Guide

Each tool's description documents its parameters, modes and limits. This guide covers what no single tool can: routing, tool choice, cross-tool workflows, safety rules and MAXScript pitfalls.

Tool Profile Routing

• Full/core: operational tools such as query_scene and create_object are advertised directly; call them by name.
• Progressive: if only list_toolsets, describe_toolset and call_tool are advertised, never call an operational name as a top-level tool. Pick a capability with list_toolsets, load only that group with describe_toolset, then invoke it through call_tool(name=..., arguments=...). If the exact tool and arguments are already known, call_tool can dispatch directly.

Principles

• Match the user's request. Do not run setup, discovery or scene analysis by habit, and do not call get_bridge_status or get_session_context as a preamble.
• Prefer a dedicated tool over raw MAXScript whenever one clearly matches.
• Do not render unless the user asks. Viewport capture is fine when visual proof helps.
• Verify meaningful edits with query_scene(action="delta"), re-inspection or a capture.
• Keep mutating calls sequential. Concurrent writes interleave undo transactions: a crash, then persistent corruption such as phantom successes and wrong handles.
• Multiple Max instances: the first native connection stays bound to that Max and never silently switches while it runs. Use list_max_instances, select_max_instance(pid), get_selected_max_instance and release_max_instance. MCP_MAX_PIPE or MCP_MAX_PID pins the startup target (the pipe takes precedence); release also clears it.
  • Shared selection: the selection belongs to the MCP server process, so sessions that share one server share it, and one session's select moves the others. Pass expected_pid (every tool takes it) to any call that must reach one particular Max. A mismatch returns TARGET_MISMATCH with nothing sent. selection_generation in each reply's transport changes on every select, release or re-resolve.
  • Default target after a restart: a target the server picked by itself (target_source "default" or "claim") follows its Max's restart (the Max that started after it stopped answering), and the reply warns. A Max that was already open belongs to another session and is never taken over: until the restart is up, calls fail with retryable TARGET_UNAVAILABLE and nothing is sent; select_max_instance it to work there. Several new instances: AMBIGUOUS, select one. A claimed instance wins. Explicit and environment targets never move; they fail until you select or release.