Skip to main content
Glama

Plan Chapter Markers

plan_chapter_markers
Read-onlyIdempotent

Detects topic shifts in a word-timed transcript to plan YouTube-style chapters, returning titles, timestamp text and marker-ready data without modifying Premiere.

Instructions

Plan YouTube-style chapters from a word-timed transcript using local TextTiling-lite topic-shift detection, titling each chapter from its distinctive tokens. Returns chapters, a youtube_timestamps block and add_marker-ready Chapter markers. Local-only plan; never changes Premiere.

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": {
      "word_timeline": "<word_timeline>"
    },
    "name": "plan_chapter_markers"
  }
}

Input Schema

NameRequiredDescriptionDefault
frame_rateNoFrame rate used to snap start/end frames; defaults to 30.
stop_wordsNoExtra stop words removed before similarity and titling.
block_wordsNoApproximate words compared on each side of a sentence gap; defaults to 60.
title_wordsNoMaximum words in each generated chapter name; defaults to 4.
max_chaptersNoMaximum number of chapters; deepest topic valleys win. Defaults to 12.
word_timelineYesCaller-supplied word-timed transcript for one Premiere source item. Words must be ordered by start time and bound to the transcript revision returned by get_clip_transcript_uxp. Different labeled speakers may overlap; same-speaker words may not, even when another speaker is between them.
expected_cep_targetNoOptional reviewed CEP sequence/clip identity and exact tick ranges. Checked before every generated command; UXP refuses this CEP-only guard.
min_chapter_secondsNoMinimum chapter duration in seconds; defaults to 90.
expected_project_pathNoOptional absolute saved-project path. Every generated CEP command refuses before its body when the active project differs or is unsaved. UXP commands refuse this CEP-only guard; local-only tools do not inspect Premiere. Omit to keep existing behavior.

Output Schema

NameRequiredDescriptionDefault
okYesWhether the tool completed successfully.
dataNoTool-specific result data when ok is true; on failure, diagnostic detail when the tool provides it.
toolYesThe registered MCP tool name.
errorNoFailure detail when ok is false.
receiptNoVersioned common mutation receipt; success never implies rendered verification.
idempotencyNoPresent when idempotency_key deduplicated this call: replayed is true when the original outcome was returned instead of running again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.30.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and local behavior, and the description adds concrete detail: TextTiling-lite topic-shift detection, distinctive-token titling, and the exact output blocks. It reinforces that no Premiere state is modified, though it leaves transcript-size limits and revision prerequisites to the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and then output and locality. Every sentence adds useful information with no boilerplate or wasted phrasing.

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 complex 9-parameter analysis tool, the description covers purpose, algorithm, output shape, and non-mutation. The schema and output schema carry the parameter and return details, though the description does not call out the get_clip_transcript_uxp revision prerequisite or word-timeline ordering constraints; those omissions are minor given full schema coverage.

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 the schema already documents word_timeline, frame_rate, max_chapters, and the other controls. The description adds no parameter-specific meaning beyond referring to a word-timed transcript and listing output blocks, making the baseline 3 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 resource: planning YouTube-style chapters from a word-timed transcript. It names the algorithm, titling behavior, and outputs, and distinguishes itself from actual marker-writing siblings by clarifying it is a local-only plan that never changes Premiere.

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?

The description establishes the applicable context: generating a local chapter plan from a supplied transcript, with add_marker-ready output for a later mutation step. It does not explicitly name alternatives like add_marker or add_markers_batch or state when not to use it, so guidance is clear but not exhaustive.

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

Deploy Server

Other Tools