What can you do with this server?

Framesleuth is a local video analysis server that converts videos into structured Context Bundles for coding agents, exposed via MCP tools. All processing runs locally — no data leaves the machine. Video Analysis * Submit any video (bug recording, demo, walkthrough) with optional intent, skill, and action mode to generate a structured report: classification, keyframes, transcript, error evidence, reproduction steps, and a timeline. * Frame-by-frame analysis using a local vision model with adaptive keyframe selection and deduplication. * Detects errors from console logs, OCR, and UI state; generates severity, reproduction steps, and Trust Signals (per-field confidence). * Redacts secrets/PII before model processing. * Supports Ollama, llama.cpp, vLLM, and degrades gracefully without a vision model. Report Management * List all available reports, retrieve full or slim Context Bundles, and inspect specific elements: reproduction steps, error evidence, merged event timeline, or individual keyframe images. Code Grounding * Locate relevant file:line code candidates in a repository based on analysis, respecting .gitignore. Artifact Rendering * Render reports as markdown, GitHub issue text, or test plans. * Generate animated GIF previews of analyzed videos (configurable fps, width, time range). * Convert self-contained HTML/CSS/JS/canvas animations into MP4, WebM, or GIF — frame-by-frame, up to 4K at 5–60 fps. Discovery & Actions * List available summary skills (e.g. bug_report, tutorial, action_items) and action modes (e.g. fix, explain, triage, test, reproduce). * Get a machine-readable suggested_actions menu (action, label, rationale, ref) derived from the report's classification. Observability & Lifecycle * Live job progress via Server-Sent Events (SSE), per-stage timings, job cancellation, webhooks, and TTL-based bundle retention.

How do I use Framesleuth?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Framesleuth analyze the bug recording video" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Framesleuth

by santoshshinde2012

Overview Schema Related Servers Score Discussions

Python

Local

Framesleuth

Local video → structured context for coding agents, exposed over MCP.

Give Framesleuth any video — a bug recording, a feature demo, a design walkthrough, a Loom, a phone capture — and it understands it frame-by-frame (plus optional browser sidecars) and produces a structured Context Bundle. It is MCP-ready, so any MCP client — a VS Code agent, another coding agent, or a custom system — can drive the analysis and consume the result to fix a bug, add or change a feature, or build a whole new feature/app grounded in what the video actually shows.

Capture happens outside this repo: any video works, or a browser capture extension can record a session and post the video + sidecars to this agent's local API. This repo is the analysis agent only.

Everything runs locally. Nothing leaves your machine.

Quick start

Want to go from a video to a grounded change inside VS Code? Follow Use with VS Code & Claude (MCP) — connect the bundled MCP server and turn a recording into a fix, a feature, or a new build.

Fastest: one command with Docker

Everything — the model server, the models, and the API — comes up with a single command. No Python, no virtualenv, no manual model setup.

git clone https://github.com/santoshshinde2012/framesleuth.git
cd framesleuth
docker compose up            # or: ./scripts/dev_up.sh

Compose loads docker-compose.override.yml automatically; that override adds the Ollama server, model-pull job, and Ollama model volume. The first run automatically pulls the vision + coder models (qwen2.5vl and qwen2.5-coder:7b, ~11 GB total) into a Docker volume, then starts the backend on http://127.0.0.1:8010. Subsequent runs are instant. It's ready when the health check reports healthy:

curl -s http://127.0.0.1:8010/v1/healthz | python -m json.tool   # "status": "healthy"

That's the whole setup — run your first analysis (below), or connect the MCP server in your editor (VS Code & Claude).

docker compose logs -f                  # follow progress / model download
docker compose down --remove-orphans    # stop  (add -v to also delete model volumes)

The stack runs its own Ollama on the internal Docker network only (its port is not published), so it never clashes with a native Ollama you may already run on :11434 — the only host port is the API on :8010.

Already run Ollama natively (with the models)? The Docker stack's Ollama is separate and would re-download them. Skip Docker and use the direct path below instead — it reuses your existing Ollama and is faster (especially on macOS, where Docker can't use the GPU).
macOS / no GPU: Docker runs the models on CPU, so the vision model is slow. NVIDIA GPU on Linux: uncomment the deploy: block on the ollama service in docker-compose.override.yml for acceleration.
To run only the backend container against a native/external model server, use docker compose -f docker-compose.yml up. The base compose file defaults to native Ollama on http://host.docker.internal:11434; override VLM_URL and CODER_URL for another server.

Run your first analysis (curl)

Once the API reports healthy (either setup path), go from a video to a Context Bundle in three calls — analysis is async (submit → poll → read):

# 1. Submit any screen recording (mp4/webm). Returns 202 { job_id, ... }
JOB=$(curl -s -F "video=@bug.mp4" http://127.0.0.1:8010/v1/analyze \
  | python -c "import sys, json; print(json.load(sys.stdin)['job_id'])")

