Skip to main content
Glama
liu-xindi

polylens-bilibili

by liu-xindi

get_comments

Read-only

Fetches top-level comments for a Bilibili video, excluding replies, with hot or newest sorting and cursor-based pagination; login is required.

Instructions

不含二级评论,二级评论通过 get_comment_replies 获取。需要登录。

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

(video comments)

Input Schema

TableJSON 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 是其长度。hot 下若还要续取,不要用 jq 截取条数(如 .[:N]):续取从整批之后开始,截掉的评论取不回。
urlYes视频链接、b23.tv 短链,或裸 BV/av 号;含链接的分享文案也可直接传入。
modeNo排序方式:hot 是平台的综合排序。hot 的 cursor 只标识浏览会话,进度记在平台侧,同一 cursor 每次调用都返回下一批,不能重放某一批;同一视频同一时间只用一个 hot cursor:新开会话后,旧 cursor 只会返回已取过的内容,新旧混用时两者都会回退。newest 按时间倒序,cursor 含位置,可重复取同一批,不受新会话影响。需要完整抓取或断点续取时用 newest。newest 的结果缓存 30 分钟,cached_at 是缓存的抓取时间。hot
countYes至少取多少条主评论。平台按每页约 20 条整页返回,实际条数约为 20 的整数倍;评论不够时返回剩余的全部。
cursorNo续取游标:不传从头开始,回传上次返回的 next_cursor 取下一批。

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYes
messageNo
commentsYes
has_moreYes
jq_countNo
video_idYes
cached_atNo
elapsed_sNo
next_cursorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
      +}
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint, so the added '需要登录' (login required) is genuine behavioral context beyond structured data. It also discloses output-shape quirks (image_urls/link_titles newline-joined), though it says nothing about rate limits or caching.

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?

Three short lines, front-loaded with the scoping constraint and login requirement, then the formatting caveat. No filler or repetition of schema content.

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?

Given an output schema exists and the input schema is fully documented, the description supplies the missing pieces an agent needs: login requirement, reply exclusion, and field formatting. The only gap is that mode/cursor usage strategy lives entirely in the schema rather than the top-level description.

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 schema already carries the heavy parameter burden (mode/cursor semantics, count pagination behavior, jq contract). The description adds only a small formatting note about image_urls and link_titles, which nudges it to the baseline of 3 rather than above.

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 explicitly scopes it by excluding secondary comments, naming the sibling get_comment_replies that handles those. It lacks an explicit verb like 'list'/'fetch', but the resource and boundary are unambiguous enough to distinguish it from siblings.

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 explicitly routes reply-fetching to get_comment_replies and states the login prerequisite. It does not cover the hot-vs-newest choice or when to use this versus search_videos/get_feed, but the primary sibling disambiguation is present.

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