Enables research on Bilibili public videos, including video metadata, available captions or audio/ASR fallback, media analysis, optional sampled comments, and a legacy Bilibili-specific analysis tool.
Enables research on YouTube public videos, including metadata, available manual or automatic JSON3 captions, and media analysis; comment sampling is unsupported in this preview.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Catalyst analyze this YouTube video: what animals are visible in the first 15 seconds?"
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.
简体中文 · English
Catalyst is a video research MCP server for existing agents. It brings Bilibili and YouTube into a shared workflow for language, visual, or multimodal questions, with explicit evidence sources, source-time ranges, availability states, and analysis limits.
Catalyst evolves from Bilibili Video Research, retaining its Git history and existing BVR tools. This is an early preview, installed from source.
Source | Scope |
Bilibili | Public video metadata, available captions or audio fallback, media research, and optional sampled comments. Access and source quality depend on the video and authorized account. |
YouTube | Public video metadata, available manual or automatic JSON3 captions, and media research. Comment sampling reports |
Local files | Existing visual analysis and silent-window inspection tools. |
Douyin and Xiaohongshu | Acquisition research candidates; no preview support claim. |
Discovery, cross-platform search, and long-running task scheduling are later work. The host agent owns the overall task and conversation.
Related MCP server: youtube-research-mcp
Requirements:
Node.js 24 or newer.
Python 3.10 or newer when using a Python-based yt-dlp distribution.
A working yt-dlp installation with EJS for YouTube, plus FFmpeg.
A StepFun or Gemini credential for model analysis.
git clone https://github.com/7oMB2006/Catalyst.git
cd Catalyst
npm ci
npm run build
cp .env.example .env
# Configure the provider and any external binary paths in .env.
npm run doctor
npm testOn Windows, use Copy-Item .env.example .env in place of cp; use py -3 -m pip or a configured python -m pip if python3 is not available.
Bundled media dependencies are used when available. For an external downloader, install the official Python distribution and set its executable path:
python3 -m pip install 'yt-dlp[default]'YTDLP_PATH=/absolute/path/to/yt-dlp
# Set this when the selected downloader needs a specific Python interpreter.
YTDLP_PYTHON=/absolute/path/to/python
FFMPEG_PATH=/absolute/path/to/ffmpegThe inherited yt-dlp-exec package is optional. Its install hook invokes python; when that command is absent or too old, npm can omit this optional dependency. Use an external yt-dlp installation through YTDLP_PATH, or make Python >=3.10 available as python in the installation environment if you want the optional bundle. YTDLP_PYTHON controls runtime execution; it does not change that install hook. FFmpeg's bundled binary may also be unavailable on a particular platform; FFMPEG_PATH is the explicit fallback.
npm run doctor runs the compiled dist/doctor.js, so build first. It checks local executable versions and whether a provider credential is configured. It does not contact video platforms or providers, read browser cookies, or test account balance. EJS detection can be inconclusive for standalone binaries; review any warning before a YouTube request. See the upstream EJS setup guide.
npm startThis starts the compiled stdio server. In an MCP host, use node as the command and the absolute path to dist/index.js as its argument. Set DOTENV_CONFIG_PATH to the absolute path to the local .env file when the host starts in a different directory. Configure the host's tool timeout to cover the requested research timeout and startup overhead.
Provider credentials belong in the process environment or local .env, rather than the host's checked-in configuration. CODEX_VIDEO_PROVIDER remains the historical provider selector: stepfun by default, or gemini.
analyze_video_url({
url: "https://www.youtube.com/watch?v=jNQXAC9IVRw",
question: "Which animals are visible, and what features can actually be seen?",
mode: "vision",
media_detail: "default",
include_comments: false,
start_seconds: 0,
end_seconds: 15,
timeout_seconds: 240
})Mode | Evidence used |
| Available platform captions first; otherwise audio/ASR. Video frames are excluded. |
| Video with its audio removed. Visible text remains valid visual evidence. |
| Original audio and visual channels. |
Provide start_seconds and end_seconds together. For media longer than 900 seconds, the generic tool requires an explicit window of at most 900 seconds; otherwise it returns WINDOW_REQUIRED. Caption-only language research is not subject to this media-upload limit. The legacy BVR entry retains its coarse/detail pass for long visual videos. language can select a preferred caption/ASR language. Actual capabilities and failures are reported for each source; an unavailable comment path does not establish that video research failed.
The new tool uses an available source by default, recording its actual quality. Visual and multimodal acquisition prefer formats at or below 1080p; inspect the reported dimensions when a source fallback is used. The default media-file budget is 256 MiB, configurable through CATALYST_MAX_MEDIA_MB. Acquisition can download the entire source before cutting the requested interval, and this preview has no cross-request media or transcription cache. To impose a quality threshold, supply source_quality, for example:
source_quality: { profile: "high", on_unavailable: "error" }Profiles inherited from BVR are standard (1080p30), high (1440p30), and custom with explicit resolution/fps. A missing target fails by default; on_unavailable: "warn" allows a reported fallback. Requesting higher quality cannot recover detail absent from the original video.
The generic tool returns structured results together with readable text. The result records video identity, requested mode/window, per-capability states, evidence, findings, warnings, errors, and processing information.
Caption evidence retains source cue times and language.
A media window records the interval supplied for analysis. It does not give every generated sentence a verified timestamp.
Model findings remain verification: "unverified". References to real evidence IDs validate the reference structure, not the truth of each statement.
Frame numbers and precise times generated by a model are not deterministic extraction records. Missing or unconfirmed precision stays explicit.
complete, partial, and unavailable distinguish an analysis response from retained evidence or a failure. Unavailable provider usage and monetary cost remain unknown.
Review supporting source material before relying on a specific claim. The architecture and validation record describe these boundaries.
The existing tools remain available:
analyze_bilibili_video: the Bilibili-specific tool and its legacy text/provenance format.
analyze_video: visual analysis of a local video.
inspect_video_window: visual analysis of a local source interval.
The legacy Bilibili tool retains its strict default 1080p30 quality policy. The generic tool's default is available source quality. Existing STEPFUN_*, GEMINI_*, and BILIBILI_* settings remain supported.
Authentication is explicit and platform-scoped. Set an authorized cookies file or browser source only for its intended platform; the YouTube adapter does not reuse Bilibili's credentials. Public metadata, selected captions/audio/video, and optional community content may be sent to the configured model provider.
npm run dev
npm run typecheck
npm test
npm run buildTests are local and do not require provider credentials or live video platforms. The compiled generic tool has been exercised on YouTube captions, a nonzero YouTube visual window, and Bilibili audio/ASR fallback. The latter returned partial with explicit caption access and discarded-citation warnings. These checks validate integration and citation structure, not model accuracy. Exact observations and deployment checks are listed in validation.
After building, a production deployment can retain dist and install with npm ci --omit=dev. Both npm start and npm run doctor then run compiled JavaScript without tsx; external media dependencies and provider configuration still need to pass doctor.
MIT. Original BVR history and attribution are retained.
Resolves a public Bilibili URL, always returns public metadata and an explicit community-context status, and optionally samples 20 most-liked root comments while displaying only 3 hot comments plus up to 2 distinct high-signal comments. Supports language-only, visual-only, and multimodal research.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public Bilibili video URL, including b23.tv short URLs. | |
| mode | Yes | language: captions then audio only; vision: silent video only; multimodal: original video with both channels. | |
| question | Yes | The research question. | |
| end_seconds | No | Optional source-video interval end in seconds. Provide together with start_seconds. | |
| media_detail | No | Use low for a broad long-video pass and default for close inspection. | default |
| start_seconds | No | Optional source-video interval start in seconds. Provide together with end_seconds. | |
| source_quality | No | Optional source acquisition quality. It affects platform downloads, not local-video tools. | |
| include_comments | No | Include untrusted community context. Fetches at most 20 most-liked root comments, presents only 3-5 representative comments, and reports empty or fetch-failed status explicitly. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint=true in annotations, the description adds substantial behavioral context: it promises public metadata and an explicit community-context status, and specifies the comment sampling and display policy in detail. That goes well beyond the annotation and helps an agent understand what the tool will actually do with community context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted clauses, front-loading the resolution behavior and return guarantees before covering research modes. The detailed comment sampling figures are dense but purposeful and easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with a nested source_quality object and no output schema, the description covers the main return behavior and the unusual comment-sampling policy. It could still be more explicit about the shape of public metadata and community-context status values, but the schema fills in most parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the mode choices and comment-sampling behavior, but adds little new parameter semantics beyond what the schema already documents for url, mode, include_comments, interval, and source_quality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: resolving a public Bilibili URL and returning metadata plus optional comment context, with modes for language, vision, and multimodal research. It clearly distinguishes the Bilibili-specific scope, but does not explicitly contrast it with siblings such as analyze_video_url or analyze_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage through the supported research modes and the requirement for a public Bilibili URL, but gives no explicit when-to-use guidance, exclusions, or comparison to the sibling tools. An agent must infer when this tool is preferable to generic video tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates an audio-free copy of a local video and sends it to the configured video-analysis provider for visual research. Visible interfaces, code, charts, labels, and subtitles remain usable visual evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | A visual-only research question about observable actions or interactions. | |
| video_path | Yes | Absolute path to a local video file. | |
| media_detail | No | Use low for a long coarse pass; use default for movement, small objects, and precise inspection. | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful context beyond the readOnlyHint annotation by revealing that an audio-free copy is created, the video is sent to an external provider, and visual elements remain usable evidence. This clarifies the non-destructive nature and external dependency, though it does not mention return values or processing time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using just two sentences. It is front-loaded with the core function ('Creates an audio-free copy...'), and the second sentence adds relevant detail about what remains visible without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the process well but omits critical information about the tool's return value and whether it runs asynchronously. Since there is no output schema, this gap affects completeness, though other aspects like annotations and schema coverage are solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions for all three parameters, achieving 100% coverage, so the baseline is met. The description does not add additional parameter guidance, such as when to choose media_detail 'low' versus 'default', but the schema already covers this sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it creates an audio-free copy of a local video and sends it to a video-analysis provider for visual research. It differentiates from sibling tools by specifically targeting local videos and emphasizing the preservation of visible UI elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for local video visual research but does not explicitly state when to use this tool instead of inspect_video_window or analyze_bilibili_video. It only hints at the local video context, which some differentiation, but lacks explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 |
| Name | Required | Description |
|---|---|---|
| video | Yes | |
| errors | Yes | |
| status | Yes | |
| request | Yes | |
| analysis | Yes | |
| evidence | Yes | |
| findings | Yes | |
| warnings | Yes | |
| processing | Yes | |
| capabilities | Yes | |
| schema_version | Yes |
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.
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.
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.
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.
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.
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.
Extracts an audio-free temporary clip for the requested source-video time window, then sends that clip to the configured video-analysis provider for visual-only analysis. Temporary media and remote uploads are removed after the answer.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | A visual-only research question about observable actions or interactions. | |
| video_path | Yes | Absolute path to a local video file. | |
| end_seconds | Yes | End time in seconds in the source video; must be after start_seconds. | |
| media_detail | No | Use low for a long coarse pass; use default for movement, small objects, and precise inspection. | default |
| start_seconds | Yes | Start time in seconds in the source video. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by disclosing that it creates temporary clips, performs remote uploads, and cleans up afterward. It also specifies the analysis is audio-free and visual-only, adding valuable behavioral context without contradicting the readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and includes a clean note about cleanup. Every word earns its place, with no redundant information. This is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the process (extract, analyze, cleanup) and the annotations cover safety, but with no output schema, it does not explicitly describe the return value format. It implies an answer is provided but does not state whether it is text, a report, or something else. This is a minor gap, given the tool's purpose is fairly self-explanatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific details beyond what the schema already provides, but it does reinforce the time-window context (start_seconds/end_seconds) implicitly. No additional param semantics are introduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific function: extracting an audio-free temporary clip for a requested time window and sending it for visual-only analysis. It uses precise verbs ('extracts', 'sends') and names the resource (source-video time window), distinguishing it from whole-video analysis tools like analyze_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes a clear context: this tool is for analyzing a precise time window of a video. It implies when to use it (when you have specific start/end times) but does not explicitly mention alternatives or exclusions. The phrase 'requested source-video time window' provides clear scope, though it does not name sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0-preview.1analyze_bilibili_videoanalyze_videoanalyze_video_urlinspect_video_windowScored across 4 tools
The tools are related but have overlapping boundaries: analyze_video_url and analyze_bilibili_video both handle public video URLs, especially Bilibili, while analyze_video and inspect_video_window both process local videos. Descriptions clarify differences like time windows and comment sampling, but an agent could still hesitate between the URL-based tools.
All names use snake_case and mostly follow an analyze_<target> pattern, but inspect_video_window breaks the verb pattern and analyze_bilibili_video versus analyze_video_url orders the target inconsistently. The deviations are minor and still readable.
Four tools is a reasonable scope for a video-analysis server, covering local video, local time-window clips, and public URL analysis. The count is appropriate, though the Bilibili-specific tool overlaps with the generic URL tool enough to question whether both earn their place.
The surface covers local and remote video analysis, time-window inspection, and Bilibili metadata/comment context, which is a fairly complete lifecycle for visual research. There are minor gaps around broader platform-specific handling and non-visual/audio analysis, but core workflows are covered.
YouTube transcripts, search, channel/playlist listings and upload tracking for AI agents.
YouTube for AI agents: transcripts, comments, video stats, channel monitor, Shorts captions.
YouTube transcripts, search, channel browsing, and playlists for AI agents via MCP.
YouTube search, whole channels, video stats, comments and full transcripts with timestamps.