# 2. Poll until state is "done" (queued → running → done)
curl -s "http://127.0.0.1:8010/v1/jobs/$JOB" | python -m json.tool

# 3. Read the Context Bundle
curl -s "http://127.0.0.1:8010/v1/report/$JOB" | python -m json.tool

Optional form fields on step 1: -F intent="why does save hang?", -F skill=bug_report, -F action=fix (GET /v1/skills and /v1/actions list the choices). Prefer a UI? Import the Postman collection — it chains these calls for you.

Run it directly (no Docker — fastest on macOS, best for development)

Prerequisites: Python 3.11+, uv, 8 GB+ RAM, and a local model server. ffmpeg is not required (PyAV bundles its own; ffprobe, if present, is used opportunistically to detect an audio stream).

git clone https://github.com/santoshshinde2012/framesleuth.git
cd framesleuth

# 1. Models — native Ollama (uses the Mac GPU) is the quick path
ollama serve &                                  # skip if already running
ollama pull qwen2.5vl && ollama pull qwen2.5-coder:7b

# 2. Install
uv venv && source .venv/bin/activate
uv pip install -e ".[dev]"
python scripts/download_models.py               # optional: pre-warm ASR + check servers

# 3. Configure + start the API (binds 127.0.0.1:8010)
cp .env.example .env                            # already defaults to the Ollama path above
framesleuth-api                                 # or: uvicorn framesleuth.service.api:app --port 8010

# 4. Verify
curl -s http://127.0.0.1:11434/v1/models | grep -q qwen2.5vl && echo "VLM ready"
curl -s http://127.0.0.1:8010/v1/healthz | python -m json.tool   # status: healthy, vlm: ready

When /v1/healthz shows vlm: ready, recordings analyze with a real classification (analysis_quality.level = full/partial). With no vision model reachable, Framesleuth degrades gracefully — it still produces a valid Context Bundle from the browser sidecars (console errors, failed requests, clicks) and records what was thin in analysis_quality. Record with narration so the audio transcript (asr) stage contributes too.

Something not working? Run the setup doctor — it works with a plain python3 even when your virtualenv is broken, and prints a one-line fix for each problem (stale/missing venv, framesleuth-api not on PATH, ffmpeg/render prerequisites, backend or model server not reachable, wrong VLM_URL):
python3 scripts/doctor.py
Common gotcha: command not found: framesleuth-api or a uv pip install error about a missing interpreter means your active venv was deleted/moved. Fix it from the framesleuth directory: deactivate; unset VIRTUAL_ENV; uv venv && source .venv/bin/activate && uv pip install -e ".[dev]".

Stop

# Stop the backend: Ctrl+C in its terminal, or
pkill -f framesleuth-api

# Stop Ollama (optional — leaving it running keeps the model warm)
pkill -f "ollama serve"              # macOS app users: quit Ollama from the menu bar

Related MCP server: popcorn

Architecture

Any video (mp4/webm) + optional sidecars
    ↓
Local Analysis Service (pipeline)
    ├─ Preprocess (PyAV: duration/fps/dims)
    ├─ Transcript (faster-whisper)
    ├─ Keyframes (visual-delta change scoring)
    ├─ Understanding (local vision model — Qwen2.5-VL by default)
    ├─ Fusion + Classification
    ├─ Extraction → Context Bundle
    ├─ Summarize (skill/system-prompt-driven)
    └─ Grounding (workspace search)
    ↓
Context Bundle
    ↓
MCP server + local HTTP API
    └─ consumed by any MCP client (VS Code agent, other agents, capture extension)

Features

