Skip to main content
Glama
Sign In

AskEditor

by com.askeditor
OverviewDiscussionsAdmin

Watch a clip

watch_clip
Read-onlyIdempotent

[read] WATCH footage as timestamp grids: a timeline clip (clipId, timeline ms) or a library video (assetId, file ms), nothing laid over it. To see what happens and when: find a moment, pick cut points, see where a person stands. The finished edit is watch_edit; exact positions read_clip. Sheets [{asset_id, grid, fromMs, toMs, cells}]; continueFromMs when more remains. Related: watch_edit, read_clip, get_clip_frames, detect_scenes. Full docs: load_skill with tools: [name].

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": {
      "project_id": "<project_id>"
    },
    "name": "watch_clip"
  }
}

Input Schema

NameRequiredDescriptionDefault
fpsNoFrames sampled a second. Default 1, fewer when a long stretch needs it.
toMsNoEnd of the stretch, ms. Default the end.
itemsNoMany clips at once, max 20, each with this tool's fields; fields beside it are defaults.
clipIdNoA timeline clip's footage (id from get_timeline); times are timeline ms.
fromMsNoStart of the stretch, ms. Default the start.
guidesNotrue: draw 10% grid lines with 20/40/60/80 marks.
assetIdNoA library video's asset id (list_media); times are the file's ms.
timesMsNoExact moments instead of a range, ms.
withShotsNotrue: add shot-change times.
project_idYesThe AskEditor project this acts on (from list_projects).
cellsPerSheetNoFrames per sheet: fewer = bigger cells. Default 12 (16 past 72 s).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes beyond them by disclosing the return shape (`Sheets [{asset_id, grid, fromMs, toMs, cells}]`) and the pagination contract (`continueFromMs` when more remains), which is exactly the context an agent needs for multi-call loops. It stops short of stating cost/latency or how much footage one call covers in practice.

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 `[read]` tag and the core verb+object, then packs return shape, continuation, and alternatives into a few short clauses with no filler. Some phrasing is terse to the point of being cryptic ("nothing laid over it", "see where a person stands"), but it never wastes a sentence.

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 an 11-parameter tool with no output schema, the description still conveys the return structure and how to resume, and points to `load_skill` for full docs. The remaining gap is operational scale – how much footage a single sheet covers and when to raise `fps` – which the agent must infer from schema defaults.

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 description coverage is 100%, so every parameter (fps, cellsPerSheet, timesMs, items, guides, withShots) is already documented with defaults and limits. The description restates only the clipId/assetId time-base distinction, which the schema also carries verbatim, so it adds little semantic value beyond structured fields. Baseline 3 is appropriate.

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?

States a specific verb and output form: "WATCH footage as timestamp grids", and immediately splits the two modes (timeline `clipId` in timeline ms vs library `assetId` in file ms). It explicitly distinguishes itself from `watch_edit` (the finished edit) and `read_clip` (exact positions), so an agent can pick the right tool without opening sibling schemas.

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 concrete tasks the tool serves ("find a moment, pick cut points, see where a person stands") and names the alternatives with the condition that selects them: `watch_edit` for the finished edit, `read_clip` for exact positions. That is explicit when-to-use and when-not-to-use guidance.

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

All AskEditor toolsInspect
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