Reel-E

Review revision notes

review_revision_notes

Read-onlyIdempotent

Takes the person's notes that point at times in the video, like 'at 0:28 a weird blur with the plant and the blue chair' or 'at 0:33 remove the older gentleman', passed in their own words. Notes without a time work when the words name the shot ('drop the closet shot'). It finds the shot or transition at each time on the saved video (or the shot the words name), looks at that spot (the photo and the rendered clip), names the element and the cause, and returns one plan with the first fix for each note (tool and arguments) and the credit cost of any fix that uses one. Editing notes ('start with the kitchen', 'make the pool shot longer') come back as the edit itself (move_shot, remove_shots, set_shot_length). Free fixes can be made straight away; credit fixes are requested with the tools it names. In the Keylight editor it checks each spot again after the fix renders. Uses no credit.

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>",
      "notes": "<notes>"
    },
    "name": "review_revision_notes"
  }
}

Input Schema

Name	Required	Description
`notes`	Yes	The person's revision notes, word for word, with their times when they gave them.
`aspect`	No	Optional: the version they watched, if they said.
`watched`	No	Only after the plan asked which version they watched: editor (the video as it is now) or download (the last file made).
`listingId`	Yes	Listing id from list_listings.
`creditLimit`	No	Optional: the most credits the person said these notes may use.

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 / creditLimit / properties / aiPlus / description
```
Added value: +"The most AI+ credits the fixes may use."
```
- addedInput schema / properties / creditLimit / properties / photoEdits / description
```
Added value: +"The most photo edit credits the fixes may use."
```
First observedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds meaningful context beyond that: uses no credit, distinguishes free fixes from credit fixes, returns credit costs, and rechecks spots after the fix renders in the Keylight editor.

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 description is front-loaded with the tool's core purpose and follows a logical flow from input to detection to returned plan. It is somewhat long and repeats phrasing around notes and fixes, but most sentences earn their place by adding behavioral detail.

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 read-only planning tool with an output schema and full parameter descriptions, the definition covers input expectations, the returned plan, free versus credit fixes, and editor rechecking. Nothing critical for correct invocation 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 description coverage is 100%, so the baseline is 3. The description adds value by giving examples of note phrasing and explaining that notes without times work when the words name the shot, which helps interpret the notes parameter beyond 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 description states a specific verb and resource: it takes revision notes, locates the referenced shot or transition, names the element and cause, and returns a plan with the first fix per note. It also names related edit tools such as move_shot, remove_shots, and set_shot_length, making its planning role distinct from raw edit tools.

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 gives clear usage context: notes may include times or named shots, and editing notes are returned as edits rather than visual fixes. However, it does not explicitly state when not to use it or name a sibling alternative such as check_revision_notes.

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?