Skip to main content
Glama
Sign In
bilibili-learning-mcp

bilibili-learning-mcp

by Unc1e-2ack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Read Bilibili subtitles

get_subtitles

Fetch timestamped subtitles from Bilibili videos to create learning notes, summarize content, or locate exact quotes.

Instructions

读取视频某一 P 的字幕，按 "[mm:ss] 文本" 逐行返回，适合做带时间戳的笔记。

何时调用：
    - 用户要总结视频、做学习笔记、提取知识点时（这是最重要的素材来源，优先于简介）。
    - 需要引用原话或定位具体时间点时。
    - 用户问「这个视频讲了什么」而 get_video_info 的简介太简略时。

参数：
    bv_id: BV 号或完整链接，例如 "BV1GJ411x7h7"。
    page: 分P序号，从 1 开始，默认 1。先用 get_video_info 查看共几 P。
    start_sec: 只返回起始时间 >= 该秒数的字幕，例如 600 表示 10:00 之后。
    end_sec: 只返回起始时间 <= 该秒数的字幕，例如 1200 表示 20:00 之前。
        字幕过长时可分段读取：先 0-600，再 600-1200……

返回示例：
    《线性代数的本质》第 1 P（向量是什么）字幕 - 中文（自动生成），共 412 行
    时间范围：00:00 - 06:52

    [00:00] 这个视频我们来聊向量
    [00:03] 首先从物理学的角度

注意：
    - AI 字幕需要登录 Cookie；部分视频没有字幕，此时会返回明确提示。
    - 单次最多返回 8000 行，超出会截断并说明总行数，请用 start_sec/end_sec 分段读取。

失败时：
    返回以「读取字幕失败：」开头的说明，并给出下一步建议。

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": {
      "bv_id": "<bv_id>"
    },
    "name": "get_subtitles"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNo
bv_idYes
end_secNo
start_secNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so: it discloses the login/Cookie requirement for AI subtitles, the no-subtitle case, the 8000-line truncation cap with the recommended segmentation workaround, and the failure message prefix with follow-up advice. These are exactly the operational traits an agent needs before calling.

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 structure is excellent — purpose first, then when-to-call, parameters, return sample, caveats, failure mode. The return sample is somewhat redundant given an output schema exists, but it clarifies the line format in a way prose could not, so the wording is largely earned.

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?

For a 4-parameter read tool with an output schema, the description covers authentication, missing-data cases, truncation limits, segmentation strategy, and error output — nothing an agent needs in order to call it correctly is missing.

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?

Schema description coverage is 0%, so the description must compensate, and it does for all four parameters: bv_id accepts a BV number or full link with an example, page is 1-based with a default and a way to discover the max P, and start_sec/end_sec are defined as inclusive/inclusive bounds on subtitle start time with concrete examples (600 → 10:00) and a chunking strategy.

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 states a specific verb and resource (读取视频某一 P 的字幕) and specifies the exact return shape ("[mm:ss] 文本" 逐行返回) plus its primary use case. An agent can distinguish it immediately from get_video_info, which is explicitly named as the shallower alternative.

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?

It gives explicit when-to-call triggers (summarizing, note-taking, quoting, locating timestamps) and states a priority relation — subtitles are the preferred source over the 简介 in get_video_info. It also names a prerequisite step (先用 get_video_info 查看共几 P) before choosing a page.

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

Deploy Server

Other Tools