How to Generate and Edit Images from Claude Code with Flux MCP

A developer documented a workflow for adding Flux MCP to Claude Code, enabling image generation and editing directly from the terminal via two tools, flux_generate_image and flux_edit_image, exposed over an HTTP transport server at flux.mcp.acedata.cloud. The setup uses the claude mcp add command with a Bearer token header and supports local, user, and project scopes, with the author warning that project scope writes configuration into .mcp.json and tokens should not be committed to public repositories.

A lot of developer work needs small but polished visuals: a cover for a technical post, an illustration for a docs page, or a corrected poster where only one detail changed. The annoying part is that image work often pulls you out of the terminal, even when the rest of the task is already happening in Claude Code. Flux MCP is a practical way to keep that visual step inside the same coding workflow. You configure one MCP server, verify it once, and then ask Claude Code to generate or edit images with natural language. The Flux MCP setup documented by Ace Data Cloud gives Claude Code two image tools: | Tool | What it does | |---|---| | flux generate image | Text-to-image generation | | flux edit image | Image editing | The same document describes three Flux model directions you can use from Claude Code: That maps well to real builder work. You can quickly try a few blog-cover directions, choose one, regenerate it with more detail, and later fix a small piece of text or layout in an existing image. Flux MCP is added to Claude Code as an HTTP transport server: https://flux.mcp.acedata.cloud/mcp Authentication is passed through a header: Authorization: Bearer YOUR ACEDATACLOUD API KEY A local project setup looks like this: claude mcp add flux --transport http https://flux.mcp.acedata.cloud/mcp \ -H "Authorization: Bearer YOUR ACEDATACLOUD API KEY" \ -s local Notice the uppercase -H . In Claude Code, lowercase -h means help, so a tiny flag typo can make the command behave very differently from what you intended. The documented scopes are: local : bound to the current project directory; user : visible across projects on your machine; project : written into .mcp.json for the current project. For most experiments, I would start with local . It gives you a low-risk way to test the workflow in one repository before deciding whether it belongs in your global Claude Code setup. From the project where you want to use image generation, run: claude mcp add flux --transport http https://flux.mcp.acedata.cloud/mcp \ -H "Authorization: Bearer YOUR ACEDATACLOUD API KEY" \ -s local If you expect to use Flux across many projects, switch only the scope: claude mcp add flux --transport http https://flux.mcp.acedata.cloud/mcp \ -H "Authorization: Bearer YOUR ACEDATACLOUD API KEY" \ -s user For a team project, you can use project scope: claude mcp add flux --transport http https://flux.mcp.acedata.cloud/mcp \ -H "Authorization: Bearer YOUR ACEDATACLOUD API KEY" \ -s project Be careful with that last option. Project scope writes configuration into .mcp.json in the project root. The config may be useful for a private team repo, but the real token should not be committed to public repositories, issues, screenshots, or chat logs. Use placeholders or have each person add their own token locally. When Claude Code reads a project-level config for the first time, it may show Pending approval . That is a normal trust prompt, not necessarily a Flux problem. Before asking for images, check the server status: claude mcp list You want flux to show ✓ Connected . If it fails, check the three most boring things first: Authorization: Bearer , /mcp , This is faster than debugging prompts or assuming a model issue. If the MCP handshake is not connected, Claude Code cannot call the tools reliably. When the visual direction is unclear, start with fast drafts. The source document gives this example: Use flux-dev to quickly generate 3 different styles of developer blog cover images, trying flat, realistic, and abstract styles That is a good pattern because it asks for comparison, not perfection. In a real docs workflow, I would add context from the file I am editing: Use flux-dev to generate 3 cover directions for this tutorial page. Keep the style technical, dark, and minimal. Try flat, realistic, and abstract variants. Once you see the directions, pick the strongest one instead of trying to force the first image to be perfect. After a draft works, regenerate the chosen direction with more detail. The documented example is: Use flux-pro to regenerate the second image, increasing details and resolution This two-step approach is useful because it separates taste decisions from final rendering. You do not spend effort polishing an image direction that might be wrong for the post, README, or landing page. Flux MCP is not only for new images. The documented flux edit image workflow supports local edits to an existing image. The example is: Edit this poster image, changing the date in the bottom right corner from 2024 to 2025 For developer content, this can be more useful than full regeneration. You might need to update a date, remove stale text, or adjust a small visual detail without changing the whole composition. Here is the workflow I would use for a real tutorial or release note: flux generate image with Dev-style exploration for 2–3 directions. flux edit image instead of starting over. The value is not that every visual becomes automatic. The value is that the image task stays close to the code, copy, and context that created the need for the image in the first place. Start with local , verify with claude mcp list , and keep tokens private. Use Dev for exploration, Pro for the final version, and Kontext when an existing image only needs a targeted edit. The full setup notes are in the official Ace Data Cloud Flux MCP document https://platform.acedata.cloud/documents/claude-code-mcp-flux .