DEV Community: Xuxuan Zhou

Why generate images through MCP instead of a standalone web UI

Xuxuan Zhou — Tue, 15 Sep 2026 14:01:19 +0000

Every image generator has a prompt box. You type what you want, click generate, and inspect the result. It works. But when you're already deep in a conversation with an AI assistant — describing a product, iterating on a brief, planning a campaign — switching to a separate web UI means reconstructing context that already exists.

This article compares two approaches to the same creative task: using a standalone image generator, and using one connected to your AI conversation through MCP. I build Claude Imagine, a remote MCP service for image and video generation. It isn't affiliated with Anthropic.

The context problem

Here is a common scenario. You're in Claude, discussing a product campaign for a skincare brand. You've described the brand's color palette, the bottle shape, the mood you want. Now you need an image.

With a standalone web UI, you:

Open Midjourney, DALL-E, or another generator in a new tab
Write a new prompt from scratch, re-describing everything you just discussed
Guess at the right parameters — aspect ratio, style, negative prompts
Generate, download the result
Return to your conversation, paste the image or describe what you got
Repeat for every revision

With MCP, you:

Say "generate a product image based on what we just discussed"
The assistant already has the brief, the brand details, the mood — it constructs the prompt
The result appears in the conversation
Say "change the background to pale pink" — the assistant references the previous image automatically

The difference isn't just fewer clicks. It's that the assistant has been part of the creative discussion from the start. It doesn't need you to re-explain.

What "context-aware" means in practice

In our September 5 test, we described a fictional skincare brand called LUMA in Chinese — the bottle material, the stone pedestal, a lime as a prop, soft studio lighting. Claude translated the creative brief into generation parameters without asking us to restate anything in a specific prompt format.

Three things happened that wouldn't in a standalone tool:

1. Language didn't matter. We described the scene in Chinese. Claude constructed the English prompt for the image model. A web UI would require you to write the prompt in the model's expected language yourself.

2. The edit referenced the previous result automatically. When we asked to change the background to pale pink, Claude's edit_image call used the CDN address of the first generation. No download, no re-upload, no copy-pasting a file URL.

3. The video used the edited image without manual handoff. Converting the revised image to a 4-second video meant Claude called generate_video with the edit's output address. In a web workflow, this would be: download edited image → open video tool → upload → configure → generate.

Step	Standalone web UI	MCP in conversation
Describe what you want	Write a new prompt from memory	Assistant already has the brief
Choose parameters	Navigate model settings manually	Assistant maps your words to API params
Edit	Download → re-upload to editor	"Change the background" — previous file referenced
Image → video	Download → open video tool → upload	"Turn this into a short clip" — file address carried over
Track cost	Check account after generating	Ask for a quote before, set a cap, verify after

The cost control difference

This is undersold. With most web UIs, you click "generate" and discover the cost afterward — or you check a pricing page and do the math yourself.

Through MCP, the assistant can call quote_generation before spending anything. In our test, we asked Claude to quote the cost and confirm our balance. Then we set max_credits to 3 on the generation call. If the price exceeded that, the request would stop without generating.

Use Claude Imagine to quote one nano-banana-2 image at 9:16.
Tell me the cost and my balance. Don't generate yet.

This isn't just a convenience. It's a programmatic guard. The max_credits parameter rejects a single call that exceeds the cap. A web UI has no equivalent of "refuse to run if it costs more than X."

When the web UI is still better

A standalone tool wins when you want:

Visual prompt builders: Midjourney's style references, DALL-E's editing canvas, and ComfyUI's node graphs are purpose-built interfaces. A text conversation can't replicate drag-and-drop composition.
Batch exploration: Generating a grid of 4 variations at once and visually comparing them side by side is faster in a dedicated UI than asking an assistant to generate and display them sequentially.
Community galleries: Browsing what others have made, remixing public prompts, and discovering styles — these are social features that live in web platforms.
Real-time preview: Painting over a region, adjusting a mask, or using ControlNet guidance requires a graphical interface.

MCP doesn't replace visual editing tools. It replaces the copy-paste-switch-tab-rewrite-prompt loop that breaks your working context.

How MCP connects technically

For developers: MCP (Model Context Protocol) is Anthropic's open standard for connecting AI assistants to external tools. A remote MCP server exposes tools — functions the assistant can call — via a standardized protocol. Claude Imagine exposes tools like generate_image, edit_image, generate_video, quote_generation, and list_generations.

The assistant sees these tools and their parameter schemas. When you describe what you want, it maps your natural language to tool calls. The generation happens server-side; the result (image URL, cost, task ID) returns to the conversation.

