Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bilibili-mcp-server search for 'Minecraft' videos"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
B 站的 MCP 服务。提供视频搜索、评论管理、弹幕字幕、用户信息、动态专栏、扫码登录、直播截图视觉分析等功能，共 31 个工具。
类别 | 工具 | 数量 |
评论 |
| 3 |
搜索 |
| 2 |
视频 |
| 5 |
用户 |
| 7 |
内容 |
| 3 |
消息 |
| 2 |
直播 |
| 2 |
登录 |
| 2 |
系统 |
| 1 |
下载 |
| 3 |
弹幕 |
| 1 |
Related MCP server: BiliStalkerMCP
Node.js 22+
B 站账号（用于需要登录的操作）
ffmpeg（仅视频下载工具需要；macOS: brew install ffmpeg，Windows: choco install ffmpeg，Linux: apt install ffmpeg）
# 直接运行
npx bilibili-mcp-server
# 或全局安装
npm install -g bilibili-mcp-server
bilibili-mcp-server支持环境变量或项目目录下的 .env 文件：
# 必填 - 从浏览器开发者工具 → Application → Cookies → bilibili.com 获取
export BILIBILI_SESSDATA=你的sessdata
export BILIBILI_BILI_JCT=你的bili_jct
export BILIBILI_DEDE_USER_ID=你的uid
# 可选 - Cookie 自动刷新
# 获取方式: bilibili.com → F12 → Console → 输入:
# console.log(localStorage.getItem('ac_time_value'))
export BILIBILI_REFRESH_TOKEN=你的refresh_token
# 可选 - 完整 Cookie（热搜等功能需要）
# export BILIBILI_FULL_COOKIE="buvid3=xxx; buvid4=xxx; _uuid=xxx; ..."
# 可选
export BILIBILI_AUTO_REFRESH=true
export BILIBILI_COOKIE_FILE=/path/to/cookie.json
export BILIBILI_DETECT_FILE=/path/to/detect.json{
"mcpServers": {
"bilibili": {
"command": "npx",
"args": ["-y", "bilibili-mcp-server"],
"env": {
"BILIBILI_SESSDATA": "你的sessdata",
"BILIBILI_BILI_JCT": "你的bili_jct",
"BILIBILI_DEDE_USER_ID": "你的uid"
}
}
}
}不想手动复制 Cookie 的话，可以调扫码登录：
调 bilibili_login 获取二维码
手机 B 站 App 扫码
调 bilibili_login_check 检测登录状态
登录成功自动保存 Cookie
工具 | 功能 | 参数 |
| 生成扫码登录二维码 | - |
| 轮询扫码状态，登录成功自动保存 |
|
| 手动触发 Cookie 刷新 | - |
工具 | 功能 | 参数 |
| 发布评论或回复 |
|
| 删除自己的评论 |
|
| 点赞/取消赞 |
|
工具 | 功能 | 参数 |
| 搜索视频 |
|
| 视频详情 |
|
| 获取评论列表 |
|
| 获取字幕 |
|
| 获取弹幕 |
|
| 热门视频 |
|
| 热搜关键词 | - |
工具 | 功能 | 参数 |
| 用户信息 |
|
| UP 主视频列表 |
|
| 收藏夹 |
|
工具 | 功能 | 参数 |
| UP 主最新动态 |
|
| 专栏文章详情 |
|
| UP 主专栏列表 |
|
工具 | 功能 | 参数 |
| 关注 UP 主 |
|
| 取消关注 |
|
| 关注列表 |
|
| 粉丝列表 |
|
关注/取关操作会被 B 站风控监控，不建议短时间内大量操作。
工具 | 功能 | 参数 |
| 发送弹幕 |
|
弹幕发送是高风控操作，建议每天不超过 5 条。
工具 | 功能 | 参数 |
| 下载视频（需 ffmpeg） |
|
| 下载专栏为 Markdown |
|
| 查看已下载列表 |
|
视频下载会自动下载 DASH 音视频并用 ffmpeg 合并为 mp4。默认保存到
./bilibili-downloads/。
工具 | 功能 | 参数 |
| 检测新回复 |
|
| 查看未读通知 | - |
工具 | 功能 | 参数 |
| 查询直播间信息 |
|
| 截取直播间当前画面（视觉分析） |
|
bilibili_live_screenshot会把关键帧截图作为图片返回给模型，让具备视觉能力的 AI 分析直播内容。如模型无视觉能力，仅返回文字元数据。
src/
├── index.ts
├── env.ts
├── config.ts
├── api/
│ ├── http.ts
│ ├── bilibili.ts
│ ├── wbi.ts
│ ├── cookie.ts
│ ├── login.ts
│ └── danmaku.ts
├── tools/
│ ├── comment.ts
│ ├── video.ts
│ ├── user.ts
│ ├── content.ts
│ ├── message.ts
│ ├── login.ts
│ └── live.ts
└── types/
└── index.tsnpm install
npm run dev # 开发模式
npm run build # 构建
npm test # 测试MIT
获取 B站 专栏文章的详细内容，包含标题、正文、发布时间、作者、数据统计等
| Name | Required | Description | Default |
|---|---|---|---|
| cvid | Yes | 专栏文章 ID（CV 号，如 123456） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists output fields but does not disclose safety profile (read-only vs. destructive), authentication needs, rate limits, or error behavior (e.g., invalid cvid). For a tool with no annotations, this lack of behavioral context is a significant shortfall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with core purpose and content details. Every word serves a purpose; no redundancy or filler. Excellent conciseness for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward info retrieval tool with one parameter and no output schema, the description covers purpose and output fields. However, it lacks usage guidelines, behavioral transparency, and error handling context. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter (cvid) already described as '专栏文章 ID（CV 号，如 123456）'. The description adds no additional meaning to the parameter beyond what the schema provides. Baseline of 3 is appropriate since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves detailed content of Bilibili column articles, listing included fields (title, text, publication time, author, data statistics). The verb '获取' and resource '专栏文章的详细内容' are specific, and it is easily distinguished from sibling tools like bilibili_video_info (videos) or bilibili_user_articles (list of articles).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. No conditions or prerequisites mentioned, such as requiring login or a valid cvid. There is no indication of when not to use it, which is a gap given the many sibling tools covering Bilibili features.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检测 B站视频/评论下的新回复，列出上次检查之后的新内容。不自动回复，需要人工确认后操作。
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | 最多检查几条（默认 20） | |
| videoId | No | 可选：指定视频 BV 号（如 BV1xx）过滤该视频的回复，不指定则查所有回复通知 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It states it lists new content since last check and does not auto-reply, but does not disclose how 'last check' is tracked (stateful?), or any side effects, rate limits, or auth requirements. More detail on state management would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no fluff. Purpose is front-loaded, and every sentence adds value. Very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could explain the return format (e.g., list of reply objects). It says 'list new content' but not how results are structured. Also lacks details on pagination or what constitutes 'new'. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for both parameters (max and videoId). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects new replies under Bilibili videos/comments, listing new content since last check. It distinguishes from auto-reply by explicitly stating it does not auto-reply, which differentiates it from sibling siblings like 'bilibili_reply'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for detecting new replies and explicitly states it requires manual confirmation before operation, advising against auto-reply usage. However, it lacks explicit when-to-use and when-not-to-use guidance compared to alternatives like bilibili_video_comments or bilibili_notifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查看已下载的文件列表（按时间倒序）
| Name | Required | Description | Default |
|---|---|---|---|
| outputDir | No | 下载目录，默认 ./bilibili-downloads | ./bilibili-downloads |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It correctly implies a read-only operation by stating 'view list', but does not explicitly confirm no side effects or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main purpose, and includes ordering detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is complete. It conveys the action and sort order adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds no parameter details beyond the schema, which already documents the outputDir parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists downloaded files in reverse chronological order. It uses a specific verb ('view') and resource ('file list'), which distinguishes it from sibling tools like download or search. However, it does not explicitly differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any conditions or prerequisites. The description only states the function without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 B站当前热门视频列表，包含播放量、弹幕数、点赞数等数据
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | 每页数量，默认 10 | |
| page | No | 页码，默认 1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description must disclose behavioral traits. It only states it 'gets' data, implying read-only, but does not explicitly confirm safety, side effects, or authorization needs. No mention of data freshness, rate limits, or result size limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loads the core purpose, including data fields. No unnecessary words. Could add structure like bullet points for clarity, but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations. Description provides minimal context: it returns a list with specific metrics. Lacks details on pagination, error handling, or data format. For a simple tool with two optional params, this is borderline adequate but still leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as both parameters (max, page) have descriptions in the schema. The tool description adds no additional meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves current hot video list from Bilibili with data like play count, danmaku count, likes. It uses a specific verb '获取' and resource '热门视频列表', making purpose clear. However, it does not explicitly differentiate from sibling tools like bilibili_search_hot, which may also return hot videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, typical use cases, or exclusions. The description lacks context about when this tool is appropriate compared to other Bilibili tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询 B站 UP 主的直播间信息。输入 uid（用户 ID），返回直播状态（是否开播）、直播间标题、人气值（热度）、关注数、直播分类、弹幕热词等。注意：人气值是热度指标，非真实观看人数
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | UP 主的用户 uid（可通过 bilibili_search 搜索获取） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to rely on, so the description must disclose behavioral traits. It mentions that '人气值' is a heat indicator, not real viewership, which is helpful. However, it does not disclose whether authentication or cookies are required, what happens on invalid input, rate limits, or any side effects. For a read-like operation, basic safety is assumed but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two short sentences. The first sentence states the core purpose, and the second lists key outputs with a crucial clarification. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param, no output schema), so the description covers basic input-output expectations. It lists return fields and clarifies the popularity metric. However, it does not specify error handling (e.g., non-existent uid), authentication needs, or return format structure. Given no output schema, more detail on the response would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'uid', so baseline is 3. The description adds that uid can be obtained via bilibili_search, providing useful context beyond the schema. However, no additional semantic depth is added (e.g., format constraints, example values).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '查询' (query) and the resource 'B站 UP 主的直播间信息' (Bilibili UP主's live room information). It lists specific return fields (live status, title, popularity, followers, category, danmaku hot words), making the tool's function distinct from siblings like bilibili_user_info or bilibili_video_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative sibling tools. No prerequisites, exclusions, or context for appropriate usage are mentioned. The only additional note is about the popularity metric, which is a behavioral clarification, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
生成 B站 扫码登录二维码。返回二维码图片（Base64）和 login_key，将 login_key 传给 bilibili_login_check 检查登录状态
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the output (Base64 image and login_key) but does not disclose behavioral traits such as authentication requirements, rate limits, error handling, or QR code expiration. Minimal behavioral context beyond basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence states the purpose directly, and the second adds return values and next steps. Every sentence is essential and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return values (Base64 image and login_key) and the next step. However, it omits potential details like QR code expiration time or error scenarios, which would improve completeness for a login tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. The description correctly focuses on the output, as there are no parameters to describe. This meets the baseline of 4 for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a Bilibili login QR code, returns a Base64 image and login_key, and instructs to pass the key to bilibili_login_check. This is specific and distinguishes from sibling tools like search or refresh.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for login by providing follow-up instructions (pass login_key to bilibili_login_check), but does not explicitly state when to use this tool vs alternatives like bilibili_login_check or bilibili_refresh_cookie. No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
检查 B站 扫码登录状态。调用 bilibili_login 获取二维码后，传入返回的 loginKey 进行轮询检查。扫码成功后自动保存 Cookie
| Name | Required | Description | Default |
|---|---|---|---|
| loginKey | Yes | bilibili_login 返回的 loginKey | |
| maxRetries | No | 最多轮询次数（每次间隔 2 秒），默认 30 次约 60 秒 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses polling behavior (2-second intervals, max retries) and auto-saving cookies on success, but does not explain what happens on failure, timeout, or expired QR codes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary function, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite moderate complexity and no output schema, the description does not mention the return value or response structure. It is incomplete regarding what the tool outputs after polling (e.g., success/failure).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions for both parameters are adequate. The description adds context that loginKey comes from 'bilibili_login', but otherwise does not add meaning beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks Bilibili scan login status, specifying the action ('检查 B站 扫码登录状态') and distinguishing from the sibling tool 'bilibili_login' which gets the QR code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to call this tool after obtaining a loginKey from 'bilibili_login', providing clear context on when to use it. It does not explicitly mention when not to use or alternatives, but the sequential dependency is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查看 B站未读消息概览，包含回复、@提及、点赞等通知
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description simply states what the tool does (view overview of unread messages). Does not disclose behavioral traits beyond the obvious (e.g., read-only nature, no side effects). Could be more transparent about return format or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no wasted words. Perfectly concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but tool is simple and parameterless. Description provides enough context for an agent to understand the purpose. Could mention it returns a list/overview, but not necessary for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist. Schema coverage is 100% (empty schema). Baseline for 0 params is 4; description adds no parameter info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb '查看' (view) and the resource 'B站未读消息概览' (Bilibili unread message overview) with examples (replies, mentions, likes). Distinguishes from sibling tools like search, replies, video info, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Usage is implied: when the agent needs to view unread notifications. No mention of alternatives or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
手动触发 B站 Cookie 刷新。检查当前 Cookie 状态，如需要则执行完整的 6 步刷新流程（含 RSA 加密、refresh_csrf 获取、刷新、确认更新）
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's behavior: it performs a 6-step refresh including RSA encryption and refresh_csrf acquisition. This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that packs all necessary information without redundancy. It is front-loaded with the verb 'refresh' and resource 'Cookie'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain the outcome (e.g., success indication) or prerequisites (e.g., must be logged in). Given no output schema, this leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. The description adds no parameter details, but this is acceptable as there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: manually triggering Bilibili cookie refresh, including checking current status and executing a detailed 6-step process. It differentiates from sibling tools like bilibili_login and bilibili_login_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for refreshing an existing cookie but lacks explicit guidance on when to use it versus alternatives like bilibili_login or bilibili_login_check. It does mention it checks status first, offering some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在 B站视频下发布评论或回复他人评论
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | 评论区类型：1=视频(默认)，12=专栏，17=动态 | |
| message | Yes | 评论内容，最大 1000 字符 | |
| videoId | Yes | 视频 BV 号（如 BV1xx）或 avid（数字） | |
| rootRpid | No | 根评论 rpid（二级以上回复时使用） | |
| parentRpid | No | 要回复的评论 rpid（楼中楼回复时使用） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral aspects. It only states the action (post/reply) but omits critical details: authentication needs, rate limits, idempotency, or the distinction between root and parent replies. The schema descriptions don't compensate for these gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, directly communicates the core action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 5 parameters and no output schema or annotations. The description is too brief to cover usage scenarios (e.g., when to use rootRpid vs parentRpid, character limits, response handling). Leaves the agent needing to infer important behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds no extra meaning beyond the schema; it only summarizes the action. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states verb '发布评论或回复' (post/reply) and resource 'B站视频下' (under Bilibili videos), clearly distinguishing from siblings like bilibili_video_comments (view comments) and bilibili_send_danmaku (send danmaku). However, the schema includes 'type' for columns and dynamics, making the scope slightly narrower than described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., bilibili_send_danmaku for scrolling messages). No prerequisites like login requirement or context about replying to existing comments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索 B站视频。⚠️ 注意：B站 totalrank 算法不按时间排，系列剧集最新一集可能不在第 1 页。如要查某 UP 主最新视频，建议先用搜索找到 UP主 uid，再调用 bilibili_user_videos 工具
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 页码，默认 1 | |
| order | No | 排序：totalrank=综合(默认，按热度), click=最多播放, pubdate=最新发布, dm=最多弹幕, stow=最多收藏, scores=最多评论 | totalrank |
| keyword | Yes | 搜索关键词 | |
| duration | No | 时长筛选：0=全部(默认), 1=<10分钟, 2=10-30分钟, 3=30-60分钟, 4=>60分钟 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that totalrank does not sort by time and that the latest episode may not appear on page 1. This is a critical behavioral trait. It does not mention rate limits or other aspects, but the given information is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sentences. It front-loads the core purpose and then provides crucial behavioral context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the most important nuance (ordering), it does not mention pagination behavior, duration filter, or the general structure of results. Given no output schema, some guidance on return format would improve completeness. Still, it addresses key usage concerns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description adds meaning beyond the schema by explaining the implication of the 'totalrank' order (not time-sorted), which is not in the parameter description. This helps the agent make better choices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '搜索 B站视频' (search Bilibili videos), specifying the verb and resource. It distinguishes from sibling bilibili_user_videos by suggesting an alternative workflow for finding latest videos by a specific UP主. However, it does not explicitly differentiate from bilibili_search_hot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool: for general search of Bilibili videos, and when not: for finding latest videos of a specific UP主, recommending bilibili_user_videos instead. It also warns about the totalrank ordering behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 B站热搜关键词列表
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states 'get list' without mentioning authentication, rate limits, or data freshness, leaving significant gaps for a parameterless tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, direct verb-object structure, no redundant words. Highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description omits details about the response format and how 'hot' is defined. Given no output schema and no siblings comparisons, it is minimally complete but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters and schema coverage is 100%. Baseline 4 applies; no additional parameter description is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of Bilibili hot search keywords, which is specific and distinguishable from siblings like 'bilibili_search' and 'bilibili_hot'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'bilibili_hot' or 'bilibili_search'. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
向视频发送一条弹幕。B 站对此操作有极严格的风控，新账号或操作频繁的账号可能直接被风控拦截。建议每天不超过 5 条。
| Name | Required | Description | Default |
|---|---|---|---|
| cid | Yes | 视频分 P 的 cid（通过 bilibili_video_info 获取） | |
| mode | No | 弹幕模式：1=滚动, 4=底部, 5=顶部, 7=高级 | |
| color | No | 弹幕颜色（十进制 RGB），默认 16777215（白色） | |
| message | Yes | 弹幕内容（最多 100 字符） | |
| videoId | Yes | 视频 BV 号或 avid | |
| progress | Yes | 弹幕出现时间点（毫秒），例如 30000 = 第 30 秒 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavioral traits: strict risk control, potential blocking for new or frequent accounts, and a daily limit recommendation. With no annotations, description carries full burden and handles it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second adds crucial risk warning. No filler, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and risk, but lacks information about authentication prerequisites and expected return (success/failure). For a sending tool, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no extra parameter-specific info beyond what the schema already provides in parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a danmaku to a video, with specific verb '发送' and resource '视频'. It distinguishes from siblings like bilibili_video_danmaku which retrieves danmakus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides strong guidance on when not to use: warns about strict risk control and advises maximum 5 per day. Lacks explicit mention of alternatives for getting danmakus, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取指定 UP 主发布的专栏文章列表，包含阅读数、发布时间等
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | 最多返回几条专栏（默认 10） | |
| uid | Yes | UP主 UID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions the returned fields (read count, publish time) but fails to note auth requirements, error handling, pagination, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence. However, it could be more concise by omitting redundant phrasing, or more structured with additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and no output schema, the description provides adequate but minimal context. It lacks information on list ordering, total count, or error states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond the schema, thus baseline score 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves a list of column articles from a specified UP host, including read count and publish time. This clearly distinguishes it from sibling tools like bilibili_video_info or bilibili_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching articles by a UP host, but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取指定 UP 主的最新动态（包括视频投稿、转发、图文等）
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | 最多返回几条动态（默认 10） | |
| uid | Yes | UP主 UID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does not disclose behavioral traits such as pagination, rate limits, authentication requirements, error handling, or how to interpret the output. Only the basic content type is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, full schema coverage, no output schema), the description covers the main function. It lacks usage context but is sufficient for a basic retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both 'uid' and 'max' described in schema). The description does not add any additional meaning or context beyond what is already in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('获取'), resource ('指定 UP 主的最新动态'), and what is included ('视频投稿、转发、图文等'). It distinguishes from sibling tools like bilibili_user_info and bilibili_video_info by focusing on dynamics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving user dynamics but provides no explicit guidance on when to use this tool versus alternatives like bilibili_user_articles or bilibili_user_followers. No exclusion criteria or scenarios for not using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询指定用户的粉丝列表（谁关注了 TA）
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | 用户 UID | |
| page | No | 页码，默认 1 | |
| pageSize | No | 每页数量，默认 20 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as authentication requirements, rate limits, pagination behavior, or what data is returned. The description only states the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the purpose. No irrelevant or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple paginated list tool, the description is minimally adequate. However, it lacks information on authentication, return format, and pagination details, which would be helpful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters have descriptions). The description adds no extra meaning beyond the schema; it does not explain how to interpret the uid or how pagination works.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (query) and resource (follower list of a specified user). It effectively distinguishes from sibling tools, which cover different Bilibili operations like search, videos, or login.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., bilibili_user_following or bilibili_user_info). No prerequisites or context for usage are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 B站用户信息，包含昵称、签名、等级、粉丝数、关注数、直播间信息等
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | 用户 UID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It only lists output fields but does not explicitly state that the tool is read-only, requires authentication, or has rate limits. The description is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, front-loaded sentence that states the action and includes a list of example outputs. No redundant or extraneous words; every part of the sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no output schema, the description lists several output fields but ends with '等' (etc.), leaving some vagueness. It covers essential information for a simple info retrieval tool but could be more explicit about the full output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as the single parameter 'uid' is described as '用户 UID'. The tool description adds no additional meaning beyond the schema; it focuses on output fields rather than enriching parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('获取 B站用户信息') and lists specific fields (昵称, 签名, 等级, 粉丝数, 关注数, 直播间信息), distinguishing it from sibling tools like bilibili_user_dynamics or bilibili_live_info. The verb+resource combination is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. While the purpose is clear, it does not differentiate from alternatives like bilibili_user_dynamics or bilibili_live_info, leaving the agent to infer based on tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 B站视频的评论列表，包含评论内容、作者信息、点赞数等
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | 最多返回几条评论（默认 10） | |
| videoId | Yes | 视频 BV 号或 avid |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It discloses the action and result contents but does not mention pagination, ordering, or authentication requirements. For a read operation, it is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-front-loaded sentence conveying the main purpose. It is conciseness but could be slightly more structured (e.g., listing inclusion details).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should compensate. It mentions included fields but omits ordering, pagination, and any rate limits or authentication. Given the tool's simplicity, it is mostly complete but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as both parameters (videoId, max) have descriptions. The description adds no extra meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb '获取' (get), the resource 'B站视频的评论列表' (Bilibili video comment list), and specifies included data (content, author info, likes). It effectively distinguishes from sibling tools like bilibili_video_info or bilibili_video_danmaku.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies straightforward usage for retrieving comments. It does not explicitly state when to use or alternatives, but given the simple read nature, the context is clear. Sibling tools are not mentioned, so some guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 B站视频的弹幕列表，包含弹幕内容、出现时间、类型、颜色等
| Name | Required | Description | Default |
|---|---|---|---|
| segment | No | 弹幕分段索引（每 6 分钟一段），默认 1 | |
| videoId | Yes | 视频 BV 号或 avid |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only lists return fields (content, time, type, color) but omits behavioral traits such as authentication requirements, rate limits, pagination, or error handling. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It efficiently conveys the purpose and key return fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description lists the return fields but does not specify the structure (e.g., array of objects, field types). It also lacks details on the segment parameter's behavior or limits, and does not mention error conditions or empty results. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for both videoId and segment. The description adds a note that segment indexes 6-minute intervals, which is slightly more than the schema. However, it doesn't explain how segments are numbered or the range, so value added is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of danmaku (bullet comments) for a Bilibili video, and specifies the fields included (content, time, type, color). This distinguishes it from sibling tools like bilibili_send_danmaku and bilibili_video_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., when to use bilibili_video_info instead). The description doesn't mention prerequisites or context, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
下载 B 站视频到本地。自动下载视频+音频并用 ffmpeg 合并为 MP4。要求系统已安装 ffmpeg。⚠️ 仅供个人备份使用，请勿传播。
| Name | Required | Description | Default |
|---|---|---|---|
| cid | No | 分 P 的 cid（不指定则取第一 P） | |
| quality | No | 画质，默认 1080P（大会员才能看 4K/1080P+） | 1080P |
| videoId | Yes | 视频 BV 号或 avid | |
| outputDir | No | 输出目录，默认 ./bilibili-downloads | ./bilibili-downloads |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool automatically downloads and merges video/audio into MP4, and mentions the ffmpeg requirement and non-sharing warning. However, it does not mention potential issues like the need for a valid cookie for high-quality downloads, rate limits, or behavior on errors. The description provides adequate but not exhaustive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a warning line. It front-loads the primary purpose and then gives prerequisite and restriction. Minimal waste, though could be slightly more structured (e.g., bullet points) but not necessary. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should cover return values and failure behavior. It does not mention what the tool returns (e.g., file path) or what happens on error (e.g., missing ffmpeg). While parameters are well-documented in schema, the overall completeness for a download tool is lacking essential behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter (videoId, cid, quality, outputDir) with descriptions including defaults and notes (e.g., VIP requirement for 4K). The description text adds no additional parameter context beyond what the schema provides, meriting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb '下载' (download), resource 'B站视频到本地', and key actions: auto-download video+audio and merge to MP4 using ffmpeg. It distinguishes from siblings like bilibili_video_info or bilibili_video_danmaku which are non-download tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (ffmpeg installed) and a usage restriction (personal backup only). However, it does not explicitly guide when to use this tool versus alternatives like bilibili_download_list for managing downloads or bilibili_video_info for metadata. The context is clear but lacks exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 B站视频的详细信息，包含标题、简介、播放量、弹幕数、评论数、点赞数、投币数、收藏数、分享数等
| Name | Required | Description | Default |
|---|---|---|---|
| videoId | Yes | 视频 BV 号或 avid |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only says what the tool returns, but does not mention side effects, authentication needs (e.g., cookie required), rate limits, or error behavior. For a read operation, it is implicitly non-destructive, but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence in Chinese that front-loads the main purpose. Efficient and no wasted words, though could be slightly more structured by listing fields compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description is fairly complete for a simple info tool. However, it omits context on authentication (e.g., whether login/cookie is needed) and the structure of the output. Sibling tools suggest auth may be relevant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema is 100% covered with description for videoId (BV or avid). The tool description adds no extra detail beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets detailed Bilibili video info and lists specific fields like title, play count, danmaku, etc. It is a specific verb+resource and distinguishes from siblings like bilibili_video_comments and bilibili_video_danmaku.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., vs. bilibili_video_comments or bilibili_video_danmaku). Does not mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.2.0bilibili_article_infobilibili_detect_repliesbilibili_download_listbilibili_hotbilibili_live_infobilibili_loginbilibili_login_checkbilibili_notificationsbilibili_refresh_cookiebilibili_replybilibili_searchbilibili_search_hotbilibili_send_danmakubilibili_user_articlesbilibili_user_dynamicsbilibili_user_followersbilibili_user_infobilibili_video_commentsbilibili_video_danmakubilibili_video_downloadbilibili_video_infoScored across 21 tools
Most tools target distinct resources (videos, users, articles, live, auth), making selection generally clear. Minor ambiguity exists between bilibili_hot vs bilibili_search_hot and bilibili_notifications vs bilibili_detect_replies, but descriptions resolve the differences.
All tools share the bilibili_ prefix, but the pattern is mixed: some are resource_noun (video_info, user_followers), some are verb-only (search, hot, reply), and pairing is inconsistent (video_download vs download_list, search_hot vs hot). Still readable, but not a uniform verb_noun convention.
21 tools is on the heavy side, but the server covers a broad Bilibili surface including auth, videos, users, articles, live, and downloads. Each tool has a concrete purpose, so the count feels slightly over a lean scope rather than bloated.
Coverage is solid for read operations and basic interactions (comments, danmaku, downloads), and auth is fully handled. Notable gaps exist: bilibili_search explicitly references a bilibili_user_videos tool that does not exist, and there are no like/coin/favorite, follow/unfollow, or comment moderation tools, leaving some workflows incomplete.
MCP server aggregating hot-search boards from 8 Chinese platforms (Weibo, Zhihu, Bilibili, Douyin).
MCP server for ByteDance Seedance AI video generation
MCP server for Hailuo (MiniMax) AI video generation
MCP server for Kling AI video generation