Skip to main content
Glama
liu-xindi

polylens-bilibili

by liu-xindi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_danmaku

Read-only

Retrieve Bilibili video danmaku by URL, BV/av ID, or share text, with optional segment and top-heat count sorting. Use a required jq expression to filter, transform, or analyze bullet comments.

Instructions

timestamp 是弹幕在视频中的秒数。

平台可能只给出部分弹幕，少于视频信息里的弹幕数。

(danmaku, bullet comments)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jqYes必填的 jq 表达式。输入是按 count 选出的弹幕组成的数组，每条字段：content,timestamp,heat。结果为字符串时原样返回，其他结果编码为表格或 JSON；结果为数组时 jq_count 是其长度。
urlYes视频链接、b23.tv 短链，或裸 BV/av 号；含链接的分享文案也可直接传入。
pageNo分段序号，1 起。不传时取链接里的 ?p=N，两者都没有则第 1 段。单段视频忽略此项。
countYes取多少条弹幕。取该段里 heat 最高的这么多条，结果仍按时间轴排序；达到或超过平台给出的条数即全部返回。heat 是平台给每条弹幕的标记，约 1-10 的档位，同档内不再细分。

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYes
danmakuYes
jq_countNo
video_idYes
elapsed_sNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.1
    • changedInput schema / properties / count / description
      Previous value: -"想要的弹幕条数。取该段里 heat 最高的这么多条，结果仍按时间轴排序；达到或超过该段弹幕总数即返回全部。heat 是平台给每条弹幕的标记，约 1-10 的档位，同档内不再细分。"New value: +"取多少条弹幕。取该段里 heat 最高的这么多条，结果仍按时间轴排序；达到或超过平台给出的条数即全部返回。heat 是平台给每条弹幕的标记，约 1-10 的档位，同档内不再细分。"
    • addedInput schema / properties / jq
      Added value: +{
+  "description": "必填的 jq 表达式。输入是按 count 选出的弹幕组成的数组，每条字段：content,timestamp,heat。结果为字符串时原样返回，其他结果编码为表格或 JSON；结果为数组时 jq_count 是其长度。",
+  "title": "Jq",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "url",
-  "count"
-]New value: +[
+  "url",
+  "count",
+  "jq"
+]
    • addedOutput schema / properties / jq_count
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Jq Count"
+}
  2. First observedv0.1.0

TDQS

C2.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the platform may return only partial danmaku, fewer than video info indicates, which is useful data-completeness context. However it omits auth, rate-limit, and return-format details, making 3 appropriate against the lower bar set by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very brief and every sentence is relevant, but it is not front-loaded: it opens with a field note rather than what the tool does. The parenthetical translation feels like an afterthought. There is no bloated text, but the structure does not prioritize selection-relevant information.

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?

Output schema exists and annotations cover read-only/open-world behavior, so return values and safety need not be explained. The remaining gap is purpose and when-to-use guidance, especially versus get_comments, which makes it only minimally complete for a tool with four parameters and three required fields.

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 all input parameters are fully documented in the schema. The description's timestamp note likely refers to an output field, and its partial-danmaku caveat only reinforces the count parameter saturation already described in schema. Baseline 3 is correct when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description never explicitly states that the tool retrieves danmaku/bullet comments; it only explains that timestamp is seconds and notes partial data. The parenthetical '(danmaku, bullet comments)' identifies the resource, but without a verb or clear purpose statement the agent must infer the action from the tool name. It also does not differentiate from siblings like get_comments.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no alternatives, and no conditions for selecting this tool over get_comments or others. The only context given is a caveat about partial data, which does not help an agent decide when to call it.

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