Civitai Get Image Metadata (JSON)

Think of this as the "raw" version of Civitai Get Image Metadata. That node hand-picks seventeen fields and breaks them into typed outputs; this one takes the same API response and hands it to you whole - a single pretty-printed JSON string containing everything Civitai knows about that image. If you're building anything that consumes Civitai data programmatically, or you want a field the other node doesn't bother to surface, this is the one you want.

The inputs and output

Same two inputs as its sibling: image_id (INT, required) and max_rating (required, default XXX, one of PG / PG-13 / R / X / XXX). One output: metadata_json (STRING), the full image item from Civitai's REST API, serialized with two-space indentation and unicode preserved - so non-ASCII prompts come out readable, not \u-escaped garbage.

The mechanism is identical to the other metadata node: a single public call to /api/v1/images?imageId=... with withMeta=true, flatMeta=true, withTags=true. No API key strictly required.

Why you'd reach for the JSON version over the typed one

Three reasons.

1. Future-proofing. Civitai adds fields to its API responses on its own schedule. The typed node has to be updated to expose each new field; the JSON node can't go stale - anything new just appears inside the blob. That matters more than it sounds, because Civitai's API is a moving target and this pack is small and young.
2. Anything the sibling misses. The typed node surfaces generation params, tags, stats and basic image context. The JSON dump also includes the full modelVersionIds, whatever nested meta extras exist, image metadata like palette or hash data, and every other key the API returned - including ones nobody's documented yet.
3. Machines, not eyeballs. If you're piping metadata into a JSON parse node, a file, or an LLM prompt, a single string is far easier to work with than seventeen scattered wires.

Because it's an output node, the natural graph is: image_id from a primitive → Civitai Get Image Metadata (JSON) → text display node (or save-to-file node) to actually see it. There's a real inspection workflow there: run it on a great sample image and you get the entire recipe plus the platform's view of that image, all in one readable block.

Where people get burned

The same rating-gate behavior as the typed node: if the image exceeds your max_rating, the API returns nothing and you get an error explaining the image exists but is gated higher - bump max_rating if that's fine for your use case. And an image_id of 0 returns {} rather than erroring, which is a quiet trap if you expected real data. The "dump everything" philosophy also means the JSON can be large and includes fields you didn't ask for - that's the point, but don't feed the whole thing to a context-limited model without trimming.

Installing it

ComfyUI Manager, search ComfyUI Civitai MCP, or:

cd ComfyUI/custom_nodes
git clone https://github.com/daceheg/ComfyUI-civitai-mcp.git

Restart after. Only dependency is requests; no models to download, no key needed for this node.