Skip to main content
Glama
Sign In
FluxMCP

FluxMCP

by AceDataCloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

flux_edit_image

Edit existing images using text prompts to modify specific elements, add or remove objects, and apply style changes.

Instructions

Edit an existing image using Flux with a text prompt.

This allows you to modify an existing image based on a text description.
The kontext models (flux-kontext-pro, flux-kontext-max) are specifically
designed for high-quality image editing and style transfer.

Use this when:
- You want to modify or transform an existing image
- You want to change specific elements in an image
- You want to apply style changes or artistic effects
- You want to add, remove, or replace objects in an image

For generating new images from scratch, use flux_generate_image instead.

Returns:
    Task ID and edited image information including URLs.

Input Schema

NameRequiredDescriptionDefault
sizeYesRequired output size. Kontext and flux-2-flex/pro/max require aspect ratios such as '1:1' or '16:9'; flux-dev/pro also accept documented pixel presets.
modelNoFlux model to use for editing. Recommended models for editing: - flux-kontext-pro: Best for context-aware editing and style transfer (recommended) - flux-kontext-max: Maximum context for complex edits - flux-dev: Basic editing support flux-2-flex/pro/max also support editing. flux-2-klein supports generation only.flux-kontext-pro
promptYesDescription of how to edit the image. Be specific about what changes to make. Examples: 'Change the background to a sunset beach', 'Add sunglasses to the person', 'Make it look like a watercolor painting', 'Replace the car with a bicycle'
image_urlYesURL of the image to edit. Must be a direct image URL (JPEG, PNG, etc.), not a web page containing an image.
callback_urlNoWebhook callback URL for asynchronous notifications.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.16
    • changedInput schema / properties / model / description
      Previous value: -"Flux model to use for editing. Recommended models for editing:\n- flux-kontext-pro: Best for context-aware editing and style transfer (recommended)\n- flux-kontext-max: Maximum context for complex edits\n- flux-dev: Basic editing support\nOther models also support editing but kontext models give best results."New value: +"Flux model to use for editing. Recommended models for editing:\n- flux-kontext-pro: Best for context-aware editing and style transfer (recommended)\n- flux-kontext-max: Maximum context for complex edits\n- flux-dev: Basic editing support\nflux-2-flex/pro/max also support editing. flux-2-klein supports generation only."
    • changedInput schema / properties / model / enum
      Previous value: -[
-  "flux-dev",
-  "flux-pro",
-  "flux-kontext-pro",
-  "flux-kontext-max",
-  "flux-2-flex",
-  "flux-2-pro",
-  "flux-2-max",
-  "flux-2-klein"
-]New value: +[
+  "flux-dev",
+  "flux-pro",
+  "flux-kontext-pro",
+  "flux-kontext-max",
+  "flux-2-flex",
+  "flux-2-pro",
+  "flux-2-max"
+]
    • changedInput schema / properties / size / description
      Previous value: -"Required output image size. For kontext models: aspect ratios like '1:1', '16:9'. For other models: pixel dimensions like '1024x1024'."New value: +"Required output size. Kontext and flux-2-flex/pro/max require aspect ratios such as '1:1' or '16:9'; flux-dev/pro also accept documented pixel presets."
  2. Changed5 schema fields changedv0.1.9
    • removedInput schema / properties / size / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / size / default
      Removed value: -null
    • changedInput schema / properties / size / description
      Previous value: -"Output image size. For kontext models: aspect ratios like '1:1', '16:9'. For other models: pixel dimensions like '1024x1024'."New value: +"Required output image size. For kontext models: aspect ratios like '1:1', '16:9'. For other models: pixel dimensions like '1024x1024'."
    • addedInput schema / properties / size / type
      Added value: +"string"
    • changedInput schema / required
      Previous value: -[
-  "prompt",
-  "image_url"
-]New value: +[
+  "prompt",
+  "image_url",
+  "size"
+]
  3. Changed1 schema field changedv0.1.7
    • changedInput schema / properties / model / enum
      Previous value: -[
-  "flux-dev",
-  "flux-pro",
-  "flux-kontext-pro",
-  "flux-kontext-max",
-  "flux-2-flex",
-  "flux-2-pro",
-  "flux-2-max"
-]New value: +[
+  "flux-dev",
+  "flux-pro",
+  "flux-kontext-pro",
+  "flux-kontext-max",
+  "flux-2-flex",
+  "flux-2-pro",
+  "flux-2-max",
+  "flux-2-klein"
+]
  4. Addedv0.1.3
  5. Removedv0.1.2
  6. First observedv0.1.0

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It does disclose that the call is asynchronous by returning a 'Task ID' plus image URLs, which is real value beyond the schema, but it omits what an agent most needs here: that the task must be polled via the sibling flux_get_task, and whether the source image is modified or a new output is produced. Permission, cost, and rate-limit behavior are also unaddressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is front-loaded with the core action and uses a scannable bullet list for use cases plus a clear Returns section. The second sentence ('This allows you to modify an existing image based on a text description') largely restates the first and could be cut, costing it a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the Returns section is a bonus rather than a necessity, and the sibling routing is handled. The one meaningful gap for a five-parameter, async, generation-billed tool is the absence of any pointer that results are retrieved with flux_get_task, leaving an agent to infer the polling workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters — including model choices, aspect-ratio sizing, and the callback webhook — are already fully documented in structured fields. The description adds nothing parameter-specific beyond reiterating that the kontext models suit editing, which the model enum description already states. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line states a specific verb and resource ('Edit an existing image using Flux with a text prompt') and the closing line explicitly distinguishes it from the sibling flux_generate_image. An agent can route between editing and generation without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides an explicit 'Use this when' list covering the main edit intents (transform, element changes, style transfer, object add/remove/replace) and names the alternative tool for the generation case. Both when-to-use and when-not-to-use are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools