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 bilibili videos about machine learning"
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.
A MCP server for Bilibili API integration
English | 简体中文
Model Context Protocol (MCP) Server for the bilibili.com API.
Get user information by mid
Search video information by bvid
Search videos by keywords
Related MCP server: Bilibili API MCP Server
bilibili-mcp-server支持两种运行模式：
stdio模式（默认）：通过标准输入输出与MCP客户端通信
streamable-http模式：通过HTTP协议提供MCP服务，支持SSE（Server-Sent Events）
要使用streamable-http模式，请使用以下命令启动服务器：
# 基本启动
node dist/streamable-http.js
# 指定端口
HTTP_API_PORT=8080 node dist/streamable-http.js
# 启用访问令牌认证
HTTP_API_TOKEN=your-secret-token HTTP_API_PORT=8080 node dist/streamable-http.js服务器启动后，可以通过以下端点访问：
MCP API端点：http://localhost:PORT/mcp
如果启用了令牌认证，客户端需要在请求头中添加：Authorization: Bearer your-secret-token
HTTP_API_COOKIE（可选）：设置此环境变量以提供您的Bilibili
Cookie用于认证请求。这有助于避免因Bilibili的反机器人措施导致的"请求失败，封控检测问题"。示例格式：SESSDATA=您的SESSDATA值; buvid3=您的buvid3值
HTTP_API_TOKEN（可选）：用于streamable-http模式的访问令牌认证。如果设置此环境变量，客户端请求时需要提供Bearer
token进行身份验证。示例：your-secret-token
HTTP_API_PORT（可选）：streamable-http服务器监听的端口号，默认为3000。示例：8080
cookie 可以在浏览器上获取。
注意：如果您使用的是 Chrome 浏览器，请确保已登录 Bilibili 账号。
Refer to the official documentation
config for npm (recommended)
{
"mcpServers": {
"bilibili": {
"command": "npx",
"args": ["-y", "@masx200/bilibili-mcp-server"],
"env": {
"HTTP_API_COOKIE": "您的SESSDATA值; buvid3=您的buvid3值"
}
}
}
}or
config for local cloned repo
{
"mcpServers": {
"bilibili": {
"command": "node",
"args": [
"/ABSOLUTE/PATH/TO/PARENT/FOLDER/bilibili-mcp-server/dist/index.js"
],
"env": {
"HTTP_API_COOKIE": "您的SESSDATA值; buvid3=您的buvid3值"
}
}
}
}Save the configuration and restart. You will see the new bilibili MCP option
as shown below:
https://github.com/user-attachments/assets/813dece6-c9b5-4bc5-96c1-c3b4d284cc76
Install dependencies
pnpm ibuild
pnpm build
# or
pnpm devdebug for local repo, see above.
To publish a new version to npm:
# For patch version update (0.0.x)
pnpm publish:patch
# For minor version update (0.x.0)
pnpm publish:minor
# For major version update (x.0.0)
pnpm publish:majorThese commands will automatically:
Bump the version in package.json
Build the project
Publish to npm registry
Get information about a Bilibili user
| Name | Required | Description | Default |
|---|---|---|---|
| mid | Yes | User's numeric ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It indicates a read-only operation through the verb 'Get', but does not disclose additional behavioral traits such as error handling, rate limits, or return format. This is a neutral score because it is not misleading, but it adds minimal behavioral context.
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 unnecessary words. It front-loads the action and resource, making it easy to parse and understand quickly.
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 simplicity of the tool (one parameter, no output schema, no annotations), the description is adequately complete. It states the core purpose clearly, and while it could mention what specific information is returned, this is not critical for a basic user-info lookup.
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 parameter 'mid' is fully documented in the schema as 'User's numeric ID'. The description does not add any additional semantic context beyond the schema, which is acceptable given the high coverage.
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 uses a specific verb ('Get') with a clear resource ('information about a Bilibili user'). It clearly distinguishes itself from siblings like get_video_info and search_videos, which target different resource types.
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 clearly implies when to use the tool: whenever you need information about a specific user. It provides clear context for usage, though it does not explicitly mention alternatives or exclusions. For a simple lookup tool, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a Bilibili video
| Name | Required | Description | Default |
|---|---|---|---|
| bvid | Yes | Bilibili video ID (BVID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to mention the return format, what fields constitute 'detailed information,' or any potential side effects (though 'get' implies read-only). It adds minimal behavioral context beyond the verb.
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 with no wasted words. It is appropriately minimal for a simple getter 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?
This tool has no output schema and no annotations, requiring the description to explain what return values to expect. The description only says 'detailed information' without specifying any fields or structure, leaving the agent with insufficient understanding of the output. Given the availability of sibling tools, it also doesn't clarify how this differs in output or use case.
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 already fully documents the only parameter (bvid) with a description, achieving 100% schema coverage. The description adds no additional parameter semantics such as format examples or constraints, so it performs at the baseline.
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 states a specific verb ('Get') and resource ('detailed information about a Bilibili video'). It distinguishes from siblings by the resource type (video vs user/search), making its purpose clear.
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 provides no explicit guidance on when to use this tool versus get_user_info or search_videos. Usage is only implied by the name and description: if you have a known BVID. No exclusions or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for videos on Bilibili
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, defaults to 1 | |
| count | No | Number of results to return, default 10, maximum 20 | |
| keyword | Yes | Keyword to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention pagination behavior, result ordering, authentication, rate limits, or what is included in the results. The schema hints at page/count but the description itself adds no behavioral context.
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, front-loaded sentence with no filler, making it highly concise. However, it is so terse that it omits useful context, though it still 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?
Given the lack of output schema and annotations, and the description's brevity, the agent is left without crucial context such as return structure, pagination limits, edge cases, or conflict with siblings. The schema covers parameters but the description does not round out the tool's behavior.
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 self-explanatory fields (keyword, page, count). The description adds no information beyond the schema, so the baseline of 3 applies.
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: searching for videos on Bilibili. The verb 'search' distinguishes it from sibling tools get_user_info and get_video_info, which are direct lookups, and it specifies the resource and platform.
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 offers no guidance on when to use this tool versus the sibling tools, nor any circumstances that would make it the preferred choice. It only states the basic functionality without any context or exclusions.
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.0.0get_user_infoget_video_infosearch_videosScored across 3 tools
Each tool targets a distinct resource and action: user info, video info, and searching videos. There is no overlap or ambiguity between them.
Names follow a mostly consistent pattern with 'get_' prefix for retrieving specific resources and 'search_' for the search operation. Minor deviation: search_videos doesn't include '_info' suffix, but overall the style is clear.
Three tools is on the lower end but acceptable for a focused read-only server covering user and video lookup plus search. It feels intentionally minimal rather than incomplete.
The set covers basic needs for retrieving user info, video details, and searching, but notable gaps include listing a user's uploaded videos, fetching comments, or trending content. Still, the core read-only workflows are supported.
Track Bilibili creators and get the latest updates on videos, dynamics, and articles. Fetch user p…
Bilibili public video, article, dynamic, creator, comments, reactions, and transcript tools.
YouTube discovery, transcripts, library search, and monitors with API keys or OAuth.
Search Chinese books with Douban ratings, AI book guides and curated toplists. Free, no API key.