Frame-by-frame understanding using a local vision model (Qwen2.5-VL by default; engine-agnostic)
Adaptive keyframe selection — coverage-binned, visual-salience-ranked (AKS-style), with a build-aware budget for feature/design videos and perceptual-hash dedup that drops near-identical frames so the VLM budget is spent on distinct content
Bug and build — a feature class plus a structured build context (screens, UI components, a screen-to-screen user flow, design notes, and where to implement) so an agent can implement, not just diagnose
Error detection and extraction from console, OCR, and UI state
Corpus-aware grounding — error symbols or feature/UI nouns → ranked file:line (definitions preferred, distinctive symbols weighted via IDF + whole-word match), respecting .gitignore and bounded for large repos
Trust signals — per-field confidence (with cross-modal corroboration — agreeing signals reinforce each other) and a task-aware actionability (ready/thin/insufficient) alongside the pipeline quality level
Redaction-first design — secrets (passwords, tokens, keys) and PII (emails, Luhn-valid card numbers, SSNs/phones, cloud keys) are scrubbed from OCR, captions, the transcript, and the raw sidecar streams before any of it reaches a model or is persisted (bundle and the sibling timeline.json / sidecars.json / transcript.json)
Observability — per-stage timings on every bundle (stage_timings) and live on GET /v1/jobs/{id}, so you can see where analysis time went
Job lifecycle & delivery — cooperative cancellation (DELETE /v1/jobs/{id}, checked between frames), a hard per-job timeout (JOB_TIMEOUT_S), crash recovery (orphaned jobs are failed on restart, not left as zombies), SSE progress with explicit terminal events (GET /v1/jobs/{id}/events), a completion webhook (WEBHOOK_URL), real queue depth in /healthz, and TTL retention cleanup (BUNDLE_TTL_DAYS) swept at startup and periodically (RETENTION_SWEEP_INTERVAL_S)
Interaction overlay — a click/cursor sidecar with coordinates draws a marker on the matching keyframe, so the model sees where the user acted
Cleaner transcripts — faster-whisper voice-activity filtering (ASR_VAD_FILTER) drops silence before decoding; detected/forced language is recorded
OCR backstop (optional ocr extra) — a sparse VLM OCR on an error frame gets a second, independent Tesseract reading; a no-op without the extra
No data leaves your machine — fully local, no telemetry or cloud APIs
Engine-agnostic — swap Ollama, llama.cpp, or vLLM via config only
Works on any video — not just bug recordings. A general video (a demo, a walkthrough, a talk, a phone/real-world clip) yields a faithful summary + a timeline of key moments (summary, key_moments[]) instead of being forced into a bug shape; the bug-only fields (severity, expected/actual, repro steps) stay null rather than carrying fabricated placeholders
Structured output — canonical Context Bundle with evidence citations
Configurable response — pick a summary skill and an action mode (fix/implement/design/summarize/explain/triage/test/report/reproduce, auto-picked from the classification), plus a machine-readable suggested_actions menu and on-demand artifact renderers (markdown / GitHub issue / test plan)
Eval harness — model-free classification / grounding / citation / faithfulness suites (python scripts/eval_harness.py --behavioral) run in CI (GitHub Actions: ruff, black, mypy --strict, pytest with coverage, then the eval harness) on every push and PR; the faithfulness suite proves every emitted key moment and step cites real, resolvable evidence (no fabrication)
Resilient — handles no-audio videos, weak local models, low-confidence cases
HTML → video (frame-by-frame) — turn a self-contained HTML animation (CSS/JS/canvas) into MP4, GIF, or WebM via the render_html_video MCP tool or POST /v1/render-html. Captures the animation frame-by-frame under a paused virtual clock and encodes a color-correct H.264 MP4 (yuv420p+bt709, near-lossless) — full color, no dropped frames, no quality loss (up to 4K, 5–60 fps). Included by default in the Docker image (headless Chromium + ffmpeg). For the direct (non-Docker) path, add the render extra (see below); returns 503 with an actionable message when unavailable.

Enable & troubleshoot HTML → video

Using Docker (docker compose up)? HTML→video already works — the image bakes in Playwright + Chromium + ffmpeg. (Build with --build-arg INSTALL_RENDER=false for a slimmer image without it.) The steps below are for the direct path.

Why is Playwright not in the core install? It's an optional [render] extra, not a core dependency, because it pulls a ~150 MB headless-Chromium browser the core video→bundle pipeline never needs — the standard way to ship a heavy, feature-specific dependency. (av, opencv, faster-whisper are core because the pipeline requires them.) Install the extra and you're done — the Chromium build downloads automatically on your first render, so there's no separate playwright install chromium step:

# In the same environment the server runs in:
uv pip install -e ".[render]"        # or ".[all]" = dev + render
# ffmpeg must be on PATH (brew install ffmpeg / apt-get install ffmpeg)

# Restart framesleuth-api, then verify (Chromium fetches itself on first render):
curl -s http://127.0.0.1:8010/v1/healthz | python -m json.tool
# → "render": {"playwright": true, "chromium": <true after first render>, "ffmpeg": true}

Set FRAMESLEUTH_AUTO_INSTALL_BROWSER=0 to disable the auto-download and run playwright install chromium yourself (e.g. in a locked-down environment).

Other optional extra — ocr. For the dedicated OCR backstop on error frames, uv pip install -e ".[ocr]" and put the tesseract binary on PATH (brew install tesseract / apt-get install tesseract-ocr). It's a no-op when absent — the VLM still does OCR; the backstop only adds a second reading. Use ".[all]" for dev + render + ocr.

If render.ready is false, the render.hint field tells you exactly what's missing. The most common cause of "Playwright is not installed" despite following the steps is that framesleuth-api is running from a different environment than the one you installed into (the render.python field shows which interpreter the server uses) — or the server simply wasn't restarted.

Project structure

