Editmamei Connect

place_image

Place another uploaded photo into an open photo as a NEW LAYER (compositing). source is an upload handle "upload:" from request_upload (or the name of one of your uploads); a built-in sample photo listed by inspect what=uploads also works. Optional x, y, width, height, name and position work as for layer op=create. For a cut-out: place, then select_with_ai target=subject with that layer, then layer_mask op=create from the channel. If the file holds several pictures (a multi-page TIFF), only ONE is placed (not a flattened composite). On this server the placed layer's scaled box must stay within the workspace's pixel limit (less at a higher bit depth), and a photo's layers together within its layer limit. Uploads and open photos belong to this server; a photo opened through another Editmamei connector stays with that connector.

Input Schema

Name	Required	Description
`x`	No	The new layer's ABSOLUTE horizontal offset in document pixels (not a delta).
`y`	No	The new layer's ABSOLUTE vertical offset in document pixels (not a delta).
`name`	No	The new layer's name. Defaults to the source file's own base filename. Every case enforces a unique name, suffixing " 2", " 3", ... if the name is already taken.
`image`	Yes	Image id, as returned by open_photo.
`width`	No	Scale the placed layer to this width. With height, stretches to exactly that box. Alone, height is derived to keep the source file's own aspect ratio. Omit both to place at the source file's natural size.
`height`	No	Scale the placed layer to this height. See width.
`source`	Yes	"upload:<upload_id>" (the name of one of your uploads also works).
`position`	No	Index within the target parent's (or top-level) stack, 0 = topmost.
`parent_group`	No	The group layer_id to insert the new layer into (omit for top-level).

Output Schema

Name	Required	Description
`x`	No
`y`	No
`name`	No
`width`	No
`height`	No
`layer_id`	No
`parent_group`	No
`baked_filters`	No	Names of the placed layer's own live filters that were baked into its pixels before placing. Omitted when the source layer had none.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (which only flag it as a writable, non-idempotent, open-world op), the description discloses multi-page TIFF handling (only ONE picture placed), workspace pixel/layer limits that constrain placement, and the server-scoping of uploads versus other connectors. These are non-obvious behavioral constraints an agent could not infer from structured fields.

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 purpose is front-loaded, then details follow in a logical order (source, geometry, cut-out recipe, multi-page caveat, limits). It is dense and long, but nearly every clause carries information; a small amount could be trimmed without loss.

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, non-idempotent compositing tool with an output schema already present, the description covers the source contract, geometric defaults, edge cases (multi-page files), workflow integration, and resource limits. Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3, but the description adds meaning by mapping x/y/width/height/name/position to the semantics of 'layer op=create' and restating the 'upload:<id>' source format. This cross-references an existing contract rather than merely echoing the schema.

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?

The first sentence states a specific verb and resource ('Place another uploaded photo into an open photo as a NEW LAYER') and even parenthetically frames the operation as compositing, which distinguishes it from adjustment/filter siblings. An agent can tell what this does without opening 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 Guidelines4/5

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

It explains the source format (upload handle from request_upload, or a built-in sample via inspect what=uploads) and gives an explicit workflow recipe for cut-outs using select_with_ai and layer_mask. It references 'layer op=create' as the semantic model but never states when NOT to use this tool versus those siblings, so it stops short of full alternative routing.

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?