Skip to main content
Glama
thenavidm

Firefly MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Fill image

generative_fill

Generate content for selected areas of an image using Adobe Firefly, producing output URLs and optional variations.

Instructions

Fill image. Consumes Firefly Services credits. Returns Adobe output URLs. Set wait=false to return an async job.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nNoCompatibility alias for numVariations. Do not supply both.
maskNoRequired. Selected areas of a background image that Firefly uses to fill the source image.
sizeNoThe desired width and height for the final expanded image in pixels. The supported sizes for the output images are: Square (1:1) - width 2048px, height 2048px Square (1:1) - width 1024px, height 1024px Landscape (4:3) - width 2304px, height 1792px Portrait (3:4) - width 1792px, height 2304px Widescreen (16:9) - width 2688px, height 1536px (7:4) - width 1344px, height 768px (9:7) - width 1152px, height 896px (7:9) - width 896px, height 1152px .
waitNoWait for completion, default true. Set false to return the job immediately.
imageNoThe image to expand. Use a URL or an uploadID as the source for the image. Firefly only allows these listed domains for input URLs in the request: amazonaws.com windows.net dropboxusercontent.com storage.googleapis.com .
seedsNoArray of seed image IDs. These reference images help ensure consistent image generation across multiple API calls. For example, you can use the same seed to generate a similar image with different styles. If specified along with numVariations, the number of seeds must equal numVariations.
widthNoCompatibility alias: provide together with height instead of size.
heightNoCompatibility alias: provide together with width instead of size.
promptNoAn optional text prompt up to 1024 characters. The longer the prompt the better Firefly performs.
confirmNoMust be true to spend Firefly Services credits for the operation the user requested.
maskUrlNoCompatibility URL alias for mask.source.url.
downloadNoDownload completed media to FIREFLY_OUTPUT_DIR, default false. Requires wait=true.
imageUrlNoCompatibility URL alias for image.source.url.
numVariationsNoGenerate this number of variations. numVariations defaults to the number of seed images, or to 1 if you do not specify seeds.
negativePromptNoAn optional text prompt up to 1024 characters. Avoid these characteristics in the generated image. Not supported for Firefly Custom Models on Image Model 3 or Firefly Custom Models on Image Model 4.
promptBiasingLocaleCodeNoA hyphen-separated string combining the ISO 639-1 language code and the ISO 3166-1 region, such as en-US. When a locale is set, the prompt will be biased to generate more relevant content for that region. The locale will be auto-detected if not specified based on your profile and the accepted language header.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

B3.2/5.0
Behavior4/5

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

Annotations cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower, and the description still contributes non-obvious traits: credit consumption, an output-URL return shape, and an async mode via wait=false. It does not say whether credits are consumed on failure or how long async jobs persist, but the additions are genuinely beyond the structured fields.

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?

Three terse sentences, front-loaded with cost and return-shape information before the async hint. Only waste is the opening 'Fill image,' which merely echoes the title. No padding or hedging.

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?

For a 16-parameter, fully schema-documented, no-output-schema tool, the description covers the two things the schema cannot: return shape (Adobe output URLs) and credit cost. It omits any routing against the 13 siblings, which is the main remaining gap, but nothing needed to invoke a call correctly is missing.

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 schema already documents all 16 parameters in detail (aliases, size presets, deprecated image.mask, confirm). The description adds only the wait=false semantics, which the schema also states. Baseline 3 is appropriate when the schema carries the parameter burden.

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

Purpose3/5

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

The opener 'Fill image' is verbatim the title, so it is close to tautological, and it never explains what 'fill' means operationally (masked-area inpainting/expansion) nor how it differs from siblings like generative_expand, generate_similar, or precise_composite. The description does add that it consumes Firefly credits and returns Adobe output URLs, which gives some concrete scope. An agent cannot confidently distinguish this tool from other image-generation siblings on the strength of the text alone.

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

Usage Guidelines2/5

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

The only usage cue is 'Set wait=false to return an async job,' which is a mode switch rather than selection guidance. There is no statement of when to choose this tool over generative_expand or the composite tools, no prerequisites, and no exclusion conditions despite 13 siblings competing for the same intent. Cost awareness ('consumes credits') is implied but not framed as a decision factor.

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