Skip to main content
Glama
yuluo688

gen-image MCP

by yuluo688
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

generate_image

Generate images from text prompts using OpenAI's Images API, save output locally, and switch to fallback models when an upstream request fails.

Instructions

Generate images with POST /v1/images/generations (OpenAI Images API). Use for gpt-image-2 and other Images-only models. Do not send those models to chat completions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nNoNumber of images, 1-4. Default 1.
sizeNoOutput size, e.g. auto or 1024x1024. Defaults to auto.
modelNoConfigured model to start with. Defaults to the first model configured for this tool.
promptYesText prompt for image generation
qualityNoImage quality
filenameNoOptional AI-chosen basename (Unicode allowed, up to 200 UTF-8 bytes, optional extension). Requires output_path to be a directory. Existing names get numbered suffixes instead of being overwritten. Unsafe names are rejected before generation, not rewritten.
output_pathYesFile or directory to write. Relative paths resolve against process.cwd().
auto_fallbackNoTry the next configured model after an upstream failure. Overrides GEN_IMAGE_AUTO_FALLBACK.
output_formatNoOutput encoding. Omit to let the upstream service decide the format.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.2.2
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / filename
      Added value: +{
+  "description": "Optional AI-chosen basename (Unicode allowed, up to 200 UTF-8 bytes, optional extension). Requires output_path to be a directory. Existing names get numbered suffixes instead of being overwritten. Unsafe names are rejected before generation, not rewritten.",
+  "type": "string"
+}
    • changedInput schema / properties / output_format / description
      Previous value: -"Output encoding. Default png."New value: +"Output encoding. Omit to let the upstream service decide the format."
    • addedInput schema / properties / size / pattern
      Added value: +"^(auto|[1-9]\\d*x[1-9]\\d*)$"
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral disclosure burden. It only states the endpoint and intended models, and does not disclose that the tool writes files to output_path, how overwrites or filenames behave, or what the response contains. Those details live in the schema, not in the behavioral description.

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

Conciseness5/5

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

Two sentences with no filler. The core action and endpoint are front-loaded, followed by the important routing guidance about Images-only models and the chat-completions exclusion.

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

Completeness2/5

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

This is a 9-parameter tool with no annotations and no output schema, yet the description does not explain return values, file-writing behavior, or how it relates to edit_image. It is enough to identify the tool, but not enough to invoke it confidently without relying heavily on schema inspection.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline of 3 applies. The description adds no parameter-level meaning; all parameter semantics are already provided by the input schema.

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

Purpose5/5

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

The description names a specific operation (generate images), the exact endpoint (POST /v1/images/generations), and scopes which models it applies to (gpt-image-2 and other Images-only models). This clearly separates it from generate_gemini_image and edit_image.

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

Usage Guidelines4/5

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

It gives a clear usage context: use for Images-only models, not for chat completions. It does not explicitly compare against the sibling image tools, but the model and endpoint guidance largely disambiguates when this tool should be selected.

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

Deploy Server

Other Tools