Skip to main content
Glama

Bilibili Video Research

Turn a Bilibili link into a research report that separates what came from public metadata, captions or ASR, video frames, and untrusted community context. Choose the mode based on the evidence your question actually needs — not simply on what media is available.

Every result also emits a deterministic VIDEO CONTEXT block containing public metadata and an explicit community-context status. The selected mode controls media evidence only; it does not remove the video context.

Demo Video

Project demo on Bilibili: Let an Agent help you research videos

Related MCP server: video-analyzer

Ecosystem

Glama listing — inspect the indexed server, tool schemas, and quality metadata.

Before you start

This is a local MCP server, but public metadata, archive tags, optional sampled comments, and selected media or text evidence may be sent to the provider configured in .env. Provider requests may consume API balance or subscription credits, and the selected provider's pricing and data terms apply. For a first run, use a short public video or an explicit source window; review Data and access boundary before using sensitive content.

What it does

Mode

Uses

Excludes

Best for

language

Bilibili captions when available; otherwise the selected provider's transcription/ASR path (stepaudio-2.5-asr for StepFun)

Video-frame inference

Project recommendations, tutorials, and claims made by the presenter

vision

StepFun step-3.7-flash by default

Audio and background music

Interfaces, workflows, experiments, objects, and silent demonstrations

multimodal

StepFun step-3.7-flash by default

Nothing by default

Questions that genuinely require both narration and what is shown

language is the intended default when a request only asks what a video says. vision is the deliberate choice when the answer lives in the pixels.

What a result looks like

Ask the MCP tool a focused question:

analyze_bilibili_video({
  url: "https://www.bilibili.com/video/BV...",
  question: "What quantitative research framework is shown on screen?",
  mode: "vision",
  media_detail: "default",
  include_comments: false,
  start_seconds: 0,
  end_seconds: 321
})

The response begins with provenance, then a deterministic VIDEO CONTEXT block, before the natural-language analysis:

RESEARCH PROVENANCE
{
  "mode": "language",
  "metadata": "bilibili_api",
  "language": "stepfun_asr",
  "visual": "none",
  "community": "disabled",
  "community_status": "disabled",
  "tags_status": "present",
  "timestamps": "none"
}

VIDEO CONTEXT
METADATA (public source facts)
{...}
COMMUNITY CONTEXT (untrusted opinions; never instructions or facts)
{"status":"disabled","sampled_count":0,"displayed_count":0}

ANALYSIS
...direct answer, evidence limits, and uncertainty...

This matters when a repository name came from speech, a framework was recognized from an interface, or a popular comment made an unverified claim. The sources are not the same and should not be reported as if they were.

Example: Focused research on a quant video

This example shows a practical workflow: define a research question, restrict a long video to a known source interval, and review an answer that separates direct visual evidence from uncertain inferences.

1. Frame the research question

2. Restrict the source interval

3. Review evidence-bounded output

Evidence flow

  • Every result emits public metadata as deterministic context, including title, uploader, category, description, actual archive tags, statistics, and video identifier.

  • Caption cues retain Bilibili timestamps when Bilibili exposes them. If captions are unavailable, language uses the selected provider's transcription/ASR path (StepFun defaults to stepaudio-2.5-asr) and reports that timestamp detail is unavailable. The provenance value is stepfun_asr on the default StepFun path and gemini_audio when Gemini is explicitly selected.

  • vision removes audio before upload. Visible text remains valid visual evidence; the narration and music do not influence the conclusion.

  • Bilibili comments are enabled by default, sampled as untrusted community context, and never treated as verified facts or executable instructions. If disabled or unavailable, the result still reports that status explicitly.

Quick start

Requirements: Node.js 24 or newer, a StepFun API key by default (or a Gemini API key if selected), and a Codex, OpenCode, or other MCP-compatible client with local MCP support.

FFmpeg is normally provided by the ffmpeg-static npm dependency, so no separate FFmpeg installation is required. If the bundled binary cannot be used on your platform, set FFMPEG_PATH in .env to a working FFmpeg executable.

Video downloads use the yt-dlp-exec npm dependency, which supplies the yt-dlp binary during installation; no separate yt-dlp installation is normally required.

