Editmamei Connect

export_photo

Write the finished photo: every live filter is baked in and ALL metadata (EXIF, XMP, IPTC, GPS, thumbnail) is stripped. jpg, png, webp and tiff are flattened. psd keeps the layers (masks, opacity, blend modes, groups) for finishing in Photoshop or another editor: text becomes pixels, a group carrying its own filter is merged into one layer, and the result lists layers that may blend slightly differently in Photoshop. A PSD is large (about 50 MB per full-size layer on a 24 MP photo), and a download here is capped at 100 MiB. It is for finishing elsewhere: open_photo does not take a PSD. Returns a download_url (valid 24 hours) plus a preview of what was exported. The link is for the user, and also downloads with a plain GET (e.g. curl -sS -o <dest> <download_url>). Transparency is flattened onto white unless keep_alpha is true (png or webp only), which keeps it, e.g. for a cut-out.

Input Schema

Name	Required	Description	Default
`image`	Yes	Image id, as returned by open_photo.
`format`	No	Output format.	jpg
`quality`	No	JPEG/WebP quality, 1-100 (higher = better/larger). Ignored for png/tiff. WebP itself accepts 0 too, but JPEG's own bound is 1-100, so this schema uses the tighter bound.
`filename`	No	Optional name for the downloaded file, e.g. "harbour-warm". The extension is added for you; anything but letters, digits, dot, dash and underscore is replaced.
`lossless`	No	WebP only: lossless encoding. Ignored for other formats.
`bit_depth`	No	PNG/TIFF/PSD only: output bit depth. JPEG/WebP are always 8-bit.
`keep_alpha`	No	PNG/WebP only: keep transparency. The visible layers are merged onto a transparent canvas, so areas no layer covers (a cut-out, say) stay transparent. Default false flattens onto white. Refused for JPEG and TIFF.
`png_compression`	No	PNG only: compression level, 0 (fastest, largest) to 9 (slowest, smallest). The default is lower than the maximum because level 9 is far slower for negligible size gain on a typical photo. Ignored for other formats.
`tiff_compression`	No	TIFF only: compression scheme (lzw and adobe_deflate are lossless; jpeg is lossy). Ignored for other formats.	none

Output Schema

Name	Required	Description
`bytes`	No
`width`	No
`format`	No
`height`	No
`layers`	No	psd only: layers in the file, groups included.
`filename`	No
`expires_at`	No
`download_url`	No
`merged_groups`	No	psd only: groups merged into one layer to keep their filter.
`rasterized_text`	No	psd only: text layers written as pixels.
`may_blend_differently`	No	psd only: visible layers below 100% opacity or with a blend mode, which Photoshop may render slightly differently.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 14, 2026

changedInput schema / properties / bit_depth / description

Previous value: -"PNG/TIFF only: output bit depth. JPEG/WebP are always 8-bit."New value: +"PNG/TIFF/PSD only: output bit depth. JPEG/WebP are always 8-bit."

changedInput schema / properties / format / enum

Previous value: -[
-  "jpg",
-  "png",
-  "webp",
-  "tiff"
-]New value: +[
+  "jpg",
+  "png",
+  "webp",
+  "tiff",
+  "psd"
+]

addedOutput schema / properties / layers

Added value: +{
+  "description": "psd only: layers in the file, groups included.",
+  "type": "number"
+}

addedOutput schema / properties / may_blend_differently

Added value: +{
+  "description": "psd only: visible layers below 100% opacity or with a blend mode, which Photoshop may render slightly differently.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / merged_groups

Added value: +{
+  "description": "psd only: groups merged into one layer to keep their filter.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / rasterized_text

Added value: +{
+  "description": "psd only: text layers written as pixels.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

First observedOct 13, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations: filters are baked in, ALL metadata (EXIF/XMP/IPTC/GPS/thumbnail) is stripped, PSD layer-merge quirks are disclosed, approximate PSD size per layer and the 100 MiB download cap are stated, the download_url lifetime is 24 hours, and transparency defaults to white unless keep_alpha is set. This is exactly the kind of destructive/behavioral detail an agent needs before invoking.

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?

Front-loaded with the core action and format split, and every clause carries real information. It is dense and runs long in places (the PSD layer-merge sentence), but there is little padding to cut.

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

Completeness5/5

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

For a 9-parameter export tool with an output schema, the description supplies the missing operational context: format-specific flattening, size/download limits, link lifetime, and how to fetch the artifact. Nothing an agent needs to call it correctly is absent.

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 already 100%, so the baseline is 3. The prose reinforces rather than extends it — keep_alpha's white-flattening and lossless/bit-depth restrictions largely duplicate the schema, though the explicit 'a download here is capped at 100 MiB' constraint adds a useful non-parameter bound.

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?

States a precise verb+resource (write the finished photo) and immediately qualifies it by format: jpg/png/webp/tiff flattened, psd keeping layers. It distinguishes itself from open_photo and tells the agent exactly which artifact each format produces.

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?

Gives clear context ('for finishing elsewhere') and names the sibling relationship (open_photo does not take a PSD), plus how the returned link is consumed. It stops short of stating when to prefer this over other output-path siblings such as bake or share_edit, so it is a strong 4 rather than a full 5.

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

All Editmamei Connect tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?