framesleuth/
├── framesleuth/              # Main package
│   ├── config.py            # Typed config (pydantic-settings)
│   ├── schemas.py           # Data contracts (Context Bundle, enums)
│   ├── errors.py            # Exception taxonomy
│   ├── logging_config.py    # Structured JSON logging, job-id correlation
│   ├── prompts.py           # VLM / classify / summary / fix prompt templates
│   ├── skills.py            # Built-in summary skills (summary, bug_report, ...)
│   ├── actions.py           # Action modes (fix/explain/triage/...) + suggested-actions menu
│   ├── render.py            # Artifact renderers (markdown / GitHub issue / test plan)
│   ├── clients/             # VLM, coder HTTP clients (OpenAI-compatible)
│   ├── pipeline/            # preprocess, asr, scenes, understand, fusion, classify, bug_extract, redact, summarize, sidecars, grounding, html_render
│   ├── orchestrator/        # graph.py — linear async stage pipeline
│   ├── jobs/                # store.py — SQLite job state + bundle index
│   ├── service/             # FastAPI HTTP endpoints
│   └── mcp_server/          # framesleuth MCP server (VS Code + any MCP client)
├── tests/                   # pytest tests + fixtures
├── scripts/                 # doctor.py (setup check), download_models.py, dev_up.sh
├── postman/                 # HTTP API collection + environment
├── docs/                    # capabilities, use-with-vscode-and-claude, web-integration
└── pyproject.toml           # Dependencies and tool config

Development

Run tests

pytest tests/ -v --cov=framesleuth

Code quality

ruff check framesleuth tests
black --check framesleuth tests
mypy --strict framesleuth

Set up pre-commit hooks

pre-commit install

A short, focused set:

Capabilities — the single reference: every input, output, skill, action, renderer, HTTP endpoint, and MCP tool
Use with VS Code & Claude (MCP) — connect the framesleuth MCP server to Copilot, Claude Code, and Claude Desktop
Web App Integration (end-to-end) — embed Framesleuth behind your own backend with an agent loop
Postman Collection — exercise the HTTP API end-to-end (import or run headless with Newman)
Runbook & Troubleshooting — setup, health checks, and common issues

License

Apache-2.0

Capture client

Bug capture lives outside this repo. Any screen recording works — drive the agent directly with your own video file. A browser capture extension can also record a session, collect browser sidecars (console errors, failed requests, clicks), and post the video + sidecars to this agent's local API. CORS is allowlisted (WEB_ORIGINS, default: the hosted demo site

local dev) plus chrome-extension:// origins, and the agent answers Chrome's Private Network Access preflight — so both a capture extension and the "Try it" widget on framesleuth.com work against a locally running backend with no extra setup. The agent stays bound to loopback; CORS only controls which browser origins may read its responses.

Status: Backend + pipeline + MCP server completed. Questions? Open an issue or check runbook.md for common questions.

Available Tools

14 tools

analyze_videoA

Analyze any video and return the new report id.

Works on any kind of video — a bug recording, a feature demo, a design walkthrough, a Loom, a phone capture — and distills it into a structured Context Bundle a coding agent can act on (fix a bug, add or change a feature, or build something new).

Args: path: Path to the video file (.mp4/.webm/.mkv/.mov/.avi). repo_root: Repo to ground references against (pass the open workspace). intent: The user's request to act on, e.g. "fix the save button that hangs", "add a dark-mode toggle like the demo shows", or "build this onboarding screen from the walkthrough". It is recorded on the report and shapes the generated action prompt so the calling agent does what the user actually asked. skill: Built-in summary style — one of the names from list_skills (e.g. "summary", "bug_report", "tutorial", "action_items"). Defaults to "summary". system_prompt: A fully custom system prompt for the summary; overrides skill when provided. action: Built-in action mode shaping the fix-prompt — one of the names from list_actions (e.g. "fix", "explain", "triage", "test", "report", "reproduce"). Auto-picked from the classification when omitted. action_prompt: A fully custom action task; overrides action.

Returns the report id, the summary/fix-prompt resource URIs, the resolved action, and the derived suggested_actions menu.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`skill`	No
`action`	No
`intent`	No
`repo_root`	No
`action_prompt`	No
`system_prompt`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a new report id and list of outputs (summary/fix-prompt URIs, resolved action, suggested actions). It describes supported video formats. It doesn't mention side effects, but for a read-like analysis tool, this is adequate. More could be said about whether the tool modifies anything or requires specific permissions.

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?

The description is well-structured with a clear opening line, a paragraph of context, then a list of arguments with explanations. It is concise enough (around 150 words) and front-loaded with the main purpose. Minor redundancy in the 'Args:' section could be tightened, but overall it's efficient.

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?

