Skip to main content
Glama
yuluo688

gen-image MCP

by yuluo688
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

edit_image

Applies text-guided edits to local images and writes the result to a specified file or directory.

Instructions

Edit or combine local images with POST /v1/images/edits (multipart). Use for gpt-image-2 image-to-image. Do not set input_fidelity for gpt-image-2.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
maskNoOptional local mask image path
sizeNoOutput size, e.g. auto or 1024x1024. Defaults to auto.
modelNoConfigured model to start with. Defaults to the first model configured for this tool.
imagesYesLocal image file paths to send as repeated multipart field `image` (max 16).
promptYesEdit instruction
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 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"
+}
    • addedInput schema / properties / images / items / minLength
      Added value: +1
    • addedInput schema / properties / mask / minLength
      Added value: +1
    • changedInput schema / properties / size / description
      Previous value: -"Output size"New value: +"Output size, e.g. auto or 1024x1024. Defaults to auto."
    • addedInput schema / properties / size / pattern
      Added value: +"^(auto|[1-9]\\d*x[1-9]\\d*)$"
  2. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description is the only source of behavioral info. It discloses the API endpoint and multipart format, and warns about a specific parameter conflict, adding value. However, it doesn't mention error handling, permissions, or output behavior beyond writing to output_path.

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

Conciseness4/5

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

The description is two sentences, reasonably concise and front-loaded with the main purpose. The warning about input_fidelity is valuable. Could be slightly more efficient by integrating the API endpoint into the first sentence, but no waste.

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

Completeness3/5

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

Given 9 parameters, some complex (filename, output_path), the description doesn't provide additional context beyond the schema, which is quite detailed. The absence of output schema and annotations means the description does not clarify what the tool returns, but the schema covers most parameters. It's adequate but could hint at typical use cases or error scenarios.

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

Parameters2/5

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

Schema coverage is 100%, so parameter descriptions are thorough. The tool description adds minimal extra semantics beyond the schema, only noting that images are sent as repeated multipart field `image` (in schema) and the input_fidelity warning. It doesn't clarify relationships between parameters or edge cases beyond what's already in schema.

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

Purpose4/5

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

The description clearly states the tool edits or combines local images via a specific API endpoint and mentions a specific model. It distinguishes itself from generate_image and generate_gemini_image by focusing on image-to-image editing rather than generation. However, it doesn't explicitly name the alternative tools for clarity.

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?

The description says 'Use for gpt-image-2 image-to-image', which provides clear context for when to use this tool, and warns against setting input_fidelity for gpt-image-2. It doesn't explicitly state when not to use it or mention alternatives, but the context implies generation tools are for other cases.

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