MCP for Claude & ChatGPT

Ask about a video

video_ask

Read-only

Ask a question in natural language about a video — on Google Drive, on YouTube or attached to an Odoo record — and get a written answer. Tuqui watches it, screen and audio, so ask about visual and temporal detail freely ('what does the error dialog say', 'what did they click at 3:20'). Only the answer comes back, never the video or a transcript, so several focused questions are cheaper AND better than one big description. Check first whether a transcript already exists — a Google Meet recording has one and reading it is free. This tool is for visual content (a screencast, a UI walkthrough, a demo) or for when there is no transcript. YouTube videos must be PUBLIC: private and unlisted ones cannot be read, and re-uploading one as unlisted does not help. Use start/end for one stretch of a long video — cheaper and more accurate than asking about the whole thing. If a video is too big to read in one go the answer covers only part of it and video.truncated says so: when that happens you MUST tell the user which stretch the answer covers. Set detailed=true only when reading small labels, form fields or grid cells IS the question: stronger model, slower. The current video model reads up to ~1,048,576 tokens of video per question.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "question": "<question>"
    },
    "name": "video_ask"
  }
}

Input Schema

Name	Required	Description
`end`	No	Optional. Where to stop watching, in seconds from the beginning.
`start`	No	Optional. Where to start watching, in seconds from the beginning.
`detailed`	No	Use the stronger model for fine reading of dense UI (small labels, cells). Slower and dearer.
`question`	Yes	What you want to know about the video, in natural language.
`video_ref`	No	The video. Either a Google Drive share link or bare file id (the /d/<id>/ segment), or a YouTube link (watch, youtu.be, /shorts/, /live/). Leave it out for an Odoo attachment.
`attachment_id`	No	The ir.attachment id of a video attached to an Odoo record, as odoo_attachment_content lists it. Pass it instead of video_ref. Up to 200 MB; a bigger video has to be on Drive.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, the description discloses that only an answer is returned (never video or transcript), that YouTube videos must be PUBLIC and re-uploading as unlisted does not help, the ~1,048,576 token read limit, and truncation behavior keyed to `video.truncated` with a mandatory user-facing disclosure. These are exactly the behavioral traits annotations cannot convey.

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?

Front-loaded with purpose, then constraints, then parameter guidance — a sensible order. It is dense rather than bloated, though there is mild overlap between "only the answer comes back ... cheaper ... several focused questions" and the later start/end cost argument, plus the closing token-limit sentence sits somewhat detached.

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 six-parameter, annotation-backed read tool with no output schema, it covers source eligibility, cost trade-offs, partial-reading behavior, and even names the `video.truncated` return field. Minor gaps remain (no explicit duration ceiling or error-mode description beyond truncation), but an agent has enough to call it correctly.

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 100%, so the baseline is 3; the description earns above that by giving the rationale behind two optional params — start/end for "one stretch of a long video ... cheaper and more accurate," and detailed=true as a deliberate trade of speed for fine reading. It does not further clarify video_ref vs attachment_id precedence beyond what the schema already says.

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?

"Ask a question in natural language about a video ... and get a written answer" names a specific verb (ask a question) and resource (a video), and scopes the accepted sources (Drive, YouTube, Odoo attachment). It also implicitly separates itself from audio_transcribe by framing the tool as visual-first.

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

Usage Guidelines5/5

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

Explicit routing: check for an existing transcript first ("a Google Meet recording has one and reading it is free"), use this tool for visual content like screencasts or UI walkthroughs, or when no transcript exists. It also states the start/end alternative for long videos and the precise condition for detailed=true ("only when reading small labels, form fields or grid cells IS the question").

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

All MCP for Claude & ChatGPT tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.