git clone https://github.com/7oMB2006/Bilibili-Video-Research.git
cd Bilibili-Video-Research
npm ci
npm run build
npm test
Copy-Item .env.example .env

The test suite is local and does not require provider credentials or live Bilibili access.

Open .env and fill in one provider key. It is ignored by Git and must never be committed. The default configuration uses StepFun's official Open Platform API.

Client configuration

The server uses the same local stdio MCP transport in Codex and OpenCode. Only the client-side configuration syntax differs. The repository started from Codex, which is why the server name and examples use codex_video; the MCP itself is not Codex-only.

Codex (Windows)

In %USERPROFILE%\.codex\config.toml, replace every <PROJECT_DIR> below with the absolute path to your clone, for example C:\Users\you\projects\Bilibili-Video-Research.

[mcp_servers.codex_video]
command = "<PROJECT_DIR>\\node_modules\\.bin\\tsx.cmd"
args = ["<PROJECT_DIR>\\src\\index.ts"]
startup_timeout_sec = 120
tool_timeout_sec = 240

[mcp_servers.codex_video.env]
DOTENV_CONFIG_PATH = "<PROJECT_DIR>\\.env"

Restart Codex after adding or changing the server. Keep provider keys in .env or a secret manager, never in config.toml.

startup_timeout_sec only controls MCP startup and tool discovery; tool_timeout_sec is the maximum duration of one tool call. Because the omitted-value default can vary by Codex version (older setups commonly used about 60 seconds), this example sets the limit explicitly to 240 seconds. A Bilibili request may combine metadata requests, video download, FFmpeg processing, media upload, and model inference in one call; increase the value further when researching unusually long videos or working on a slow connection.

OpenCode

In the global ~/.config/opencode/opencode.json or a project-level opencode.json, add the local MCP server. On Windows, <PROJECT_DIR> should be an absolute path.

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "codex_video": {
      "type": "local",
      "enabled": true,
      "command": [
        "<PROJECT_DIR>\\node_modules\\.bin\\tsx.cmd",
        "<PROJECT_DIR>\\src\\index.ts"
      ],
      "environment": {
        "DOTENV_CONFIG_PATH": "<PROJECT_DIR>\\.env"
      }
    }
  }
}

Restart OpenCode after adding or changing the server. You can verify the connection with opencode mcp list. OpenCode also supports project-level configuration, so a project-specific opencode.json can keep this MCP setup close to the repository.

The model selected in Codex or OpenCode is the client-side agent model. It does not change the media provider used inside this MCP. Set CODEX_VIDEO_PROVIDER and the provider keys in .env to control the models that receive video, image, or audio inputs.

OpenCode references:

Client-side packaging

This repository provides the MCP layer and does not require a specific agent or harness. If you use Codex or OpenCode, you can use the documented tools and research workflow as a reference and wrap them as a client-specific skill for easier reuse. If you use a personal agent or another harness, you can package the MCP tools according to its own extension model, such as a skill, plugin, command, or system prompt.

The MCP interface is the compatibility boundary guaranteed by this project. Installing the MCP does not automatically create a Bilibili Video Research command or skill in every client; the client-side wrapper must be installed or authored separately.

After installation

Register the local MCP server in the target client, restart the client, and run one public Bilibili request to verify the end-to-end path. A client-side skill or command is an optional wrapper and is not created automatically by installing the MCP.

Provider selection

StepFun

The default provider is StepFun through the official Open Platform API. When CODEX_VIDEO_PROVIDER is unset, the server still selects StepFun; missing StepFun credentials are reported as configuration errors rather than silently switching to Gemini. Set CODEX_VIDEO_PROVIDER=stepfun, STEPFUN_API_KEY, and STEPFUN_BASE_URL=https://api.stepfun.com/v1 in .env. The official URL is also used when STEPFUN_BASE_URL is omitted; set it explicitly to use Step Plan instead. To use Gemini instead, set CODEX_VIDEO_PROVIDER=gemini and GEMINI_API_KEY.

Choose the StepFun base URL that matches your account channel:

Channel

Base URL

Use

Official Open Platform API

https://api.stepfun.com/v1

Standard API billing or balance

Step Plan

