Catalyst

Research a Video with Catalyst

analyze_video_url

Read-only

Research public Bilibili or YouTube videos by URL with language, vision, or multimodal analysis; get structured evidence, source-time ranges, and explicit capability limits.

Instructions

Research a public Bilibili or YouTube video using a shared language, vision or multimodal workflow. Returns structured evidence, capability states, source-time precision and explicitly unverified model findings. Source quality follows the available source unless explicitly requested. Comments are opt-in.

Input Schema

Name	Required	Description	Default
`url`	Yes
`mode`	Yes
`language`	No	Preferred caption and ASR language, for example en or zh.
`question`	Yes
`end_seconds`	No	Source-video interval end, after start_seconds and within the source duration. Media windows are limited to 900 seconds.
`media_detail`	No		default
`start_seconds`	No	Source-video interval start. Provide together with end_seconds; URL timestamp parameters do not set the research window.
`source_quality`	No	Optional source acquisition quality. It affects platform downloads, not local-video tools.
`timeout_seconds`	No	Overall research deadline in seconds, including acquisition and model calls.
`include_comments`	No

Output Schema

Name	Required	Description	Default
`video`	Yes
`errors`	Yes
`status`	Yes
`request`	Yes
`analysis`	Yes
`evidence`	Yes
`findings`	Yes
`warnings`	Yes
`processing`	Yes
`capabilities`	Yes
`schema_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0-preview.1Nov 2, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations only declare readOnlyHint, and the description adds real depth: structured evidence with capability states, source-time precision, and explicitly unverified model findings, plus default source-quality and opt-in comments. It omits that this performs network acquisition/downloads and the timeout/latency profile, which would matter for an agent.

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?

Four tight sentences, no repetition, with the capability and return shape front-loaded and the caveats (unverified findings, opt-in comments) trailing.

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?

For a 10-parameter nested tool with 3 required fields and an output schema, the description covers return semantics adequately but leaves the research-window and timeout parameters unexplained and gives no sense of cost or expected duration.

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?

At 50% schema coverage, the description partially compensates by explaining the three modes and the comments/source-quality defaults, but required fields url and question are unaddressed, and mode's enum values are only paraphrased rather than distinguished in effect.

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?

Specific verb and resource: research a public Bilibili or YouTube video via language/vision/multimodal workflows, with return content sketched. It implicitly separates from analyze_video and analyze_bilibili_video by requiring a public URL and a mode, but never names the siblings to sharpen that boundary.

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?

'Comments are opt-in' and 'Source quality follows the available source unless explicitly requested' give conditional behavior, but there is no explicit guidance on when to pick this over analyze_video or inspect_video_window, nor on prerequisites for public-only sources.

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

Deploy Server