Skip to main content
Glama
DanCommitsGit

openai-mcp

by DanCommitsGit
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Edit image

edit_image
Destructive

Edit or combine existing images with a text prompt using OpenAI image models, optionally guided by a mask. Results are saved to disk and returned as file paths, or as inline base64 data.

Instructions

Edit or combine existing images using a text prompt and an OpenAI image model. By default returns the local file path(s) the result was saved to rather than inline image data; set returnAs to 'base64' for inline data instead

Input Schema

NameRequiredDescriptionDefault
nNoNumber of edited images to generate (1-10)
maskNoOptional PNG mask, as an http(s) URL or a file path, with the same dimensions as the first image. Fully transparent areas mark where the image should be edited
sizeNoImage dimensions. GPT image models accept 1024x1024, 1536x1024, 1024x1536, or auto; dall-e-2 accepts 256x256, 512x512, or 1024x1024
modelYesOpenAI model to use for image editing. GPT image models and dall-e-2 support editing; dall-e-3 does not
imagesYesImages to edit, each as an http(s) URL or a file path on this server's filesystem. GPT image models accept up to 16 PNG, WEBP, or JPEG files under 50MB; dall-e-2 accepts a single square PNG under 4MB
promptYesDescription of the edit to make
returnAsNoHow to return edited images. 'path' (default) saves each image to disk and returns its file path, avoiding the large inline payloads that can exceed an MCP client's tool result size limit. 'base64' returns the image data inline instead, which is more likely to hit that limit for anything but small imagespath
outputPathNoFile path to save the image to when returnAs is 'path'. Ignored when returnAs is 'base64'. If n > 1, a 1-based index is inserted before the file extension for each image. Defaults to a temp file if omitted

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false and destructiveHint=true; the description adds genuinely useful context by disclosing that results are written to disk and returned as file paths by default, with the client result-size limit as the rationale for that default. It stops short of warning that writing to outputPath may overwrite an existing file, which is the specific behavior the destructiveHint implies.

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, zero filler, with the core action stated first and the return-mode caveat second. Every clause carries information the agent needs before calling.

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

Completeness4/5

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

With 8 parameters, full schema coverage and no output schema, the description covers purpose and output form adequately. The remaining gap is file-side-effect semantics (overwrite behavior on outputPath, where temp files land), which matters for a tool flagged destructive.

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% and the schema already explains returnAs, outputPath, model compatibility and size constraints in detail. The description's returnAs explanation mostly restates the schema's own rationale, so it adds little beyond structured fields – baseline 3 applies.

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?

States a specific verb ('Edit or combine') and resource ('existing images') plus the underlying capability (text prompt + OpenAI image model). It implicitly distinguishes itself from the sibling generate_image (which creates new images), but never names that sibling explicitly.

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

Usage Guidelines3/5

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

Usage is only implied by the word 'existing' – an agent must infer that this tool is for transforming supplied images rather than creating new ones, and that generate_image is the alternative. No explicit when-to-use / when-not-to-use guidance is given.

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