Skip to main content
Glama
losslesscut-mcp
by bariswha

Detect scene changes

detect_scenes
Read-only

Finds cuts and scene changes in a video with FFmpeg so you can locate edit points; lower thresholds return more changes.

Instructions

Finds cuts and scene changes in the video with FFmpeg. Lower threshold finds more changes.

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": {
      "path": "<path>"
    },
    "name": "detect_scenes"
  }
}

Input Schema

NameRequiredDescriptionDefault
endNoEnd of the part to analyse (default: end of file)
pathYesAbsolute path of a file the user gave you
limitNo
startNoStart of the part to analyse (default: start of file)
thresholdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that detection is FFmpeg-based and that threshold directionally controls sensitivity, but says nothing about what the operation returns or what the limit parameter does when many cuts are found.

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?

Two short sentences with no filler, front-loading the core action and following with the one actionable tuning rule. Slightly lean given how many parameters go unmentioned, but nothing is wasted.

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

Completeness3/5

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

With five parameters, no output schema, and the second-highest complexity among the detect_* tools, the description should at least hint at the return shape (a list of cut timestamps) and the truncation behaviour of limit. It covers the core purpose adequately but leaves these gaps for an agent to discover by calling it.

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 60%, and the description only elaborates on threshold ('lower finds more changes'), adding real directional meaning beyond the bare default of 0.3. The limit parameter (default 300, max 2000) carries no explanation anywhere, and start/end meaning is left entirely to the schema.

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?

The description names a specific verb ('finds') and a specific resource ('cuts and scene changes in the video'), plus the underlying mechanism (FFmpeg). It does not, however, distinguish this from siblings like detect_black or detect_silence, which an agent must choose between.

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?

There is useful tuning guidance ('Lower threshold finds more changes') but no statement of when to prefer this over detect_black/detect_silence or what precondition applies (e.g. a file must be open). Usage is implied from the tool name and the tuning hint rather than explicitly framed.

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