- Reliability 10/20
- Static evidence: server.json declares a stdio PyPI package [email protected], and the README's mcp-name ownership token matches the manifest name byte-for-byte. The README claims CI runs pytest + ruff on Python 3.10/3.14 and that one core loop (server_info → run_workflow → fetch_outputs) was validated end-to-end against a live local ComfyUI. However, this review is read-only: no execution was performed, so CI results and test coverage cannot be independently confirmed, and no committed test files are visible in the supplied material. The docs also disclose inconsistencies and edge states (40 tools claimed; system_stats/free_memory are never remoted by COMFYUI_URL; the version guard fails OPEN on an unparseable --version), meaning declared behavior can diverge from real behavior. Dependencies are deliberately undeclared (comfy-cli must be installed separately with a >=1.14.0 runtime floor), reducing dependency controllability, though error paths are structured ({"error": …, "unsupported": true}) with explicit upgrade guidance. Happy path is plausible and failures are designed to be diagnosable, but verifiable execution evidence is absent; per the static calibration cap of 12 for reliability, 10 is awarded.
- Security and permissions 15/20
- No red lines triggered: no malware, credential theft, or covert exfiltration; no install example contains a real token (COMFY_API_KEY appears only as <your-comfy-api-key> placeholders or via ${env:COMFY_API_KEY} interpolation); no unconfirmed irreversible delete/pay/deploy/remote-command defaults. Credit-spending tools (partner_generate, run_template, run_workflow) use MCP elicitation and fail closed, and COMFY_MCP_ASSUME_CONSENT explicitly excludes spending (even 'all'), can only be written by the user, and cannot be self-granted by a model argument. Other dangerous operations (install_node, version switch, restarting a server it did not start, --listen network exposure) also require confirmation. Credential handling is delegated to comfy-cli; the server never sees tokens, and auth_login only returns an OAuth URL. Deductions: the remote-ComfyUI mode requires the target to be unauthenticated and the server does not authenticate to it, so the network is the only boundary — a real exposure surface on shared networks; COMFY_MCP_REMOTE_SHARED_MODELS=1 bypasses the download guard purely on user assertion with no verification; and partner-API nodes / a COMFY_T2I_TEMPLATE retargeted to an API template can spend without a prompt, a disclosed-but-residual risk. Score 15.
- Maintenance 13/20
- The repository is not archived, has 212 stars and 16 open issues, and server.json pins version 0.10.0 with repository source/id and websiteUrl, indicating an active release line with a documented comfy-cli 1.14.0 floor. CI workflows and badges are referenced and ownership by Comfy-Org is clear. Gaps: the GitHub license field is NOASSERTION while the README/badge claim 'AGPL-3.0-or-later OR Commercial' dual licensing — the license status is opaque at the metadata level, a substantive deduction; there is also no evidence in the supplied material of issue-response cadence, a security-response channel, or dependency-update practice beyond the version floor. Activity is evident but governance and license expression are incomplete, so 13.
- Documentation 17/20
- Documentation is the strongest dimension. The README is layered: a four-step Quickstart; copy-paste config for three mainstream clients (Claude Code, Claude Desktop, Cursor); an explicit comparison with Comfy Cloud MCP; a full table of contents; Prerequisites plus optional environment variables; a tool capability overview; partner-API node and credit-confirmation mechanics; a local_check table for template runnability; remote-ComfyUI URL/variable tradeoffs; non-default port handling via COMFY_LOCAL_URL; troubleshooting; an opt-in failure log; macOS directory restrictions; and a migration table from comfy-local-mcp. Limitations are explicitly disclosed: which tools are not remoted, that system_stats/free_memory ignore COMFYUI_URL, that the version guard fails open, that COMFY_T2I_TEMPLATE can spend without a prompt, and that arbitrary custom nodes can bill outside any gate. Deductions: remaining hidden assumptions (the remote must be unauthenticated; shared storage must be asserted by the user), the NOASSERTION-vs-Commercial license ambiguity, and the sheer length that scatters key constraints. Score 17.
- Setup experience 14/20
- The install path is explicit: pip install comfy-mcp "comfy-cli>=1.14.0", comfy install for a workspace, comfy launch, then registering the comfy-mcp command in the client; all three clients have ready-to-paste JSON/command snippets, and the README explains why COMFY_BIN / COMFY_API_KEY must live in the client env block (clients launch the subprocess with a minimal environment) and how to verify with comfy-mcp --help/--version. Cross-platform notes are present (macOS Full Disk Access and ~/Documents restrictions; Windows/Linux log-directory differences). Deductions: the chain is long (Python >=3.10 plus comfy-cli plus a ComfyUI workspace plus a manually started server), and comfy-cli is deliberately not a declared dependency, so 'comfy not found on PATH' is a common first-run failure; remote and non-default-port scenarios require extra env vars plus a manual self-check (confirm the resolved address via server_info) and are easy to get wrong. Under the static calibration cap of 15 absent real execution evidence, 14 is awarded.