Skip to main content
Glama

find_transcript

Read-onlyIdempotent

Find WHEN a phrase is spoken: a timestamp lookup for anchoring B-roll, motion graphics, markers, or overlays at that moment. Not a transcript reader or editor.

Returns the source timestamp (MM:SS.mmm, word-precise) and every timeline placement that plays it (track alias, item id, frame range Nf), across tracks and copies.

Scope: with no filter it searches what the active timeline plays, respecting edits (edited-out phrases do not match). asset searches that asset's raw transcript, ignoring edits. track narrows to that track. asset + track searches the raw transcript but lists only placements on that track, so a match outside the placed ranges has none.

Matching: case-, punctuation-, and whitespace-insensitive contiguous match by default; fuzzy: true tolerates fillers between words. Timeline mode can span ASR segments and items; asset mode matches only within one ASR segment.

0 matches for a phrase you saw in Script means it is not on the searched timeline (edited out, or in an asset not used here); pass asset to search the source. Script files carry no sentence- or word-level timing, so timing questions belong here.

Not for transcript-based editing. To cut, keep, extract, remove, reorder, or insert what is spoken (clips, highlights, short versions, "keep the part about X"), a match is orientation only: edit through Script (read_script → timeline.md → apply_script), and never drive split_item, edit_item, or item deletes from this output to select transcript content. To read transcript text, use the files from read_script.

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": {
      "query": "<query>"
    },
    "name": "find_transcript"
  }
}

Input Schema

NameRequiredDescriptionDefault
assetNoAsset ID or prefix ID to search its raw transcript. Omit to search what the timeline plays.
fuzzyNoToken-window match (tolerates fillers between tokens).
limitNoMax results returned (default 10).
queryYesText to search for.
trackNoTrack alias (V1/A1/...) resolved on the searched timeline, or a track id. Restricts timeline placements (and asset discovery, when asset is omitted) to that track.
projectIdNoProject for this call (full ID or unambiguous prefix). Explicit-timeline calls never change the target of later calls; legacy project selection applies otherwise.
timelineIdNoTimeline id/prefix (from manage_timelines list) to search instead of the active timeline, without switching. Timeline placements, frames, and track aliases then refer to that timeline.
refreshCacheNoBypass and replace the task-local transcript cache before searching. Use after transcript data changed or when explicitly checking fresh ASR data.
includeWordTimestampsNoInclude per-word timestamps inside each match (default false). Use when syncing animation beats to speech cadence (e.g., MG internal rhythm matched to which word is being said). Adds a `Words:` block under each match with each word's start -> end time. Skip for the typical lookup case (anchoring a single overlay to a phrase boundary).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial behavior beyond them: edit-aware matching in timeline mode vs. raw transcript in asset mode, contiguous vs. fuzzy token-window matching, cross-item/cross-segment spanning, and an explicit refutation of a destructive misuse pattern (never drive split_item/edit_item from this output). The only gap is that result ordering and the default limit's interaction with cross-track expansion are left 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.

Conciseness4/5

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

Well front-loaded — the purpose sentence and the sibling negation come first, followed by returns, scope, matching, and exclusions in a logical order, with terse inline formatting. It runs long for a lookup tool, and the timing/editing prohibition paragraph could be tightened since "Not a transcript reader or editor" is already stated up top.

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?

With 9 parameters, no output schema, and no enums, the description carries the return-format burden itself and does: source timestamp format, track alias, item id, frame range, plus the optional `Words:` block when includeWordTimestamps is set. Scope, matching, and misuse boundaries are all covered, leaving nothing an agent needs in order to call this correctly.

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 coverage is 100%, so the baseline is 3; the description earns above that by explaining the non-obvious `asset` + `track` interaction (raw transcript search but only placements on that track, so out-of-range matches return nothing), which the schema's per-parameter text does not make clear. The matching rules for `query` (case/punctuation/whitespace-insensitive) also add real meaning beyond "Text to search for."

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?

"Find WHEN a phrase is spoken: a timestamp lookup" states a specific verb, resource, and output shape, and immediately negates the adjacent interpretations ("Not a transcript reader or editor"). An agent can separate this from read_script, manage_transcript, and trigger_transcript without opening any schema.

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 names concrete use cases (anchoring B-roll, motion graphics, markers, overlays), explicit exclusions (editing speech content, reading transcript text), and routes to alternatives with a path: Script via read_script → timeline.md → apply_script. It even supplies a diagnostic rule for zero matches (pass `asset` to search the source), which is the most common failure mode for a search tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.