GPT Image Playground MCP
GPT Image Playground MCP
Lass deinen Agenten GPT Image Playground über den Browser nutzen.
Keine Änderungen am Playground-Quellcode nötig. Nach der Installation der Browsererweiterung und einer einmaligen Verbindungseinrichtung kann der Agent Bildgenerierungsaufgaben einreichen, den Aufgabenfortschritt verfolgen und die erzeugten Originalbilder lokal speichern.
Dieses Projekt stellt die Seitenbasis des Playgrounds über CookSleep/gpt_image_playground bereit. Dieses Projekt bietet eine MCP-Brücke für die auf der Seite sichtbaren Aktionen und enthält den Playground-Quellcode weder, noch verändert es ihn.
[!NOTE] Der Playground ist weiterhin für den Aufruf der Bild-API und die Verwaltung seines eigenen Anmeldestatus verantwortlich. Dieses Tool überträgt nur Aufgaben und bedient die Seite.
Das kannst du damit tun
den Agenten anhand einer Beschreibung ein Bild erzeugen lassen;
abfragen, ob eine Aufgabe bereits abgeschlossen ist;
für eine bestimmte Aufgabe das Originalbild herunterladen;
mehreren Agenten die Nutzung derselben Browser-Aufgabenwarteschlange erlauben;
mit lokalen Referenzbildern an der Generierung teilnehmen.
Die zugehörigen MCP-Tools sind generate_image, get_task_status und download_image.
Related MCP server: openai-gpt-image-1-mcp
So funktioniert es
Agent
-> MCP stdio
-> 本机桥接服务
-> Chromium 扩展
-> Playground 页面
-> 生成并返回图片Aufgaben werden vom lokalen Bridge-Dienst in der Reihenfolge ihrer Einreichung nacheinander verarbeitet. Für die Bildgenerierung gibt es keine feste 20-Sekunden-Frist; nach der Übernahme einer Aufgabe während der Erweiterung von Warten darauf, bis die Seite fertig ist, und bleibt verbunden. Verschiedene Bilder können unterschiedlich lange für die Generierung brauchen, was nicht zu doppelter Einreichung oder automatischer Neuordnung der Aufgaben führt.
Nach dem Schließen des Browsers können Seitenaufgaben nicht weiter ausgeführt werden. Öffne den Browser erneut und prüfe zuerst den Status der ursprünglichen Aufgaben, bevor du neue Aufgaben einreichst.
Bevor du beginnst
Halte Folgendes bereit:
Node.js 18 oder höher;
Chrome, Chromium oder einen anderen Chromium-Browser mit Manifest-V3-Unterstützung;
eine Browserseite, auf der GPT Image Playground normal geöffnet wird;
einen MCP-fähigen Agent-Client.
Schnellstart
1. Projekt abrufen und bauen
Hole das Projekt von GitHub:
git clone https://github.com/PEKI7483/image-playground-mcp.git
cd image-playground-mcp
npm install
npm run buildWenn du das Projekt in ein anderes Verzeichnis legst, ist <Projektstammverzeichnis> weiter unten das geklonte Verzeichnis image-playground-mcp.
Nach dem Bau sollte dist/ die Dateien server.js, bridge.js und bridgeMain.js enthalten.
2. Verbindungscode generieren
Der Verbindungscode schützt den lokalen Bridge-Dienst und ist kein Playground-API-Key. Erzeuge einen zufälligen Verbindungscode und bewahre ihn sicher auf:
node -e "console.log(require('node:crypto').randomBytes(32).toString('hex'))"Die Erweiterung und jeder Agent-Client müssen denselben Verbindungscode verwenden. Committe den Verbindungscode nicht in das Repository und veröffentliche ihn nicht in Logs.
Die Standard-Bridge-Adresse ist http://127.0.0.1:8787. Falls der Port belegt ist, kannst du einen anderen Port verwenden, zum Beispiel 8790 – aber die Erweiterung und alle Agents müssen übereinstimmen.
3. Browsererweiterung installieren
Öffne Chrome oder Chromium und rufe
chrome://extensionsauf.Aktiviere oben rechts den „Entwicklermodus“.
Klicke auf „Entpackte Erweiterung laden“.
Wähle:
<项目根目录>/extensionKlicke in der Browser-Symbolleiste auf das Symbol der Erweiterung, um das Erweiterungsfenster zu öffnen.
Klicke oben auf „Verbindungseinstellungen“.
Setze bei „Bildtool-Adresse“ den Wert
http://127.0.0.1:8787und bei „Verbindungscode“ den eben erzeugten Verbindungscode.Klicke auf „Speichern und prüfen“. Nach erfolgreicher Verbindung kehrt das Fenster zur „Betriebsübersicht“ zurück.
Die Einrichtung erfolgt ausschließlich im kleinen Erweiterungsfenster und öffnet keinen neuen Tab. Die Erweiterung speichert Bridge-Adresse und Verbindungscode, aber keinen Playground-API-Key.
4. Agent auswählen
Schließe zuerst die Erweiterungskonfiguration ab und wähle danach die zu deinem Agent-Client passende Methode. Alle Agents können sich denselben Bridge-Dienst teilen, müssen aber denselben Verbindungscode und Port verwenden.
Agent | Hinzuf-Art | Geeignete Konfigurationsorte |
Codex CLI / Codex-App |
| Gemeinsame MCP-Konfiguration |
Claude Code |
| Nutzer- oder Projektkonfiguration |
Gemini CLI | MCP-Konfigurationsdatei |
|
Cursor | MCP-Konfiguration oder JSON |
|
Cline | MCP-Konfiguration | Seite „MCP-Server“ |
Roo Code | MCP-Konfiguration | Seite „MCP-Server“ |
Windsurf | MCP-Konfiguration oder JSON | MCP-Konfigurationsdatei |
Claude Desktop | JSON-Konfiguration |
|
Codex CLI und Codex-App
Codex CLI, Codex-App und die IDE-Erweiterung teilen sich die MCP-Konfiguration. Setze <Projektstammverzeichnis> und den Verbindungscode auf die tatsächlich verwendeten tatsächlichen Werte und führe Folgendes aus:
codex mcp add gpt-image-playground \
--env MCP_BRIDGE_TOKEN=替换为连接码 \
--env MCP_BRIDGE_PORT=8787 \
-- node "<项目根目录>/dist/server.js"Konfiguration prüfen:
codex mcp listWeitere Optionen findest du in der offiziellen Codex-MCP-Dokumentation.
Claude Code
claude mcp add --transport stdio gpt-image-playground \
--env MCP_BRIDGE_TOKEN=替换为连接码 \
--env MCP_BRIDGE_PORT=8787 \
-- node "<项目根目录>/dist/server.js"Gemini CLI
Gemini CLI konfiguriert lokale Dienste in der Regel über die MCP-Konfigurationsdatei. Füge in der Datei settings.json unter mcpServers Folgendes hinzu:
{
"gpt-image-playground": {
"command": "node",
"args": ["<项目根目录>/dist/server.js"],
"env": {
"MCP_BRIDGE_TOKEN": "替换为连接码",
"MCP_BRIDGE_PORT": "8787"
}
}
}Cursor, Cline, Roo Code, Windsurf und Claude Desktop
Diese Clients können den lokalen STDIO-Dienst auf der MCP-Einstellungsseite hinzufügen oder die entsprechende JSON-Konfiguration bearbeiten. Führe das folgende Objekt gpt-image-playground in ein vorhandenes mcpServers-Objekt ein und behalte dabei die anderen Serverkonfigurationen bei:
{
"gpt-image-playground": {
"command": "node",
"args": ["<项目根目录>/dist/server.js"],
"env": {
"MCP_BRIDGE_TOKEN": "替换为连接码",
"MCP_BRIDGE_PORT": "8787"
}
}
}Häufige Orte sind:
Cursor:
.cursor/mcp.jsonim Projektverzeichnis oderCursor Settings > MCP;Cline: die Seite
MCP Serversin der Erweiterung;Roo Code: die Seite
MCP Serversin der Erweiterung;Windsurf: die MCP-Einstellungsseite oder die MCP-Konfigurationsdatei;
Claude Desktop:
mcpServersinclaude_desktop_config.json.
Nach dem Speichern bitte den Client neu starten oder die MCP-Konfiguration neu laden.
Wenn der MCP-Client dist/server.js startet, wird das MCP-Protokoll über stdio bereitgestellt und gleichzeitig der lokale Bridge-Dienst gestartet. Ein manueller Aufruf von npm start ist normalerweise nicht erforderlich.
Starten und Verbindung bestätigen
Öffne GPT Image Playground und lasse die normale Seite im Galerie-Modus geöffnet.
Stellen Sie sicher, dass das Eingabefeld für die Aufforderung und das Bild-Upload-Steuerungsfeld auf der Seite sichtbar sind.
Starte oder starte deinen Agent-Client neu, damit er die zuvor hinzugefügten MCP-Konfiguration laden.
Klicke in der Browser-Symbolleiste auf das Symbol der Erweiterung.
Prüfe in der „Betriebsübersicht“, ob Bridge-Dienst, Erweiterungsverbindung und Playground-Seite einen normalen Status haben.
Du kannst die Verbindung auch über den Health-Check-Endpunkt prüfen:
curl -H 'X-MCP-Bridge-Token: 替换为连接码' \
http://127.0.0.1:8787/v1/healthBeispiel für den Zustand (Health Status):
{
"bridge": "running",
"extensionConnected": true,
"playgroundTabCount": 1,
"queueLength": 0
}Beispiele für Aufrufe
Ein Bild erzeugen
Rufe generate_image mit mindestens einer Aufforderung auf:
{
"prompt": "一只戴红色围巾的橘猫,工作室摄影风格"
}Das Tool warten darauf, dass die Seite fertig wird, und verwendet keine 20-Sekunden-Frist als Frist. Mehrere Agents können sich gleichzeitig über denselben Bridge-Adresse verbinden; Die Aufgaben landen in derselben FIFO-Warteschlange und werden nacheinander ausgeführt.
Referenzbilder verwenden
Referenzbilder können direkt über die MCP-Parameter übergeben werden; du musst das Upload-Steuerelement im Playground nicht manuell anklicken:
{
"prompt": "保留参考图的构图,改成水彩插画",
"reference_image_paths": [
"/absolute/path/reference.png",
"/absolute/path/style.jpg"
]
}Unterstützt werden PNG, JPEG/JPG, WebP, GIF und AVIF; höchstens 16 Bilder, wobei ein einzelnes Bild nicht über 8 MiB und die Gesamtgröße nicht über 24 MiB liegt. Nachdem der MCP-Dienst die lokalen Dateien gespeichert hat, fügt die Erweiterung die Bedingungen in das vorhandene Multi-File-Upload-Steuerelement des Playgrounds an; die Bildverarbeitung übernimmt weiterhin die Playground-Seite.
Erzeugtes Ergebnis herunterladen
Nach erfolgreichem generate_image wird mit der zurückgegebenen task_id download_image aufrufen:
{
"task_id": "上一步返回的 task_id",
"output_path": "/absolute/path/generated.png",
"image_index": 0
}output_path muss ein absolut Pfad sein. Wenn eine Datei bereits vorhanden ist, ist der Erfolg idempotent nur dann korrekt, wenn der Inhalt exakt übereinstimmt; andernfalls das Tool weist auf einen Konflikt hin und überschreibt die vorhandene Datei nicht.
Das Originalbild im Detail-Dialog wird möglicherweise erst später geladen als die Miniaturansicht der Aufgabenkarte. Die Erweiterung kompatibel mit normalen img-Bildern, wartet maximal 60 Sekunden und schließt den Detail-Dialog, nachdem der Download abgeschlossen oder fehlgeschlagen ist.
Sicherheit und Datenschutz
[!IMPORTANT] Dein Anmeldestatus und dein API-Key für Playground werden weiterhin von Playground selbst verwaltet. Dieses Tool hat nur auf die Seite zu und liest oder speichert keine Cookies,
localStorage, IndexedDB, JavaScript-Variablen der Seite oder Schlüssel aus API-Antworten.
Der Verbindungscode dient nur zum Schutz der lokalen Bridge-Schnittstelle und ist kein Playground-API-Key;
Der Bridge-Dienst läuft standardmäßig nur auf der lokalen Loopback-Adresse;
Die Bildgenerierung erfolgt über die sichtbare Playground-Seite, nicht durch direkte Aufrufe der Bild-API;
Referenzbilder werden von MCP-Dienst des Dienstes gelesen und der Playground-Seite zur Verarbeitung übergeben;
Mehrere Agents können sich den Dienst teilen, sollten aber denselben Verbindungscode und port verwenden.
Häufig gestellte Fragen
Die Erweiterung zeigt „Dienst nicht erreichbar“
Bitte prüfe in der folgenden Reihenfolge:
Wurde
dist/server.jsvom Agent-Clients bereits gestartet und geladen?Ist die Bridge-Adresse in der Erweiterung
http://127.0.0.1:8787?Stimmt der Verbindungscode in der Erweiterung exakt mit struktur in der Agent-Konfiguration überein?
Hast du nach Änderungen am Erweiterungscode bei
chrome://extensionsauf „Neu laden“ geklickt?Hast du die normale Gallery-Seite von GPT Image Playground geöffnet?
Falls weiterhin keine Verbindung zustande kommt, verwende den Health-Check-Befehl oben und bewahre das Ergebnis auf, um es weiter zu lokalisieren.
Die Anzahl der Playground-Seiten ist 0
Öffne die Seite im normalen Gallery-Modus von GPT Image Playground und stelle sicher, dass das Eingabefeld für den Prompt sichtbar ist. Die Erweiterung funktioniert auf. Sie funktioniert nicht über direkte Aufrufe der Bild-API und bearbeite keine Seiten ohne entsprechende Seitenelement.
Die Generierung dauert lange, der Agent scheint nicht zu reagieren
Die Generierungszeit hängt von Prompt, Referenzbildern und Seitenstatus ab. Prüfe zuerst die Aufgabenkarten im Playground und die Betriebsübersicht der Erweiterung; klicke nicht erneut auf „Generieren“. Eine bereits übernommene Aufgabe wird weiterhin auf die Fertigstellung der Seite warten; bei Bedarf kannst du mit get_task_status nachfragen.
Referenzbilder erscheinen nicht
Bitte bestätige:
Der Dateipfad ist absolut;
das Datei format wird unterstützt;
das einzelne Bild nicht über 8 MiB liegt und die Gesamtgröße 24 MiB nicht übersteigt;
die Anzahl der Bilder nicht mehr als 16 beträgt;
das Multi-File-Upload-Steuerelement auf der Playground-Seite vorhanden ist.
Download des Originalbilds schlägt fehl
Prüfe zuerst, ob die Aufgabe abgeschlossen ist, die Aufgabenkarte noch sichtbar ist und verwende einen neuen absoluten Ausgabepfad. Der Download liest das Originalbild aus dem Detail-Dialog und nicht über den Browser-Speicher.
Konfiguration
Umgebungsvariable | Standard | Beschreibung |
| Zufällig beim Start | Verbindungscode zwischen MCP und Erweiterung auf dem lokalen Rechner; für mehrere Agents muss er auf einen festen Wert gesetzt sein |
|
| Lokaler Bridge-Port |
|
| Standardmäßig deaktiviert; wenn aktiviert, werden nur Aufgaben ohne Heartbeat-Clients freigegeben, keine automatischen Generierung versucht. |
Wenn du den Bridge-Dienst zur Fehlerbehandlung separat starten möchtest, verwende:
MCP_BRIDGE_TOKEN='替换为连接码' MCP_BRIDGE_PORT=8787 npm run bridgeNormalerweise ist es nicht nötig, diesen Befehl manuell über den Befehl cmd auszuführen. Wenn der MCP-Client dist/server.js startet, wird gleichzeitig der lokale Bridge-Dienst gestartet.
Feedback und Hilfe
Wenn du auf ein Problem stößt, reiche gerne ein Issue ein. Um uns zu helfen, die Situation, bitte stell die folgenden Informationen bereit:
den verwendeten Agent-Client und dessen Version;
Browser und Version;
den Status aus der Betriebsübersicht der Erweiterung;
das Ergebnis des Health-Check-Endpunkts;
die Fehlermeldungen der zugehörigen Aufgaben.
Entferne vor dem Teilen von Logs den Verbindungscode, persönliche Pfade und andere sensible Informationen.
Design-Grenzen
Dieses Projekt ändert den Quellcode von GPT Image Playground nicht;
Der API-Key verbleibt in der Browser-Sitzung des Playground selbst; MCP und Erweiterung lesen ihn nicht;
Aufgaben werden nur über die lokale Loopback-Adresse bereitgestellt und erfordern einen Verbindungscode;
Nach dem Schließen des Browsers können Seitenaufgaben nicht weiter ausgeführt werden;
Aufgaben werden seriell verarbeitet, damit nicht mehrere Agents gleichzeitig dieselbe Playground-Seite bedienen.
Danke, dass du dir die Zeit genommen hast, dieses Tool auszuprobieren. Ich hoffe, es macht die Bildgenerierung flüssiger und macht die Zusammenarbeit zwischen Agent und Playground natürlicher.
Available Tools
3 toolsdownload_imageB
把已完成任务中的图片从 Playground 页面保存到 MCP 主机的本地绝对路径。
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| image_index | No | ||
| output_path | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action (saving a file) without mentioning side effects, overwriting behavior, permission requirements, or error handling. The agent has no information about what happens if the task is incomplete or if the output path already exists.
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 concise sentence with no unnecessary words. It front-loads the key action and scope, making it easy to scan.
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's complexity (3 parameters, no output schema, no annotations), the description is too minimal. It lacks essential context for parameter usage, expected behavior on failure, and any safety considerations, making it incomplete for an agent to confidently invoke the tool.
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 0% and the description does not explain any of the three parameters (task_id, image_index, output_path). The agent must infer meaning solely from parameter names, which is insufficient, especially for optional image_index which could be ambiguous.
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's purpose: downloading an image from a completed task to a local absolute path. It uses a specific verb (save/download) and resource (image from completed task), distinguishing it from sibling tools like generate_image and get_task_status.
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 mentions the precondition that the task must be completed, giving clear context for when to use this tool. However, it does not mention alternatives or when not to use it, though the distinct purpose makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_imageA
通过已打开的 GPT Image Playground 页面生成图片,可先注入本地参考图。请求会被浏览器桥接扩展串行处理,直到页面报告完成或失败;没有 20 秒固定上限。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| reference_image_paths | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有注解,描述承担了行为披露的全部责任。描述说明了请求会被串行处理、等待页面完成报告、没有20秒超时限制,这些是有用的行为细节,让代理了解执行模型。但未涉及权限、副作用或错误处理等,考虑到无注解,整体披露较充分。
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?
描述简洁,两个句子传达了核心功能和行为特征,没有冗余信息。第二句补充了重要的执行细节(串行处理、无固定超时),结构合理,但可再稍微结构化一点。
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?
工具接受2个参数,无输出schema,描述提供了行为的额外细节(串行处理、异步等待)。但对于兄弟工具(get_task_status、download_image)的关系没有提及,缺少集成上下文的说明。考虑到相对简单,描述基本够用,但可以更全面。
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覆盖率为0%,描述仅提到了'注入本地参考图'对应reference_images参数,但核心参数prompt没有额外解释,仅从字段名推断其含义。描述未能完全补偿schema参数的缺乏,特别是prompt的格式、要求或约束未提及。
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?
描述明确说明了工具的动作是生成图片,资源是GPT Image Playground页面,并提到可注入本地参考图。与兄弟工具get_task_status和download_image在功能上明显区分,目的清晰具体。
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?
描述暗示了使用场景(需要通过已打开的页面生成图片),但没有明确说明何时应使用此工具而非其他兄弟工具,也未提及限制条件(如页面必须已打开、注入参考图的步骤等)。缺少明确的'何时使用/何时不使用'指导。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_task_statusB
查询 Playground 页面中某个生成任务的状态。
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that the tool queries a status, implying a read-only operation, but it does not disclose return format, error behavior, or any Playground-specific constraints or 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?
One short sentence with no filler, directly stating the tool's purpose. It is front-loaded and appropriately sized for a simple status-query 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 one parameter and no output schema, yet the description does not explain what the status response looks like or how it relates to the sibling generate/download workflow. This leaves the agent with gaps in knowing how to interpret the result or integrate the tool.
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 0%, and the description does not explain the task_id parameter. While '某个生成任务' hints at the parameter's purpose, the description adds no concrete meaning beyond the schema's bare field name and type.
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 uses the specific verb '查询' (query) and a clear resource '生成任务的状态' (status of a generation task), scoped to the Playground page. This distinguishes it from sibling tools that generate or download images.
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 usage context is implied by the nature of the tool—checking status after generation—but there is no explicit guidance on when to use it vs. alternatives, no exclusions, and no mention of prerequisites.
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.
3 tool updates
v0.1.0- First observed
download_image - First observed
generate_image - First observed
get_task_status
TDQS
Scored across 3 tools
Each tool handles a distinct phase of the image generation workflow: generating, checking status, and downloading. There is no overlap in their purposes, making it clear which tool to use at each step.
All three tool names follow a consistent verb_noun pattern (generate_image, get_task_status, download_image), using snake_case and clear action-first naming. The pattern is uniform across the set.
With only 3 tools, the server is tightly scoped to a single workflow (generate, track, download). This is appropriate for a focused purpose and each tool is necessary for the complete flow.
The workflow covers the essential lifecycle: generation initiation, status polling, and downloading results. A minor gap is the lack of a cancellation or listing tool, but agents can work around this by waiting or using status checks.
Maintenance
Related MCP Connectors
Generate images, GIFs, videos, and PDFs from HTML, URLs, or templates — from your AI agent.
Generate images with your own ChatGPT subscription (Plus, Pro or Team), without spending API credits
Generate AI images, videos, music, SFX & speech in any AI assistant. Results appear inline in chat.
Generate images, video, and audio with Glif's media-generation agent
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables image generation and editing using OpenAI's GPT Image API (gpt-image-1, 1.5, 2) with support for multi-image generation, history management, and batch processing.12125 npm1MIT
- AlicenseNot gradedqualityDmaintenanceProvides AI agents and coding assistants with image generation and editing capabilities using OpenAI's GPT-image-1 model, with support for local or Supabase storage.3MIT
- AlicenseBqualityBmaintenanceEnables generating images from text or transforming existing images using GPT-Image-compatible APIs, with support for OpenAI and Agnes AI backends.2MIT
- AlicenseNot gradedqualityCmaintenanceEnables image generation and editing via ChatGPT web without API keys, saving images locally with conversation-aware editing.11 npm2MIT