Skip to main content
Glama
liu-xindi

polylens-bilibili

by liu-xindi

get_feed

Read-only

Fetch Bilibili homepage recommendation feed with up to 30 items per batch; use jq to select video titles, authors, URLs, and stats for browsing or analysis.

Instructions

B 站首页推荐流,每批最多 30 条。

(homepage feed, recommendations, browse)

Input Schema

NameRequiredDescriptionDefault
jqYes必填的 jq 表达式。输入是全部条目组成的数组,每条字段:title,url,author,author_url,published_at,duration_sec,view_count,danmaku_count,like_count,rcmd_reason。体积大、多数任务用不到的字段:author_url(查看 UP 主时需要);特定任务需要时照常使用。结果为字符串时原样返回,其他结果编码为表格或 JSON;结果为数组时 jq_count 是其长度。
descriptionYes格式为 工具名:目的。

Output Schema

NameRequiredDescriptionDefault
feedYes
countYes
jq_countNo
elapsed_sNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.12.1
    • addedInput schema / properties / description
      Added value: +{
      +  "description": "格式为 工具名:目的。",
      +  "title": "Description",
      +  "type": "string"
      +}
    • changedInput schema / properties / jq / description
      Previous value: -"必填的 jq 表达式。输入是全部条目组成的数组,每条字段:title,url,author,author_url,published_at,duration_sec,view_count,danmaku_count,like_count,rcmd_reason。体积大、多数任务用不到的字段:url(后续调用其他工具时需要)、author_url(查看 UP 主时需要);特定任务需要时照常使用。结果为字符串时原样返回,其他结果编码为表格或 JSON;结果为数组时 jq_count 是其长度。"New value: +"必填的 jq 表达式。输入是全部条目组成的数组,每条字段:title,url,author,author_url,published_at,duration_sec,view_count,danmaku_count,like_count,rcmd_reason。体积大、多数任务用不到的字段:author_url(查看 UP 主时需要);特定任务需要时照常使用。结果为字符串时原样返回,其他结果编码为表格或 JSON;结果为数组时 jq_count 是其长度。"
    • changedInput schema / required
      Previous value: -[
      -  "jq"
      -]New value: +[
      +  "description",
      +  "jq"
      +]
  2. Changed3 schema fields changedv0.3.1
    • addedInput schema / properties / jq
      Added value: +{
      +  "description": "必填的 jq 表达式。输入是全部条目组成的数组,每条字段:title,url,author,author_url,published_at,duration_sec,view_count,danmaku_count,like_count,rcmd_reason。体积大、多数任务用不到的字段:url(后续调用其他工具时需要)、author_url(查看 UP 主时需要);特定任务需要时照常使用。结果为字符串时原样返回,其他结果编码为表格或 JSON;结果为数组时 jq_count 是其长度。",
      +  "title": "Jq",
      +  "type": "string"
      +}
    • addedInput schema / required
      Added value: +[
      +  "jq"
      +]
    • addedOutput schema / properties / jq_count
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Jq Count"
      +}
  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 one useful fact, the 30-item batch cap, but says nothing about pagination/refresh behavior or authentication, so it adds only modest context beyond the annotations.

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?

Two short clauses with the resource and the batch limit front-loaded, plus compact discovery keywords. Nothing is redundant or padded.

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?

With an output schema present and annotations covering the safety profile, the description needn't explain return values or read-only status. The only meaningful gap is that it never clarifies how the feed differs from the sibling search tools, which an agent might need to route correctly.

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 jq parameter is documented in exceptional detail (field list, size warnings, result formatting), so the schema carries the full burden. The description contributes nothing about parameters; baseline 3 applies.

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?

Names a concrete verb+resource: the Bilibili homepage recommendation feed, with a stated batch cap. It is clearly distinguishable from siblings like search_videos or list_up_videos, though it never states that distinction explicitly.

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

Usage Guidelines3/5

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

The gloss '(browse)' implies a discovery use case, but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as search_videos when the user wants a targeted result rather than passive browsing.

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