TokenLab MCP Server

Edit image

edit_image_file

Edit existing images by uploading source files or passing image URLs with a prompt for supported GPT Image models; optionally apply masks and set output format.

Instructions

Edits an image using multipart image uploads, JSON image URLs, or the official JSON images array for supported GPT Image models.

Input Schema

TableJSON Schema

Name	Required	Description
`n`	No
`mask`	No	Pass local file path.
`size`	No
`user`	No
`async`	No
`image`	No	Source image file(s). Repeat image for multiple source images. GPT Image edits accept up to 16 imag…
`model`	Yes	Model to use for image edits. Send this explicitly, for example gpt-image-2.
`prompt`	Yes
`image[]`	No	Alternative repeated multipart field name for multiple source images. The same model-specific limit…
`quality`	No
`background`	No
`moderation`	No
`resolution`	No
`compression`	No
`aspect_ratio`	No
`output_format`	No
`response_format`	No
`output_compression`	No
`X-TokenLab-Delivery-Policy`	No	Per-request Delivery policy. Overrides the API key and Workspace defaults. Auto tries TokenLab Veri…

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.6.24Oct 2, 2026

addedInput schema / properties / X-TokenLab-Delivery-Policy

Added value: +{
+  "description": "Per-request Delivery policy. Overrides the API key and Workspace defaults. Auto tries TokenLab Veri…",
+  "enum": [
+    "auto",
+    "verified",
+    "official"
+  ],
+  "type": "string"
+}

changedInput schema / properties / image / description

Previous value: -"Source image file(s). Repeat image for multiple source images. GPT Image edits accept up to 16 images; xAI Grok Imagine edit models accept at most 3 source images. Pass local file paths."New value: +"Source image file(s). Repeat image for multiple source images. GPT Image edits accept up to 16 imag…"

changedInput schema / properties / image[] / description

Previous value: -"Alternative repeated multipart field name for multiple source images. The same model-specific limits apply: GPT Image up to 16, xAI Grok Imagine up to 3. Pass local file paths."New value: +"Alternative repeated multipart field name for multiple source images. The same model-specific limit…"

Changed3 schema fields changedv0.6.4Jul 25, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedInput schema / properties / n / maximum
```
Removed value: -9007199254740991
```

removedInput schema / properties / stream

Removed value: -{
-  "const": false,
-  "description": "Image streaming is not exposed through MCP tool calls; omit stream or set it to false.",
-  "type": "boolean"
-}

Addedv0.3.1Jul 10, 2026

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), lowering the bar. The description adds one genuine behavioral fact — that edits are only supported for certain GPT Image models — but says nothing about the async flag, cost implications, rate limits, or what happens to the source file, leaving significant behavior unexplained.

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?

A single front-loaded sentence with no filler; the input-mode clause is the most useful information and leads. It is arguably too terse for a 19-parameter tool, but nothing is wasted.

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?

For a 19-parameter, open-world mutation tool with no output schema and only 26% schema coverage, the description is far too thin. An agent cannot determine what most parameters do, how async mode behaves, or what the delivery-policy header affects without opening the schema.

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 description coverage is only 26% across 19 parameters, so the description is expected to compensate. It clarifies the three source-image input forms (multipart 'image', repeated 'image[]', JSON array), which is useful, but the other ~15 parameters (size, quality, background, moderation, output_format, async, delivery policy) get no explanation in either place.

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 and resource ('Edits an image') and adds the distinguishing detail that it accepts multipart uploads versus JSON image URLs, which hints at how it differs from the plain edit_image sibling. It stops short of naming the sibling or stating the selection rule explicitly.

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

Usage Guidelines2/5

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

The mention of input transport modes implies a file-upload context, but there is no explicit when-to-use guidance, no statement of when to prefer edit_image or create_image_file instead, and no prerequisites or exclusions. The agent must infer routing from the tool name alone.

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

Edit image

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools