Skip to main content
1 tool. Generated from the live MCP tool schemas — do not edit by hand; run npm run docs:gen.
You don’t type these calls. Ask your agent for what you want in ordinary English — it chooses the tool and fills in the arguments. The JSON on this page is what it sends. New here? Start with Using the tools.

restart_comfyui

Control the lifecycle of the ComfyUI server process. Driven by the action parameter:
  • action:“restart” — Restart ComfyUI: stops the running process (capturing its config), waits for the port to free, relaunches with the same arguments, and polls the API for bounded readiness. Also works against a REMOTE/tunnelled ComfyUI (via —comfyui-url) by rebooting through ComfyUI-Manager over HTTP and polling for it to come back (requires ComfyUI-Manager present and its security level permitting the reboot). When COMFYUI_RESTART_COMMAND is set, a LOCAL restart runs that command instead of kill+relaunch — the recovery path for an externally managed install (a container, a systemd unit, a launcher) whose launch path cannot be proven from here. This is the normal way to reload newly installed custom nodes, and the escalation when queue (action:“cancel”) reports a job WEDGED. On Windows restart_comfyui never launches ComfyUI itself. A local restart there asks ComfyUI-Manager to reboot a ComfyUI Desktop backend whose supervisor is verified, or INFERRED from Desktop’s launch arguments when the process tree cannot be read (disclosed in the result; a server started by hand with Desktop’s flags would stay down); or reboots a verified EZi/CEI proxy backend; or runs COMFYUI_RESTART_COMMAND (keeping what that command starts outside the agent’s process tree is up to the command). Any restart that would need restart_comfyui to relaunch ComfyUI is refused BEFORE anything is stopped. Other launch paths (comfy_cli server_start/server_restart, commands you run yourself) are not covered by this.
  • action:“start” — Start ComfyUI using process info saved from a previous action:“stop” call. Supports both Desktop app and manual Python installs on macOS/Linux. Polls the API for bounded readiness before reporting ready. Local installs only. NOT available on Windows: a process launched from here belongs to the agent’s process tree and can be killed when the agent closes or updates, so start always refuses there (startup:“not-attempted”) — start ComfyUI from the Desktop app or its own launcher.
  • action:“stop” — Stop the running ComfyUI process. Captures process info so it can be restarted with action:“start”. Kills the process tree and resets the WebSocket client. Local installs only. Anything queued or rendering is lost. On Windows the stop is one-way from this tool: action:“start” cannot bring it back (the result says has_restart_info:false), so only stop when ComfyUI should stay down until someone restarts it by hand; to cycle it use action:“restart”, which refuses rather than leaving ComfyUI down when it cannot bring it back.
  • action:“status” — READ-ONLY: report what start, stop and restart would do right now, and whether this tool could bring ComfyUI back after a stop (stop.recoverable_by_start “yes”/“no”/“unknown”, with manual_recovery_reason and the manual restart_hint), plus the restart route and its evidence (verified-supervisor, inferred-supervisor, proven-launch-files, validated-command, user-configured, corroborated-proxy, unverified-remote, none). Stops, launches, reboots and writes nothing. For maintenance, call it BEFORE action:“stop”, and cycle ComfyUI with action:“restart” rather than stop+start. It is a prediction: each action re-checks when it runs and may still refuse. target_stable:false means the ComfyUI target changed while it was checking, so every answer is “unknown” — retry.
In plain terms: Starting, stopping and restarting ComfyUI, chosen with action. Restarting is the standard next step after installing a node pack — new nodes are not loaded until ComfyUI starts again.

Parameters

enum
required
Which process operation to perform. None of them takes any other parameter. “restart” stops and relaunches in one call (and is the only action that also works against a remote/tunnelled ComfyUI); “start” relaunches from the info a previous “stop” saved (never on Windows); “stop” kills the running process tree; “status” is read-only and changes nothing — call it before “stop”. Options: action:"restart", action:"start", action:"stop", action:"status".

Examples

You say: Restart it so the new nodes load.
You get back: The server stops and comes back up, and you are told when it is answering again.
Anything queued or rendering is lost. Check the queue is empty first if a long job is in flight.
You say: Shut ComfyUI down, I need the VRAM.
You get back: Confirmation that the process stopped.
Any running or queued render is lost.
You say: Start ComfyUI again.
You get back: It launches the server and waits until it is answering, then tells you the URL. Only works for a ComfyUI on this machine.