Skip to main content
Glama
DavidLearning1023

bilibili-info-gathering

deep_read

Aggregates Bilibili video transcripts, comments, danmaku, and cover in one call, reducing round trips and returning unified degradation signals.

Instructions

一次调用聚合多条通道:字幕 + 评论 + 弹幕 + 封面(可选抽帧)。

为什么要有它

本项目有 5 条取数通道,但每条要单独一次调用:Agent 要自己编排、 每次都要重新拼参数、而且每条通道都要先拉一次视频元数据。 DSH 那边的实现把多路整合成"一次看懂"(字幕/弹幕/热评/封面/抽帧)。 本工具是同构的等价物:少几轮往返,且一次拿到各通道的统一降级信号。

channels(默认 ["transcript","comments","danmaku","cover"]): transcript 字幕(受 transcript_query / transcript_head_ratio / transcript_max_chars 控制) comments 评论(受 comment_n / comment_detail 控制) danmaku 弹幕(密度与披露线索) cover 封面 URL(批次 C3 放回来的 pic,成本最低的一路) frames 抽帧(只在给了 frames_at 时才做;需要 ffmpeg)

返回:{bvid, title, channels: {...}, degraded: [...], ok, cost} 每条通道的完整载荷在 channels.<name> 里,与单通道工具同构—— 所以 deep_read 的结果可以直接当单通道结果用,不会出现"两套结构"。

⚠️ 成本:一次调用可能打多次上游(cost.calls 会告诉你实际打了几次)。 字幕仍是最大头——强烈建议给 transcript_query 或 transcript_head_ratio。

Input Schema

NameRequiredDescriptionDefault
bvidYes
pageNo
qualityNo
channelsNo
comment_nNo
frames_atNo
comment_detailNoopinion
transcript_queryNo
transcript_max_charsNo
transcript_head_ratioNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations present, the description carries the burden well: it discloses that one call may hit upstream multiple times (cost.calls), that frames requires ffmpeg and only runs when frames_at is supplied, which channel is cheapest, and that degraded[] reports per-channel failures. Missing richer detail on failure modes or permissions, but the behavioral picture is above average.

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 channel breakdown is front-loaded and scannable, with the cost warning placed at the end for emphasis. The '为什么要有它' paragraph adds some narrative padding and an external DSH comparison that an agent doesn't strictly need, but structure remains tight enough.

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?

For a 10-parameter aggregator with an output schema, the description covers the mechanics an agent needs: channel selection, per-channel knobs, degradation handling and cost. The unexplained page and quality parameters are the notable gap, since the output schema does not cover request-side semantics.

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 coverage is 0%, so the description must compensate, and it does map most controls to their channels: transcript_query/transcript_head_ratio/transcript_max_chars for transcript, comment_n/comment_detail for comments, frames_at for frames. However it leaves page and quality entirely unexplained and gives no value semantics for comment_detail beyond the raw default.

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 gives a specific verb-and-resource statement (aggregating transcript, comments, danmaku, cover and optional frames in a single call) and explicitly positions it against the single-channel siblings by saying results are structurally identical to them. An agent can distinguish it from get_transcript/get_comments/get_danmaku without opening any schema.

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?

It explains the selection rationale clearly: use it to cut round trips and obtain a unified degradation signal rather than orchestrating the five channels separately. It also names a concrete cost-avoidance recommendation (supply transcript_query or transcript_head_ratio). It stops short of an explicit 'use X instead when' rule for the lightweight single-channel case.

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