adobe-firefly-mcp
This server lets you control Adobe Firefly's web UI through browser automation (Playwright) to generate and edit images/videos, with deep debugging and session management tools.
Image & Video Generation
Generate images (
firefly_generate) — Create images from text prompts with options for aspect ratio, style, content class, negative prompt, and count (up to 4)Generate videos (
firefly_generate_video) — Create videos from text prompts supporting multiple models (Veo, Kling, Firefly Video), resolution, duration, aspect ratio, visual style, camera motion, and seed
Image Editing
Create variations (
firefly_variations) — Upload a local image and generate variations, optionally guided by a promptExpand/outpaint (
firefly_expand) — Outpaint a local image to a new aspect ratio using generative expandRemove backgrounds (
firefly_remove_background) — Automatically remove the background from a local image
Session & Environment Management
Check status (
firefly_status) — Open/check the persistent browser session, view auth state, and take screenshots; used for first-time sign-inVerify environment (
firefly_verify_environment) — Read-only check of the live Firefly page including authentication and credit detailsValidate environment (
firefly_validate_environment) — Comprehensive readiness check (auth, selectors, browser health, credits) returning a 0–100 readiness score with optional auto-fix
Debugging & Diagnostics
Inspect DOM (
firefly_dom_inspect) — Inspect the current page in multiple modes (full, selector, shadow DOM, accessibility tree) with screenshots, network requests, and console messagesWatch DOM mutations (
firefly_dom_watch) — Monitor real-time DOM changes via MutationObserver to track UI eventsCapture debug bundle (
firefly_debug_bundle) — Generate a comprehensive 26+ file diagnostic snapshot including screenshots, HTML, cookies, storage, selector validation, performance metrics, and automation health reports
Resilience Features: Persistent browser profile (sign in once, reused across restarts), self-healing selector recovery when Adobe updates the UI, and explicit error classification (auth, moderation, credit, transient errors).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@adobe-firefly-mcpgenerate a surreal painting of a clock melting in a desert"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
adobe-firefly-mcp
Local MCP server for using Adobe Firefly from Claude Code through Playwright browser automation.
This project is designed for a personal local workflow where you already have access to Adobe Firefly in your browser. It launches a persistent Playwright Chromium profile, lets you sign in manually once, then reuses that profile for future image workflows.
It does not use a private Adobe API, automate login credentials, bypass authentication, or store credentials outside the browser profile.
Features
Image generation — prompt-to-image with aspect ratio, style, and count.
Video generation — prompt-to-video via Veo, Kling, and the first-party Firefly Video model, with reliable download handling.
Image editing — variations, generative expand/outpaint, and background removal from local images.
Persistent Adobe session — sign in once; the profile is reused across restarts.
Resilient automation — ordered selectors, environment overrides, and a self-healing engine that recovers when Adobe changes the UI.
Deep debugging tools — DOM inspection, real-time mutation watching, and a 26+ file diagnostic bundle.
Typed error classification — auth, moderation, credit, and transient backend errors are reported distinctly instead of as opaque timeouts.
Related MCP server: io.github.pvliesdonk/image-generation-mcp
Quick Start
Install from npm:
# 1. Install the server
npm install -g adobe-firefly-mcp
# 2. Install the Chromium build Playwright drives (one-time)
npx playwright install chromiumOr build from source:
# 1. Clone and install
git clone https://github.com/peroxide-dev/adobe-firefly-mcp.git
cd adobe-firefly-mcp
npm install
# 2. Install the Chromium build Playwright drives
npm run install:browser
# 3. Build
npm run buildThen add the server to your MCP client (see Claude Code Configuration) and complete the one-time First Run sign-in. Total time: a few minutes.
Documentation
MCP Tools Reference — every tool and its parameters
Architecture — how the server is put together
Security Policy — session storage and safe handling of
profile/Contributing — dev setup and quality bar
Changelog — release history
Tools
adobe-firefly-mcp exposes these MCP tools:
firefly_generate- prompt-to-image generation.firefly_generate_video- prompt-to-video generation.firefly_variations- upload a local image and ask Firefly for variations.firefly_expand- upload a local image and run Firefly's expand/outpaint workflow.firefly_remove_background- upload a local image and run Firefly's remove-background workflow.firefly_status- open/check the persistent browser profile, auth state, paths, and optional screenshot.firefly_verify_environment- read-only verification of the current live Firefly page, including authentication and visible account/credit details.firefly_dom_inspect- inspect the current DOM state for debugging automation issues.firefly_dom_watch- watch for DOM mutations in real-time.firefly_debug_bundle- capture comprehensive debug bundle with 26+ diagnostic files.firefly_validate_environment- check environment readiness and auto-fix common issues.
Generated files are saved locally and returned as absolute file paths.
Install
Published on npm as adobe-firefly-mcp.
Global install (recommended):
npm install -g adobe-firefly-mcp
npx playwright install chromium # one-time browser downloadRun without installing:
npx adobe-firefly-mcpFrom source:
npm install
npm run install:browser # downloads the Chromium build Playwright drives
npm run buildChromium is required. By default the server drives Playwright's bundled Chromium, which is not downloaded automatically. Run
npm run install:browser(from source) ornpx playwright install chromium(global install) once. If you prefer to reuse your installed Google Chrome and its existing profile, setFIREFLY_USE_PERSISTENT_PROFILE=trueandFIREFLY_USER_DATA_DIRinstead — see Configuration.
Claude Code Configuration
From a source checkout:
{
"mcpServers": {
"adobe-firefly-mcp": {
"command": "node",
"args": ["./dist/server.js"],
"cwd": "/absolute/path/to/adobe-firefly-mcp"
}
}
}From a global install:
{
"mcpServers": {
"adobe-firefly-mcp": {
"command": "adobe-firefly-mcp",
"env": {
"FIREFLY_MCP_DATA_DIR": "/absolute/path/to/.adobe-firefly-mcp"
}
}
}
}On Windows, use escaped backslashes or forward slashes in JSON paths:
"FIREFLY_MCP_DATA_DIR": "C:/Users/you/.adobe-firefly-mcp"First Run
Start Claude Code with the MCP server configured.
Run
firefly_statuswithopenBrowser: true.A Chromium window opens at Adobe Firefly.
Sign in manually with your Adobe account.
Run
firefly_statusagain. The same profile inprofile/will be reused.
firefly_status, firefly_verify_environment, firefly_validate_environment,
firefly_debug_bundle, and the generation tools share the same in-memory
BrowserManager, BrowserContext, and live Page for the lifetime of one MCP
server process. The diagnostic tools do not navigate an already-open page.
The default browser mode is headed (FIREFLY_HEADLESS=false) because the first sign-in must be done by you.
Example Tool Call
Image Generation
{
"prompt": "A cinematic product photo of a translucent blue mechanical keyboard on a polished steel desk",
"aspectRatio": "16:9",
"style": "Photo",
"count": 4
}Video Generation
{
"prompt": "A timelapse of clouds moving over a mountain landscape at golden hour",
"aspectRatio": "Widescreen (16:9)",
"resolution": "720p",
"duration": "8 seconds",
"model": "Veo 3.1 Fast"
}Example Claude prompts for video generation:
"Generate a video of a cat playing with a ball of yarn in slow motion"
"Create a 1080p video of ocean waves crashing on a rocky shore at sunset"
"Make a widescreen video of a busy city street at night with neon lights reflecting in puddles"
"Generate a short video of steam rising from a freshly brewed cup of coffee"
DOM Inspection (Developer Tool)
The firefly_dom_inspect tool is a read-only debugging utility for diagnosing broken automation. It never navigates, clicks, or modifies the page.
Modes
Full mode (default) - Returns everything:
{
"mode": "full"
}Selector mode - Inspect specific elements:
{
"mode": "selector",
"selector": "[data-testid='generate-button']"
}Shadow DOM mode - Inspect Adobe Spectrum components:
{
"mode": "shadow",
"maxDepth": 8
}Accessibility mode - Return accessibility tree:
{
"mode": "accessibility"
}Tree mode - Visual DOM tree:
{
"mode": "tree",
"maxDepth": 10
}Output Includes
Page info (URL, title, browser version, viewport, frameworks detected)
Discovered selectors with Playwright locator suggestions
Selector uniqueness (how many elements each selector matches)
XPath alongside CSS and Playwright locators
Shadow DOM traversal for Adobe Spectrum components
Console messages (captured via listeners in MCP process)
Network requests with duration
Performance metrics (Navigation Timing, LCP, FCP)
Screenshots (standard + annotated with numbered labels)
HTML snapshots
Element screenshots (optional)
Example: Diagnose Broken Automation
When Adobe changes the UI and your automation breaks:
{
"mode": "full",
"includeScreenshot": true,
"captureElementScreenshots": true
}This returns:
All discovered buttons/inputs with their selectors
Which selectors are unique (matches: 1) vs shared (matches: 14)
Playwright locator recommendations ranked by stability
Screenshots showing exactly what's on screen
DOM Watch (Real-time Monitoring)
The firefly_dom_watch tool uses MutationObserver to report exactly when elements appear, disappear, or attributes change.
{
"timeoutMs": 60000,
"targetSelector": "[data-testid='generate-container']",
"mutations": ["childList", "attributes"]
}Returns:
{
"mutations": [
{
"timestamp": "2026-07-06T12:34:56.789Z",
"type": "childList",
"action": "added",
"targetSelector": "[data-testid='generate-button']",
"addedNodes": ["Generate"],
"removedNodes": []
}
],
"summary": {
"totalMutations": 5,
"addedNodes": 3,
"removedNodes": 1,
"attributeChanges": 1
}
}Example use cases:
"Watch for the Generate button to appear after page load"
"Monitor when the spinner disappears and results show"
"Track when the download button becomes enabled"
Debug Bundle (Comprehensive Diagnostics)
The firefly_debug_bundle tool captures a complete diagnostic snapshot with 26+ files. This is a read-only tool that never clicks Generate, uploads files, modifies settings, changes prompts, or navigates away.
{}Optional: Specify a URL to navigate to first:
{
"url": "https://firefly.adobe.com/generate/video"
}Output Files
The tool creates a timestamped directory at debug/bundles/YYYY-MM-DDTHH-MM-SS/ with:
File | Description |
| URL, title, browser version, frameworks detected |
| Browser status and config |
| DOM tree, shadow DOM count, iframes, forms, dialogs |
| Accessibility tree snapshot |
| Navigation Timing, LCP, FCP, memory usage |
| Console messages (last 500) |
| Network requests with timing (last 500) |
| All browser cookies |
| localStorage and sessionStorage keys |
| Detected frameworks (React, Vue, Angular, etc.) |
| Discovered elements with bounding boxes |
| Selector validation results (exists/visible/enabled) |
| Form elements and validation state |
| Modal dialogs and alerts |
| Shadow DOM tree traversal |
| Iframe inspection |
| Browser permissions state |
| Browser fingerprint (user agent, WebGL, etc.) |
| Registered service workers |
| IndexedDB databases |
| localStorage contents |
| sessionStorage contents |
| Automation detection indicators (webdriver, etc.) |
| Auth state, Adobe cookies, token expiry |
| Human-readable selector validation report |
| Human-readable automation health report |
| Overall diagnostic summary with confidence level |
| Full-page screenshot |
| Complete HTML snapshot |
Use Cases
"Run a full diagnostic on the current page"
"Check if automation is being detected"
"Validate all selectors are still working"
"Get a snapshot before something breaks"
"Compare browser fingerprints between sessions"
Validate Environment
firefly_validate_environment checks your environment readiness and optionally auto-fixes common issues:
{
"autoFix": true
}Checks Performed
Authentication: Verifies Adobe session cookies are present and valid
Selectors: Validates all critical UI selectors still work
Browser: Confirms browser is available and launchable
Cookies: Checks cookie file integrity and expiration
Storage: Verifies storage directory exists and is writable
Credits: Attempts to detect Adobe credit/quota status
Automation health: Tests prompt input and download button availability
Response
{
"ok": true,
"readinessScore": 85,
"issues": [
{
"severity": "warning",
"category": "auth",
"message": "Adobe session cookie expired",
"autoFixed": false
}
],
"autoFixes": [],
"recommendations": ["Re-authenticate with Adobe Firefly"]
}Readiness score ranges from 0 (completely broken) to 100 (fully operational).
Successful tool calls return JSON like:
{
"ok": true,
"operation": "firefly_generate",
"files": [
{
"path": "/absolute/path/to/downloads/firefly-example.png",
"source": "download"
}
],
"pageUrl": "https://firefly.adobe.com/...",
"warnings": []
}Configuration
All configuration is optional.
Environment variable | Default | Purpose |
| current working directory | Base directory for |
|
| Saved image output directory. |
|
| Persistent Chromium user data directory. |
|
| Run Chromium headless after you have already signed in. |
|
|
|
|
| Default maximum generated images to save. |
|
| General UI action timeout. |
|
| Generation wait timeout. |
|
| Page navigation timeout. |
|
| Base Firefly URL. |
|
| Prompt-to-image route. |
|
| Variations route. |
|
| Expand route. |
|
| Remove-background route. |
|
| Video generation route. |
| built-in candidates | CSS selector override for the prompt input. |
| built-in candidates | CSS selector override for the generate/action button. |
| built-in candidates | CSS selector override for download buttons. |
| built-in candidates | CSS selector override for upload controls. |
|
| Use real Chrome with user's existing profile instead of Chromium. |
| undefined | Path to Chrome user data directory (required when using persistent). |
|
| Enable automatic selector recovery. |
|
| Minimum confidence score (0-1) to accept recovered selector. |
Adobe can change the Firefly UI at any time. The server uses resilient Playwright locators first, then CSS selector overrides when needed. Self-healing automatically recovers when selectors break.
Development
npm install
npm run dev
npm run checkUseful scripts:
npm run build- compile TypeScript todist/.npm run lint- run ESLint.npm run format- apply Prettier.npm run test- run Vitest unit tests.npm run check- typecheck, lint, format-check, test, and build.
Security Model
Uses
chromium.launchPersistentContext()with a dedicated local profile.Never asks for Adobe credentials.
Never fills login forms.
Never stores credentials in config, logs, env vars, or project files.
Reuses whatever Adobe session exists in the Playwright profile.
Writes MCP protocol messages to stdout and logs only to stderr.
Keep profile/ private. It may contain browser cookies/session storage after you sign in.
Architecture
The server uses a modular architecture with centralized selectors, reusable utilities, and automatic diagnostics:
Core Modules
src/firefly/selectors.ts- Centralized selector candidates for image, video, and shared UI elementssrc/firefly/locatorResolver.ts- ReusableresolveLocator()with timeout, scroll, retry, and debug loggingsrc/firefly/selfHealing.ts- Self-healing engine with confidence scoring and selector recoverysrc/firefly/diagnostics.ts- Automatic screenshot/HTML capture on failuressrc/firefly/generationWait.ts- Generation completion monitoring with explicit error detectionsrc/firefly/downloads.ts- Robust download handling withdownloadMode: "first"|"all"
Self-Healing Automation
The server includes a self-healing selector recovery system that automatically recovers when Adobe changes their UI, without requiring code changes:
Recovery Chain
Primary selector - Try the first selector candidate (fastest, most specific)
Remaining candidates - Try other predefined selector candidates
DOM inspector discovery - If all candidates fail, discover elements by role, name, and text
Confidence scoring - Each discovered element is scored based on match quality
Fail safely - If no match exceeds confidence threshold (default 0.7), report failure
Confidence Scoring
Each selector candidate is scored based on its kind and match quality:
Selector Kind | Base Score |
| 100 |
| 90 |
| 85 |
| 80 |
| 80 |
| 70 |
| 40 |
| 10 |
Bonuses: visibility (+10), enabled (+5), unique match (+40).
Usage
Self-healing is integrated into locatorResolver.ts. When you call resolveLocator(), it automatically:
Tries the primary selector candidate
Falls back to other candidates if primary fails
Uses self-healing engine if all candidates fail
Returns
healed: trueandconfidence: numberwhen recovery succeedsPersists recovered selectors to
debug/recovered-selectors.json
const result = await resolveLocator(page, candidates, "Generate button", 3000);
if (result.healed) {
console.log(`Healed with confidence: ${result.confidence}`);
}Configuration
const config: AppConfig = {
selfHealing: {
enabled: true,
confidenceThreshold: 0.7, // 0-1, minimum confidence to accept
maxRecoveryAttempts: 3,
persistencePath: "debug/recovered-selectors.json",
},
};Error Detection
The video generation tool explicitly detects Firefly errors instead of treating them as timeouts:
Status | Description |
| Generation completed and download button is enabled |
| "Something went wrong", "Try again", "Server error", etc. |
| Content policy violations |
| Session expired, sign-in required |
| No credits/quota remaining |
| No success or error detected within timeout |
Debugging Workflow
When automation fails:
Run
firefly_debug_bundleto capture a comprehensive diagnostic snapshotRun
firefly_statusto check auth state and take a screenshotRun
firefly_dom_inspectwithmode: "full"to see all selectors and page stateUse
firefly_dom_watchto monitor real-time DOM changesCheck tool output for structured error diagnostics
The debug bundle provides the most complete picture with 26+ diagnostic files, selector validation, automation health checks, and auth diagnostics.
Troubleshooting
"Executable doesn't exist" / browser fails to launch.
Playwright's Chromium isn't installed. Run npm run install:browser (from
source) or npx playwright install chromium (global install).
A Chromium window never opens on first run.
The default mode is headed so you can sign in. Ensure FIREFLY_HEADLESS is not
set to true, then run firefly_status with openBrowser: true.
Tools report auth_error or I'm asked to sign in repeatedly.
Your Adobe session expired or the profile wasn't reused. Run firefly_status
with openBrowser: true, sign in again, and confirm the profile/ path in the
output matches across runs. Do not delete profile/ between runs.
Generation returns credit_error.
Your Adobe plan is out of Firefly credits/quota. This is an account state, not a
bug.
Automation broke after an Adobe UI change.
Adobe changed routes, labels, or structure. Run firefly_debug_bundle and
firefly_dom_inspect to find new selectors, then set the relevant
FIREFLY_SELECTOR_* or FIREFLY_*_URL overrides. The self-healing engine will
also attempt automatic recovery.
Browser won't start: profile is locked.
Another instance is using the profile, or a previous run didn't exit cleanly.
Close other Chromium instances using profile/ and retry.
Nothing appears in the MCP client / protocol errors.
Logs go to stderr, never stdout (stdout is reserved for the MCP protocol).
Check stderr and set FIREFLY_LOG_LEVEL=debug for more detail.
Limitations
This is browser automation over a consumer web UI, not an official Adobe API. It can break when Adobe changes routes, labels, or page structure. Use firefly_status and selector/URL environment overrides to diagnose and adapt.
You are responsible for using Adobe Firefly in accordance with your Adobe plan and applicable terms.
Contributing
Contributions are welcome. See CONTRIBUTING.md for setup and the quality bar, and CODE_OF_CONDUCT.md. For security issues, follow SECURITY.md rather than opening a public issue.
License
MIT © Anik
Available Tools
6 toolsfirefly_dom_inspectAdobe Firefly DOM InspectorA
Inspect the current Adobe Firefly DOM state for debugging. This is a read-only tool that never navigates, clicks, or modifies the page. Use it to diagnose broken automation, discover selectors, and inspect shadow DOM.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Inspection mode | full |
| maxDepth | No | Maximum depth for tree/shadow traversal | |
| selector | No | CSS selector for selector mode (required when mode=selector) | |
| includeHtml | No | Save HTML snapshot to debug/dom.html | |
| includeConsole | No | Capture console messages | |
| includeNetwork | No | Capture network requests | |
| includeScreenshot | No | Save screenshot to debug/dom-inspect.png | |
| maxConsoleMessages | No | Maximum console messages to return | |
| maxNetworkRequests | No | Maximum network requests to return | |
| includeAccessibility | No | Include accessibility tree | |
| captureElementScreenshots | No | Save individual screenshots for each discovered element | |
| includeAnnotatedScreenshot | No | Save annotated screenshot with element labels |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden and delivers: 'This is a read-only tool that never navigates, clicks, or modifies the page.' This is a model of behavioral transparency, clearly stating safety guarantees. Additional context about inspecting shadow DOM and discovering selectors adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The most critical information (purpose, read-only guarantee) is front-loaded. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 12 parameters, no output schema, and no annotations, the description provides a clear purpose and behavioral guarantee but lacks guidance on parameter interplay (e.g., which mode for which use case) and what the return value looks like. The description covers essential context but is incomplete for fully informed tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add significant parameter-level detail beyond what the schema provides. It mentions some use cases (shadow DOM, selectors) that hint at parameter choices but does not elaborate on mode selection or other options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'inspect', the resource 'Adobe Firefly DOM state', and the purpose 'for debugging'. It explicitly distinguishes itself as a read-only diagnostic tool, differentiating from sibling tools like firefly_dom_watch (likely for monitoring changes) and firefly_debug_bundle (a broader debug collection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use it to diagnose broken automation, discover selectors, and inspect shadow DOM.' This provides clear context. However, it does not explicitly mention when not to use or compare with alternatives like firefly_dom_watch, leaving some ambiguity for agents deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
firefly_generateAdobe Firefly GenerateA
Generate images in Adobe Firefly using the existing persistent browser session. Requires manual Adobe sign-in in the browser profile.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Maximum number of generated images to save. | |
| style | No | Optional visible Firefly style/control label to try to select. | |
| prompt | Yes | Image prompt to send to Adobe Firefly. | |
| outputDir | No | Optional output directory. Relative paths resolve under the MCP data dir. | |
| aspectRatio | No | Optional Firefly aspect ratio label, such as "1:1" or "16:9". | |
| contentClass | No | Optional Firefly content type/control label, such as "Photo" or "Art". | |
| negativePrompt | No | Optional things to avoid. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It mentions the sign-in requirement but omits critical details such as potential side effects, error behavior, rate limits, or what happens to the browser session. This lack of transparency leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that immediately convey the core action and a critical prerequisite. Every word serves a purpose, and the most important information is front-loaded. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 7 parameters and no output schema, the description fails to explain what the tool returns, how errors are handled, how to effectively use optional parameters, or any post-invocation behavior. For a complex image generation tool, this is insufficient, leaving the agent without essential operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for all 7 parameters (100% coverage). The tool description does not add meaningful semantic context beyond what the schema already conveys, so it meets the baseline of 3 but does not excel.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate' and the resource 'images in Adobe Firefly', and it uniquely identifies the tool among siblings by distinguishing it from video generation or background removal. It also specifies the context of a persistent browser session, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes the prerequisite of manual Adobe sign-in and the use of an existing persistent browser session, providing clear context for when to use the tool. However, it does not offer exclusion criteria or alternatives (e.g., comparing with firefly_generate_video), so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
firefly_generate_videoAdobe Firefly Video GenerateA
Generate videos in Adobe Firefly using the existing persistent browser session. Requires manual Adobe sign-in in the browser profile.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Optional seed value for reproducible generation. | |
| model | No | Optional model selection, such as "Veo 3.1" or "Veo 3.1 Fast". | |
| prompt | Yes | Video prompt to send to Adobe Firefly. | |
| duration | No | Optional video duration, such as "4 seconds" or "8 seconds". | |
| outputDir | No | Optional output directory. Relative paths resolve under the MCP data dir. | |
| resolution | No | Optional resolution, such as "720p" or "1080p". | |
| aspectRatio | No | Optional aspect ratio, such as "Widescreen (16:9)" or "Square (1:1)". | |
| visualStyle | No | Optional visual style, if supported by the model. | |
| cameraMotion | No | Optional camera motion style, if supported by the model. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the dependency on a browser session and manual sign-in, but does not cover failure modes, rate limits, or other behavioral traits. This adds some transparency but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two front-loaded sentences with no superfluous words. Every sentence adds essential information about the tool's purpose and prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description should clarify the return value (e.g., file path or URL) and explain parameter dependencies (e.g., model support for duration). It fails to address these, leaving the tool's behavior incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 9 parameters are fully described in the input schema with 100% coverage. The description adds no additional meaning beyond the schema, which is adequate. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'generate' and resource 'videos in Adobe Firefly', distinguishing it from sibling tools like 'firefly_generate' (likely images) and 'firefly_remove_background'. It also mentions the browser session requirement, adding specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the prerequisite of a persistent browser session with manual Adobe sign-in, guiding when to use this tool. It does not explicitly state when not to use it or list alternatives, but sibling tool names provide sufficient context for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
firefly_remove_backgroundAdobe Firefly Remove BackgroundC
Use Adobe Firefly's browser UI to remove the background from a local image and save the result.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Maximum images to save. | |
| imagePath | Yes | Local source image path. Relative paths resolve from the server cwd. | |
| outputDir | No | Optional output directory. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states 'use Adobe Firefly's browser UI' and 'save the result' but does not disclose side effects (e.g., whether the original file is modified, if network calls are made, or if the browser stays open). Minimal behavioral info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise—only one sentence. Front-loaded with action and resource. However, it could benefit from a slight structure break (e.g., separate outcome) but not necessary for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema or annotations. The description omits what happens to the output (where it's saved, format), error handling, or prerequisites (e.g., Firefly UI availability). Incomplete for a task with moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes background from a local image and saves the result, which distinguishes it from generation or variation tools. However, mentioning 'browser UI' is slightly ambiguous—does it mean headless automation or user-facing? Still, the verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like firefly_generate or firefly_variations. No alternatives or exclusions mentioned. The description implies a generic use case without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
firefly_validate_environmentAdobe Firefly Environment ValidatorA
Validate the Adobe Firefly environment readiness. Checks authentication, selectors, browser health, cookies, storage, credits, and automation indicators. Returns a readiness score from 0-100.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It implies a read-only diagnostic operation by listing checks (authentication, browser health, etc.) and a readiness score, but does not explicitly confirm non-destructiveness, permissions, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose; every sentence provides essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's function and output for a simple validation tool with no parameters. However, given the similar sibling 'firefly_verify_environment', more distinguishing context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100%. The description adds value by detailing what aspects of the environment are validated (authentication, selectors, etc.), which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Validate') and the resource ('Adobe Firefly environment readiness'), and lists specific checks. However, the presence of a sibling tool 'firefly_verify_environment' with a similar name creates ambiguity; the description does not distinguish between validate and verify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'firefly_verify_environment' or other siblings. No exclusions or context for appropriate use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
firefly_verify_environmentAdobe Firefly Live Environment VerificationA
Read-only verification of the current live Firefly page. It reuses the MCP server's BrowserManager, BrowserContext, and Page without navigating or clicking.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It explicitly states 'Read-only' and 'without navigating or clicking', which communicates safety and lack of side effects. It also details reuse of BrowserManager, BrowserContext, and Page, providing transparency about internal dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the core purpose. It is concise, front-loaded with the key action ('Read-only verification'), and avoids extraneous detail. Every part of the sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description is clear about behavior, it lacks information about what the verification checks or what the output or result looks like. Since there is no output schema, the description should at least hint at the return value or success criteria. The current description feels slightly incomplete for an agent needing to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is perfect (100% of 0 parameters). The description does not need to add parameter information. A baseline score of 4 is appropriate given that there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read-only verification of the current live Firefly page', specifying the verb (verify) and resource (live Firefly page). It also clarifies that it reuses browser objects without navigation or clicks, effectively distinguishing itself from potentially similar tools like firefly_validate_environment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a safe, side-effect-free operation ('without navigating or clicking'), which helps in understanding when to use it. However, it does not explicitly contrast with sibling tools like firefly_validate_environment or provide conditions for when one should be preferred over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
7 tool updates
v0.1.1- Removed
firefly_debug_bundle - Removed
firefly_dom_watch - Removed
firefly_expand - Removed
firefly_status - Changed
firefly_validate_environment1 field changed- removed
Input schema / properties / urlRemoved value: -{ - "description": "Optional URL to navigate to before validation. Defaults to current page.", - "type": "string" -}
- Removed
firefly_variations - Added
firefly_verify_environment
10 tool updates
v0.1.0- First observed
firefly_debug_bundle - First observed
firefly_dom_inspect - First observed
firefly_dom_watch - First observed
firefly_expand - First observed
firefly_generate - First observed
firefly_generate_video - First observed
firefly_remove_background - First observed
firefly_status - First observed
firefly_validate_environment - First observed
firefly_variations
TDQS
Each tool has a clearly distinct purpose: generate images, generate videos, expand, remove background, create variations, and several debug/diagnostic tools that are all different in function. No two tools are ambiguous.
All tools start with 'firefly_' prefix, which is consistent. However, naming patterns mix verb_noun (firefly_generate, firefly_validate_environment) and noun_noun (firefly_debug_bundle) or noun (firefly_status). Minor inconsistency but still readable.
10 tools is well-scoped for an image generation service. It covers generation, editing, and diagnostics without being overwhelming or too sparse. Each tool earns its place.
Core features like generate, video, expand, background removal, and variations are present. Missing features like inpainting or style transfer are gaps, but the set covers the most common workflows. Diagnostics are a bonus.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
MCP server for Qwen Image 3 AI image generation
MCP server for Flux AI image generation
Related MCP Servers
- AlicenseAqualityBmaintenanceMCP server for AI-powered image, audio, and video generation, enabling media creation directly from Claude, Cursor, and other MCP clients.1164MIT
- AlicenseAqualityAmaintenanceMulti-provider image generation MCP server that enables image generation from Claude Desktop, Claude Code, or any MCP client using OpenAI, Google Gemini, Stable Diffusion, or a placeholder provider.101MIT
- FlicenseAqualityCmaintenanceMCP server that lets Claude control Google Gemini Omni video generation via a browser bridge (Playwright) until the official API ships.3-
- AlicenseNot gradedqualityCmaintenanceMCP server that enables Claude Code to generate images using Google's Gemini image generation models.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/peroxide-dev/adobe-firefly-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server