Skip to main content
Glama
Sign In
Tapra MCP server

Tapra MCP server

Official
by tapra-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Find in transcript

find_in_transcript
Read-onlyIdempotent

Locate words or phrases in a saved transcript and return timestamps for each match, including fuzzy, Arabic-script, and accent-optional French matches, to help find exact moments for video cutting.

Instructions

Find when a word or phrase is said, with timestamps, in a transcript saved by speech_to_text or transcribe_video (.json gives word-level times; .srt/.vtt give subtitle-level times). Matches Arabic script with or without harakat and letter variants (أ/ا, ة/ه, ى/ي), French accents optional, and small typos when fuzzy. Useful for cutting video ("where does he say X?"). Free, runs locally.

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

Input Schema

NameRequiredDescriptionDefault
fuzzyNoAlso match near spellings (words of 3+ letters).
queryYesWord or phrase to find, in the same script as the transcript.
max_resultsNo
transcript_pathYesTranscript file (.json, .srt, .vtt) or tapra://output/... resource.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, local (openWorldHint=false), so the safety profile is covered. The description adds real behavioral context beyond that: timestamp granularity depends on file format (.json word-level vs .srt/.vtt subtitle-level) and normalization behavior for Arabic harakat/letter variants and French accents. It omits result ordering and what happens when nothing matches.

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?

Three dense sentences with no filler, and the core action ('find when X is said, with timestamps') is front-loaded. The parenthetical format list is slightly heavy but each clause carries distinct information.

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?

With no output schema, the description correctly tells the agent the return contains matches with timestamps, and it disambiguates timestamp precision per file format. It leaves max_results semantics (ordering, truncation) and no-match behavior unexplained, which is a minor gap for a 4-parameter read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75% and the description meaningfully extends it: it explains what 'fuzzy' actually tolerates (letter variants أ/ا, ة/ه, ى/ي, optional accents, small typos) rather than restating the schema's vague 'near spellings'. It also clarifies that the query must match the transcript's script and what accepted file types mean for output precision.

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+resource+output: 'Find when a word or phrase is said, with timestamps, in a transcript saved by speech_to_text or transcribe_video'. It names the exact upstream siblings that produce its input, so an agent can place it in the pipeline without opening a schema.

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?

Gives a concrete use case ('where does he say X?' for cutting video) and identifies the prerequisite producers (speech_to_text / transcribe_video). It does not state exclusions or contrast with alternatives like transcribe_video itself, but the triggering context is clear.

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