Loading ToolBench
MCP server for meeting video analysis — transcription, frame extraction and context delivery to LLMs
Strong tool definitions with comprehensive descriptions and clear parameter schemas. All 9 tools have detailed, LLM-optimized descriptions (150-400 chars) explaining WHAT, WHEN, and HOW. Input schemas are complete with types and descriptions for all parameters. Naming follows verb_noun convention (transcribe, extract_frames, process_meeting). Key strengths: excellent guidance on language/model selection, clear blocking vs non-blocking patterns, and actionable warnings about CPU times. Weaknesses: output schemas not formally documented in code; error handling guidance minimal; no enum constraints on language/model_size despite fixed valid values; destructive tool (close_session) lacks confirmation pattern.
Remove a session from memory and optionally delete its files from disk. Each session stores JPEG frames and JSON metadata on disk. Use this tool to free space when a session is no longer needed. WARNING: Once closed, the session is inaccessible via get_frame. If you need to inspect frames again after closing, re-run process_meeting or extract_frames to create a new session. keep_files behaviour: - keep_files=False (default): deletes the entire session directory from disk (frames + JSON). The space is freed immediately and cannot be recovered. - keep_files=True: removes the session from memory only. Files stay on disk and will be reloaded automatically on the next server restart.
Extract key frames from a meeting video, classify and deduplicate them. Captures frames at regular intervals, discards webcam/person frames, and collapses consecutive similar frames (e.g. the same slide shown for 2 minutes becomes one frame). Returns a session_id and a list of frame metadata. Use this when you only need the visual content without a transcript. For a combined transcript + frames analysis, use process_meeting instead. To view a specific frame image, call get_frame(session_id, frame_id) with the session_id returned here and any frame id from the frames list.
Retrieve a specific frame image from a session as base64 JPEG. Use this to inspect any frame listed in available_frames from process_meeting, or any frame id returned by extract_frames. The response includes the image encoded as base64 JPEG plus the transcript text associated with that time window. Typical usage after process_meeting: 1. Review the inline frames attached to segments. 2. For frames in available_frames that seem relevant (by timestamp or context), call get_frame to see the actual image. Note: sessions are restored from disk on server startup. If a session_id is not found (e.g. the session was created outside the server's search path), re-run process_meeting or extract_frames to create a new one.
Output schemas not formally documented. Tool descriptions explain output conceptually but no structured schema (fields, types, examples) is visible in code. LLMs cannot reliably plan downstream calls or extract nested fields.
language and model_size parameters accept free-form strings instead of enums. Descriptions list valid values ('pt'/'en', 'tiny'/'small'/'medium') but no enum constraint. LLMs may hallucinate invalid values like 'es' or 'large'.
Destructive tool (close_session) lacks confirmation or dry-run pattern. Calling with keep_files=false permanently deletes session data. No recovery guidance if user regrets the action.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Check the status of a background meeting pipeline job. Returns the current status of the job. When status is "done", the full pipeline result is included (same format as the process_meeting tool). When status is "error", the error message is included. Status values: - "running" — pipeline is still in progress (transcription + frames) - "done" — finished successfully, result is available - "error" — failed, check the error field
Check the status of a background transcription job. Returns the current status of the job. When status is "done", the full transcript result is included (same format as the transcribe tool). When status is "error", the error message is included. Status values: - "running" — transcription is still in progress - "done" — finished successfully, result is available - "error" — failed, check the error field
Full meeting pipeline: transcription + frame extraction + temporal association. This is the recommended entry point for meeting analysis. It runs everything in one call: transcribes the audio, extracts slides/screen frames, and links each transcript segment to the most relevant frame at that moment. Output has two parts: - segments: transcript with an optional inline frame per segment (up to max_inline_frames total). Each segment includes start/end times and text. - available_frames: remaining frames not sent inline. Use get_frame(session_id, frame_id) to retrieve any of them with the full image in base64. Before calling, ask the user which language the meeting is in ("pt" or "en") and suggest an appropriate model (same guidance as transcribe). WARNING: This call is synchronous and blocks for the full duration of transcription + frame extraction. Inform the user before calling.
Start a full meeting pipeline (transcription + frames) in the background. Use this instead of process_meeting when you want the chat to remain responsive during processing. The job runs in the background — call get_process_meeting_status(job_id) to check progress or retrieve the result. Before calling, ask the user which language the meeting is in ("pt" or "en") and suggest an appropriate model: - Portuguese meetings: "small" (good balance) or "medium" (best accuracy) - English meetings: "small" is usually sufficient - Avoid "tiny" — poor accuracy especially for Portuguese Approximate CPU times per hour of video: tiny ~7min, base ~17min, small ~27min, medium ~50min Frame extraction adds roughly 1-2 min per hour on top of transcription.
Start a transcription job in the background and return immediately. Use this instead of transcribe when you want the chat to remain responsive while transcription runs. The job runs in the background — call get_transcription_status(job_id) at any time to check progress or retrieve the result when done. Before calling, ask the user which language the meeting is in ("pt" or "en") and suggest an appropriate model: - Portuguese meetings: "small" (good balance) or "medium" (best accuracy) - English meetings: "small" is usually sufficient - Avoid "tiny" — poor accuracy especially for Portuguese Approximate CPU times per hour of video: tiny ~7min, base ~17min, small ~27min, medium ~50min
Transcribe a meeting video and return segments with timestamps. Use this when you only need the transcript. For a full analysis that also extracts slides and screen content, use process_meeting instead — it runs transcription + frames in a single call. Before calling, ask the user which language the meeting is in ("pt" or "en") and suggest an appropriate model: - Portuguese meetings: suggest "small" (good balance) or "medium" (best accuracy) - English meetings: "small" is usually sufficient - "tiny" is fast but has poor accuracy, especially for Portuguese — avoid unless the user explicitly wants a quick rough draft WARNING: This call is synchronous and will block until the transcription finishes. Inform the user before calling so they know the chat will be unresponsive. Approximate CPU times per hour of video: tiny ~7min, base ~17min, small ~27min, medium ~50min
Error handling guidance minimal. Descriptions warn about blocking behavior and CPU times but do not explain what errors can occur, how to recover, or when to retry. E.g., what if video_path is invalid or inaccessible?
Numeric parameters (interval_seconds, similarity_threshold, confidence_threshold, max_inline_frames) lack explicit min/max constraints in descriptions. LLMs may pass out-of-range values (e.g., interval_seconds=-5, similarity_threshold=2.0).