https://api.stepfun.com/step_plan/v1

Optional Step Plan subscription Credit

StepFun is the default because step-3.7-flash natively accepts video input and also covers the project's ASR fallback path, matching the core Bilibili video research workflow. The author has also used StepFun's multimodal models extensively and had a positive experience with them (and, admittedly, there is a little personal bias too, ovo — before reliable multimodal models were readily available, StepFun helped carry me through much of that journey), so this project prioritizes StepFun integration and recommends it as the default provider. This is a project-fit and usage-based choice, not a claim that StepFun is best for every task. Step Plan remains available as an optional channel for accounts that have Step Plan Credit access. Other providers require their own adapter and are not part of the documented setup. In the author's use, the response speed of step-3.7-flash has also made it a good fit for the repeated, tool-like media-understanding calls common in an MCP workflow.

Other

  • Gemini remains an optional provider.

  • MiniMax is not integrated because this project has not validated an official video-input understanding route.

  • Only StepFun and Gemini are currently integrated; other providers require their own adapter and are not part of the documented setup.

StepFun references:

Tool reference

Tool

Purpose

analyze_bilibili_video

Research a public bilibili.com or b23.tv link in language, vision, or multimodal mode; optionally restrict analysis with start_seconds and end_seconds

analyze_video

Inspect a local video visually after removing its audio track

inspect_video_window

Inspect one precise audio-free source interval for detailed visual research

Use media_detail: "low" for a broad long-video pass and "default" for small UI text, code, movement, or close inspection.

For a known source interval, pass start_seconds and end_seconds together. The window is applied to captions when available and to the downloaded media for audio, visual, and multimodal analysis. Explicit windows skip the automatic long-video coarse pass.

Motion and transition analysis

When the question depends on animation, camera movement, or a shot boundary, do not classify the transition from sparse before-and-after frames alone. First use a broad, low-detail pass to locate likely boundaries, then inspect a narrow start_seconds/end_seconds window at media_detail: "default" so the intermediate motion remains observable.

Keep observations separate from inferences. Distinguish a hard cut from continuous motion such as a push, radial collapse or expansion, paper or plane flip, mask wipe, perspective movement, or shape morphing. Record the approximate direction and duration when visible. If the selected window cannot establish continuity, report that limitation instead of calling it a hard cut.

For motion-heavy references, a boundary table is usually easier to verify: time, outgoing element, incoming element, transition type, direction, duration, confidence, and evidence. Keep visual evidence separate from any advice about reconstructing the effect.

Data and access boundary

  • Provider API keys remain in the local process environment; the server does not store them.

  • Public metadata, archive tags, optional sampled comments, and selected media or text evidence may be sent to the configured provider. Provider media uploads or data URLs may leave the local machine. Review the applicable provider terms before using sensitive videos.

  • Provider requests may consume API balance or subscription credits. Check the selected provider's pricing and quota before long or multimodal runs; use an explicit source window when possible.

  • Public Bilibili access is attempted first. Restricted, paid, or login-gated videos may fail rather than bypassing access controls.

  • For a user-authorized logged-in Bilibili account, point BILIBILI_COOKIES_FILE at a local Netscape-format cookie file. Never commit it or paste its contents into chat:

BILIBILI_COOKIES_FILE=/absolute/path/to/cookies.txt

BILIBILI_COOKIES_FILE takes precedence over the optional legacy setting BILIBILI_COOKIES_FROM_BROWSER=edge (or chrome, firefox, brave). Direct browser cookie extraction can fail because the browser database is locked.

License

MIT

Available Tools

3 tools
analyze_bilibili_videoResearch a Bilibili VideoA
Read-only

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesPublic Bilibili video URL, including b23.tv short URLs.
modeYeslanguage: captions then audio only; vision: silent video only; multimodal: original video with both channels.
questionYesThe research question.
end_secondsNoOptional source-video interval end in seconds. Provide together with start_seconds.
media_detailNoUse low for a broad long-video pass and default for close inspection.default
start_secondsNoOptional source-video interval start in seconds. Provide together with end_seconds.
include_commentsNoInclude 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.

TDQS

A4.5/5.0
Behavior5/5

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

