Editmamei Connect

canvas_size

Destructive

Extend the canvas: grow it and reposition the existing content within the larger frame. It never shrinks (use crop for that): REFUSED when either dimension would be smaller than the current one, and when neither dimension actually grows. Choose where the existing content lands with anchor (a 3x3 grid, default 'center') or explicit offset_x / offset_y; give one or the other, not both. fill sets a solid backdrop layer under the WHOLE canvas: white, black, a '#rrggbb' hex color (rendered as luminance on a grayscale photo), or transparent (the default, which adds no backdrop layer at all; see the field description for what that means at export time). IRREVERSIBLE in this session: there is no undo, so make a checkpoint first when in doubt. REFUSES when the photo has a masked filter, or any filter made outside Editmamei, AND the existing content actually moves (offset_x / offset_y not both 0; a top-left anchor never moves anything): extend the canvas before adding masked filters, not after, because a filter's mask does not travel with the layer it confines when the canvas repositions it. An unmasked effect (a vignette and friends) is unaffected. On this server the new canvas must stay within the workspace's pixel limit (less at a higher bit depth).

Input Schema

Name	Required	Description	Default
`fill`	No	'white', 'black', a '#rrggbb' hex color, or 'transparent' (default — no fill layer is added at all; see the note on export_photo/flatten below). Any other choice is painted onto a new, full-canvas layer inserted at the BOTTOM of the whole stack — a solid backdrop behind every existing layer, not just the newly added area, so it also shows through any pre-existing transparency in those layers. On a GRAYSCALE image a hex color renders as its LUMINANCE (a weighted gray, not one channel picked out). transparent: genuinely transparent only in a live, layered document — export_photo and layer op=flatten both flatten first, which fills any transparent area with the ambient background color (white, unchanged by this tool) and drops alpha, not with transparency. A non-transparent fill on an INDEXED image is REFUSED outright, before the canvas resizes at all — indexed has no backdrop layer type to add.	transparent
`image`	Yes	Image id, as returned by open_photo.
`width`	Yes	New canvas width, in pixels. Must be at least the current width, and at least one of width/height must actually be LARGER than the current size (both equal to the current size is refused — there is nothing to extend).
`anchor`	No	Where the existing content sits within the new, larger canvas — a 3x3 grid. Defaults to 'center' when neither this nor offset_x/offset_y is given. Mutually exclusive with offset_x/offset_y.
`height`	Yes	New canvas height, in pixels. Must be at least the current height. See width.
`offset_x`	No	Explicit horizontal offset (document pixels) for the existing content's left edge in the new canvas, instead of an anchor — must be between 0 and (new width - current width). Requires offset_y too; mutually exclusive with anchor.
`offset_y`	No	Explicit vertical offset for the existing content's top edge, instead of an anchor — must be between 0 and (new height - current height). Requires offset_x too; mutually exclusive with anchor.

Output Schema

Name	Required	Description	Default
`width`	No
`height`	No
`offset_x`	No
`offset_y`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

changedInput schema / properties / fill / description

Previous value: -"'white', 'black', a '#rrggbb' hex color, or 'transparent' (default — no fill layer is added at all; see the note on export_photo/flatten below). Any other choice is painted onto a new, full-canvas layer inserted at the BOTTOM of the whole stack — a solid backdrop behind every existing layer, not just the newly added area, so it also shows through any pre-existing transparency in those layers. On a GRAYSCALE image a hex color renders as its LUMINANCE (a weighted gray, not one channel picked out). transparent: genuinely transparent only in a live, layered document (e.g. saved via save_project) — export_photo and layer op=flatten both flatten first, which fills any transparent area with the ambient background color (white, unchanged by this tool) and drops alpha, not with transparency. A non-transparent fill on an INDEXED image is REFUSED outright, before the canvas resizes at all — indexed has no backdrop layer type to add."New value: +"'white', 'black', a '#rrggbb' hex color, or 'transparent' (default — no fill layer is added at all; see the note on export_photo/flatten below). Any other choice is painted onto a new, full-canvas layer inserted at the BOTTOM of the whole stack — a solid backdrop behind every existing layer, not just the newly added area, so it also shows through any pre-existing transparency in those layers. On a GRAYSCALE image a hex color renders as its LUMINANCE (a weighted gray, not one channel picked out). transparent: genuinely transparent only in a live, layered document — export_photo and layer op=flatten both flatten first, which fills any transparent area with the ambient background color (white, unchanged by this tool) and drops alpha, not with transparency. A non-transparent fill on an INDEXED image is REFUSED outright, before the canvas resizes at all — indexed has no backdrop layer type to add."

First observedOct 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructive=true and idempotent=false, but the description goes well beyond them: no undo in this session, refusal on masked/foreign filters, workspace pixel limits at higher bit depths, and the filter-mask-doesn't-travel caveat. This is unusually rich behavioral disclosure.

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 purpose and constraint-first ordering, and most sentences carry non-obvious refusal/caveat information. It is dense and slightly repetitive of the schema's fill wording, but little is genuinely wasted.

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?

With an output schema present, the description needn't explain returns, and it covers everything else an agent needs: refusal triggers, irreversibility, anchor/offset exclusivity, fill layering, and ordering relative to filters.

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 coverage is 100% and the field descriptions are themselves detailed (fill semantics, mutual exclusivity, offset bounds). The description restates rather than extends: 'give one or the other, not both' and the anchor grid are already in the schema, and the long fill parenthetical duplicates the field description.

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 specific verb+resource ('Extend the canvas: grow it and reposition the existing content') and immediately disambiguates from the sibling `crop` since it 'never shrinks'. An agent can tell exactly what this does without reading the schema.

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

Usage Guidelines5/5

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

Explicitly routes shrinking to `crop`, tells the agent to run `checkpoint` first when in doubt, and gives the ordering rule (extend the canvas before adding masked filters, not after). Refusal conditions (no growth, masked filters with content movement) are spelled out as when-not-to-constraints.

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?