A
licenseNot graded
qualityC
maintenanceA lightweight MCP server that bridges AI agents with a local ComfyUI instance to generate and iteratively refine images, audio, and video through conversational tool calls.
41
MIT
comfyui-loop-mcp
by huikku
ComfyUI Loop MCP is a loop-aware Model Context Protocol server that lets an AI agent autonomously build, run, visually inspect, and iteratively refine ComfyUI workflows — with a durable ratchet mechanism that preserves the best-so-far state and prevents regression.
Discovery & Exploration
Check ComfyUI status, device/VRAM info, queue status, and interrupt running jobs
List/search installed nodes and models, inspect node interfaces (inputs, outputs, types)
Search ~550 official workflow templates (online or local) and list overridable template slots
Install Missing Components
Identify missing nodes for a template, install node packs via ComfyUI-Manager, download models from catalog, and restart ComfyUI to register new nodes
Build & Run Workflows
Convert FlowZip or litegraph to API format, upload images, submit workflows for execution
Run templates with input overrides without loading full graphs into context
Inspect & Measure Results
Retrieve output images and fetch actual rendered pixels for visual inspection
Compare two images side-by-side or as difference maps, get pixel-level diff statistics
Measure objective metrics like sharpness, tile seams, or brightness
Durable Iterative Loop (the Ratchet)
Open a loop session with a brief and optional objective gate (
loop_start)Record each pass with change description, verdict, graph, and score; ratchet auto-keeps best and reverts regressions (
loop_record)Fetch the best-so-far graph or full append-only ledger after context compaction (
loop_best,loop_ledger)Close the loop and generate a self-contained HTML report of all passes, images, and changes (
loop_finish,loop_report)
Deliver Editable Workflows
Convert API-format graphs back to UI/litegraph format with round-trip verification, and save to ComfyUI's workflow list for human editing
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@comfyui-loop-mcpGenerate a high-res image of a cat with no pixelation."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
comfyui-loop-mcp
A loop-aware MCP server for your own ComfyUI. It doesn't just call the API — it runs the loop: build → run → look → critique → fix, until the output actually meets the brief.
A graph that runs with zero node_errors is valid, not correct. Mangled hands, a
drifted background, a hard matte edge, a visible tile seam — none of that shows up in an
error log. It only shows up in the pixels. So every tool description, every tool
response, and the server's own instructions push the model to look before it declares
a graph done.
The part nobody else has: the ratchet is a tool, not a suggestion. Most agent tooling drives ComfyUI. This one manages the loop — a long loop gets its context compacted, and the moment that happens a remembered "best-so-far" is gone: the ratchet silently stops ratcheting, the model retries changes it already rejected, and it can hand you a regression as the final answer. So the best graph and the ledger live on disk, not in the model's memory. Reverting is a tool call, not an act of recall.
loop_start ─▶ submit ─▶ get_result ─▶ get_image ─▶ compare_images ─▶ loop_record ─┐
▲ (LOOK) (what moved?) (ratchet) │
└─────────────────── revert to best, try something else ◀─────────────────┘
↓ can't name a defect?
loop_finish + loop_report → sign-offThe method ships with the server. The loop prompt and the Claude Code skill live in
comfy_loop/docs/ and are packaged into the wheel, so
comfy_loop / comfy_skill / comfy_install serve them verbatim from wherever the
server is installed — one source, nothing to keep in sync. (They started life in
comfyui-llm-onboarding-prompt, which is no longer maintained; this repo is where
they're kept now.)
How it compares to Comfy's own MCP servers — the local one and the cloud one, honestly
Design position: discovery vs. repair — where a local tool genuinely wins/loses, and the north star
How it compares to Comfy's own MCP servers
ComfyUI ships two official servers, and this is a third thing built alongside them — independently, and from the other end of the problem.
Comfy-Org/comfy-mcp (first commit
2026-07-01, one day after this one, though it was public first) drives a local
ComfyUI through comfy-cli: every tool shells out to the comfy binary and
parses its JSON envelope. Comfy Cloud MCP (https://cloud.comfy.org/mcp) is a
remote HTTP server that runs the graph on Comfy's GPUs. Both are built and
maintained by the ComfyUI team.
This one speaks HTTP to /prompt and /object_info directly — no CLI, no
account, nothing to install beyond httpx — and spends its surface area on the
half of the job that starts after a graph runs.
The actual difference
Their local server treats the ComfyUI install as the thing to manage: launch it, stop it, roll it to another version, sign in, spend credits on hosted partner models, tail its logs, keep the packs updated. That is a genuinely bigger surface than this repo has, and it is the surface a platform vendor is best placed to own — it moves whenever ComfyUI, comfy-cli or the partner APIs move. If what you need is drive and maintain my install, use theirs.
This one treats the output as the thing to manage — because that is the part
we were on the hook for. It came out of Alienrobot's own production work, where a
graph that runs is the start of the job, not the end of it. Nothing here launches
a process or spends a credit. Instead: return the pixels to the model, diff two
passes into an image where drift can't hide, score the thing the brief actually
demands, and hold the best-so-far on disk so a compacted context can't lose
it. That's the part no one else has — not because it's hard to call /view, but
because "make the agent look, and stop it building on a regression" is a
discipline, not an endpoint.
this repo | Comfy-Org/comfy-mcp | |
Talks to ComfyUI via | its HTTP API ( |
|
Extra dependency | none ( |
|
Sees a ComfyUI you didn't install | yes — anything the URL reaches, incl. a box you have no shell on | partially; some tools are local-only by construction |
Look at the result |
|
|
Judge the result |
| — |
Keep the best one |
| — |
Explore a parameter |
|
|
Pre-flight a graph |
|
|
Subgraph templates | expanded and rewired (promoted widgets kept) | expanded client-side |
Token cost of discovery | compact node notation (93% off | not a stated goal |
Install what's missing | ComfyUI-Manager: | registry |
Zero to running | the agent does it: | tells you to run |
Run the ComfyUI process | no — restart only (via Manager); the agent owns the shell |
|
Hosted/partner models, accounts, credits | no, deliberately |
|
Job control |
| one |
MCP surface | 43 tools + 2 prompts + 3 resources | 39 tools |
Size / licence | ~3,700 lines, MIT | ~16,000 lines, AGPL-3.0-or-later or commercial |
Built by | Alienrobot — built for, and used in, our own VFX/generative work | the ComfyUI team, alongside the platform itself |
Scope of the commitment | the loop: discovery, conversion, and judging the output | the whole install: lifecycle, accounts, partner APIs, packs |
Which to use
No GPU → Cloud MCP. Nothing local competes with hardware you don't have.
"Install it, run it, keep it working" → Comfy-Org/comfy-mcp. Lifecycle, partner models, background downloads, version pinning.
"The first result runs, and a trained eye rejects it" → this one. Six fingers, a drifted background, a hard matte edge, a visible tile seam, a clip that boils. That's a loop, and this is a server built entirely around it.
They compose: nothing stops you running both, and the tool names don't clash.
(The package names did — this one was comfy-mcp too, briefly, which is a losing
argument to have with the people who own the ComfyUI namespace. Hence
comfyui-loop-mcp; the import package is comfy_loop, and both can be installed
side by side.)
What we're not going to add
Absorbing a competitor's feature list wholesale is how you end up with two mediocre tools. What's here from theirs is what a loop needs — pre-flight, job status, log tailing, VRAM headroom, updates. What stays out, on purpose:
Accounts, credits, hosted partner models. The pitch is "nothing leaves your machine, no signup, no meter." A credit gate contradicts it. If you want Kling or Veo, their server does it properly, with consent gates this repo has no reason to reinvent.
Launching and stopping the ComfyUI process. An HTTP client cannot start a server that isn't running, and pointing this at a box you have no shell on is a supported case, not an edge one.
restart_comfyui(via Manager) is the honest limit — but "can't" is not the same as "won't help": the agent usually does have a shell, so an unreachable server returns the install/start commands for this machine and expects the agent to run them. Neither this server nor Comfy-Org's installs ComfyUI for you (theirs points you atcomfy installin a terminal); the difference is that here the instructions come back through the tool call, aimed at whoever can act on them.Workflow save / share / reproduce as a service.
save_workflowhands you a round-trip-verified file. Where it lives after that is your business.
Related MCP server: ComfyPilot
The three MCP primitives, mapped to the loop
Primitive | What it exposes | Loop step |
Tools |
| Discover, don't guess |
| Extend (install what a template needs) | |
| Verify before the GPU is involved | |
| Compress (token-efficient graphs) | |
| Run a known-good template with overrides (no graph in context) | |
| Build → Run | |
| Look | |
| Ratchet + ledger, on disk | |
| Control | |
Prompts |
| The whole discipline, one command |
Resources |
| Truth + docs |
Three things make it loop-aware rather than a plain API wrapper:
get_imagereturns the rendered output to the model — that's the step that makes "look" real. The model literally sees the pixels.Tool responses push the loop.
submit_workflowon success says "valid, not correct — now LOOK"; on a rejection it says "not an iteration — fix the named node and re-submit."get_resultends with a directive: "do not stop here — LOOK, then change one parameter or declare the brief met."The server instructions carry a prefer-looping policy (see below) that the client injects at connect time.
The prefer-looping policy (server instructions)
At handshake the server tells the agent when to loop and when not to:
ALWAYS discover from the live API before writing JSON; validate by executing;
node_errorsare not iterations — fix and re-submit.PREFER LOOPING whenever a trained eye could reject the output — composition/ count, likeness, matte/edge quality, upscale/restore, relight, texture seams, video temporal stability, "make it look right."
RATCHET — hold a best-so-far; keep a change only if it beats it, else revert and try something different; pivot param → wiring → model on plateau. Gate on an objective test only where the brief has one; judge by eye otherwise.
SKIP the loop only for mechanical tasks (format conversion, a pure API query, or when the user explicitly wants just a runnable graph).
When unsure, do at least one look-and-critique pass before declaring done.
The ratchet/ledger/pivot are adapted from Karpathy's AutoResearch loop, tuned for subjective image work (objective gate only where one exists; a human sign-off checkpoint instead of running forever). These policy lines live in the server instructions + tool responses; the full method is in the comfy_loop prompt, which serves the repo's loop doc verbatim.
MCP can't force behavior — it exposes capabilities and guidance. This makes looping the strong, well-scoped default the agent is repeatedly told to prefer. For a hard guarantee in Claude Code, install the same text as an always-on skill:
mkdir -p ~/.claude/skills/comfyui-workflows cp comfy_loop/docs/SKILL.md ~/.claude/skills/comfyui-workflows/Skill = always-on discipline, MCP = the tools it drives. It's the same file the
comfy_skillprompt serves, so they can't disagree — and it defers tocomfy_installfor bootstrapping rather than carrying its own stale recipe.
Tool reference
Discover
Tool | Args | Returns |
| — | Loop step 0, and a real preflight. When nothing answers it returns what to do about it, specific to this machine — start the install it found, create one, or open the tunnel for a remote URL (see Troubleshooting). When it does answer, it still names what stands between here and a working render: torch running on the CPU (every render works, ~50x slower, nothing reports an error), no weights on disk (a fully functional ComfyUI that can render nothing), no ComfyUI-Manager (with the two commands to fix it, since |
|
| Nodes whose class name or display name matches (a strict superset of the skill's class-only search). Omit keyword for the count. |
|
| One node's interface as compact |
|
| The real model files a loader offers on disk (ground truth), read from its enum — handles both the legacy list and |
|
| The downloadable model catalog (ComfyUI-Manager's list) — find checkpoints/LoRAs/VAEs/upscalers you may not have yet; each result flags whether it's already installed. Install with |
|
|
|
|
| Fetches a template. |
|
| Expands FlowZip text back into full litegraph JSON. |
|
| Converts FlowZip/litegraph → API/prompt format for |
|
| Lists a template's overridable inputs (node_id → params + current values) without loading the full graph — including parameters inside subgraphs. Also returns the author's own Note/MarkdownNote text, where trigger words and required weights actually live, quoted as untrusted data rather than instructions. |
|
| Runs a known-good template with |
Extend (install what a template needs — requires ComfyUI-Manager on the host)
Tool | Args | Returns |
|
| Diffs node classes against |
|
| Installs a pack via ComfyUI-Manager's queue (trusted registry, no arbitrary code). Then a restart is required. |
|
| Downloads a catalog model (from |
| — | Restarts ComfyUI (via Manager) so new nodes register in |
|
| Updates ComfyUI core and/or every installed pack via Manager's queue, then tells you a restart is required. Runs third-party code — say so first. Not mid-loop: it moves node behaviour under a ratchet whose earlier passes were measured against the old code. |
Verify — everything knowable before the GPU is involved
Tool | Args | Returns |
|
| One answer to "will this run on this box": node classes you don't have (resolved to pack ids in the same pass), model filenames that aren't in that loader's list (with the nearest thing you do have), required inputs left unset, wires pointing at absent nodes, values outside a node's declared range, and a graph with no output node — which runs green and produces nothing to look at. |
Build → Run → Look
Tool | Args | Returns |
|
| Uploads a local image to ComfyUI's |
|
| On success: |
|
| Polls |
|
| The actual image, returned to the model so it can judge the pixels. |
|
| The comparison as an image. |
|
| Mean/max absolute difference + % of pixels changed — the "I changed only what I meant to" gate. Catches the 'small tweak' that quietly rewrote the frame. |
|
| An objective score for the ratchet, where the brief has an objective test. |
|
| Dimensions, fps and frame count for a video output. Call it before indexing frames — you need the range, and you need to know whether two clips you're about to compare are even the same length. |
|
| One frame of a video output by frame index, returned as an image. The video half of |
|
| Same comparison, at the same frame index in both clips. Comparing by timestamp goes quietly wrong the moment lengths differ (a frame cap, a trim, a different fps) — you compare two unrelated moments with full confidence. On a frame-count mismatch the warning is burned onto the image, not left in text you can skim past. |
|
| Frame-to-frame instability as a number — the objective gate for "does it boil?", which no single still can show. Naive consecutive-frame difference, so real motion counts: use it on the SAME clip before/after a change, or pass an |
The loop, as durable state — the ratchet is a tool, not a memory exercise. A long loop gets compacted; if best-so-far and the ledger live only in the model's context, the ratchet silently stops ratcheting, the model retries changes it already rejected, and it can hand back a regression as final. So they live on disk.
Tool | Args | Returns |
|
| Opens a run → |
|
| Records a pass and applies the ratchet. |
|
| Runs the same graph across up to 8 values of one input, in one call — for the values you can't reason your way to (denoise, cfg, strength). Everything else is held identical, so the outputs differ by exactly one variable. The value → |
|
| The best-so-far graph. The source of truth after a compaction — your recollection isn't. |
|
| The append-only loop log: every pass, what changed, what it did. Recovers the thread after compaction; it's also the log you hand the user at sign-off. |
|
| Closes at the convergence checkpoint; returns the final ledger + best graph to present for sign-off. |
|
| Renders the whole run as one self-contained HTML page — every pass, what was kept, what was reverted, thumbnails base64-inlined so it opens with ComfyUI off. The final image proves nothing; the passes you threw away are what show the loop converged. |
Deliver
Tool | Args | Returns |
|
| API → UI/litegraph so a human can open and edit it, saved into ComfyUI's workflows list. Round-trip verified: the result is converted back to API and diffed against your input, because |
Control
Tool | Args | Returns |
| — | Device / VRAM (useful when tuning resolution/batch or after an OOM). |
| — | What's running and pending. |
|
| Where one run is without blocking: queued (with its position), running, done with N outputs, or the execution error that killed it. What you want with several in flight — a |
|
| Drops one queued run, or interrupts it if that id is the one executing. No id clears the pending queue and leaves the running job alone. |
| — | Cancels the current run. |
|
| Unloads models and resets the executor cache ( |
|
| Tails ComfyUI's own log, where failures explain themselves: the traceback inside a node, the OOM, the custom node that failed to import at startup (which is why its class is missing from |
Prompts: comfy_loop (full autonomous method) and comfy_skill (compact
skill), both served verbatim from the repo's markdown, plus comfy_install —
the bootstrap recipe, generated against the machine the server is running on: an
install if one is already there, the interpreter to build the venv from (this
server's own, so Python is never a prerequisite to solve), whether comfy-cli and
git are present, and the torch build this box's accelerator actually wants
(CUDA / ROCm / MPS / none). The server can't run any of it; the agent can, and
that is who it's addressed to.
Resources: comfyui://object_info (live full dump), comfyui://loop-method,
comfyui://skill.
Watch the loop actually work
Driven entirely through this MCP server against a real ComfyUI (RTX 4090, SD1.5), brief: "a crisp, sharply focused macro studio photo of a single red apple on a warm wooden table, fine skin texture, rich detail." Seed fixed at 42 so each pass changes exactly one knob and the effect is attributable. The objective metric is variance-of-Laplacian (a standard sharpness/focus measure).
Pass | One change | Sharpness (varLap) | Verdict by looking |
1 | baseline — 6 steps, cfg 2.5 | 425 | Soft, flat, matte. Weakest. |
2 | steps 6 → 24 | 1204 | Sharper — but the high number is the wood grain, apple skin still plasticky. |
3 | cfg 2.5 → 7.5 | 515 | Apple gets richer (saturated, skin speckles) — metric drops because the background softened. |
4 | euler → dpmpp_2m + karras | 740 | Winner. Crisp highlight, visible lenticels, believable wood. |
5 | steps 24 → 36 | 661 | ≈ pass 4. Diminishing returns → stop. |
The lesson the loop is built on, caught live: the metric peaked at pass 2, but pass 2 is not the best image — its score was inflated by background texture, not apple detail. The winner (pass 4) was chosen by looking. A green number is valid, not correct. (example_apple.png is that pass-4 result.)
…and the other half: when the model is the one that's wrong
The apple shows why you can't trust the metric blindly. This run shows why you can't trust the model blindly — which is the entire reason the ratchet is a tool and not a note in a prompt.
Brief: "a seamlessly tileable cobblestone texture — no visible seam at the wrap,"
with an objective gate (measure_image → tile_seam). Same seed throughout, so each
pass changes exactly one thing. Every texture below is tiled 2×2 — a seam has
nowhere to hide.
Pass | One change |
| Ratchet |
1 | baseline SDXL | h 1.77 · v 1.23 → borderline | kept (first) |
2 |
| h 0.78 · v 1.12 → seamless | NEW BEST |
3 |
| h 1.03 · v 1.56 → seam returns | REVERTED |
On pass 3 the model told loop_record the result was "better". It wasn't:
x_only tiles horizontally and leaves the vertical wrap broken — visible in the
right-hand image as stones chopped flat against the horizontal join. The objective
score overruled the claim, restored pass 2, and handed the good graph back.
That is the failure this server exists to prevent: an agent that wants to be finished will call a regression an improvement. If best-so-far had lived in the model's context instead of on disk, that regression would have been the final answer.
Install
The short version: ask your agent to do it. Paste this into Claude Code (or any MCP client with a shell) and stop there:
Set up the ComfyUI loop MCP from https://github.com/huikku/comfyui-loop-mcp — register it with my client, and install and launch ComfyUI too if it isn't running.
It has everything it needs to finish that without you: registering the server is one
claude mcp add, and once connected, the comfy_install prompt hands back the
bootstrap for your machine — an existing ComfyUI to start, the interpreter to build
the venv from, the torch build your card actually wants, ComfyUI-Manager, and where
to put models. check_comfyui then names anything still missing (no weights, torch
on the CPU, no Manager) as things for the agent to fix, not report.
If you'd rather paste config than prose, this runs the server straight from GitHub
— nothing to clone, nothing to pip install:
{
"mcpServers": {
"comfyui": {
"command": "uvx",
"args": ["--from", "git+https://github.com/huikku/comfyui-loop-mcp", "comfyui-loop-mcp"],
"env": { "COMFYUI_URL": "http://localhost:8188" }
}
}
}Claude Code, one line:
claude mcp add comfyui -- uvx --from git+https://github.com/huikku/comfyui-loop-mcp comfyui-loop-mcpClone the repo instead and .mcp.json is already there — Claude Code
offers the server on first open, no command at all. Reconnect the client after adding
it; MCP servers are read at connect time.
Developing on it:
git clone https://github.com/huikku/comfyui-loop-mcp && cd comfyui-loop-mcp
pip install -e . # or: uv tool install --editable .Requires Python ≥ 3.10 and a reachable ComfyUI. Installs mcp[cli], httpx,
anyio, pillow. Works on both MCP SDK 1.x and 2.x — 2.0 renamed FastMCP
to MCPServer and moved the Image helper, which the server imports either way.
Had this installed as
comfy-mcp? That name belongs to Comfy-Org's server on PyPI, so this one is nowcomfyui-loop-mcp(import packagecomfy_loop, commandcomfyui-loop-mcp). Runpip uninstall comfy-mcpfirst, and update your MCP client config. Loop runs already on disk are found automatically — the old~/.comfy-mcp/runskeeps being used until you pointCOMFY_LOOP_STATE_DIRsomewhere else.
Always-on discipline (Claude Code)
The method also installs as a skill, so it loads on the trigger words instead of waiting to be asked for — ask the agent to do this too, or:
mkdir -p ~/.claude/skills/comfyui-workflows
cp comfy_loop/docs/SKILL.md ~/.claude/skills/comfyui-workflows/Same file the comfy_skill prompt serves, so the skill and the server can't drift.
Config
Env var | Default | Purpose |
|
| Your ComfyUI server |
| repo root above this package | Where the |
|
| Git ref of |
| unset | Set to |
|
| Where the ratchet and ledger live. Falls back to a pre-rename |
Pointing at a remote ComfyUI
ComfyUI usually binds to 127.0.0.1, so a ComfyUI on another machine isn't
reachable across the network by default. Two options:
SSH tunnel (simplest, keeps ComfyUI private): forward the port, then leave
COMFYUI_URLat localhost:ssh -N -L 8188:localhost:8188 your-remote-host # COMFYUI_URL stays http://localhost:8188Bind ComfyUI to the network and point at it directly (only on a trusted network — this exposes an unauthenticated API):
python main.py --listen 0.0.0.0 --port 8188 # COMFYUI_URL=http://<remote-ip>:8188
Use it
In your agent, load the
comfy_loopprompt (or let it read thecomfyui://loop-methodresource) to pull in the full method. If your client injects server instructions, the prefer-looping policy is already active.Give it a goal. It will
check_comfyui→list_nodes/get_node/list_models→ build API-format JSON →submit_workflow→get_result→get_image, then critique and iterate — one change per pass — until it can't name a defect, then present the result for sign-off.
Troubleshooting
"ComfyUI is NOT reachable" — the reply is a set of instructions, not a complaint, and they're addressed to the agent, which has a shell this server doesn't: it looks for a ComfyUI on this machine (
$COMFYUI_PATH, comfy-cli's workspace,~/ComfyUI,~/comfy,~/code,~/github,/opt) and either hands back the start command using that install's own venv python, or the clone + venv + Manager + launch sequence if there is none. IfCOMFYUI_URLis remote it deliberately does not offer to install locally — that just leaves a second, unused ComfyUI on the wrong box — and gives you the SSH tunnel instead. Every tool returns this, not justcheck_comfyui; the advice is attached at the transport.Node/model not found — install the pack/model on the ComfyUI side, then restart ComfyUI so
/object_inforeflects it (the API is stale until then).get_imagereturns nothing — make sure the graph has aSaveImage/PreviewImagenode;get_resultlists what was actually produced.install_node_packblocked / no-op — the install tools need ComfyUI-Manager on the host, and Manager's security level must permit API installs. After installing,restart_comfyuiis required before/object_infoshows the new nodes.find_missing_nodespicks the "wrong" pack — several packs can export a same-named node; resolution takes the first registry match. If an install doesn't provide the class, check the reported pack and install the right one explicitly.
License
MIT.
Maintenance
–Maintainers
–Response time
–Release cycle
–Releases (12mo)
Commit activity
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Servers
- AlicenseBqualityBmaintenanceAn MCP server that bridges AI agents with ComfyUI for automated workflow building, execution, monitoring, and output routing.961MIT
- AlicenseAqualityCmaintenanceMCP server that lets OpenCode (or any MCP-compatible AI coding tool) directly control ComfyUI for AI image generation.142MIT
- AlicenseAqualityAmaintenanceThe MCP server that drafts ComfyUI workflows a human can actually read. It lets coding agents build, repair, port, validate, and run ComfyUI workflows against your own ComfyUI instance, delivering clean, organized, fully-labeled workflows.292MIT
Related MCP Connectors
MCP server for Hailuo (MiniMax) AI video generation
MCP server for Luma Dream Machine AI video generation
MCP server for Flux AI image generation
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/huikku/comfyui-loop-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server