This means any MCP-compatible client — claude.ai, Claude Desktop, Claude Code, or third-party clients — can use the same service without a separate integration per platform.

A practical test you can run

If you want to compare the two approaches yourself:

Pick a simple creative task — a product shot, a blog cover, an illustration
First, do it in your preferred standalone generator. Note how long the prompt takes to write and how many tabs you switch between
Then connect Claude Imagine as a custom connector in Claude and try the same task in conversation. Describe what you want in your own words
Compare: which felt like less friction? Where did each approach do better?

The connection address for Claude's custom connectors:

https://claudeimagine.com/api/mcp

The point isn't that one is categorically better. It's that they serve different moments in a workflow. When you're already talking to an AI assistant about your project, switching to a separate tool to create an image is a context break that MCP eliminates.

Disclosure: I build Claude Imagine. This article was prepared with AI assistance, using our recorded product tests from September 2026.

Generate an image in Claude with a remote MCP connector

Xuxuan Zhou — Wed, 09 Sep 2026 12:41:52 +0000

Connect Claude Imagine to Claude, check the price of one image, then generate it with a credit cap. The example here is a product shot for a fictional skincare brand called LUMA.

In our September 5 Claude Desktop test, we asked for a vertical product image using Nano Banana 2. The request cost 3 credits, and the image appeared in an embedded card in the conversation.

Disclosure: I build Claude Imagine, the independent service used here. It isn't affiliated with Anthropic.

AI-generated example from our September 5 test. LUMA is a fictional product. This is the output image, not a screenshot of Claude.

Connect the service

Claude handles the conversation and the tool request. Claude Imagine sends the image request to an image-generation model. You'll need accounts for both services; their usage balances are separate.

In Claude, find Customize → Connectors, choose Add custom connector, and enter:

https://claudeimagine.com/api/mcp

Name it Claude Imagine. Add the connector, then use Connect if authentication hasn't started. Sign in to Claude Imagine and approve the connection. Enable it for the conversation if necessary.

Menu labels can change. Anthropic maintains the current custom-connector instructions, including organization setup. Our September 5 generation test used an already connected Claude Desktop account; it didn't repeat account registration.

Ask for the cost first

Start with a request that doesn't create anything:

Use Claude Imagine to list the available image models and check my balance.
Quote one nano-banana-2 text-to-image generation at 9:16.
Don't generate an image yet.

The relevant tools are list_models, get_credits, and quote_generation. The quote should tell you the cost and whether your account can use the requested model.

Our recorded image cost 3 credits. Treat that as the cost of that test, not a permanent price promise. Check the quote returned for your account before continuing.

Generate one image

Here is a starter prompt for the same type of task. It's a reusable brief, not a transcript of the original test:

Generate exactly one image using Claude Imagine and nano-banana-2 at 9:16.
Set max_credits to 3. If the request costs more, stop.

Create a product image for a fictional skincare brand named LUMA.
Place one bottle on a stone plinth, with a lime nearby and soft studio light.
Use a simple background and leave space above the bottle for a future headline.
Don't add a headline to the image.

Show the result using the available image card and include the original file link.
Don't generate alternatives or video.

Approve the tool call if Claude asks. The max_credits value caps this individual request; it doesn't create a shared budget for future edits. If the quote exceeds the cap, choose a different model or deliberately change your budget.

Check the result you actually received

In our Desktop test, the result appeared in an embedded card with an original-image link. That observation doesn't establish the same rendering behavior in Claude Code, mobile, or every web-client version.

On September 8, we ran a separate English-language test in claude.ai: one new LUMA image with Nano Banana 2 at 16:9. Claude quoted 3 credits before generation and reported the same cost afterward. The finished image appeared in the conversation.

Actual claude.ai screenshot, September 8. This AI-generated 16:9 image is a separate result from the September 5 vertical image above. The prompt shown in the card differs from the starter template. The screenshot is cropped to leave out private account details.

Check the tool result if you don't immediately see the preview. Keep the original link as well. If the file exists but the preview is missing, don't immediately ask Claude to generate again: retrieving a result and creating a second image are different operations.

Inspect the image before using it. Product labels, bottle shape, and spacing need a visual check. A completed tool call confirms that a file was produced; it doesn't confirm that the image meets your brief.

Once the first image works, you can try a separate edit. In our test, changing the background used edit_image with the previous result's address, so we didn't download and re-upload the image. That edit was another paid operation.

The Claude Imagine website has the connector setup and account access. Save the first result before expanding the workflow.