Given 7 parameters (1 required), no annotations, and an output schema existing, the description covers the key aspects: input formats, parameter meanings, and return value structure (report id, URIs, action, suggestions). It does not mention potential errors or prerequisites (e.g., ffmpeg installation), but for typical usage within a coding agent environment, this is sufficient.

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?

The schema has 0% description coverage (no enum definitions, and parameters are generic anyOf string), but the description provides detailed explanations for each parameter: path (file format), repo_root (grounding references), intent (user request), skill (summary style from list_skills), system_prompt (overrides skill), action (action mode from list_actions), action_prompt (overrides action). This fully compensates for the missing schema descriptions.

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 explicitly states it analyzes any video and returns a report id, using strong verbs like 'analyze' and 'return'. It lists varied video types (bug recording, feature demo, etc.) and explains the output (structured Context Bundle for coding agents). This clearly distinguishes it from sibling tools like get_keyframe_image or get_timeline, which deal with specific parts of the analysis.

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?

The description explains when to use the tool: to analyze any video for a coding agent. It implicitly suggests when not to use it by describing the full analysis scope, but it doesn't explicitly name alternative tools or conditions where other tools (e.g., get_error_evidence) are better suited.

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

get_error_evidenceC

Return the timestamped error evidence for a report.

ParametersJSON Schema

Name	Required	Description	Default
`report_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description must bear full weight. It says 'return,' implying read-only, but lacks disclosure of side effects, permissions, rate limits, or other behavioral traits beyond the basic read operation.

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?

The description is a single, clear sentence with no superfluous words. It is front-loaded with the action and resource, making it easy to parse, though it could benefit from additional context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter and an output schema, the description is too minimal. It does not clarify what 'timestamped error evidence' specifically entails, nor does it help distinguish among many sibling retrieval tools.

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

Parameters2/5

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

The single parameter 'report_id' is not described in the text, despite 0% schema coverage. While its purpose is somewhat evident from its name, the description adds no semantic value or constraints beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'return' and the resource 'timestamped error evidence for a report,' providing specific intent. However, it does not differentiate from sibling tools like 'get_report' or 'get_repro_steps,' which could cause confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it, leaving the agent without decision-making support.

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

get_keyframe_imageC

Return a keyframe image for a report by its index.

ParametersJSON Schema

Name	Required	Description	Default
`index`	Yes
`report_id`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It only states the function without mentioning what the return value is (e.g., image URL, binary data) or any 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no fluff, but it lacks structure. It could benefit from front-loading the purpose and adding brief parameter details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, the description is insufficient. It does not specify the output format (e.g., image data, URL) or any constraints, making it incomplete for inference.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no extra meaning to parameters. 'index' and 'report_id' are not explained (e.g., index base, valid report IDs).

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 clearly states the action ('Return') and the resource ('keyframe image for a report by its index'), effectively distinguishing it from sibling tools like 'get_video_gif' or 'get_report'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description does not mention prerequisites or provide context for selection among many sibling tools.

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

get_reportA

Return the Context Bundle for a report id.

view="full" (default) returns everything; view="slim" returns the action-relevant subset (classification, quality, steps, evidence, candidates, suggested actions) for agents on a small context window.

ParametersJSON Schema

Name	Required	Description	Default
`view`	No		full
`report_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description adequately discloses the return content and view options. It doesn't mention error handling or side effects, but for a read-like tool this is acceptable.

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?

Two sentences, front-loaded with the main purpose, then succinctly explains the view parameter. No wasted words.

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?

Given sibling tools, this tool is comprehensive. Output schema exists, so return values are handled. Description effectively covers functionality.

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

Parameters4/5

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

Schema coverage is 0%, but the description explains the view parameter with two options and meanings. Report_id is covered implicitly, though not elaborated.

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 clearly states the tool returns a Context Bundle for a given report id, and distinguishes between 'full' and 'slim' views. It differentiates from siblings that extract specific parts.

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?

Provides guidance on when to use each view based on context window size. While it doesn't explicitly list alternatives, the implied use cases are clear.

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

get_repro_stepsA

Return the numbered reproduction steps for a report.

ParametersJSON Schema

Name	Required	Description	Default
`report_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

No annotations provided, description lacks behavioral details like read-only nature, side effects, or prerequisites. Simply states what it returns.

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?

Extremely concise: a single sentence that directly states the tool's function with no wasted words.

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?

For a simple retrieval tool with an output schema, the description is largely sufficient. Could mention that the report must exist, but overall adequate.

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

Parameters2/5

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

Schema description coverage is 0%. The single parameter 'report_id' is self-explanatory, but description adds no extra context or format guidance beyond the schema.

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?

Description clearly states verb 'Return', resource 'numbered reproduction steps', and scope 'for a report'. This distinguishes it from sibling tools like get_report or get_error_evidence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance. It's implied the tool is for retrieving reproduction steps for a given report_id, but no alternatives mentioned.

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

get_suggested_actionsA

Return the machine-readable next-step menu for a report.

Each item is {action, label, rationale, ref} — present them to the user or auto-invoke the referenced resource/tool. Recomputed from the current bundle so it reflects the latest grounding/quality.

ParametersJSON Schema

Name	Required	Description	Default
`report_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

