Skip to main content
Glama

photo_effect

Idempotent

Effects on a photo in one call, as named layers (nothing is flattened): type says which. It makes no file: call export_photo afterwards for a download link. Each takes a checkpoint first and puts the image back if anything fails; running it again replaces its earlier layer, and strength 0 removes it. A multi-layer image needs layer. type=background_blur: portrait mode. The server finds the subject with the selection service, copies the photo layer as "Background blur" directly above it, blurs the copy with a live Gaussian blur and hides the blur over the subject with a layer mask (the inverted subject, pulled in 1-2 px from its edge and feathered, so the subject's edge stays the original). strength 0-100 (default 50) sets the blur radius from 0.3% to 2.5% of the image's long side. It leaves the channels "Portrait subject" and "Portrait blur mask" on the image (replacing channels called that); a layer you named "Background blur" yourself is left alone. Known gap: the subject's colours can bleed a little into the blur right at its edge. type=skin: smooth skin for portraits and influencer shots. The server finds the person with the selection service, finds the skin inside them by colour (a YCbCr rule on a small render of the photo, cleaned up), copies the photo layer as "Skin smoothing" directly above it, smooths the copy with a live edge-preserving surface blur plus a faint grain (so the skin keeps some texture) and shows it only through the feathered skin mask. Eyes, lips and hair mostly fall outside the colour rule, and the blur keeps hard edges. strength 0-100 (default 50) sets the copy's opacity from 0 to 85% and its blur radius from 0.25% to 0.6% of the image's long side (at most 6 px, the effect's limit). It leaves the selection channels "Skin subject", "Skin" and "Skin mask" on the image, and replaces channels already called that; a layer you named "Skin smoothing" yourself is left alone (the new one gets another name). Known gaps: skin is found by colour, so skin-toned areas that are not skin (a wooden wall, an orange shirt) inside the person get smoothed too, and very pale, very dark or heavily tinted skin can be missed. For background_blur and skin: if the subject lies on its side or upside down, say which edge its top points toward with subject_up. type=sky: replace the sky. You supply the sky photo in sky (an upload handle from request_upload, or an https:// image URL); no sky images are bundled. The server selects the sky with the selection service (it refuses when less than 3% of the photo is sky), places the sky photo as the layer "New sky" above the photo, scaled to cover the sky's box without distortion, masks it with the feathered sky channel, then nudges the foreground's colour toward the new sky's average colour with live curve filters confined to everything but the sky. strength 0-100 (default 70) scales that nudge: at 100 the foreground moves 25% of the way, and never more than 24 levels in a channel; 0 leaves the foreground alone. It leaves the channels "Sky", "Sky mask" and "Sky foreground" on the image (replacing channels called that); a layer you named "New sky" yourself is left alone. Known gaps: the old sky can show as a thin fringe along fine edges, and the foreground light is not relit.

Input Schema

NameRequiredDescriptionDefault
skyNotype=sky only (required there): the new sky photo, "upload:<id>" or an https:// image URL.
typeYesWhich effect: background_blur, skin or sky.
imageYesImage id, as returned by open_photo.
layerNoLayer name; required when the image has more than one layer.
strengthNoHow strong the effect is, 0 to 100; 0 removes it. Default by type: background_blur 50, skin 50, sky 70.
subject_upNotype=background_blur and type=skin only: which edge of the image the subject's head/top points toward, if not the top.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Despite annotations covering read-only, destructive, and idempotent hints, the description adds rich behavioral context: checkpoint/rollback on failure, layer replacement on re-run, strength=0 removal, channel side effects, layer naming collisions, and known gaps. This goes well beyond what annotations provide and gives an agent confidence about mutating behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the overall purpose but then becomes extremely long, diving into implementation details (YCbCr rules, channel names, exact blur percentages) that an agent may not need for tool selection. It is well-structured by type but likely contains more detail than necessary for efficient invocation.

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?

Given the tool's high complexity (three effect types, layer handling, external upload dependency, no output schema), the description is remarkably complete: it covers parameter requirements, side effects, failure recovery, and known limitations. An agent has all information needed to call the tool correctly.

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 description coverage is 100%, so the baseline is 3. The description adds substantial meaning beyond schema text—e.g., how strength maps to blur radius, opacity, and curve intensity per type—plus the requirement conditions for `sky`, `layer`, and `subject_up`. This extra semantic depth warrants a 4, though the schema already covers the basic parameter purpose.

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 description states a specific verb ('Effects on a photo'), resource ('photo'), and output form ('as named layers, nothing is flattened'), immediately distinguishing it from tools that bake or flatten. It also names a required follow-up sibling (export_photo), so an agent can place it correctly in a workflow.

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?

The description clearly indicates when each effect type is appropriate (portrait mode, skin smoothing, sky replacement) and states that export_photo is needed for a file. However, it does not explicitly compare itself to sibling effect tools like add_effect or apply_look, leaving some alternative selection to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources