Indexes YouTube videos by transcribing original speech, aligning captions, detecting speakers, and capturing frames, then enables searching for relevant moments with timestamps and evidence links back to the source video.
Find the relevant moment in a long YouTube video—and see the evidence behind the answer.
A long video in a language you do not speak can still become searchable. CuePrecise is an open-source MCP server for Claude Desktop, Codex, Cursor, and other AI clients. It turns a YouTube video's original speech, available captions, speaker labels, and selected frames into a searchable local reference. The index stays in the video's original language; your AI client may translate a question into search terms, but cross-language retrieval is not guaranteed.
On a tested setup, CuePrecise analyzes videos longer than an hour in about three minutes. It does not send the whole video to your AI client for every question. It transcribes the original audio in chunks, indexes the evidence, and retrieves only the passages and frames related to your question.
The transcription starts with the original audio. When an original-language YouTube caption track is available, CuePrecise uses it to recover matching Latin-script terms and phrases that the transcription missed. You can ask your AI client in your own language, but reliable retrieval may require the original wording. Results still include the original words, speaker information, relevant frames, and a timestamp that takes you back to YouTube. Actual processing time depends on the video, network, and API response time.
The attached demo uses a Polish-language interview. Ask what it is about in your own language; CuePrecise returns relevant moments, the original transcript, and matching frames as evidence.
You: I do not speak Polish. What is this interview about?
Your AI + CuePrecise:
Explains the interview in your language, points to relevant moments,
and provides the original transcript and matching frames as evidence.https://github.com/user-attachments/assets/ce7d595b-871f-469a-bcb8-798713751ffd
Demo source: “Czym jest prompt injection i jak chronić firmę przed złośliwą instrukcją dla AI? Gośc. Tomasz Bartel” by Daniel Bartosiewicz | Content i Automatyzacja, licensed under CC BY.
Download CuePrecise → GitHub Releases
Jump to the answer. Get a timestamp for each item in a summary.
Keep speakers separate. Compare what each person said and why.
Find a referenced screen again. Connect a relevant frame to what was being explained.
Check the source. Open the original YouTube video at the cited moment.
Try questions like these:
What is the main argument of this video? Include timestamps for each point.
Find where the speaker explains self-supervised learning.
When does that phrase appear on screen?
Compare each speaker's position on basic income and include the supporting passages.
If these speakers debated a new issue, what arguments and counterarguments
would follow from what they actually said in the video?In Claude Desktop, clicking a timestamp opens YouTube at that moment. Other AI clients may render timestamp links differently.
Related MCP server: popcorn
CuePrecise is not just a summarizer. It gives your AI client the material it needs to answer a question and lets you check where the answer came from:
Gemini's word-level transcription of the original speech.
Original-language YouTube captions, when available, aligned to the same timeline.
Frames from transcript screen-reference phrases, restored terms, or requested timestamps.
Speaker labels, evidence confidence, and provenance for retrieved spans.
When the search finds no supporting passage, CuePrecise reports that there is no evidence in the indexed material instead of inventing a source. The resulting evidence bundle stays on your computer, so a later conversation can search the same video without starting over. Audio chunks used for transcription are sent to Gemini; see PRIVACY.md for the network boundary.
Names and technical terms are easy to lose in a long transcription. In one 23-minute
Korean technical lecture, the phrase self supervised learning disappeared from all four
Gemini-only transcription runs.
Gemini transcription:
So how did they learn this ability? It is a way of learning.
CuePrecise merge:
So how did they learn this ability? self supervised learning is a way of learning.CuePrecise checks the YouTube captions from the same time range and fills only a matching gap. It does not rewrite Gemini's words. Words supplied by captions keep their origin.
The measured example looked like this:
The YouTube original-language captions contained 91 Latin-script words and the missing phrase.
The Gemini runs contained 28–29 Latin-script words, but missed the phrase every time.
The merged result contained 38 Latin-script words and recovered the phrase while keeping the Korean transcription quality.
This is one measured edge case, not a general accuracy claim. The exact merge rules and validation criteria are documented in CONTRACT.md.
CuePrecise carries speaker information across chunks of a long video. Speaker labels are identifiers, not real names. Confirmed and inferred identities are kept separate, and weak evidence remains unresolved instead of being presented as a fact.
That lets your AI client:
collect one speaker's claims and supporting passages;
compare the positions of several speakers;
simulate a debate about a new issue using the speakers' actual statements as evidence.
A simulated debate is generated from the video. It is not a claim that those people actually discussed the new issue.
Open Releases and download
cueprecise-windows.mcpb.
In Claude Desktop, open Settings → Extensions → Advanced settings → Install Extension.
Select the file. Claude will ask for a Gemini API key and a folder for local video data.
Enable CuePrecise and ask Claude about a YouTube link.
The approximately 86 MiB bundle includes CuePrecise, yt-dlp, FFmpeg, and FFprobe. You do
not need to install Python, Git, or the video tools separately. The extension is currently
available for Claude Desktop on Windows.
Open Releases and download
cueprecise-setup.exe.
Run the installer, click Create API key, and paste a key from Google AI Studio.
Select the AI clients found on your computer and click Connect.
Fully quit and reopen the connected clients.
The installer checks for FFmpeg and FFprobe and installs FFmpeg through WinGet when it is missing. It adds only the CuePrecise entry and backs up existing configuration when it can do so safely; a secret-bearing Codex TOML may be left without a backup to avoid copying the key. On Windows, the API key is encrypted with Windows DPAPI for the current user. Older plaintext CuePrecise keys are moved into the protected store during an upgrade.
Unsigned preview:
v0.2.5is not digitally signed, so Windows may show an unknown-publisher warning. Download it only from this repository's Releases page and verifySHA256SUMS.txtif you want to check the file before installing it.
With uv:
uv tool install git+https://github.com/Nattentia/cueprecise
cueprecise setupThe setup command configures detected supported AI clients, including Claude Desktop, and
creates the default data directory ~/.cueprecise/data. It keeps a timestamped .bak file when
it changes an existing configuration, unless a secret-bearing configuration format cannot be
backed up safely.
Install ffmpeg and ffprobe, then check the environment:
cueprecise doctorCreate a Gemini API key, then pass it through standard input or a file so it does not appear in the command or shell history:
cueprecise setup --api-key - # paste the key, then press Enter
cueprecise setup --api-key-file ~/.gemini-key # read it from a file
pass show gemini/api-key | cueprecise setup --api-key -
cueprecise run "https://www.youtube.com/watch?v=VIDEO_ID" --language en-US
cueprecise status VIDEO_IDIf a key is exposed, delete it in Google AI Studio and create a new one. See PRIVACY.md for the full procedure.
For source development only:
git clone https://github.com/Nattentia/cueprecise.git
cd cueprecise
python -m pip install -r requirements.txt
python src/pipeline.py --helpcueprecise setup can detect and configure these clients:
Claude Desktop
Codex
Claude Code
VS Code
Cursor
Windsurf
Gemini CLI
The Cursor, Windsurf, and Gemini CLI configuration paths are automatic setup targets, but they have not been end-to-end tested on the current development machine.
Run it for every detected client, for one named client, or to inspect the result:
cueprecise setup
cueprecise setup --client codex
cueprecise doctorAn application counts as installed when its executable is on PATH. A leftover configuration
folder is not treated as proof that the application is present. An undetected client can
still be named explicitly with --client <name>.
CuePrecise skips an existing cueprecise entry if CuePrecise did not create it. It does not
overwrite another MCP server's settings, and a failure for one client does not stop the
others.
ChatGPT connectors and Claude.ai on the web are not currently supported by CuePrecise's local stdio transport. Web clients that require a remote HTTP MCP server cannot use this setup.
CuePrecise accepts both the request-per-request MCP revision 2026-07-28 and the earlier
initialize handshake. cueprecise setup is preferred because it preserves existing
configuration and handles credentials for supported clients.
The JSON below is for a source checkout or an MCP host not listed above. It stores the key in plaintext, so use the setup command when possible:
{
"mcpServers": {
"cueprecise": {
"command": "python",
"args": [
"C:/path/to/cueprecise/src/mcp_server.py",
"--bundle-root",
"C:/path/to/cueprecise/data"
],
"env": {
"GEMINI_API_KEY": "..."
}
}
}
}Use absolute paths. On every platform, literal --api-key VALUE is rejected to keep the key
out of process listings and shell history. The server can start without GEMINI_API_KEY:
existing analyses remain searchable, while new transcription requests stop with a
configuration message.
The tools fall into four groups.
Analysis and status:
cueprecise_register — register and analyze a YouTube video. You can choose the stages to run.
cueprecise_status — report progress, generated artifacts, and estimated local usage.
Search and evidence:
cueprecise_outline — return a timestamped outline, recovered terms, and speaker state.
cueprecise_query — search transcript evidence and related frames.
cueprecise_excerpt — return transcript and frames for a specific time range.
cueprecise_frames — extract frames around screen-reference moments or requested timestamps.
Saved results:
cueprecise_summary — create or retrieve a summary.
cueprecise_set_summary — validate and save a host-improved summary.
cueprecise_set_chapter_titles — validate and save host-written chapter titles.
Cleanup:
cueprecise_purge — explicitly remove chunks, source video, derived results, raw data, or
all data.
After YouTube fetching and Gemini transcription, assembly, caption merge, chapters, rendering, visual extraction, and indexing run locally. Chapter titles and summaries are written by the host AI from retrieved evidence; CuePrecise does not create another Gemini transcription call.
The installer and cueprecise setup use ~/.cueprecise/data. A source checkout can use
data unless you set --bundle-root.
data/<video_id>/
job.json chunk plan and progress
raw/
captions.json YouTube caption track (original preferred)
metadata.json metadata used for language checks
audio/ audio chunks used for transcription
transcripts/ per-chunk transcripts and raw responses
frames/ extracted frames
derived/
transcript.json assembled Gemini transcription
merged.json transcription plus caption evidence
chapters.json timestamped outline
frames.json frame index
output.srt, output.txt optional render output
index.sqlite3 transcript, chapter, frame index, and summaryEach indexed evidence span keeps its timestamp, speaker status, evidence confidence, and origin. The merged word data also keeps per-word timestamps and origin:
{
"text": "supervised",
"start": 208.93,
"end": 209.87,
"speaker": "speaker:0",
"speaker_status": "confirmed",
"origin": "youtube"
}A query result includes the time range, text, source, confidence, and any related frame:
{
"start": 1728.4,
"end": 1740.2,
"timecode": "00:28:48",
"text": "The experiment was stopped after eight participants had seizures.",
"source_path": "derived/merged.json",
"source_kind": "transcript",
"speaker": "speaker:3",
"speaker_status": "inferred",
"speaker_confidence": 0.75,
"confidence": 1.0
}Frames are not sampled uniformly across the whole video. CuePrecise prioritizes screen-reference phrases in the transcript, terms restored from captions, and timestamps requested by the user. It does not semantically classify every code, table, or diagram frame. If OCR is installed, recognized text is stored as separate provenance instead of silently replacing the transcript.
CuePrecise does not try to make your AI client watch the entire video in one pass. It builds a knowledge bundle that can be searched again:
Fetch audio, original-language captions when available, metadata, and a low-resolution video
stream for the visual stage from YouTube. With --skip-video, the video download is deferred
until frames are requested.
Split the audio into chunks and request word-level transcription and speaker information from Gemini.
Assemble completed chunks and, when an original-language caption track exists, use matching Latin-script terms to fill gaps in the transcription.
Extract frames at transcript screen-reference moments, restored-term moments, and timestamps requested by the user.
Index transcript, chapters, speakers, and frames in SQLite.
Let the AI client retrieve the relevant evidence and write the answer with timestamps.
Stages communicate through JSON files and can be rerun independently. Completed chunks are reused when the input and settings match. Raw transcription responses are saved before validation, so a parse failure does not automatically spend another Gemini call on the same response.
The optional render stage creates SRT and TXT files. Overflowing text is carried into the
next cue instead of being silently dropped, preserving 100% of the words in the rendered
output.
Pass the video's original language when possible, for example --language en-US, --language ko-KR, or another BCP-47 code. Without it, Gemini can occasionally return a translation
instead of a verbatim transcript.
CuePrecise checks each chunk against whichever of the original-language captions, requested language, and video metadata is available. If it detects a translation, it stops before spending calls on the remaining chunks. If there is no usable basis, the guard is skipped and recorded as such. The check uses material already fetched and does not make an extra API call.
python src/pipeline.py run <url> [options]
python src/pipeline.py status <video_id>
python src/pipeline.py purge <video_id> --scope <scope>Common run options:
--language — comma-separated BCP-47 language codes; specifying the original language is recommended
--stages — stages to run; all includes optional stages
--bundle-root — directory for video bundles
--force — ignore cached results and rebuild
--skip-video — skip the video download
--keep-video — keep the video after frame extraction
--at — timestamps, in seconds, at which to extract frames
--max-frames — maximum number of frames; default 40
--chunk-max-secs — maximum chunk length; default 1790 seconds
--overlap-secs — overlap between chunks; default 10 seconds
--daily-limit, --rpm-limit — local Gemini usage limits
--width — subtitle line width; default 20. Use 42 when rendering English subtitles.
Rebuild selected derived output or clean up source material:
python src/pipeline.py run <url> --stages render
python src/pipeline.py run <url> --stages visual
python src/pipeline.py purge <id> --scope chunks--scope accepts chunks, video, derived, raw, or all. Deletion is explicit.
The pipeline is designed to resume. Completed chunks are reused when the input and settings are unchanged, and local post-processing such as merge, visual extraction, and indexing does not call Gemini.
Bundle size depends on the video's audio, transcript, and selected frames. The source video is
normally removed after frame extraction; use --keep-video to retain it. Transcription audio
can be removed with purge --scope chunks.
A local usage ledger records attempts by an API-key hash and Pacific date, never the original key. CuePrecise shows the expected calls before a job starts and stops if a configured limit would be exceeded. Google AI Studio remains authoritative for server-side usage.
Python 3.11+
ffmpeg and ffprobe for audio chunking and frame extraction
Optional Python packages pytesseract and Pillow, plus the tesseract binary, for frame OCR
python -m pip install -r requirements.txt
python -m pip install -r requirements-optional.txt # optional OCR and timezone supportThe installable distribution is cueprecise-mcp, with cueprecise and cueprecise-mcp as
its command-line entry points. It has not been published to PyPI yet, so install from the
GitHub URL above.
python -m unittest discover -s testsThe suite uses the standard-library unittest runner. Tests do not access the network or
call the Gemini API. Tests that require google-genai are skipped when the SDK is not
installed.
YouTube caption spelling errors can remain in recovered terms, and captions may be unavailable.
OCR requires the optional pytesseract and Pillow packages and the Tesseract binary.
The caption-merge threshold was tuned on a limited set of real videos and needs broader validation.
Across three or more chunks, a speaker absent from the overlap can remain unresolved.
CuePrecise avoids assigning a potentially wrong identity.
The interruption/resume path for a long-running job on the real API still needs end-to-end validation.
Visual-reference phrase matching currently focuses on Korean and English.
Visual search is candidate-based: it prioritizes transcript screen references and requested timestamps rather than inspecting every frame semantically.
Cross-language retrieval is lexical rather than translation- or embedding-based; original terms may be needed when the host AI does not translate the query.
Timestamps assigned to caption-recovered words are placed inside the missing transcription gap and should be treated as approximate within that interval.
README.ko.md — Korean README
CODE_SIGNING_POLICY.md — Windows release review and signing policy
PRIVACY.md — API keys, local data, external services, and uninstall behavior
CONTRACT.md — authoritative data contracts and validation rules
DECISIONS/ — design decisions and rejected alternatives
CONTRIBUTING.md — development environment and pull request process
SECURITY.md — private vulnerability reporting
Host-specific timestamp links
Pipelined chunk transcription
Multi-video research with source-specific evidence
The initial transcription flow was informed by the MIT-licensed
gemini-transcribe-wrapper.
CuePrecise is an independently written project.
MIT. See LICENSE.
CuePrecise is not affiliated with or endorsed by YouTube or Google. YouTube is a supported service, not part of the product name.
지정한 시각 구간의 자막 원문과 그 구간의 프레임을 조회한다. 긴 구간은 앞부분만 돌아오고 truncated 가 참이 된다 — 그때는 start 를 옮겨 이어 부른다.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| start | Yes | ||
| video_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the truncation behavior and the need to advance the start value, which is a key behavioral trait. Since no annotations are provided, the description carries the burden, and it does well by revealing this non-obvious behavior, though it does not explicitly state whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, using just two sentences to convey purpose, output contents, truncation behavior, and continuation strategy. No superfluous words or redundant explanations are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives enough context for an agent to understand the basic invocation and output type (subtitles and frames), but it omits details like time units, frame format, and the exact output structure. Given that no output schema is defined, a bit more detail would improve completeness, but it is still adequate for a basic call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only indirectly references the 'start' parameter in the truncation note, while 'video_id' and 'end' are not explained at all. With zero schema-level descriptions and no parameter annotations, the description fails to convey the meaning or units of these parameters, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving subtitle text and frames for a specified time interval. It uses a specific verb ('조회한다') and resource ('자막 원문과 프레임'), and the truncation note helps distinguish it from related tools like cueprecise_frames or cueprecise_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance for handling truncated results by moving the start parameter to continue fetching, which is actionable. However, it does not explicitly compare with sibling tools or state when to choose this over alternatives, so it loses a point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
화면 참조 시각의 프레임을 추출하고 frames.json 을 갱신한다. 영상이 없거나 --skip-video를 사용한 경우 원본 URL로 저해상도 영상을 받아온다. Gemini 호출 없음.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | 추가로 뽑을 초 단위 시각 | |
| video_id | Yes | ||
| max_frames | No | 최대 프레임 수. 기본 40 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. It transparently states that it updates frames.json, fetches low-resolution video under certain conditions, and makes no Gemini call. This gives the agent a clear picture of behavioral consequences, though it does not mention permissions or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three short sentences with no fluff or redundant information. It is well-structured: statement of action, conditional fallback, and explicit note about no Gemini call. Every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives adequate context for an agent to understand the tool's core purpose, side effects, and a notable non-behavior (no Gemini). It lacks some details (e.g., what constitutes 'screen reference times' or output format), but given the simplicity of the tool and the absence of an output schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes two of three parameters (at and max_frames), and the description adds minimal context by referencing 'screen reference times' which helps interpret 'at'. However, video_id is not described, and the description does not elaborate on parameter ranges or units. The description adds some value but not enough to exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: extracting frames at screen reference times and updating frames.json. It uses specific verbs ('extract', 'update') and identifies the resource (frames.json). It also distinguishes itself by explicitly stating it does not call Gemini, which helps differentiate it from other tools that might use Gemini.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions conditional behavior (e.g., fetching low-res video when video is absent or --skip-video is used) but does not state use cases or compare with sibling tools. There is no 'use this when...' or 'instead of...' instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
영상 개요와 timestamp 목차를 조회한다. needs_titles가 있으면 근거를 보고 제목을 직접 지은 뒤 cueprecise_set_chapter_titles를 호출한다.
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | ||
| max_entries | No | 기본 100 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavior. It indicates a read operation ('retrieve') but does not mention error handling, authentication, rate limits, or side effects. It also references 'needs_titles' without clarifying whether it is a parameter or a data condition, adding ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two short sentences) and front-loads the core purpose. However, the reference to 'needs_titles' without schema context introduces confusion, slightly reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain the return structure, parameter usage, and any prerequisites. It only states the retrieval action and a conditional follow-up, omitting details about max_entries behavior, output format, or the nature of 'needs_titles'. This is incomplete for reliable agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (max_entries has a default note, video_id has none). The description does not explain video_id or max_entries, and it introduces 'needs_titles' which is not in the schema. This leaves the agent unclear about required parameters and the meaning of the conditional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb (retrieve) and resource (video outline and timestamp TOC), and implicitly distinguishes from sibling tools by noting that setting titles is a separate tool. It is specific about what it does, though it could be more explicit about the output format or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: if needs_titles is present, after reviewing the evidence, create titles and call cueprecise_set_chapter_titles. This tells the agent when to use this tool and what to do next, but it does not explicitly state when not to use it or mention alternatives like excerpt or frames.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
영상 자료를 명시적으로 삭제한다. scope: derived(기본) | chunks | video | raw | all. chunks 는 전사용 청크 오디오만 지우며 원본 오디오에서 다시 만들 수 있다.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | ||
| video_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing destructive behavior. It does state that deletion is explicit and that 'chunks' data can be recreated from original audio, which is useful. However, it does not warn that raw/video/all scopes may cause unrecoverable data loss or describe any additional side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured, with the core action stated first followed by a compact scope reference. Every sentence contributes meaningful information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema and no annotations, the description is too incomplete. It lacks information about irreversibility, authorization requirements, return values, and the precise meaning of several scope values. An agent could not confidently call this tool with the riskiest scopes based solely on this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the default scope and partially clarifies 'chunks', but it does not describe 'video_id' at all and leaves 'video', 'raw', and 'all' scopes semantically ambiguous. The enum values are listed in the schema, but the description adds only minimal clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear action, '영상 자료를 명시적으로 삭제한다' (explicitly deletes video material), and enumerates the affected scopes. Among the sibling tools, none are deletion-oriented, so this tool is clearly distinguished by its destructive purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention any sibling tools, prerequisites, or conditions for safe use, only defines what the scopes mean. The regenerability note for chunks implies one usage consideration but does not constitute usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
영상 내용을 질의한다. 근거 span 과 frame 을 timestamp 와 함께 반환한다. 근거가 없으면 없다고 답한다.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 기본 8 | |
| query | Yes | ||
| video_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal the return type (evidence span, frame, timestamp) and the no-evidence response. However, it omits important details like whether the operation is read-only, what happens if the video_id is invalid, how results are ordered, pagination limits, or error behavior. For a query tool, this is minimal but not entirely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action ('Queries video content') and then detailing the output and edge case. Every word earns its place; no fluff or repetition. It is optimally sized for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It explains the return type and no-evidence case but omits crucial context: what constitutes a valid query, how to interpret 'evidence span', whether results are paginated, error handling, and any dependencies on other tools (e.g., video registration). An agent would need to guess many operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only 'limit' has a description, and it is trivial: 'default 8'). The description does not explain video_id or query beyond their obvious names, nor does it clarify the format of the query, the expected type of evidence spans, or how 'limit' affects results. The description adds no value over the schema, and with such low coverage, it fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Queries video content' (영상 내용을 질의한다) and specifies the output: evidence span and frame with timestamp. It also notes the no-evidence behavior. This distinguishes it from sibling tools like cueprecise_excerpt (which likely extracts) and cueprecise_summary (which summarizes), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many siblings. It does not mention alternative tools, prerequisites (e.g., video registration), or scenarios where it should not be used. The only behavioral hint is the no-evidence response, which is about outcome, not selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
YouTube 영상을 등록하고 분석 파이프라인을 실행한다. stages 를 주면 일부 단계만 재실행한다.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube URL 또는 video_id | |
| stages | No | 생략하면 기본(fetch, plan, transcribe, assemble, merge, chapters, visual, index). 전체는 ["all"]. 가능: fetch, plan, transcribe, assemble, merge, chapters, render, visual, index | |
| language | No | 쉼표 구분 BCP-47. 생략하면 자동 감지 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description must carry the full burden. It indicates a state-changing action ('registers' and 'runs pipeline') but does not detail side effects such as network calls, storage modifications, or potential destructive actions. It is moderately transparent but lacks explicit side-effect disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two short sentences. It front-loads the primary purpose and then adds a note about the optional 'stages' parameter. Every word serves a purpose, with no redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and the key parameter behavior, but it omits information about return values, error handling, or whether the analysis pipeline is synchronous or asynchronous. Given the absence of an output schema, this missing context could leave an agent unsure about what to expect after calling the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage and the description adds meaningful details. For 'stages', it explains the default list and the 'all' option. For 'language', it specifies the format (comma-separated BCP-47) and default behavior. This goes beyond simple labels, though the description doesn't elaborate on the exact meaning of each stage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: registering a YouTube video and running the analysis pipeline. It uses a specific verb ('registers') and resource ('YouTube video'), which distinguishes it from siblings like 'cueprecise_status' or 'cueprecise_excerpt', though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that providing 'stages' allows re-running only some steps, which gives a hint about the optional parameter. However, it does not explicitly state when to use this tool versus other sibling tools, nor does it describe any prerequisites or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cueprecise_outline의 needs_titles에 대해 호스트가 직접 지은 제목을 검증 후 저장한다. 경계와 원문은 바꿀 수 없다.
| Name | Required | Description | Default |
|---|---|---|---|
| titles | Yes | ||
| video_id | Yes | ||
| fingerprint | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It discloses two useful traits: titles are validated before saving, and boundaries/original text are immutable. However, '검증' (validation) criteria are undefined, and there's no mention of overwrite behavior, failure handling, or side effects, which is a notable gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, with the main action front-loaded and the immutability constraint neatly appended. No filler or redundancy; every phrase earns its place. It loses one point because the brevity contributes to the under-specification of validation semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a save operation with no annotations, no output schema, and zero parameter documentation in the schema. The description leaves critical unknowns: what validation rules titles must pass, what happens on invalid input, whether existing titles are replaced, and how fingerprint acts. For a state-changing tool, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides zero descriptions for its parameters (0% coverage), so the description must compensate. It clarifies that the titles array holds host-authored titles for needs_titles, but leaves the purpose of video_id and fingerprint entirely unexplained, and doesn't state how the title object's id relates to existing outline data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource combination: validating and saving host-authored titles destined for cueprecise_outline's needs_titles. It also adds a meaningful negative constraint ('경계와 원문은 바꿀 수 없다'), distinguishing the tool's scope from one that edits boundaries or original text. It falls short of a 5 only because no sibling differentiation is explicitly made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use context: this tool is for the needs_titles field populated by host-authored titles. However, it provides no explicit when-to-use guidance, no exclusion conditions, and no named alternatives, leaving the agent to infer when this tool is appropriate vs. other title-handling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cueprecise_summary packet만 근거로 작성한 구조화 요약을 검증·저장한다. chapter 경계와 timestamp는 서버가 결정한다.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| video_id | Yes | ||
| fingerprint | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions storing data and server-side decisions on boundaries, but does not disclose whether existing data is overwritten, what the return value is, or potential error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no extraneous information, effectively communicating the core behavior and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context: it does not explain what a 'cueprecise_summary packet' is, how video_id and fingerprint relate, or what success/failure looks like. Given the nested schema and no annotations, this is insufficient for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for video_id, fingerprint, or content, and the description only references the summary packet without explaining the expected structure or semantics of the content object, leaving parameter meaning largely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates and stores a structured summary based on the cueprecise_summary packet, and explicitly notes that chapter boundaries and timestamps are determined by the server, which defines its core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by referencing the cueprecise_summary packet and server-determined boundaries, but does not explicitly differentiate from sibling tools (e.g., cueprecise_set_chapter_titles) or state when this tool should be preferred over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
작업 상태, 청크 진행도, 산출물 존재 여부, 로컬 Gemini 사용량 추정을 조회한다.
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only mentions that Gemini usage is an '추정' (estimation), which hints at approximate data. It does not state whether the operation is read-only, whether it has side effects, how it behaves for unknown video_ids, or what error conditions may arise.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly scoped sentence that front-loads the action (조회한다) and enumerates the four queried data categories in a clean list. There is no redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema, no annotations), and the description adequately names what data is queried. However, it omits the return format/shape of results, does not define terms like '작업 상태' or '청크 진행도', and provides no context about how the status relates to the video_id lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter video_id has zero documentation in both the schema and the description. Since schema coverage is 0% (below the 50% threshold), the description was required to compensate, but it never explains what video_id represents, how it is used, or what formats are acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries status information (작업 상태, 청크 진행도, 산출물 존재 여부, 로컬 Gemini 사용량 추정) using the verb 조회한다, identifying a specific read operation. However, it does not explicitly distinguish itself from sibling tools by name, though the sibling names (set_chapter_titles, excerpt, frames, purge, register, outline, summary, set_summary) make the status tool's distinct role fairly obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention conditions like 'use this to check progress before other operations' or contrast it with sibling tools. The intended usage context must be inferred entirely from the tool name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
사용자가 전체 영상 요약을 요청할 때만 요약을 만들거나 현재 요약을 재사용한다. 로컬 요약은 즉시 사용 가능하며, packet이 있으면 호스트가 cueprecise_set_summary로 한 번 개선할 수 있다.
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only hints at caching ('reuse current summary') and availability ('immediately usable'). It does not clarify side effects, whether the tool modifies state, or what 'packet' means. The transparency is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and reasonably brief, though it includes some jargon ('packet', 'local summary') that could be clearer. It is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context: what constitutes a 'full video summary', what the output format is, and what a 'packet' refers to. It is not complete enough for an agent to fully understand the tool's role and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one required parameter 'video_id' with no description, and the tool description does not mention it at all. With 0% schema coverage and no compensation, the parameter semantics are not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('create or reuse') and resource ('summary') but lacks specificity about what the tool actually returns or does beyond that condition. It mentions 'local summary' and 'packet' without clear definitions, making the purpose somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a condition ('only when the user requests a full video summary') and references the sibling 'cueprecise_set_summary' for improvements, which gives some guidance. However, it does not explicitly distinguish when to use this tool versus other siblings like 'cueprecise_query' or 'cueprecise_outline'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.5cueprecise_excerptcueprecise_framescueprecise_outlinecueprecise_purgecueprecise_querycueprecise_registercueprecise_set_chapter_titlescueprecise_set_summarycueprecise_statuscueprecise_summaryEach tool targets a clearly distinct resource or action: registration, status, outline, summary, query, excerpt, frames, purge, and two writer/validator tools. Even similar tools like excerpt and frames are separated by retrieval vs extraction, and set_chapter_titles vs set_summary write to different artifacts.
All tools share the consistent cueprecise_ prefix, but the suffix style mixes verbs (register, purge, query), nouns (status, outline, summary, frames), and verb-object pairs (set_chapter_titles, set_summary). This is readable and mostly predictable, but not a uniform verb_noun naming convention.
Ten tools is well-scoped for a video analysis pipeline covering registration, status, content retrieval, summarization, querying, frame extraction, metadata editing, and purging. Each tool earns its place without overlap or bloat.
The pipeline covers the core lifecycle well: register → status → outline/summary/query/excerpt → set metadata → purge. Minor gaps exist, such as no direct full-transcript retrieval tool and no general artifact listing beyond status, but agents can work around these via excerpt paging and status checks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
💯 The fastest YouTube transcript + YouTube search MCP for AI agents. Try for free.
Extract YouTube transcripts, search what was said, and read on-screen frames with cited timestamps.
An MCP server that gives any LLM or agent clean YouTube transcripts on demand: a single video, a whole channel, or a playlist, plus AI cleanup of auto-generated captions. API-key auth, credit-based, same backend as the public v1 API. Get a free API key with 25 free credits at youtubetranscriptdownload.com/account.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Nattentia/cueprecise'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
