talkthrough-mcp

Overview Schema Source Related Servers Discussions Admin

search

Read-onlyIdempotent

Find any spoken or on-screen phrase in recordings across transcripts and OCR. Returns timestamps, speaker, and frame positions to jump straight to evidence. Optional speaker and match-mode filters.

Instructions

Case-insensitive word search across BOTH transcript segments and frame OCR text. The default match_mode="all_words" requires EVERY query word as a substring; match_mode="any_word" requires at least one (ё and е are interchangeable). Hits carry source (transcript|ocr), t_ms, t_wall when known, the matched text, and the nearest frame position — everything needed to jump straight to evidence. Optional speaker accepts a raw label ("S2") or saved name and narrows to that voice's transcript hits. Duplicate saved names search all matching labels honestly. No embeddings. When NOT to use: fuzzy/semantic questions ("anything about performance?") — page get_transcript and read; regex is not supported. Examples:

search(job_id="...", query="login") — every spoken or on-screen mention of login
user: "what did I say about the login button?" → search(job_id, "login button") → get_moment at hits
search(job_id, "TypeError") — on-screen stack traces and error text are OCR-indexed; great for bug repros
search(job_id, "€49") — prices, IDs, and literals on screen are findable via OCR
take hit.t_wall and grep your server logs ±30 s around it to pair remark ↔ log line
broad lexical recall: search(job_id, "timeout latency", match_mode="any_word")
multi-word = ALL words as substrings, any order: "first phase" hits "the first real phase"
stems beat inflected phrases: "кнопк отправк" finds «Кнопка отправки» and «кнопку отправки»
every hit has nearest_frame_ms → get_frames(job_id, at_ms=) shows the moment
diarized job: transcript hits carry "speaker" — "who mentioned the deadline?" is answered by the hit itself
search(job_id, "deadline", speaker="S2") — only S2's mentions; OCR hits are excluded (screens have no voice)
search(job_id, "deadline", speaker="Vera") — saved names are matched case-insensitively
audio-only job → transcript hits only (there is no OCR index)
anti-example: "summarize the pricing discussion" → get_transcript(format="text") and read it
anti-example: "everything S2 said" → get_transcript and collect speaker=="S2" — search always needs a query

Input Schema

TableJSON Schema

Name	Required	Default
`query`	Yes
`job_id`	Yes
`speaker`	No
`match_mode`	No	all_words

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.3.0Aug 29, 2026

addedInput schema / properties / match_mode

Added value: +{
+  "default": "all_words",
+  "enum": [
+    "all_words",
+    "any_word"
+  ],
+  "title": "Match Mode",
+  "type": "string"
+}

Addedv0.2.4Aug 3, 2026
Removedv0.2.3Jul 18, 2026
First observedv0.1.0Jul 11, 2026

TDQS

A5/5.0

Behavior5/5

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

The description reveals far more than annotations: case-insensitivity, ё/е equivalence, all_words vs any_word semantics, OCR exclusion when speaker is set, audio-only jobs producing transcript-only hits, duplicate saved name behavior, and the exact fields each hit carries. These behavioral details materially change how an agent invokes and interprets the tool and align with the read-only annotations.

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?

The description is long but exceptionally dense and well-structured, opening with core semantics and then organized into examples and anti-examples. Each bullet earns its place by conveying a distinct behavioral or routing fact, and the when-not-to-use section is placed early for quick decision-making.

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?

For a search tool with four parameters, an output schema, and several subtle behaviors, the description covers invocation, match semantics, speaker filtering, OCR/transcript scope, return-value contents, and routing to alternatives. The output schema exists and the description complements rather than repeats it, giving an agent everything needed to call and interpret the tool correctly.

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 description coverage is 0%, so the description fully carries parameter meaning. It explains query as substring-based with multi-word all-substring matching, match_mode with its default and contrast, speaker as raw label or saved name with case-insensitive matching and OCR exclusion, and job_id is used throughout examples.

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?

The description states a specific verb and resource: 'Case-insensitive word search across BOTH transcript segments and frame OCR text.' It clearly distinguishes the tool from siblings like get_transcript, get_frames, and get_moment by defining its unique search-over-both-indexes role.

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?

The description explicitly says when NOT to use it ('fuzzy/semantic questions' and regex) and directs the agent to get_transcript instead. It also provides positive examples and anti-examples, such as using get_transcript to summarize or collect all of one speaker's lines, making alternatives and exclusions unmistakable.

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

Deploy Server