bilibili-mcp-server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.2.0
Disambiguation5/5
Each tool targets a distinct Bilibili resource and action (e.g., search vs. hot, comments vs. replies, user info vs. dynamics). Descriptions clearly differentiate overlapping areas.
Naming Consistency4/5
All tools share 'bilibili_' prefix but mix verb_noun (e.g., bilibili_search_hot) and noun-only (e.g., bilibili_notifications) patterns. Minor inconsistency but still readable.
Tool Count4/5
21 tools cover a wide range of Bilibili features (video, user, live, download, login, etc.). Scope is comprehensive but slightly high; still well-scoped for the platform's complexity.
Completeness3/5
Covers major Bilibili operations, but notably missing bilibili_user_videos tool (referenced in search description). Other gaps like subscription management exist, but core workflows are supported.
Average 3.6/5 across 20 of 21 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 34 commits in the last 12 weeks
- Last stable release on July 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
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 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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
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 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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bilibili-mcp-server MCP server](https://glama.ai/mcp/servers/Iseenope/bilibili-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Iseenope/bilibili-mcp-server)

Score Badge

Copy to your README.md:

[![bilibili-mcp-server MCP server](https://glama.ai/mcp/servers/Iseenope/bilibili-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Iseenope/bilibili-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Iseenope/bilibili-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server