The EFLOWCODE Image MCP server provides AI-powered image generation and editing across multiple providers (GPT, Grok, Nano Banana) via the MCP protocol.
Tools:
image_generate — Generate images from a text prompt, with options for size, number of images (1–10), model, provider, aspect ratio, and output file settings.
image_edit — Edit or generate a new image using a single local image as a reference, guided by a text prompt.
image_batch_edit — Apply the same edit prompt to multiple local images in a single call.
image_multi_reference — Synthesize a new image from 2–10 local reference images using a text prompt (Grok supports up to 3).
server_info — Retrieve current server configuration including active provider, model, save directory, and capability limits.
Additional Highlights:
Multi-provider routing: Automatically or explicitly route requests to gpt, grok, or banana; models prefixed with grok-* or nano-banana-* are auto-routed.
Local file output: Generated images are saved to a sandboxed, configurable local directory.
Input validation: Supports PNG, JPEG, WebP, and GIF with magic byte and size checks.
Secure by design: API keys are never stored in the repo; runtime tools do not accept dynamic base URLs to prevent prompt-injection attacks.
Configurable: API keys, base URLs, default models, timeouts, and save paths are managed via environment variables.
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., "@EFLOWCODE Image MCP Generate a 16:9 research presentation cover about AI in healthcare"
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.
MCP server for EFLOWCODE image generation across GPT Responses, Grok, and Nano Banana providers.
It exposes image tools to MCP clients such as Codex, Claude Desktop, Claude Code, Cursor, and other MCP-compatible agents. The default provider still calls:
POST {EFLOWCODE_BASE_URL}/responses
model: gpt-5.5
tools: [{"type": "image_generation"}]You can also route a request with provider="grok" or provider="banana", or by choosing a model name such as grok-* or nano-banana-*. Existing calls that omit provider continue to use GPT Responses by default.
Text-to-image generation with image_generate
Single image editing / reference generation with image_edit
Batch image editing with image_batch_edit
Multi-reference image synthesis with image_multi_reference
Multi-provider routing with provider="gpt", provider="grok", or provider="banana"
Automatic routing for grok-* and nano-banana-* model names
Local file output with a save-directory sandbox
Input image validation for PNG, JPEG, WebP, and GIF
Works with EFLOWCODE or any compatible /v1/responses endpoint that supports image_generation
Does not store API keys in this repository; keys are read from MCP client environment variables
Related MCP server: universal-image-mcp
git clone https://github.com/WenNinghan/eflowcode-image-mcp.git
cd eflowcode-image-mcp
python -m pip install -e .Then configure your MCP client.
python install.py --api-key sk-your-key --no-claudeRestart Codex, then ask your agent to call server_info.
The installer appends this MCP server to ~/.codex/config.toml and backs up the existing config first.
Add this to ~/.codex/config.toml:
[mcp_servers.eflowcode-image]
command = "python"
args = ["/absolute/path/to/eflowcode-image-mcp/server.py"]
env = {
EFLOWCODE_API_KEY = "sk-your-key",
EFLOWCODE_DEFAULT_PROVIDER = "gpt_responses",
EFLOWCODE_BASE_URL = "https://e-flowcode.cc/v1",
EFLOWCODE_MODEL = "gpt-5.5",
EFLOWCODE_NANO_API_KEY = "sk-your-nano-key",
EFLOWCODE_NANO_BASE_URL = "https://e-flowcode.cc",
EFLOWCODE_NANO_MODEL = "nano-banana-pro",
EFLOWCODE_GROK_API_KEY = "sk-your-grok-key",
EFLOWCODE_GROK_BASE_URL = "https://api.x.ai/v1",
EFLOWCODE_GROK_MODEL = "grok-imagine-image-quality",
EFLOWCODE_SAVE_DIR = "~/Pictures/eflowcode-image-out",
EFLOWCODE_SAVE_DIR_ROOT = "~/Pictures/eflowcode-image-out"
}On Windows, use escaped paths:
args = ["C:\\Users\\you\\eflowcode-image-mcp\\server.py"]Add this to your MCP config:
{
"mcpServers": {
"eflowcode-image": {
"command": "python",
"args": ["/absolute/path/to/eflowcode-image-mcp/server.py"],
"env": {
"EFLOWCODE_API_KEY": "sk-your-key",
"EFLOWCODE_DEFAULT_PROVIDER": "gpt_responses",
"EFLOWCODE_BASE_URL": "https://e-flowcode.cc/v1",
"EFLOWCODE_MODEL": "gpt-5.5",
"EFLOWCODE_NANO_API_KEY": "sk-your-nano-key",
"EFLOWCODE_NANO_BASE_URL": "https://e-flowcode.cc",
"EFLOWCODE_NANO_MODEL": "nano-banana-pro",
"EFLOWCODE_GROK_API_KEY": "sk-your-grok-key",
"EFLOWCODE_GROK_BASE_URL": "https://api.x.ai/v1",
"EFLOWCODE_GROK_MODEL": "grok-imagine-image-quality",
"EFLOWCODE_SAVE_DIR": "~/Pictures/eflowcode-image-out",
"EFLOWCODE_SAVE_DIR_ROOT": "~/Pictures/eflowcode-image-out"
}
}
}
}Variable | Required | Default | Description |
| yes for GPT | - | GPT Responses API key used by |
| no |
| Default provider when |
| no |
| GPT Responses base URL without trailing |
| no |
| Responses model used for image generation |
| no | OpenAI no-rewrite prompt | Prefix added to GPT Responses prompts |
| yes for Banana | - | Nano Banana key used only by |
| no |
| Nano Banana base URL; generateContent path is appended automatically |
| no |
| Default Nano Banana model |
| yes for Grok | - | Grok/xAI key used only by |
| no |
| Grok image API base URL. Use |
| no |
| Default Grok image model |
| no |
| Retry count for retryable HTTP failures |
| no |
| Request timeout in seconds |
| no |
| Default output directory |
| no | same as save dir | Sandbox root for output paths |
| no |
| Set to |
Compatibility aliases are also accepted: EF_API_KEY, EF_BASE_URL, EF_MODEL, and OPENAI_API_KEY.
server_infoReturns current mode, base URL, model, save directory, and limits.
image_generateGenerate images from text.
Arguments:
prompt: image prompt
size: optional WxH, default 1024x1024
n: number of images, 1-10
model: optional override
provider: optional gpt / grok / banana override
aspect_ratio: optional provider aspect ratio such as 16:9 or 9:16
image_size: optional Nano Banana size, 1K / 2K / 4K
resolution: optional Grok resolution, 1k / 2k
save_dir: optional output directory under EFLOWCODE_SAVE_DIR_ROOT
basename: optional output filename stem
image_editGenerate a new image using one local image as an input reference.
Arguments include prompt, image_path, optional size, model, provider, aspect_ratio, image_size, resolution, save_dir, and basename.
mask_path is accepted for interface compatibility. The current provider implementations do not upload alpha masks separately; describe the edit area in the prompt.
image_batch_editApply the same edit prompt to multiple images, one request per image.
image_multi_referenceGenerate one new image from 2-10 local reference images.
Grok multi-reference editing supports up to 3 input images.
Text-to-image:
Generate a 16:9 research presentation cover about intelligent optimization algorithms and urban traffic.Image edit:
Edit C:\Pictures\apple.png so the apple becomes blue, keep the white background.Multi-reference:
Use these two product images as references and generate one clean poster in the same style.You can keep prompts natural in MCP clients:
用 GPT 生图：a cinematic city skyline at dawn
用 Grok 生图：a product poster, 16:9
用 Banana 生图：一张 9:16 的柔和摄影风格人像
用 nano-banana-2-4k 生成 9:16 海报Routing rules:
Explicit provider wins. Aliases include gpt, openai, grok, xai, banana, nano, and nano-banana.
Models starting with nano-banana route to Nano Banana automatically.
Models starting with grok route to Grok automatically.
Otherwise the server uses EFLOWCODE_DEFAULT_PROVIDER.
GPT uses /v1/responses with stream=true, tool_choice="required", and the no-rewrite prompt prefix.
Nano Banana uses /v1beta/models/{model}:generateContent and reads images from structured inlineData.
Grok text-to-image uses /v1/images/generations; Grok image editing uses JSON /v1/images/edits with image data URIs in image or images.
If your Grok access is proxied by E-FlowCode rather than xAI directly, set:
EFLOWCODE_GROK_BASE_URL=https://e-flowcode.cc/v1
EFLOWCODE_GROK_MODEL=<model listed by your E-FlowCode key>The server extracts base64 image data from response.output items where:
{
"type": "image_generation_call",
"result": "..."
}If no image result is found, the tool returns a clear error plus a compact response summary.
The multi-provider generation path was smoke-tested with three text-to-image requests per provider, nine requests total:
Provider | Model | Result | Typical latency | Output |
Banana |
| 3/3 successful | 21-23s/image | 1024x1024 JPG |
GPT |
| 3/3 successful | ~20s/image | 1024x1024 PNG |
Grok |
| 3/3 successful | 8-10s/image | JPG, actual size 784x1168 |
Provider API keys are only sent to their configured provider base URLs.
Runtime tools do not accept a base URL parameter, to avoid prompt-injection key exfiltration.
Output paths are restricted to EFLOWCODE_SAVE_DIR_ROOT.
Input images are checked by magic bytes and size limits before upload.
Generated binary responses are capped before writing to disk.
Example files use placeholder keys only. Do not commit real API keys.
MIT
这是一个面向 EFLOWCODE / Grok / Nano Banana 的多模型图像生成 MCP 服务。默认仍通过 Responses API 调用支持 image_generation 工具的 gpt-5.5 模型，也可以通过 provider="grok" 或 provider="banana" 路由到对应生图接口。不传 provider 的旧调用会继续走 GPT Responses。
服务默认调用：
POST {EFLOWCODE_BASE_URL}/responses
model: gpt-5.5
tools: [{"type": "image_generation"}]GPT Responses 默认会在发送给模型前加上英文 no-rewrite 前缀，避免提示词被模型重写。
image_generate：文本生成图像
image_edit：基于单张本地图片进行编辑或参考生成
image_batch_edit：对多张图片逐张执行同一编辑指令
image_multi_reference：使用 2-10 张参考图合成一张新图
provider 路由：支持 gpt、grok、banana / nano-banana
模型名自动路由：grok-* 自动走 Grok，nano-banana-* 自动走 Banana
图片自动保存到本地目录
输出目录沙箱保护，避免写到非预期路径
输入图片格式和大小校验，支持 PNG、JPEG、WebP、GIF
可用于 EFLOWCODE 或任何兼容 /v1/responses 且支持 image_generation 的接口
仓库不会保存 API key；密钥从 MCP 客户端环境变量读取
git clone https://github.com/WenNinghan/eflowcode-image-mcp.git
cd eflowcode-image-mcp
python -m pip install -e .安装后需要把 MCP 服务配置到你的客户端中。
python install.py --api-key sk-your-key --no-claude执行后重启 Codex，然后让 Codex 调用 server_info 验证配置。
安装脚本会把 MCP 配置追加到 ~/.codex/config.toml，并在写入前备份原配置。
把下面内容加入 ~/.codex/config.toml：
[mcp_servers.eflowcode-image]
command = "python"
args = ["/absolute/path/to/eflowcode-image-mcp/server.py"]
env = {
EFLOWCODE_API_KEY = "sk-your-key",
EFLOWCODE_DEFAULT_PROVIDER = "gpt_responses",
EFLOWCODE_BASE_URL = "https://e-flowcode.cc/v1",
EFLOWCODE_MODEL = "gpt-5.5",
EFLOWCODE_NANO_API_KEY = "sk-your-nano-key",
EFLOWCODE_NANO_BASE_URL = "https://e-flowcode.cc",
EFLOWCODE_NANO_MODEL = "nano-banana-pro",
EFLOWCODE_GROK_API_KEY = "sk-your-grok-key",
EFLOWCODE_GROK_BASE_URL = "https://api.x.ai/v1",
EFLOWCODE_GROK_MODEL = "grok-imagine-image-quality",
EFLOWCODE_SAVE_DIR = "~/Pictures/eflowcode-image-out",
EFLOWCODE_SAVE_DIR_ROOT = "~/Pictures/eflowcode-image-out"
}Windows 路径需要转义反斜杠：
args = ["C:\\Users\\you\\eflowcode-image-mcp\\server.py"]在 MCP 配置中加入：
{
"mcpServers": {
"eflowcode-image": {
"command": "python",
"args": ["/absolute/path/to/eflowcode-image-mcp/server.py"],
"env": {
"EFLOWCODE_API_KEY": "sk-your-key",
"EFLOWCODE_DEFAULT_PROVIDER": "gpt_responses",
"EFLOWCODE_BASE_URL": "https://e-flowcode.cc/v1",
"EFLOWCODE_MODEL": "gpt-5.5",
"EFLOWCODE_NANO_API_KEY": "sk-your-nano-key",
"EFLOWCODE_NANO_BASE_URL": "https://e-flowcode.cc",
"EFLOWCODE_NANO_MODEL": "nano-banana-pro",
"EFLOWCODE_GROK_API_KEY": "sk-your-grok-key",
"EFLOWCODE_GROK_BASE_URL": "https://api.x.ai/v1",
"EFLOWCODE_GROK_MODEL": "grok-imagine-image-quality",
"EFLOWCODE_SAVE_DIR": "~/Pictures/eflowcode-image-out",
"EFLOWCODE_SAVE_DIR_ROOT": "~/Pictures/eflowcode-image-out"
}
}
}
}变量 | 是否必填 | 默认值 | 说明 |
| GPT 必填 | - | GPT Responses API key，仅供 |
| 否 |
| 未指定 provider 时的默认生图 provider |
| 否 |
| GPT Responses Base URL，不包含 |
| 否 |
| 用于 Responses 图像生成的模型 |
| 否 | 英文 no-rewrite 前缀 | 自动添加到 GPT Responses 提示词前的前缀 |
| Banana 必填 | - | Nano Banana API key，仅供 |
| 否 |
| Nano Banana Base URL，服务会自动拼接 generateContent 路径 |
| 否 |
| 默认 Nano Banana 模型 |
| Grok 必填 | - | Grok/xAI API key，仅供 |
| 否 |
| Grok 图片 API Base URL；走 E-FlowCode 代理时填 |
| 否 |
| 默认 Grok 图片模型 |
| 否 |
| 可重试 HTTP 失败的重试次数 |
| 否 |
| 请求超时时间，单位秒 |
| 否 |
| 默认图片输出目录 |
| 否 | 同输出目录 | 输出目录沙箱根路径 |
| 否 |
| 设为 |
也兼容 EF_API_KEY、EF_BASE_URL、EF_MODEL 和 OPENAI_API_KEY。
server_info返回当前服务模式、Base URL、模型、保存目录和限制信息。
image_generate根据文本生成图片。
常用参数：
prompt：图片提示词
size：可选，格式为 宽x高，默认 1024x1024
n：生成数量，范围 1-10
model：可选模型覆盖
provider：可选 gpt / grok / banana
aspect_ratio：可选比例，例如 16:9 或 9:16
image_size：Nano Banana 可选尺寸，1K / 2K / 4K
resolution：Grok 可选分辨率，1k / 2k
save_dir：可选输出目录，必须位于 EFLOWCODE_SAVE_DIR_ROOT 下
basename：可选文件名前缀
image_edit使用一张本地图片作为输入参考，结合提示词生成新图。
常用参数包括 prompt、image_path、size、model、provider、aspect_ratio、image_size、resolution、save_dir 和 basename。
mask_path 参数会被保留用于接口兼容。当前 provider 实现不会单独上传 alpha mask。如果需要指定编辑区域，请直接在提示词中描述。
image_batch_edit对多张图片逐张执行同一编辑提示词。每张图片会发起一次独立请求。
image_multi_reference使用 2-10 张本地参考图生成一张新图。
Grok 多图参考编辑最多支持 3 张输入图。
文本生图：
生成一张 16:9 的科研汇报封面图，主题是智能优化算法和城市交通。单图编辑：
把 C:\Pictures\apple.png 里的苹果改成蓝色，保持白色背景。多图参考：
参考这两张产品图，生成一张同风格的干净产品海报。在 Codex 或其他 MCP 客户端里可以直接这样说：
用 GPT 生图：a cinematic city skyline at dawn
用 Grok 生图：a product poster, 16:9
用 Banana 生图：一张 9:16 的柔和摄影风格人像
用 nano-banana-2-4k 生成 9:16 海报路由规则：
显式 provider 优先，别名包括 gpt、openai、grok、xai、banana、nano、nano-banana。
model 以 nano-banana 开头时自动走 Banana。
model 以 grok 开头时自动走 Grok。
都没有指定时走 EFLOWCODE_DEFAULT_PROVIDER。
GPT 使用 /v1/responses，带 stream=true、tool_choice="required" 和 no-rewrite prompt 前缀。
Nano Banana 使用 /v1beta/models/{model}:generateContent，从结构化 inlineData 读取图片。
Grok 文生图使用 /v1/images/generations；Grok 图像编辑使用 JSON /v1/images/edits，图片以 data URI 放在 image 或 images 字段里。
如果你的 Grok 由 E-FlowCode 代理，而不是直接走 xAI 官方接口，请配置：
EFLOWCODE_GROK_BASE_URL=https://e-flowcode.cc/v1
EFLOWCODE_GROK_MODEL=<你的 E-FlowCode key 可用的模型名>服务会从 response.output 中提取如下结构里的 base64 图片：
{
"type": "image_generation_call",
"result": "..."
}如果没有找到图片结果，工具会返回明确错误，并附带简短的响应摘要，方便排查接口兼容性。
多 provider 生图链路已完成稳定性 smoke test：每个 provider 各执行 3 次文本生图，共 9 次请求，全部成功。
Provider | 模型 | 结果 | 典型耗时 | 输出 |
Banana |
| 3/3 成功 | 21-23 秒/张 | 1024x1024 JPG |
GPT |
| 3/3 成功 | 约 20 秒/张 | 1024x1024 PNG |
Grok |
| 3/3 成功 | 8-10 秒/张 | JPG，实际尺寸 784x1168 |
Provider API key 只会发送到对应 provider 的已配置 Base URL
工具运行时不接受动态 Base URL 参数，避免提示词注入导致 key 外泄
输出路径会被限制在 EFLOWCODE_SAVE_DIR_ROOT 下
上传前会校验输入图片的 magic bytes 和文件大小
写入本地前会限制生成图片的响应大小
示例文件只使用占位 key，不要提交真实 API key
MIT
批量单图编辑。对每张图片独立调用 image_edit。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| image_paths | Yes | ||
| size | No | 1024x1024 | |
| model | No | ||
| save_dir | No | ||
| basename | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It only mentions that each image is edited independently, but provides no details on parallelization, error handling, rate limits, or side effects. This is insufficient transparency for a batch operation.
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 at two sentences, with no wasted words. The first sentence states the purpose, the second adds procedural detail. It is front-loaded and efficient.
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 complexity (batch operation, 7 parameters, no schema coverage, no annotations), the description is incomplete. It does not explain behavior like how image paths are processed, parameter effects, or output format, despite having an output schema. A more detailed description is needed for effective use.
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%, so the description must compensate. However, it mentions no parameters whatsoever, offering no additional meaning beyond the parameter names. For a tool with 7 parameters, this is a significant gap.
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 it performs batch editing of single images by calling image_edit for each image. It distinguishes from the sibling image_edit tool which is for single images, so purpose and scope are well-defined.
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 usage for multiple independent edits, but does not explicitly state when to use this versus the alternative image_edit tool. It lacks guidance on prerequisites or scenarios where batch is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
单图参考/编辑。把本地图片作为 Responses image input 传入 image_generation。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| image_path | Yes | ||
| mask_path | No | ||
| size | No | 1024x1024 | |
| model | No | ||
| save_dir | No | ||
| basename | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the tool modifies files, requires authentication, or has rate limits. It merely states a vague transformation without explaining side effects or safety.
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 brief (one sentence), which is concise but lacks structure. It front-loads a verb phrase but fails to elaborate on the tool's functionality or parameters. The sentence mixes Chinese and awkward phrasing, reducing clarity.
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 8 parameters, no annotations, and no schema descriptions, the description is grossly insufficient. It does not explain required inputs, optional parameters, expected output (even though an output schema exists), or usage patterns. Critical gaps leave the agent unable to invoke the tool correctly.
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?
With 0% schema description coverage, the description should compensate by explaining parameters. It only indirectly references 'image_path', ignoring 6 other parameters including 'mask_path', 'size', 'model', etc. No parameter semantics are conveyed.
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 states 'Single image reference/edit' and mentions passing a local image to image_generation, giving a vague sense of purpose. However, it does not clearly differentiate from siblings like 'image_generate' or 'image_batch_edit', and the reference to 'Responses image input' is ambiguous.
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 such as 'image_generate' or 'image_multi_reference'. There is no indication of prerequisites, constraints, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
文本生成图像。使用 gpt-5.5 /v1/responses + image_generation。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| size | No | 1024x1024 | |
| n | No | ||
| model | No | ||
| save_dir | No | ||
| basename | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; description only mentions backend but lacks information on authentication (api_key parameter), rate limits, or side effects. Minimal behavioral disclosure.
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, efficiently stating purpose, but omits essential details, making it too sparse to be truly helpful.
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 7 parameters and output schema present, the description fails to explain usage, parameter roles, save behavior, or output format. Severely incomplete.
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 adds no explanation for any of the 7 parameters. Parameter purposes are entirely implicit from names.
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 generates images from text and mentions the backend (gpt-5.5 /v1/responses + image_generation), distinguishing it from sibling tools like image_edit and image_batch_edit.
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 alternatives like image_edit or image_batch_edit. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
多图参考生成一张新图。把多张本地图片作为 Responses image input。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| image_paths | Yes | ||
| size | No | 1024x1024 | |
| model | No | ||
| save_dir | No | ||
| basename | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info. It only mentions generating a new image from local images, omitting side effects, authentication needs, or output details.
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 concise with two sentences, front-loading the main action. However, it lacks structure and could benefit from more detail without verbosity.
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 (7 parameters, no schema descriptions) and an output schema, the description fails to cover essential aspects like authentication or saving behavior, making it incomplete.
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%, so the description must explain parameters. It only loosely refers to 'image_paths' as local images, leaving the other six parameters (like prompt, size, api_key) unexplained.
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 generates a new image from multiple reference images. However, it does not explicitly differentiate from sibling tools like image_edit or image_generate, which could lead to confusion.
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, nor are there any exclusions or prerequisites mentioned. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
返回 Codex 生图 MCP 的当前配置和能力。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states that the tool returns configuration and capabilities. It does not disclose any behavioral traits such as read-only nature, required permissions, or side effects. Given the lack of annotations, the description is insufficient to understand the tool's behavior fully.
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, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose without 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?
Given the absence of parameters and the presence of an output schema, the description is fairly complete. It indicates what the tool returns, though it could be more precise about the specific configuration details. However, with the output schema available, the agent can infer the return structure.
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?
There are no parameters, and the input schema is empty with 100% description coverage. The description does not need to add parameter information, and the baseline for zero parameters is 4. The description is adequate for the parameter context.
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 that the tool returns the current configuration and capabilities of the Codex image generation MCP. The verb '返回' (return) and resource '当前配置和能力' are specific, and the tool is distinctly different from sibling tools which perform image generation/editing.
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 does not explicitly state when to use this tool versus alternatives. However, the context of sibling tools (image generation/editing) implies that this tool is for querying server info, so the usage is somewhat implied but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0image_batch_editimage_editimage_generateimage_multi_referenceserver_infoEach tool has a distinct purpose: batch editing, single editing, text-to-image generation, multi-reference generation, and server info. No overlap or ambiguity.
Most tools follow 'image_' prefix with verb_noun pattern, but 'server_info' breaks the prefix pattern. Minor inconsistency.
5 tools is well-scoped for an image generation MCP, covering essential operations without being excessive.
Covers generation, editing, batch, and multi-reference. May lack advanced features like deletion or configuration but core workflows are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Qwen Image 3 AI image generation
MCP server for Flux AI image generation
MCP server for NanoBanana AI image generation and editing
MCP server for Midjourney AI image generation and editing
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/EF-FlowCode/eflowcode-image-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server