Editmamei Connect

transform_image

Destructive

Rotate or flip the whole photo: op 'rotate' (any degrees, so you can straighten, plus expand) or 'flip' (orientation horizontal or vertical). 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: straighten and flip before adding masked filters, not after (crop is the one geometry change that is always safe afterward). A rotate by anything other than exactly 0/90/180/270 degrees is also refused while a position- or direction-dependent filter is present, since only a right angle keeps such a filter locked to the content: rotate at a right angle instead, or delete the filter (manage_filters op=delete) and re-add it afterwards. expand resizes the canvas to the rotated content's new bounds (like 'reveal all'); without it the corners fall outside the canvas and are cropped. Rotating a very large photo can take tens of seconds; if it times out the editing session restarts and unsaved work (filters, masks, any other open photo) is lost, so make a checkpoint first. With expand the rotated canvas must stay within the workspace's pixel limit.

Input Schema

Name	Required	Description
`op`	Yes	'rotate' takes an arbitrary `degrees` (straighten) + `expand`. 'flip' takes `orientation`.
`image`	Yes	Image id, as returned by open_photo.
`expand`	No	rotate only. Resize the canvas to the rotated content's new bounds. Without it, rotated content can fall outside the original canvas and be cropped.
`degrees`	No	rotate only. Arbitrary angle (straighten), not limited to 90° multiples. Positive rotates clockwise.
`orientation`	No	flip only.

Output Schema

Name	Required	Description
`width`	No
`height`	No
`degrees`	No
`effect_update_failures`	No	Names of effect filters (position/direction/size-dependent ones tracked through geometry changes — a center, an angle, an offset, or a size-dependent blur radius under resize) whose own params could not be updated for this transform (a live update failure) -- they were restored to their OLD values in manage_filters's own ledger (guaranteed), and the live render was also asked to restore those same OLD values (best effort — it can, rarely, also fail). Omitted when every filter updated cleanly.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructive/irreversible, but the description adds concrete failure modes beyond them: refusal with masked or externally-created filters, refusal of off-right-angle rotation when position/direction-dependent filters exist, timeout causing session restart and loss of unsaved work, and the workspace pixel limit with expand. This is rich behavioral context an agent cannot infer from the 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?

Front-loaded with the core action and op semantics before the constraint warnings, and each sentence earns its place (refusals, data-loss, pixel limits). It is dense and long for one tool, but not padded or redundant.

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?

An output schema exists, so return values need not be described. Given a destructive geometry tool with refusal conditions and timeout risk, the description covers edge cases, ordering constraints, and data-loss scenarios thoroughly.

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 100%, so the schema already documents all five params. The description nonetheless adds useful meaning: expand is characterized as 'like reveal all' with the consequence that corners fall outside the canvas without it, and degrees is framed as arbitrary straightening. This exceeds the baseline without fully duplicating 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?

Opens with a specific verb+resource ('Rotate or flip the whole photo') and disambiguates the two ops with their parameters. It also names sibling operations it is not (crop, manage_filters), so an agent can distinguish it from adjacent tools without opening a 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?

Gives explicit ordering rules ('straighten and flip before adding masked filters, not after'), routing to alternatives (rotate at a right angle instead, or delete the filter via manage_filters), and a prerequisite ('make a checkpoint first when in doubt'). When/when-not/alternatives are all present.

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?