If you already live inside Cursor, the fastest image workflow is not another browser tab — it is asking your editor to generate or edit an image while it still has the context of the code, copy, and UI you are building.
What you can do
Flux MCP is a small but practical setup: it exposes Flux image tools to Cursor through the Model Context Protocol. Once configured, you can ask Cursor to create assets while you are working on a product surface, README, landing page, or design prototype.
The source document describes two available tools:
| Tool | Use case |
|---|---|
flux_generate_image |
Text-to-image generation |
flux_edit_image |
Image editing |
That means you can keep common builder tasks close to your project:
- generate several visual directions for an empty state illustration;
- refine the most promising image with a higher-quality pass;
- edit an existing background or image without starting from scratch;
- batch-generate a small set of consistent avatars or UI assets.
This is not meant to replace a full design system or a designer's review. It is most useful in the messy middle: when you need something concrete enough to unblock a UI decision, a prototype, or a draft.
How it works
Cursor can talk to MCP servers through a local project configuration file. For Flux, the documented server is an HTTP MCP endpoint:
https://flux.mcp.acedata.cloud/mcp
Authentication is passed with a bearer token in the Authorization header. The minimal Cursor configuration from the documentation is:
{
"mcpServers": {
"flux": {
"type": "http",
"url": "https://flux.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer yourToken"
}
}
}
}
In a Cursor project, place this in:
.cursor/mcp.json
Replace yourToken with your Ace Data Cloud API token. The same source notes that a single token can be used across MCP servers, so you do not need a separate token just for Flux.
A practical security note: avoid committing .cursor/mcp.json if it contains a real token. Add it to .gitignore, or use a team-approved secret-management pattern if your workflow supports one.
Step 1: Configure Cursor
Create the MCP config file at the root of your project:
mkdir -p .cursor
cat > .cursor/mcp.json <<'JSON'
{
"mcpServers": {
"flux": {
"type": "http",
"url": "https://flux.mcp.acedata.cloud/mcp",
"headers": {
"Authorization": "Bearer yourToken"
}
}
}
}
JSON
Then open Cursor and check that the MCP server is available in the editor's MCP/tooling area. The exact UI may change over time, but the important pieces are stable: server name flux, type http, URL https://flux.mcp.acedata.cloud/mcp, and the Authorization bearer header.
For other editors, the document points to similar configuration patterns: VS Code uses .vscode/mcp.json with the same configuration under servers, while Windsurf uses .windsurf/mcp.json under mcpServers.
Step 2: Generate quick visual directions
The best first use case is fast iteration. Suppose you are building an app screen with an empty state and the page currently feels unfinished. Instead of leaving a gray placeholder, ask Cursor for multiple directions:
Use flux-dev to quickly generate 3 different styles of "no data" empty state illustrations, trying flat, 3D, and hand-drawn styles.
The documentation describes Dev mode as the fastest path for trial and error. The point is not to get the final asset immediately. The point is to compare directions while you are still thinking about the component, the surrounding copy, and the audience.
Once one direction feels right, you can ask for a refinement pass:
Use flux-pro to refine the second image, increasing the resolution.
This two-step pattern keeps the workflow efficient: use a quick pass to find the visual idea, then spend the slower/high-quality step only on the candidate that deserves it.
Step 3: Edit an existing image
Image generation is useful, but editing is often more practical in real product work. Maybe a designer sent you a background image, but the center title needs to be changed for an English prototype. The documented tool for this is flux_edit_image.
A natural instruction might look like this:
Edit this image, changing the Chinese title in the middle to "Welcome to the Future."
This is where having the tool inside Cursor helps. You can keep the task connected to the current feature branch: the asset, the component copy, the README, or the issue you are working from.
Be specific when you ask for edits. Mention what should change, what must stay the same, and where the change should happen. For example: “keep the background and lighting, only replace the centered title text.” That reduces accidental regeneration.
Step 4: Batch small assets
Another documented scenario is batch image generation. If your app needs default avatars for a user system, you can ask for a consistent set in one go:
Generate 5 minimalist geometric style avatars, each with a different color combination, circular cropped.
The source document notes that the count parameter can generate multiple images at once, which is useful when consistency matters. For UI work, I like to include constraints such as “same visual style,” “different color combination,” and “circular cropped” so the output is easier to drop into a mockup.
A few builder tips
Treat Flux MCP as an iteration tool, not a magic finalizer. Start broad, compare options, then refine. Keep prompts close to the product context: who the screen is for, where the asset appears, and what should not change. And when a generated image becomes part of production work, review it the same way you would review copy or code.
If you want the original setup details, the Ace Data Cloud document is here: https://platform.acedata.cloud/documents/cursor-mcp-flux
Top comments (1)
Remote MCP tools are powerful, but the trust boundary changes a lot compared with local tools. The setup question is not only "can Claude call it?" but also "what can this server see, mutate, and log?"
I like starting with read-only tools, explicit scopes, and a small task-specific toolset. If every remote capability is always loaded, the agent has too much authority and too much choice at the same time.