Provides behavioral context that the menu is recomputed and reflects latest grounding/quality. However, since no annotations exist, the description should explicitly state if it's read-only or has no side effects. It does not mention authentication or mutability.

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?

Two sentences, first defines purpose, second explains items and recomputation. No superfluous words. Information is front-loaded and clear.

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?

Covers purpose, output structure, and dynamic nature. However, lacks error handling information or any expansion on the return schema, which is present. For a simple read tool with one parameter, it is nearly complete.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate. It ties the single parameter 'report_id' to the report context but does not elaborate on format or constraints. Since only one parameter exists and is implied, the description adds marginal value.

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?

Clearly states the action 'Return' and the resource 'machine-readable next-step menu for a report'. Further describes the items and their use, distinguishing from sibling tools that focus on analysis, reports, or specific actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage context through description of dynamic recomputation from current bundle, but does not explicitly state when to use or when to prefer alternatives. No mention of when not to use or comparisons with sibling tools.

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

get_timelineC

Return the merged event timeline for a report.

ParametersJSON Schema

Name	Required	Description	Default
`report_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states a return action, omitting any read-only nature, permission requirements, or side effects. For a non-destructive read operation, this is minimal disclosure.

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?

A single sentence is appropriately concise and front-loaded. Every word earns its place, though more detail would improve value without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, return values are not needed. However, with 0% parameter description coverage and no annotations, the description fails to compensate. Context signals show high complexity in sibling tools, requiring more guidance.

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

Parameters1/5

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

The single parameter 'report_id' has 0% schema description coverage, and the description adds no explanation of its meaning, format, or how to obtain it. The tool relies entirely on the parameter name for semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns a 'merged event timeline for a report', identifying the verb and resource. However, it lacks sibling differentiation; numerous get_* sibling tools exist, and 'merged event timeline' remains vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool over alternatives like get_report or get_repro_steps. There is no when-to-use, when-not-to-use, or prerequisites information.

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

get_video_gifA

Render an animated GIF preview of the video for a report.

Useful for embedding a short looping preview in an issue, chat, or PR description. fps/width/start/end are optional and clamped to safe ranges; the GIF is cached on disk per parameter set.

ParametersJSON Schema

Name	Required	Description	Default
`end`	No
`fps`	No
`start`	No
`width`	No
`report_id`	Yes

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries full responsibility. It reveals that parameters are 'clamped to safe ranges' and 'the GIF is cached on disk per parameter set,' offering useful behavioral insights. However, it does not mention permission requirements, side effects like cache eviction, or the nature of the return (binary vs. URL).

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 concise—three sentences—and front-loads the primary purpose. Every sentence adds value, with no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and 5 parameters, the description does not specify the return format (e.g., binary data, URL) or error handling. It covers caching behavior and parameter clamping, but leaves gaps in understanding the output and potential failure modes.

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

Parameters2/5

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 mentions that fps, width, start, and end are optional and clamped, but fails to explain their meaning (e.g., units for time parameters, default values for fps and width). Given 5 parameters with no schema descriptions, additional detail is needed for accurate invocation.

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 clearly states the tool's action ('Render an animated GIF preview of the video for a report') with a specific verb ('Render') and resource ('animated GIF preview of the video for a report'). It distinguishes itself from siblings like get_keyframe_image (static) and render_html_video (different format) by emphasizing animation and GIF format.

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?

The description provides explicit use cases ('embedding a short looping preview in an issue, chat, or PR description') and notes that parameters are optional and clamped. However, it does not explicitly compare with sibling tools like analyze_video or get_keyframe_image, nor does it state when not to use this tool.

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

list_actionsA

List built-in action modes (names + descriptions) for analyze_video.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must convey behavioral traits. It only states the action of listing names and descriptions, without disclosing side effects, read-only nature, rate limits, or authentication needs. For a list operation, the description does not confirm it is safe or non-destructive.

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 a single, concise sentence that immediately communicates the purpose. Every word serves a function, and there is no redundancy or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and an output schema exists, the description is adequate but minimal. It covers the basic function but omits behavioral context and fails to explain when or why to use this tool. Completeness is borderline acceptable for a simple list tool.

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

Parameters4/5

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

The input schema has zero parameters, so the description does not need to explain parameters. However, it adds value by specifying that the output includes names and descriptions and that it is specific to 'analyze_video'. Baseline for 0 params is 4.

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 clearly states the tool lists built-in action modes for 'analyze_video', specifying both names and descriptions. This is a specific verb and resource, and it distinguishes itself from siblings like 'list_reports' and 'list_skills' by tying directly to a particular parent tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for discovering available actions for 'analyze_video', but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The context is clear but missing actionable usage rules.

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

list_reportsA

List all available report ids (from any analyzed video).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description effectively communicates the read-only nature and scope (from any analyzed video). It does not disclose potential limitations like pagination or ordering, but the simplicity of the tool (no parameters) reduces the need for extensive behavioral details.

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 a single, concise sentence with no wasted words. It front-loads the verb and resource, making it quick to parse.

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?

Given the tool has no parameters, an output schema exists, and sibling tools provide context, the description is sufficiently complete. It clearly conveys the tool's purpose without missing critical information.

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

Parameters4/5

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

There are no parameters, so the input schema already covers everything. The description does not add parameter semantics, but the baseline for zero parameters is 4, as no additional explanation is needed.

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 clearly states the tool lists all available report IDs from any analyzed video. It uses a specific verb 'list' and resource 'report ids', and the scope 'all available' differentiates it from sibling tools like get_report which retrieves a specific report.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not mention that the IDs can be used with get_report, nor does it specify when not to use it. The description only states what it does without usage context.

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

list_skillsA

List built-in summary skills (names + descriptions) for analyze_video.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations, so description carries full burden. It states it lists names and descriptions, implying a read-only operation, but lacks details on side effects, rate limits, or return structure beyond what output schema might provide.

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?

Single sentence front-loads the action and resource, with no extraneous words or redundancy.

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?

For a parameterless list tool with an output schema, the description is minimally adequate. It could benefit from clarifying the purpose of skills in relation to analyze_video.

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

Parameters4/5

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

No parameters exist, baseline 4. Description adds meaning by specifying the tool returns names and descriptions, aligning with the schema.

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 clearly states the tool lists built-in summary skills for analyze_video, with specific verb 'list' and resource 'built-in summary skills', distinguishing it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied (for analyze_video), but no explicit guidance on when or when not to use it vs alternatives is provided.

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

locate_in_codeC

Return code candidates already grounded in the bundle, or re-ground now.

ParametersJSON Schema

Name	Required	Description	Default
`repo_root`	No
`report_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.1/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only mentions returning candidates and re-grounding. It does not explain the re-grounding process, side effects, authentication needs, or output structure, leaving critical behavioral traits undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no redundancy, but it sacrifices clarity for brevity. It is not optimally structured to convey essential information upfront.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description fails to explain the return value, parameter roles, or tool behavior. With no schema annotations and minimal description, the tool is severely incomplete for an agent to use correctly.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not clarify or add meaning to the two parameters (`report_id`, `repo_root`). The agent receives no help in understanding how these parameters affect the tool's behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it returns code candidates and can re-ground, but the term 'grounded in the bundle' is jargon that obscures clarity. The verb 'locate' aligns with the tool name, but the overall purpose is vague without context on what 'code candidates' means.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool over siblings. The description lacks any context on appropriate usage scenarios or alternatives, leaving the agent to infer based solely on the name.

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