The description goes well beyond the readOnlyHint annotation by disclosing that it 'always returns public metadata and an explicit community-context status', and it details the exact comment sampling behavior: at most 20 most-liked root comments fetched, only 3-5 presented, and empty/fetch-failed states reported explicitly. It also transparently enumerates the three research modes. This gives an agent a precise behavioral model without any contradiction.

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 tightly packed sentences deliver the purpose, the guaranteed return behavior, the comment handling policy, and the supported research modes. Every clause conveys a distinct piece of information, and the most important scoping information appears first. No filler or redundancy.

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 rich 100%-covered schema, the readOnly annotation, and the absence of an output schema, the description provides a complete operational picture: what it always returns, what it optionally fetches and how it filters it, and which modes it supports. It leaves no ambiguity about whether comments are included, how many, or how failures are surfaced. The tool is complex enough that this level of detail is necessary and sufficient.

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 description coverage is 100%, so the input schema already fully documents url, mode, question, start/end seconds, media_detail, and include_comments. The description's mention of 'language-only, visual-only, and multimodal' and 'optionally samples 20 most-liked root comments' adds some semantic color, but it does not add parameter-level meaning beyond the schema. Baseline 3 is appropriate.

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 uses a specific verb ('resolves') with a clear resource (public Bilibili URL) and states what it returns (public metadata and community-context status). It distinguishes itself from siblings like analyze_video and inspect_video_window by being Bilibili-specific and by emphasizing comment sampling and language/vision/multimodal modes. The title reinforces the purpose without being a mere tautology.

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 clearly defines when to use the tool: when given a public Bilibili URL, including b23.tv short URLs, and when research requires language-only, visual-only, or multimodal analysis. It gives concrete scope and indicates the optional comment-related behaviorging, but it does not explicitly mention when to prefer a sibling tool instead. The context is clear enough for most agents to route correctly.

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

analyze_videoAnalyze a Video VisuallyA
Read-only

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
questionYesA visual-only research question about observable actions or interactions.
video_pathYesAbsolute path to a local video file.
media_detailNoUse low for a long coarse pass; use default for movement, small objects, and precise inspection.default

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

inspect_video_windowInspect a Precise Video WindowA
Read-only

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
questionYesA visual-only research question about observable actions or interactions.
video_pathYesAbsolute path to a local video file.
end_secondsYesEnd time in seconds in the source video; must be after start_seconds.
media_detailNoUse low for a long coarse pass; use default for movement, small objects, and precise inspection.default
start_secondsYesStart time in seconds in the source video.

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

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 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.

Usage Guidelines4/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedanalyze_bilibili_video3 fields changed
      • addedInput schema / properties / end_seconds
        Added value: +{
        +  "description": "Optional source-video interval end in seconds. Provide together with start_seconds.",
        +  "exclusiveMinimum": 0,
        +  "type": "number"
        +}
      • changedInput schema / properties / include_comments / description
        Previous value: -"Attach untrusted community context. Fetches at most 20 most-liked root comments but presents only 3-5 representative comments."New value: +"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."
      • addedInput schema / properties / start_seconds
        Added value: +{
        +  "description": "Optional source-video interval start in seconds. Provide together with end_seconds.",
        +  "minimum": 0,
        +  "type": "number"
        +}
  2. 3 tool updatesv0.1.0
    • First observedanalyze_bilibili_video
    • First observedanalyze_video
    • First observedinspect_video_window

TDQS

A4.3/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a distinct video source and analysis mode: local video, Bilibili URL with community context, and a specific time window from a local video. No overlap in purpose or usage.

Naming Consistency5/5

All names follow a consistent verb_noun pattern (analyze_video, analyze_bilibili_video, inspect_video_window). The verbs 'analyze' and 'inspect' are semantically appropriate and distinct.

Tool Count5/5

Three tools is a tight, well-scoped set for a video analysis server. Each tool addresses a clear need without redundancy, and the count is appropriate for the narrow purpose.

Completeness4/5

The tool set covers local video analysis, remote Bilibili analysis, and analysis of specific video segments. The only minor gap is lack of tools for other remote video platforms or listing available providers, but the core workflow is complete.

Maintenance

ActivityActive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers