Skip to main content
Glama
liu-xindi

polylens-bilibili

by liu-xindi

get_comments

Read-only

Fetch top-level comments from Bilibili videos, sorted by hot or newest, with cursor-based pagination. Supports jq filtering for specific fields.

Instructions

不含二级评论,二级评论通过 get_comment_replies 获取。

image_urls、link_titles 是字符串,多个时以换行分隔。

(video comments)

Input Schema

NameRequiredDescriptionDefault
jqYes必填的 jq 表达式。输入是本批条目组成的数组,每条字段:id,author,author_url,author_level,is_up,ip_location,content,like_count,reply_count,parent_id,created_at,is_top,up_liked,image_urls,link_titles。体积大、多数任务用不到的字段:author_url(查看评论者资料时需要)、is_up、created_at、is_top、up_liked;特定任务需要时照常使用。分页字段不在输入里;只筛本批,筛完为空时仍以 has_more 判断有无下一批。结果为字符串时原样返回,其他结果编码为表格或 JSON;结果为数组时 jq_count 是其长度。
modeNo排序方式:hot 是平台的综合排序。hot 的 cursor 只标识浏览会话,进度记在平台侧,翻页与重放靠 batch_id;同一视频同一时间只用一个 hot cursor:新开会话(包括其他对话里的)后,旧 cursor 会重复取过的内容或提前返回空,混用时新的也会回退;遇到时从 cursor 为空重新开始。newest 按时间倒序,cursor 含位置,可重复取同一批,不受新会话影响。需要完整抓取或断点续取时用 newest。缓存:除 jq 外参数相同的调用返回同一结果,from_cache 表示是否来自缓存;被限速的不完整结果不缓存。newest 要新数据用 refresh,hot 换 batch_id 取下一批。调用没收到结果时服务端仍会取完,之后用相同参数再取直接用缓存。hot
countYes至少取多少条主评论。平台按每页约 20 条整页返回,实际条数可能多于 count;评论不够时返回剩余的全部。主评论与二级评论合计每分钟约取 30 页(约 600 条),取得多则耗时长,可以分几次取。
videoYes视频链接、b23.tv 短链,或裸 BV/av 号;含链接的分享文案也可直接传入。
cursorNo续取游标:不传从头开始,回传上次返回的 next_cursor 取下一批。
refreshNo跳过缓存重新取,并更新缓存。仅用于 newest。
batch_idNomode=hot 时必填。自定的短字符串:其他参数相同时,同一个值返回同一批,换新值取下一批。重放结果与之前不同时,原批次已丢失,需要就从 cursor 为空重新开始。
descriptionYes格式为 工具名:目的。

Output Schema

NameRequiredDescriptionDefault
countYes
messageNo
commentsYes
has_moreYes
jq_countNo
video_idYes
cached_atNo
elapsed_sNo
from_cacheNo
next_cursorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv0.12.1
    • addedInput schema / properties / batch_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "mode=hot 时必填。自定的短字符串:其他参数相同时,同一个值返回同一批,换新值取下一批。重放结果与之前不同时,原批次已丢失,需要就从 cursor 为空重新开始。",
      +  "title": "Batch Id"
      +}
    • changedInput schema / properties / count / description
      Previous value: -"至少取多少条主评论。平台按每页约 20 条整页返回,实际条数约为 20 的整数倍;评论不够时返回剩余的全部。"New value: +"至少取多少条主评论。平台按每页约 20 条整页返回,实际条数可能多于 count;评论不够时返回剩余的全部。主评论与二级评论合计每分钟约取 30 页(约 600 条),取得多则耗时长,可以分几次取。"
    • addedInput schema / properties / description
      Added value: +{
      +  "description": "格式为 工具名:目的。",
      +  "title": "Description",
      +  "type": "string"
      +}
    • changedInput schema / properties / jq / description
      Previous value: -"必填的 jq 表达式。输入是本批条目组成的数组,每条字段:id,author,author_url,author_level,is_up,ip_location,content,like_count,reply_count,parent_id,created_at,is_top,up_liked,image_urls,link_titles。体积大、多数任务用不到的字段:author_url(查看评论者资料时需要)、is_up、created_at、is_top、up_liked;特定任务需要时照常使用。分页字段不在输入里;只筛本批,筛完为空时仍以 has_more 判断有无下一批。结果为字符串时原样返回,其他结果编码为表格或 JSON;结果为数组时 jq_count 是其长度。hot 下若还要续取,不要用 jq 截取条数(如 .[:N]):续取从整批之后开始,截掉的评论取不回。"New value: +"必填的 jq 表达式。输入是本批条目组成的数组,每条字段:id,author,author_url,author_level,is_up,ip_location,content,like_count,reply_count,parent_id,created_at,is_top,up_liked,image_urls,link_titles。体积大、多数任务用不到的字段:author_url(查看评论者资料时需要)、is_up、created_at、is_top、up_liked;特定任务需要时照常使用。分页字段不在输入里;只筛本批,筛完为空时仍以 has_more 判断有无下一批。结果为字符串时原样返回,其他结果编码为表格或 JSON;结果为数组时 jq_count 是其长度。"
    • changedInput schema / properties / mode / description
      Previous value: -"排序方式:hot 是平台的综合排序。hot 的 cursor 只标识浏览会话,进度记在平台侧,同一 cursor 每次调用都返回下一批,不能重放某一批;同一视频同一时间只用一个 hot cursor:新开会话后,旧 cursor 只会返回已取过的内容,新旧混用时两者都会回退。newest 按时间倒序,cursor 含位置,可重复取同一批,不受新会话影响。需要完整抓取或断点续取时用 newest。newest 的结果缓存 30 分钟,cached_at 是缓存的抓取时间。"New value: +"排序方式:hot 是平台的综合排序。hot 的 cursor 只标识浏览会话,进度记在平台侧,翻页与重放靠 batch_id;同一视频同一时间只用一个 hot cursor:新开会话(包括其他对话里的)后,旧 cursor 会重复取过的内容或提前返回空,混用时新的也会回退;遇到时从 cursor 为空重新开始。newest 按时间倒序,cursor 含位置,可重复取同一批,不受新会话影响。需要完整抓取或断点续取时用 newest。缓存:除 jq 外参数相同的调用返回同一结果,from_cache 表示是否来自缓存;被限速的不完整结果不缓存。newest 要新数据用 refresh,hot 换 batch_id 取下一批。调用没收到结果时服务端仍会取完,之后用相同参数再取直接用缓存。"
    • addedInput schema / properties / refresh
      Added value: +{
      +  "default": false,
      +  "description": "跳过缓存重新取,并更新缓存。仅用于 newest。",
      +  "title": "Refresh",
      +  "type": "boolean"
      +}
    • removedInput schema / properties / url
      Removed value: -{
      -  "description": "视频链接、b23.tv 短链,或裸 BV/av 号;含链接的分享文案也可直接传入。",
      -  "title": "Url",
      -  "type": "string"
      -}
    • addedInput schema / properties / video
      Added value: +{
      +  "description": "视频链接、b23.tv 短链,或裸 BV/av 号;含链接的分享文案也可直接传入。",
      +  "title": "Video",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "url",
      -  "count",
      -  "jq"
      -]New value: +[
      +  "description",
      +  "video",
      +  "count",
      +  "jq"
      +]
    • addedOutput schema / properties / from_cache
      Added value: +{
      +  "default": false,
      +  "title": "From Cache",
      +  "type": "boolean"
      +}
  2. Changed7 schema fields changedv0.3.1
    • changedInput schema / properties / count / description
      Previous value: -"想要的主评论条数,实际返回可能多于或少于这个数。"New value: +"至少取多少条主评论。平台按每页约 20 条整页返回,实际条数约为 20 的整数倍;评论不够时返回剩余的全部。"
    • addedInput schema / properties / jq
      Added value: +{
      +  "description": "必填的 jq 表达式。输入是本批条目组成的数组,每条字段:id,author,author_url,author_level,is_up,ip_location,content,like_count,reply_count,parent_id,created_at,is_top,up_liked,image_urls,link_titles。体积大、多数任务用不到的字段:author_url(查看评论者资料时需要)、is_up、created_at、is_top、up_liked;特定任务需要时照常使用。分页字段不在输入里;只筛本批,筛完为空时仍以 has_more 判断有无下一批。结果为字符串时原样返回,其他结果编码为表格或 JSON;结果为数组时 jq_count 是其长度。hot 下若还要续取,不要用 jq 截取条数(如 .[:N]):续取从整批之后开始,截掉的评论取不回。",
      +  "title": "Jq",
      +  "type": "string"
      +}
    • changedInput schema / properties / mode / description
      Previous value: -"排序方式:hot 是平台的综合排序。hot 的游标绑在一次翻页过程上,中断后无法从原处接续,重复用同一个游标会继续往后走;newest 的游标是位置标识,可以重复取到同一批。"New value: +"排序方式:hot 是平台的综合排序。hot 的 cursor 只标识浏览会话,进度记在平台侧,同一 cursor 每次调用都返回下一批,不能重放某一批;同一视频同一时间只用一个 hot cursor:新开会话后,旧 cursor 只会返回已取过的内容,新旧混用时两者都会回退。newest 按时间倒序,cursor 含位置,可重复取同一批,不受新会话影响。需要完整抓取或断点续取时用 newest。newest 的结果缓存 30 分钟,cached_at 是缓存的抓取时间。"
    • changedInput schema / required
      Previous value: -[
      -  "url",
      -  "count"
      -]New value: +[
      +  "url",
      +  "count",
      +  "jq"
      +]
    • addedOutput schema / properties / cached_at
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Cached At"
      +}
    • addedOutput schema / properties / jq_count
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Jq Count"
      +}
    • addedOutput schema / properties / message
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Message"
      +}
  3. First observedv0.1.0

TDQS

A3.6/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 the output-format detail that image_urls and link_titles are newline-delimited strings, which is genuinely useful and not in the annotations. However, it says nothing about pagination, caching, or rate limits — those live entirely in the schema, so the description's independent contribution is modest.

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?

Extremely terse and front-loaded: the reply exclusion, the alternative tool, and the field-format note are all delivered with zero filler. The trailing "(video comments)" fragment is slightly awkward but functions as the resource label.

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?

An output schema exists, so return-value explanation is not required, and the rich schema carries pagination/caching/mode semantics. Given that, the description covers what it uniquely must: scope (top-level only) and the routing alternative. Only the thin positive statement of purpose keeps it from a 5.

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% and the parameter descriptions are unusually detailed (mode/cursor/batch_id pagination and caching semantics), so the baseline is 3. The description adds no input-parameter meaning at all — the newline-separated note concerns output fields, not the 8 input params — so it cannot exceed baseline.

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

Purpose4/5

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

The description identifies the resource ("video comments") and scopes it precisely by excluding second-level comments, then names the sibling get_comment_replies that handles them. An agent can distinguish it from get_comment_replies and get_video_info without opening a schema, though it never states the verb explicitly.

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 gives an explicit routing rule: replies are NOT returned here and must be fetched via get_comment_replies. That is a clear when-to-use-this-vs-alternative statement for the main ambiguity. It does not address other sibling tools or when this tool is inappropriate beyond the reply case.

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