Diagnosing a Broken STL File: Union-Find, Boundary Loops, and SDF Voxel Rebuilds

Xuxuan Zhou — Tue, 14 Jul 2026 14:07:24 +0000

A lot of 3D files are quietly broken. Not "won't open" broken — they load fine in a viewer, look like a normal model, and then a slicer either rejects them outright or silently produces garbage: missing walls, phantom internal cavities, infill leaking out through a gap you can't see. This happens constantly with AI-generated meshes and phone LiDAR scans, and it's rare enough with hand-modeled CAD files that most tutorials don't cover it well.

We've spent the last few months building MeshRefinery, a mesh repair and format-conversion tool, and the interesting part turned out to be less "how do you fix a hole in a mesh" and more "how do you even define broken, and how do you fix it without a full watertight-reconstruction pipeline when you don't need one." This post walks through both the cheap, entirely-client-side repair pass and the expensive, guaranteed-correct one, plus a color-preservation trick that isn't really about repair at all.

Originally published on the MeshRefinery blog.

What "broken" means to a slicer

A mesh is a soup of triangles. A slicer needs it to describe a closed volume — for every point in space, "inside" or "outside" has to be unambiguous. Three properties matter:

Watertight: no boundary edges. Every edge of every triangle should be shared by exactly one other triangle.
Manifold: no edge shared by more than two triangles. If three or more faces meet at an edge, "inside vs outside" stops being well-defined there.
Consistent winding / single shell where expected: disconnected fragments (common in AI output — dozens of tiny floating shards) confuse a slicer's part detection.

You get all of this from one structure: an edge → face-count map.

function buildEdgeMap(indexArr: ArrayLike<number>) {
  const edgeMap = new Map<string, { count: number; faces: number[] }>();
  const faceCount = indexArr.length / 3;
  for (let f = 0; f < faceCount; f++) {
    const [a, b, c] = [indexArr[f * 3], indexArr[f * 3 + 1], indexArr[f * 3 + 2]];
    for (const [v1, v2] of [[a, b], [b, c], [c, a]] as const) {
      const key = v1 < v2 ? `${v1}_${v2}` : `${v2}_${v1}`;
      const info = edgeMap.get(key) ?? { count: 0, faces: [] };
      info.count++;
      info.faces.push(f);
      edgeMap.set(key, info);
    }
  }
  return edgeMap;
}

Count == 1 → boundary edge (a hole). Count > 2 → non-manifold. Count == 2 → fine. Run a union-find over faces connected by manifold edges and you get shell count for free — which doubles as an AI-slop detector: a model with 40+ disconnected components is almost never a real 40-part assembly, it's floating debris from generation noise.

One catch that eats a surprising amount of debugging time: STL doesn't share vertices. Every triangle stores three fresh corner points, so two triangles that meet at an edge in space have geometrically-identical-but-distinct vertex indices. Run edge analysis on raw STL data and everything looks like a boundary edge, because nothing is technically shared. You have to weld coincident vertices first, within a tolerance — and the tolerance has to scale with the model, not be a fixed epsilon:

const WELD_TOLERANCE_RATIO = 2e-5; // relative to bbox diagonal
const tolerance = Math.max(diag * WELD_TOLERANCE_RATIO, 1e-6);

A fixed epsilon either welds legitimate close-but-distinct vertices on a tiny model, or fails to weld numerically-fuzzy duplicates on a large one. Scaling to the bounding-box diagonal fixes both.

Tier 1: light repair, entirely in the browser

MeshRefinery's free tool runs this in-browser with three.js, no upload required — the file never leaves the client. The pipeline, in order:

Weld coincident vertices (above).
Drop degenerate faces — zero-area triangles, detected via the cross-product area test. Harmless but they pollute every downstream step.
Remove floating fragments — union-find shell detection, drop any shell under ~0.5% of total face count. This is the AI-slop cleanup: keep the model, discard the noise.
Fan-fill small holes.

Hole filling is the fiddly part. You can't just connect arbitrary boundary vertices — you need the loop, walked in the winding order the surrounding surface already uses, so the new triangles come out facing the right way. The trick: build a directed boundary-edge map instead of an undirected one. Each boundary edge belongs to exactly one face, so record it in that face's winding direction; the resulting map is a set of v1 -> v2 pointers that chain into a loop automatically:

function traceLoops(nextMap: Map<number, number>, maxLoopSize: number) {
  const visited = new Set<number>();
  const loops: number[][] = [];
  for (const start of nextMap.keys()) {
    if (visited.has(start)) continue;
    const loop = [start];
    visited.add(start);
    let cur = nextMap.get(start);
    while (cur !== undefined && cur !== start) {
      loop.push(cur);
      visited.add(cur);
      cur = nextMap.get(cur);
    }
    if (cur === start && loop.length >= 3 && loop.length <= maxLoopSize) loops.push(loop);
  }
  return loops;
}

Each closed loop under the size cap gets a centroid vertex and a triangle fan. Cheap, and it's honestly all you need for the vast majority of "AI mesh has a few small gaps" cases.

It is explicitly not a general watertight guarantee. Fan-filling from a centroid works for small, roughly-planar loops. It does nothing useful for a hole with saddle topology, or one large enough that a flat fan would self-intersect, or a mesh that's non-manifold in ways no amount of hole-filling touches. Being honest about that boundary in the product copy — "this cleans up the common stuff, it will not rescue a genuinely broken mesh" — mattered more to user trust than we expected going in.

Tier 2: when fan-filling isn't enough

For anything harder, the paid path throws away the fan-fill approach entirely and rebuilds the surface from a signed distance field:

Generalized winding number (via libigl) to classify points as inside/outside — this is the part that makes the whole approach robust to non-manifold and disconnected input; unlike ray casting, it degrades gracefully instead of returning garbage on bad topology.
Evaluate that at every point on a voxel grid, turn it into a signed distance field (Euclidean distance transform, outside − inside), Gaussian-smooth it.
Marching cubes over the SDF's zero-isosurface produces a brand-new, watertight, manifold mesh — by construction, not by patching.
Drop any voxel-noise fragments under the same 0.5% face-count threshold as before, fix normals, and run a few iterations of Taubin smoothing to knock down the voxel staircasing without shrinking the volume the way naive Laplacian smoothing would.

The tradeoff is real: you lose the original vertex positions and any UV/vertex-color data, because you have an entirely new mesh. So the last step is transferring color back — for every new vertex, find the nearest point on the original surface, get its barycentric coordinates within that triangle, and interpolate the original triangle's vertex colors:

closest, dist, tri_id = trimesh.proximity.closest_point(src, dst.vertices)
bary = trimesh.triangles.points_to_barycentric(src.triangles[tri_id], closest)
colors = (src_colors[src.faces[tri_id]] * bary[:, :, None]).sum(axis=1)

And because "trust me, it's fine" isn't a great answer for something as lossy-sounding as a full SDF rebuild, the API also reports fidelity: sample points on the new surface, measure distance back to the original, express it as a percentage of the model's bounding-box diagonal. Mean error is typically well under 1% of diagonal — small enough not to matter for FDM printing, and now a number instead of a vibe.

A repair-adjacent problem: color survives the trip too

This one isn't repair, it's format translation, but it hits the same "the naive version is wrong" pattern. GLB/glTF store color as a PBR base-color texture, not per-vertex color — so a plain geometry load silently drops all color. To carry it into a vertex-colored format, bake the texture: sample the base-color image at each vertex's UV coordinate.

const px = Math.min(w - 1, Math.max(0, Math.floor(u * w)));
const py = Math.min(h - 1, Math.max(0, Math.floor(v * h)));
const p = (py * w + px) * 4;
colors[i * 3] = data[p] / 255;     // R
colors[i * 3 + 1] = data[p + 1] / 255; // G
colors[i * 3 + 2] = data[p + 2] / 255; // B

One color-space gotcha buried in there: baseColorTexture is sRGB-encoded and 3MF colors are sRGB hex, so the raw getImageData bytes map straight through with zero conversion — but three.js's flat material.color is stored linear, so that path needs an explicit convertLinearToSRGB() or flat-colored meshes come out visibly wrong while textured ones look fine. Easy to miss because it only breaks one of the two code paths.

3MF itself is worth a mention: it's just a zip (an OPC package, the same container format DOCX/XLSX use), holding three tiny XML parts — a content-types manifest, a relationships file, and the actual model. Colors go in an <m:colorgroup>, deduped into a palette and referenced per-vertex-per-triangle — that's the exact structure Bambu Studio, PrusaSlicer, and Cura read to drive full-color/AMS printing.

Where this leaves things

Two tiers, two very different engineering budgets: a fast, honest, client-side pass that fixes the common cases for free with zero upload, and a heavier server-side SDF rebuild for the cases that actually need a real watertight guarantee — with a measured fidelity number instead of a promise. If you're dealing with broken meshes yourself, both the diagnosis logic and the format converters are free to try.