Reel-E

Edit a photo

request_photo_edit

Destructive

Edit one listing photo: how it looks or what is in it. enhance (brighter, sharper, better color), declutter, twilight (dusk or night look, lights on; interiors too), day (daytime, blue sky), stage (virtual staging in a style) or custom (describe the change in instructions: remove or add an object, swap a finish). Use it for the shot the person named or is on. The shot then shows the edited photo (kept in the photo's history) and its clip is remade from it by itself. Uses 1 photo edit once approved; on an AI+ shot the AI+ clip is remade too (1 AI+ credit), and the confirmation says so. On a Full control connection it starts at once; otherwise it returns a confirmationId and waits for the owner's yes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "listingId": "<listingId>",
      "photoId": "<photoId>",
      "edit": "<edit>"
    },
    "name": "request_photo_edit"
  }
}

Input Schema

Name	Required	Description
`edit`	Yes	The kind of edit: enhance, declutter, twilight, day, stage or custom.
`style`	No	Staging style, for edit=stage. Default modern_minimal.
`photoId`	Yes	A photo: its photoId from the edit summary, or its play position like "shot 3".
`listingId`	Yes	Listing id from list_listings.
`instructions`	No	For stage, the style; for custom, the change in plain words.

Output Schema

Name	Required	Description	Default
`status`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 10, 2026

addedInput schema / properties / edit / description

Added value: +"The kind of edit: enhance, declutter, twilight, day, stage or custom."

addedInput schema / properties / instructions / description

Added value: +"For stage, the style; for custom, the change in plain words."

First observedNov 9, 2026

TDQS

A4/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing cost ('Uses 1 photo edit once approved', plus 1 AI+ credit on an AI+ shot), the approval lifecycle (starts immediately on Full control, otherwise returns a confirmationId and waits for the owner), and the side effects (edited photo kept in the photo's history, clip remade). This makes the destructiveHint=true and non-idempotent profile understandable rather than mysterious.

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-loads the edit taxonomy and then layers cost, side effects, and the confirmation path in a tight sequence; almost every clause carries information. Minor drag from awkward phrasing ('its clip is remade from it by itself') and the compressed single-paragraph packing of four distinct concerns.

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

Completeness4/5

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

For a mutating, credit-consuming tool with an output schema, the description covers the essentials an agent needs: what each edit does, what gets charged, and how approval gating works. It does not say whether an edit can be reverted from history or what happens on failure/insufficient credits.

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 baseline is 3, but the description adds real meaning on top: it explains what custom instructions should contain ('remove or add an object, swap a finish'), notes twilight applies to interiors too, and clarifies that style/instructions are the staging inputs. It stops short of documenting the photoId position syntax or listingId sourcing, which the schema already covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Edit one listing photo') and enumerates the six edit kinds with a short gloss for each (enhance, declutter, twilight, day, stage, custom), so an agent knows exactly what operations are offered. It does not name or distinguish itself from close siblings such as replace_photo or set_edit_style, which is the only thing keeping it from a 5.

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

Usage Guidelines3/5

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

'Use it for the shot the person named or is on' is the only selection guidance, and it addresses which photo, not which tool. There is no explicit when-not or alternative routing (e.g., replace_photo for a different image, set_edit_style for defaults), so usage must be inferred from the enumerated edits plus the approval flow.

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

All Reel-E 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?