Skip to main content
Glama

SocialDataX B站 Bilibili MCP

bilibili_get_content_likes_and_reposts_by_url

Read-only

根据 Bilibili 专栏/动态链接、移动端链接、b23.tv 短链接或分享文案获取赞与转发列表。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesBilibili 专栏/动态链接、移动端链接、t.bilibili.com 动态链接、b23.tv 短链接或包含链接的分享文案;支持 /opus/{id}、/dynamic/{id}、t.bilibili.com/{id}、t.bilibili.com/h5/dynamic/detail/{id} 等同一专栏/动态的常见 B 站链接形态。从专栏搜索结果出发时,先获取详情,再使用详情里的 post.share_url 或 post.post_id。不要传视频链接、其他链接或用户主页链接。
page_tokenNoBilibili 专栏/动态赞与转发列表分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回;page_token 是不透明分页令牌;不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成,不得用省略号替换中间内容。只能用于同一专栏/动态的同一 post_id 或同一 url 赞与转发分页链路;继续翻页时必须使用同一个入口,by_post_id 返回的 token 只能继续传给 by_post_id,by_url 返回的 token 只能继续传给 by_url;不能跨能力或内容复用。

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYes当前页赞与转发动作记录列表,每项包含动作类型、B 站展示文案、补充说明和互动用户。
pointsYes本次成功调用的积分消耗与调用完成时的账户积分余额。
post_idYes本次赞与转发列表对应的专栏/动态 post_id;可用于后续不带当前 page_token 的新查询。继续当前分页时必须沿用原入口和 next_page_token,不要用本字段切换入口。不是评论 ID、用户 ID 或 cv 专栏 ID。
next_page_tokenYes下一页不透明分页令牌;为空表示没有更多结果。继续获取赞与转发下一页时,必须将返回的完整 next_page_token 原样作为 page_token 传回,并沿用本次调用入口;by_post_id 返回的 token 只能继续传给 by_post_id,by_url 返回的 token 只能继续传给 by_url。不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成,不得用省略号替换中间内容;不能跨能力、入口或专栏/动态复用。
like_repost_countYes赞与转发合计总数,不是当前页数量;当前不区分赞和转发分别计数;不可用时为 null。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the agent knows the operation is non-destructive. The definition adds behavioral context beyond these annotations: the page_token parameter description discloses that tokens are opaque, must be passed verbatim, are bound to a single URL/post_id pagination chain, and cannot be reused across endpoints. This is valuable behavioral information that helps agents paginate correctly.

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?

The description is a single, front-loaded sentence with no wasted words. It states the action and input scope immediately, allowing an agent to quickly understand the tool's purpose.

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 the rich input schema, the presence of an output schema, and the readOnly/openWorld annotations, the definition is nearly complete. The only minor gap is that the top-level description does not mention the paginated nature of the result, though this is captured in the page_token parameter 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%, and both url and page_token already have detailed descriptions. The top-level description adds no extra parameter semantics beyond what the schema provides, so the baseline 3 applies.

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 clearly states a specific verb ('获取' / get) and resource ('赞与转发列表' / likes and reposts list), and enumerates the supported input forms (专栏/动态链接、移动端链接、b23.tv 短链接、分享文案). This makes it easily distinguishable from siblings like bilibili_get_content_comments_by_url and bilibili_get_content_detail_by_url.

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?

The description gives clear context on the expected input forms and a workflow hint (from article search results, get detail first, then use post.share_url or post.post_id). The url parameter description further excludes video links, other links, and user profile links, which guides correct use. It does not explicitly name sibling alternatives, but the by_url/by_post_id distinction is clear from the tool name and schema.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources