Loading ToolBench
Model Context Protocol server for controlling Foundry Nuke compositing software via socket-based commands and FastMCP integration
The Nuke MCP server provides 13 tools with basic descriptions and schemas, but exhibits significant quality gaps across naming, parameter documentation, and error handling. Most tools have verb-based names (good) but lack depth in parameter descriptions and output schema documentation. Input schemas are present but sparse, many lack constraints and proper typing. Critically, execute_code (tool 9) presents an irreversible security risk without confirmation or validation guidance. No output schemas are documented, forcing LLMs to guess response structures. Error handling is absent, no recovery guidance, no invalid-value explanations, no permission checks. The server enforces internal workflow rules (NukeWorkflowRules class) but does not surface these constraints to the LLM via parameter descriptions or error messages.
Automatically arrange nodes in the node graph for better visibility
Connect the output of one node to the input of another node
Create a new node in the Nuke composition with specified type, name, and parameters
Create a new viewer node in the composition
Delete a node from the composition by name
Execute arbitrary Python code in the Nuke environment
Retrieve detailed information about a specific node
execute_code tool lacks confirmation/dry-run and has dangerously minimized description. Irreversible operations should enforce confirmation before executing.
No output schemas documented for any tool. LLMs cannot infer response structures and must guess what fields are returned, leading to parsing errors and hallucination.
create_node and modify_node accept untyped 'parameters' objects with no shape guidance. Valid Nuke knob names are enumerated in NukeWorkflowRules but NOT exposed to the LLM via parameter constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 19 | - | v1 |
Retrieve information about the current Nuke script including name, frame range, and other metadata
Modify parameters of an existing node in the composition
Set the position of a node in the node graph
Start rendering from a specified node, optionally writing to disk
Set the frame range for the composition
Control the playback state of the viewer (play, pause, or stop)
create_node 'node_type' parameter lacks enum constraint despite NukeWorkflowRules.get_valid_node_types() listing 30+ valid types. LLM can pass invalid values like 'InvalidNode' and receive no guidance on recovery.
connect_nodes hides B-pipe workflow rule ('input_index = 1 for Merge') in code logic; not exposed in parameter description. LLM may connect to wrong input and break intended compositing flow.
viewer_playback 'action' parameter lacks enum constraint. LLM may pass invalid values ('start', 'resume', 'rewind') instead of the three valid options ('play', 'pause', 'stop').
No error handling or recovery guidance across any tool. LLM receives raw failures with no actionable next steps (e.g., 'node not found' offers no suggestion to call get_node_info first).
Numeric parameters (position_node x/y, set_frames first/last) lack min/max constraints or valid range guidance. LLM may pass absurd values (negative frame numbers, extreme coordinates).
Descriptions are inconsistent in depth and clarity. Some are generic ('Retrieve information'), others minimal ('Set the position'). Baseline is 194 chars; many fall below 75 chars.