renderB

Render a report as a shareable artifact.

format is one of markdown, issue (GitHub issue text), or test-plan. Returns the rendered text.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No		markdown
`report_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description bears the full burden. It only states that the tool returns rendered text, but does not disclose whether it is read-only, idempotent, or has side effects. No mention of errors or permissions needed.

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 very concise: two sentences, no fluff. Every sentence adds necessary information (purpose and format details). Front-loaded with the action.

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?

Given the tool's simplicity and the existence of an output schema (which likely describes the return format), the description covers the essential aspects. It could mention that the report must exist, but for a rendering tool, this is acceptable.

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

Parameters3/5

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

The description adds value for the 'format' parameter by listing the allowed values (markdown, issue, test-plan), which is not in the schema's type alone. However, the required 'report_id' is not explained. Schema coverage is 0%, so the partial explanation is helpful but incomplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool renders a report as a shareable artifact, and lists specific formats (markdown, issue, test-plan). This distinguishes it from sibling tools like get_report (raw data) and render_html_video (video output), though it could be more explicit about differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like get_report or get_suggested_actions. The description does not mention prerequisites or context for invocation.

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

render_html_videoA

Render an HTML document (CSS / JS / canvas animation) to mp4/gif/webm.

Use this to export a self-contained animated HTML page (e.g. one you just designed) as a shareable clip. Captures the animation frame-by-frame (full color, no dropped frames, no quality loss) and encodes a color-correct H.264 MP4 / VP9 WebM / palette GIF — up to 4K, 5-60 fps. Returns the absolute path to the encoded file, written under the bundle directory. Requires the optional render extra (Playwright) + ffmpeg.

ParametersJSON Schema

Name	Required	Default
`fps`	No
`html`	Yes
`width`	No
`format`	No	mp4
`height`	No
`duration_s`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations, description fully discloses behavior: frame-by-frame capture, quality preservation, color correction, codec details, resolution/fps range, output format (absolute path), and required dependencies (Playwright, ffmpeg). No contradictions.

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?

Well-structured single paragraph with clear segments: purpose, usage, behavior details, and requirements. Slightly verbose in listing quality claims, but overall concise and front-loaded.

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?

Covers core behavior, prerequisites, and output format. Parameter details are not explained, but schema provides defaults. With no output schema, description notes return path. Adequate for a tool with 6 params and dependencies.

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

Parameters3/5

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

Schema coverage is 0%, so description should compensate. It mentions output formats (mp4/gif/webm) which correspond to the 'format' parameter, but does not explain other parameters beyond what schema provides. Baseline 3 is appropriate as schema has defaults and types.

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?

Clearly states verb 'render' and resource 'HTML document' to video formats. Distinguishes from sibling tools like analyze_video by focusing on export of animated HTML pages.

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?

Explicitly says 'Use this to export a self-contained animated HTML page as a shareable clip.' Provides clear usage context but does not mention when not to use or alternatives among siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

14 tool updatesv0.1.0Jun 29, 2026
- First observedanalyze_video
- First observedget_error_evidence
- First observedget_keyframe_image
- First observedget_report
- First observedget_repro_steps
- First observedget_suggested_actions
- First observedget_timeline
- First observedget_video_gif
- First observedlist_actions
- First observedlist_reports
- First observedlist_skills
- First observedlocate_in_code
- First observedrender
- First observedrender_html_video

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: analyze_video is the entry point, get_* tools retrieve specific aspects of a report, list_* tools enumerate available options or reports, render tools produce output, and locate_in_code handles code grounding. No overlapping functionality.

Naming Consistency5/5

All 14 tool names follow a consistent verb_noun pattern using snake_case (e.g., analyze_video, get_report, list_skills, render_html_video). No deviations or mixed conventions.

Tool Count5/5

14 tools is well-scoped for a video analysis and rendering server. It covers analysis, report retrieval, listing, rendering, and code location without being overwhelming or sparse.

Completeness5/5

The tool surface is thorough for its domain: analyzing videos, retrieving all report components, rendering to multiple formats (Markdown, GitHub issue, test plan, GIF, MP4), and even grounding code locations. The only minor gap is the lack of a delete/update tool, but those are unnecessary for its core purpose.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

clipkit A
dev.clipkit
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
Multimedia Processing Image & Video Processing
15215
BugEzy A
dev.bugezy
Voice-powered bug reporting with 13 MCP tools. Record bugs by talking; let AI find and fix them.
Speech Processing Testing & QA Tools Coding Agents
142
ContendeoOAuth
app.contendeo
Multimodal video analysis MCP — transcription, vision, and OCR for any video URL.
Multimedia Processing Image & Video Processing AI & Machine Learning
2
agent-replay-debugger-mcp
io.github.CSOAI-ORG
Agent Replay Debugger MCP — record every agent step + deterministic replay. Step-debugger for
Agent Orchestration Testing & QA Tools
2

Related MCP Servers

mcp-video-analyzer
Image & Video Processing Multimedia Processing Web Scraping
guimatheus92
A
license
A
quality
A
maintenance
MCP server for video analysis — extracts transcripts, key frames with OCR, and annotated timelines from video URLs. Supports Loom and direct video files (.mp4, .webm). Zero auth required.
Updated 19 hours ago (2026-09-05 18:26 UTC)
4
8
570
58
MIT
popcorn
Multimedia Processing Image & Video Processing Speech Processing
haithamelmengad
A
license
A
quality
D
maintenance
An MCP server that enables AI agents to analyze videos locally by extracting transcripts, detecting scene changes, and returning key frames.
Updated 7 months ago (2026-02-05 12:49 UTC)
5
6
MIT
Screen Vision MCP Server
Image & Video Processing Monitoring
avicuna
F
license
A
quality
B
maintenance
Enables Claude to capture screenshots, watch your screen in real-time, read text via OCR, and analyze video files, all running locally as an MCP server.
Updated 20 days ago (2026-08-17 23:05 UTC)
14
-
vidsight
Image & Video Processing Search AI & Machine Learning
szepix
A
license
Not graded
quality
B
maintenance
Enables AI agents to query local video timelines by extracting speech, frame captions, and on-screen text into a SQLite store, exposing search and retrieval tools via MCP.
Updated 2 months ago (2026-06-29 22:43 UTC)
PolyForm Noncommercial 1.0.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/santoshshinde2012/framesleuth'

If you have feedback or need assistance with the MCP directory API, please join our Discord server