Loading ToolBench
Exposes the Youty vault index (sqlite-vec + FTS5) to MCP-compatible AIs. Provides semantic + keyword search over saved YouTube, Instagram, and TikTok videos with on-device embeddings.
Youty MCP demonstrates solid tool design with clear naming (verb_noun pattern), comprehensive descriptions (194 - 400 chars), and well-structured input schemas. All 7 tools have explicit type definitions and parameter descriptions. However, output schemas are not documented in the source code, and error handling guidance is absent. The search tool's description is exceptionally detailed (pattern:tool-description baseline met), but get_video and get_transcript lack differentiation. No tool annotations (readOnlyHint, destructiveHint) are visible, and no confirmation/dry-run patterns for safety-critical operations.
Find videos visually or semantically similar to a given video. Uses dense embeddings to locate related content in the vault.
Read the full timestamped transcript for one video from the Youty vault. Call this AFTER `search` whenever a chunk you got back looks promising but is truncated — the snippet is ~400 tokens; the full video.md may be 50× longer. Pass the `video_id` from `search`'s result row (e.g. "yt:dQw4w9WgXcQ", "ig:DEF456", "tt:7234567890123456789"). Returns the parsed frontmatter (title, channel, url, tags, duration, date_saved), the full transcript with `[mm:ss]` timestamps, and the absolute path to the video.md file. Reliably resolves the file even if the bundle folder has been renamed since indexing.
Retrieve metadata and full transcript for a video by its ID. Similar to get_transcript but returns structured metadata alongside the transcript text.
List all saved videos in the vault with their metadata. Returns a paginated list of videos with title, channel, platform, URL, tags, duration, and date saved.
Semantic + keyword search over every saved video in the user's vault. This is the FIRST tool to reach for whenever the user asks a question that could be answered using content from their saved YouTube / Instagram / TikTok videos. Internally runs a dense embedder + SQLite FTS5 (BM25) fused via RRF. The dense side is the on-device EmbeddingGemma model — the same model the index was built with, so no API key and no cloud call. Results cover both what a video *said* and what it *showed*: each result's `chunk.type` is "body"/"description"/"header" for the spoken transcript + metadata, or "frame_text" for text recognized **on-screen** via OCR (slides, code, terminal output, labels).
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., video_id from search results for chaining to get_transcript). Baseline: 100% of A+ tools document return types.
get_video and get_transcript have overlapping functionality ('Retrieve metadata and full transcript') without clear differentiation. LLMs may conflate them, causing wrong tool selection. Pattern: distinct tool names for distinct operations.
No error handling guidance. Tools lack recovery hints (e.g., 'If video_id not found, try search() first'). Baseline: error responses must tell LLM what to do next.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | <=2025-11-25 | v2 |
Search for frames across all videos using visual or text-based queries. Finds frames that match the query using on-device embeddings (SigLIP for visual, EmbeddingGemma for text).
Load matching frames as inline images for vision context. Returns the JPEGs as native MCP image content, so the loop's visual half works in EVERY client — not just Claude Code, which is the only one with a filesystem `Read` tool. Hard ceiling on how many frames returned as inline images (max 12). Each image is real vision tokens for the model, so "look at this" stays deliberate and cheap — the agent asks for the few frames that matter, not a contact sheet.
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). All tools are read-only, but this is not declared in schema. Spec 2026-07-28 supports tool annotations for clarity.
list_videos pagination lacks total_count or next_cursor in description. LLMs cannot determine if more results exist or how to fetch them. Baseline: paginated tools must return count or cursor.