Reel-E

AI Seamless

request_ai_seamless

Destructive

AI Seamless is one continuous generated camera move from a shot into the shot right after it, steered by an optional prompt: walking through a doorway, turning from one view of a room to another (a 90 or 180 degree turn between two photos of the same space), flying from an aerial down to the front door. It joins two Standard shots next to each other anywhere from shot 2 to the second to last shot (the first cut and the last cut stay clean cuts), a shot can be in only one AI Seamless pair, and an AI+ shot or a Boomerang cannot be part of one. To join the opening photo, another shot has to open the video first. afterPhotoId is the first shot of the pair. Uses 1 AI+ credit once approved; a pair it cannot join is refused before anything runs, with the reason. 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>",
      "afterPhotoId": "<afterPhotoId>"
    },
    "name": "request_ai_seamless"
  }
}

Input Schema

Name	Required	Description
`prompt`	No	Optional: the camera move between the two shots, like 'walk through the doorway'.
`listingId`	Yes	Listing id from list_listings.
`afterPhotoId`	Yes	A photo: its photoId from the edit summary, or its play position like "shot 3".

Output Schema

Name	Required	Description	Default
`status`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

addedInput schema / properties / prompt / description

Added value: +"Optional: the camera move between the two shots, like 'walk through the doorway'."

First observedNov 9, 2026

TDQS

A4/5.0

Behavior3/5

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

Beyond the annotations it discloses cost (1 AI+ credit once approved), that invalid pairs are refused pre-flight with a reason, and the approval flow (instant on Full control, otherwise a confirmationId awaiting owner approval) - strong additions. However, it never confirms the destructiveHint=true consequence: that the existing cut between the two shots is replaced by generated content. With annotations covering mutation/idempotency, this is above baseline but not complete.

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 content is front-loaded with the core concept first, and nearly every clause carries a real constraint. But it is delivered as a single sprawling run-on chain with nested parentheticals and mid-sentence topic shifts (eligibility, credits, approval flow), which makes it harder to scan than a few structured sentences would be.

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?

An output schema exists, so return values need not be explained, and the description covers eligibility, cost, failure, and approval paths thoroughly. The remaining gap is the effect on the underlying timeline - whether the two source shots remain or the transition replaces the cut - which matters for a destructiveHint=true tool.

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%, so the schema already explains all three parameters, including the 240-character prompt with its own example. The description adds one genuinely new fact - that afterPhotoId is the first shot of the pair - which the schema does not state, but otherwise restates prompt behavior at baseline.

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 defines a specific action and artifact: one continuous generated camera move joining a shot to the shot immediately after it, with concrete examples (doorway walk, 90/180 degree turn, aerial-to-front-door). It also distinguishes itself from sibling `request_ai_plus` by stating that an AI+ shot or Boomerang cannot participate in a Seamless pair.

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?

It gives explicit eligibility rules: pairs may start anywhere from shot 2 to the second-to-last shot, the first and last cuts stay clean, a shot belongs to at most one pair, and joining the opening photo requires another shot to open the video. Exclusions (AI+, Boomerang) are stated directly, leaving little inference for the agent.

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?