Why
ComfyUI now ships its own agent and MCP tooling — Comfy Agent and Comfy MCP — built and supported by the Comfy-Org team. It sits inside the product, with a level of integration a community project can’t match from the outside, and it is where the effort belongs. Comfy wanted to do their own thing, and that is the right call for ComfyUI users. That also settles the other half of the question. Keeping a project like this alive is support work — triaging reports, chasing regressions in someone else’s release cycle, keeping up with a frontend that moves every week — and open source is a thankless place to do it. It made sense while there was nothing else. With an official tool in the box, it doesn’t.Use the official tooling
- Comfy Agent — the agent that lives inside ComfyUI
- Agent tools documentation
- Comfy MCP
- Comfy-Org/comfy-mcp on GitHub
Fork it, remix it
The code stays public as a reference, MIT-licensed. If some part of it is useful to you — the tool surface, the installer packs, the skills, the panel — fork it and make it yours. I’d genuinely like to see what people build out of the pieces. Nothing here needs my permission, and nothing here is coming back to me as a pull request, so don’t wait on that.What happens to the npm package and the registry node
- npm (
comfyui-mcp) stays published, unmaintained. It will keep working for as long as ComfyUI keeps the surfaces it depends on. As ComfyUI grows and changes, it will eventually just stop working — that is expected, and it will not be fixed. When it does, I’ll unpublish it. - The Comfy Registry node (
comfyui-agent-panel) follows the same path: it stays listed until it breaks, and then the submission comes down. report_issueand the report-bug skill in the final release are stubs. They file nothing and point you at the official tooling instead.