Skip to main content
Glama

SocialDataX B站 Bilibili MCP

bilibili_get_user_info_by_user_id

Read-only

根据 Bilibili 用户 user_id 获取用户资料。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
user_idYesB 站用户 user_id,通常是 space.bilibili.com/{user_id} 路径里的数字 ID;可从搜索、详情、评论或用户资料结果中的 author.user_id 或 user_id 复制;不要传用户主页链接,不要传视频链接、昵称、BV 号或 aid。已有用户主页链接时使用 by_profile_url 工具。

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
bioYes用户简介;不可用时为空字符串。
nameYesB 站用户名称;不可用时为空字符串。
genderYes用户性别:male 表示男,female 表示女,unknown 表示未知或未公开。
pointsYes本次成功调用的积分消耗与调用完成时的账户积分余额。
user_idYesB 站用户 user_id;用于标识作者或用户。
birthdayYes公开生日,通常为 MM-DD;不可用时为 null。
verifiedYes是否有 B 站个人或机构认证。
live_infoYes用户直播状态摘要;没有直播间或不可用时为 null。
avatar_urlYes用户头像链接;不可用时为 null。
profile_urlYesB 站用户主页链接;可用于打开用户主页;不可用时为 null。
charging_urlYes充电入口链接;不可用时为 null。
charging_countYes累计充电人数;未开通或不可用时为 null。
follower_countYes粉丝数;不可用时为 null。
profile_noticeYesB 站空间公告;没有公告或不可用时为 null。
following_countYes关注数;不可用时为 null。
video_view_countYes累计视频播放数;不可用时为 null。
posted_audio_countYes用户公开投稿音频数量;不可用时为 null。
posted_video_countYes用户公开投稿视频数量;不可用时为 null。
verification_labelYesB 站认证说明;没有认证或不可用时为 null。
received_like_countYes累计获赞数;不可用时为 null。
posted_content_countYes用户公开投稿总数,对应 B 站空间投稿页的「投稿」总数;不可用时为 null。
posted_image_text_countYes用户公开投稿图文数量,对应 B 站空间投稿页的「图文」分类;不可用时为 null。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior2/5

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

Annotations already declare readOnlyHint true and openWorldHint true. The description itself adds no behavioral context beyond 'get user profile'—it does not mention response shape, error behavior, rate limits, or any data caveats. Since annotations cover the safety profile, this is a low but non-contradictory score.

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, focused sentence with no redundancy. It front-loads the action and resource, which is appropriate for a simple read-only lookup tool.

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 one-parameter, read-only lookup with an output schema and safety annotations, the definition is nearly complete. The main gap is that the by_profile_url alternative routing appears only in the parameter description, not in the tool description, but the overall definition still gives an agent enough to use the tool 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?

The input schema already provides 100% coverage of user_id with a rich, detailed description including acceptable sources and exclusions. The main description adds no additional parameter meaning, so the schema-description heavy lifting keeps this at 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 clearly states the action (获取/get) and the resource (用户资料/user profile), and identifies the key by user_id. It does not explicitly differentiate from the sibling bilibili_get_user_info_by_profile_url in the description body, though the tool name and parameter description do make the distinction.

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 top-level description gives no usage context, but the user_id parameter description provides explicit routing guidance: use by_profile_url when a profile URL is already available, and do not pass links, nicknames, BV numbers, or aids. This is practical guidance even though it lives in the schema rather than the description.

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