A
licenseA
qualityD
maintenanceEnables AI assistants to interact with Google Drive, supporting file operations like list, search, read, create, update, delete, share, and manage permissions.
7
1,601 npm
4
MIT
bososo-mcp
by JUTZUGC
Supports searching and retrieving resources hosted on Baidu Netdisk (百度网盘): search results can be filtered to only Baidu Netdisk entries via the baidu cloud type, and each matching result can be exchanged for a savable Baidu Netdisk share link with its extraction code.
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., "@bososo-mcp帮我找一下「囧次元」的安装包，然后把最相关的一条转成夸克网盘分享链接"
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.
博搜搜 MCP 工具
把博搜搜的资源搜索能力接给 AI —— 支持 MCP 协议，同时提供命令行工具。
不需要任何 API Key。 零第三方依赖，只用 Node 18+ 内置能力。
本目录可以整体作为一个独立仓库使用：
cli.mjs/mcp-server.mjs都在根目录。 如果你把它放在别的仓库的子目录里，把下面命令里的路径相应调整即可。
目录
Related MCP server: google-drive-mcp-server
这是什么
博搜搜是一个网盘资源搜索引擎。这个工具把它的两个能力包装成 AI 可以直接调用 的形式：
步骤 | 工具 | 作用 |
1 |
| 按关键词搜索，列出找到的资源 |
2 |
| 把其中一条换成可保存的分享链接 |
两步的顺序不能颠倒：搜索结果里每条都带一个 token，它是第 2 步的唯一凭据。
一个典型的对话：
用户：帮我找一下「囧次元」的安装包 AI：调用
bososo_search，关键词「囧次元」 → 找到 42 条 → 挑最相关的一条调用bososo_get_resource→ 拿到一条夸克网盘的分享链接和提取码。
├── README.md 本文件
├── lib/bososo.mjs 客户端封装
├── cli.mjs 命令行工具
└── mcp-server.mjs MCP server特性
双形态：既能作为 MCP server 接入 AI 客户端，也能当普通命令行工具用
零依赖：不需要
npm install，clone 下来就能跑无需密钥：走公开接口，不用申请任何 token 或 API Key
两步操作自动衔接：
token的传递、等待、重试都在工具内部处理，调用方只管拿结果错误可操作：每个失败都会带
code+hint，明确告诉你下一步该做什么（而不是丢一句「失败」）
环境要求
Node.js ≥ 18（需要内置的
fetch）能访问
https://www.bososo.com
node -v # 确认 >= 18快速开始
1. 拿到代码
git clone <本仓库地址>
cd <仓库目录>不需要 npm install。
2. 试一次搜索
node cli.mjs search "囧次元"第一次调用会慢一些（通常 20~40 秒）——搜索需要一点时间把结果找全，工具会等到结果齐了再返回。
输出类似：
共 42 条结果（第 1 页 / 共 3 页，服务端检索 18240ms）
[1] 囧次元.apk
平台：夸克网盘 时间：2026-03-15
token：s1.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
要保存这条资源：node cli.mjs get "<token>"3. 把结果换成可保存的链接
复制上一步某个结果的 token：
node cli.mjs get "s1.xxxxxxxxxxxx"✅ 获取成功
分享链接：https://pan.example.com/s/xxxxxxxxxxxx
提取码：abcd4. （可选）接入 AI 客户端
见 接入 AI 客户端。
命令行用法
node cli.mjs <命令> [参数]search <关键词>
node cli.mjs search "囧次元"
node cli.mjs search "酷我音乐" --clouds quark,uc --page-size 50 --json
node cli.mjs search "剪映" --days 30 --match-mode precise选项 | 取值 | 默认 | 说明 |
| ≥1 |
| 页码 |
| 1~50 |
| 每页条数 |
| 线路编号 | 默认线路 | 不同线路的搜索结果不同 |
|
|
|
|
|
| 不限 | 只看指定网盘的结果 |
| ≥0 | 不限 | 只看最近 N 天 |
| 1~500 | 服务端决定 | 结果上限 |
| 开关 | 关 | 忽略缓存，重新检索一遍 |
| ≥5 |
| 等待结果找全的最长时间 |
get <token>
node cli.mjs get "s1.xxxxxxxxxxxx"
node cli.mjs get "s1.xxxxxxxxxxxx" --json选项 | 取值 | 默认 | 说明 |
| ≥5 |
| 服务端还在处理时，允许等待/重试的最长时间 |
通用选项
选项 | 说明 |
| 输出 JSON，给程序 / AI 消费（人类可读信息走 stderr，JSON 走 stdout） |
| 覆盖接口域名，默认 |
| 出错时额外打印服务端原始报错（排障用） |
| 帮助 |
退出码
码 | 含义 |
| 成功 |
| 失败（需要安全验证、请求过多、资源取不到等，详见 失败时怎么办） |
| 用法错误（缺参数、命令拼错） |
MCP 工具契约
bososo_search
入参（keyword 必填）
字段 | 类型 | 默认 | 说明 |
| string | — | 必填，上限 200 字符 |
| integer ≥1 |
| 页码 |
| integer 1~50 |
| 每页条数 |
|
|
| 匹配模式 |
| string[] | 不限 |
|
| integer ≥0 | 不限 | 最近 N 天 |
| integer 1~500 | 服务端决定 | 结果上限 |
| boolean |
| 忽略缓存重新检索 |
| integer 5~300 |
| 等待结果找全的最长秒数 |
返回
字段 | 类型 | 说明 |
| number | 命中总数 |
| number | 当前页 / 总页数 |
| boolean |
|
| number | 服务端检索耗时 |
| number | 本次实际等待耗时 |
| string | 服务端提示，正常为空 |
| number | 本次返回条数 |
| array | 见下 |
| string | 下一步提示 |
results[] 元素：
字段 | 类型 | 说明 |
| number | 序号 |
| string | 资源标题 |
| string | 中文平台名，如 |
| string | 资源时间， |
| string | 第 2 步要用的凭据 |
{
"total": 42, "page": 1, "maxPage": 3,
"incomplete": false, "tookMs": 18240, "waitedMs": 18310,
"serverNote": "", "resultCount": 2,
"results": [
{ "n": 1, "title": "囧次元.apk", "platform": "夸克网盘", "datetime": "2026-03-15", "token": "s1.xxxxxxxxxxxx" },
{ "n": 2, "title": "酷我音乐_v9.3.0.apk", "platform": "百度网盘", "datetime": "2026-03-12", "token": "s1.yyyyyyyyyyyy" }
],
"nextStep": "用 bososo_get_resource 传某个结果的 token，即可拿到可保存的分享链接。"
}bososo_get_resource
入参（token 必填）
字段 | 类型 | 默认 | 说明 |
| string | — | 必填，来自 |
| integer 5~180 |
| 允许等待/重试的最长秒数 |
成功返回
字段 | 类型 | 说明 |
| string | 可保存的分享链接 |
| string | 提取码，可能为空串 |
| boolean |
|
{ "ok": true, "shareUrl": "https://pan.example.com/s/xxxxxxxxxxxx", "sharePassword": "abcd", "reused": false, "note": "" }失败返回（isError: true）
{
"ok": false,
"code": "INVALID_REQUEST",
"error": "token 无效，请重新搜索后再获取",
"hint": "参数不合法；若是 token 无效，说明这条结果已过期，需要重新搜索拿新的 token。",
"retryAfterMs": 0
}失败时以 hint 为准决定下一步。
支持的 MCP 方法
initialize / tools/list / tools/call / ping（stdio 传输，换行分隔的 JSON-RPC 2.0）
接入 AI 客户端
在客户端的 MCP 配置里加上这一段（args 请填绝对路径）：
{
"mcpServers": {
"bososo": {
"command": "node",
"args": ["<本目录的绝对路径>/mcp-server.mjs"]
}
}
}也可以手动验证 server 是否正常：
printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1"}}}' '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' | node mcp-server.mjs应当看到两行 JSON 响应（initialize 结果 + 两个工具的定义）。
MCP server 的所有日志都走 stderr，stdout 只输出 JSON-RPC 消息，不会污染协议流。
常见问题
Q：需要申请 API Key 吗？ 不需要。走公开接口，clone 下来直接就能用。
Q：为什么搜索这么慢？ 搜索需要一点时间把结果找全，通常 20~40 秒。工具会等到结果齐了再返回，所以单次调用耗时长是正常现象。不要因为慢就重复调用——重复调用不会更快。
Q：搜索很慢的话，能先看部分结果吗？
可以。把 waitSeconds 调小（比如 10），工具会在等不到全量时先把已有的结果返回，并在 incomplete 里标 true。
Q：为什么有时要求我做「安全验证」？ 短时间内获取资源过于频繁时会触发。这个验证只能由人在浏览器里手动完成，工具不做任何绕过。被拦下的请求没有产生任何消耗，所以在完成验证之前反复重试没有意义。
Q：token 能用多久？
长期有效。但如果服务端返回「token 无效」，说明这条结果已经失效，重新搜索拿一个新的即可。
Q：为什么同一条资源有时拿不到？ 常见原因是对方的分享链接失效了、内容被平台限制，或者当前网盘平台临时不可用。换一条结果或换一个平台即可。
Q：为什么我搜到的和网页上搜到的条数不一样？
工具默认等到结果全了再返回；如果你调小了 waitSeconds，拿到的是当前已有的部分结果（incomplete: true）。
Q：能不能不带 Node 用？ 工具本身是 Node 脚本。MCP server 只依赖 Node ≥18，没有其它运行时要求。
Q：--json 的输出怎么有两条流？
人类可读的提示走 stderr，JSON 走 stdout，所以可以直接 node cli.mjs search xxx --json > out.json 而不被提示文字污染。
Q：Windows 上路径怎么写？
MCP 配置里的 args 用双反斜杠或正斜杠都可以，例如 "D:/tools/bososo-mcp/mcp-server.mjs"。
失败时怎么办
| 你会看到 | 怎么办 |
| 需要完成安全验证 | 在浏览器里打开站点手动完成一次验证，验证前重试没有意义 |
| 操作过于频繁 | 等一会儿再试 |
| 服务端当前任务较多 | 等几秒再试 |
| 服务端当前任务较多 | 等几秒再试 |
| 关键词被拦 | 换一个关键词 |
| 该条结果无法获取 | 换一条结果 |
| 参数或 token 无效 | 重新搜索拿新 token |
| 还在处理中 | 工具已自动重试；仍失败就稍后再试一次 |
| 该条资源当前取不到 | 换一条结果 |
| 该平台暂时不可用 | 换一个平台的资源 |
| 服务端异常 | 稍后再试 |
免责声明
本工具只是一个接口客户端，本身不存储、不传播任何文件，也不提供下载或在线播放能力。
所有搜索结果与分享链接均来自第三方网盘平台，工具不对其内容、合法性、安全性做任何保证。
请在使用前自行判断资源的合法性与安全性，并遵守所在地区的法律法规及各网盘平台的服务条款。
请勿将本工具用于任何侵权、违法或商业侵权的用途。如有侵权问题，请联系相关网盘平台处理。
License
MIT
Available Tools
2 toolsbososo_get_resourceA
用 bososo_search 返回的 token 换取一份可保存的分享链接。这是获取资源的第 2 步，token 只能来自 bososo_search 的结果，不能自行构造。该操作服务端要真实处理一次、耗时较长；短时间内请求过多时会被要求先完成一次安全验证（返回 CAPTCHA_REQUIRED）—— 这种情况只能由用户在浏览器里手动完成验证，不要反复重试。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | bososo_search 结果项里的 token（必填） | |
| waitSeconds | No | 允许等待/重试的最长秒数，默认 90 |
TDQS
A4.8/5.0
Behavior5/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 and does so well: it discloses that the operation requires real server-side processing and is slow, that bursty requests trigger a security check returning CAPTCHA_REQUIRED, and that this error is not retryable by the agent. Latency expectations, failure mode, error code, and human-in-the-loop requirement are all surfaced.
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?
Front-loaded with the action and its input source, then prerequisites, then operational hazards. Four sentences, each carrying distinct information (purpose, provenance, latency, rate-limit/error handling) with no filler or repetition.
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?
Covers input provenance, expected latency, the CAPTCHA_REQUIRED failure mode, and retry policy — everything needed to invoke and recover correctly, and the return value (share link) is named despite no output schema. The only soft spot is that waitSeconds is not tied to the described long-running/CAPTCHA behavior, though the schema documents it fully.
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 description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema for `token` by constraining its provenance (must originate from bososo_search, non-constructible). `waitSeconds` is left entirely to the schema, and its relationship to the long server-side wait is not connected in the prose.
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?
States a concrete verb+resource: exchange a bososo_search token for a savable share link, and explicitly frames itself as step 2 of the flow, distinguishing it from the sibling bososo_search (step 1). The provenance constraint ('token can only come from bososo_search, cannot be constructed') removes any ambiguity about what input is valid.
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?
Explicitly names the prerequisite tool (bososo_search) and the step ordering, and gives a clear when-not rule: on CAPTCHA_REQUIRED the agent must stop retrying and hand off to the user in a browser. Both the trigger condition and the required alternative behavior are stated, not inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bososo_searchA
按关键词搜索网盘资源（夸克/UC/百度/迅雷等），返回带 token 的结果列表。这是获取资源的第 1 步；要用 bososo_get_resource 取回可保存的分享链接，必须使用本工具返回的 token。注意：搜索需要一点时间把结果找全（通常 20~40 秒），本工具会等到结果齐了再返回，耗时较长属正常，不要因为慢就重复调用。
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 页码，默认 1 | |
| keyword | Yes | 搜索关键词（必填，上限 200 字符） | |
| refresh | No | true = 忽略服务端缓存重新检索；一般不需要 | |
| pageSize | No | 每页条数，默认 20，上限 50 | |
| matchMode | No | fuzzy（默认）匹配标题+正文；precise 只匹配标题，结果更准但更少 | |
| cloudTypes | No | 只要指定网盘平台的结果；不传 = 不限 | |
| maxResults | No | 结果上限；不传由服务端决定 | |
| waitSeconds | No | 等待结果找全的最长秒数，默认 120 | |
| timeRangeDays | No | 只取最近 N 天的结果；0 或不传 = 不限 |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses meaningful behavior: the call blocks until results are complete (20-40s typical), long latency is normal, and repeated calls are discouraged. It does not cover failure modes, rate limits, or the exact shape/ordering of the token-bearing results, so it stops short of 5.
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?
Front-loaded with purpose, then workflow routing, then the latency warning; each sentence is functional. The closing caution about slowness is slightly redundant with the earlier '通常 20~40 秒' statement, which keeps it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter, 1-required search tool with no annotations and no output schema, the description covers the essentials: purpose, workflow position, token dependency, and latency expectations. It omits the structure/ordering of the returned result list and any failure behavior, which are minor given the well-documented 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 description coverage is 100%, and every parameter (page, keyword, refresh, pageSize, matchMode, cloudTypes, maxResults, waitSeconds, timeRangeDays) already carries its own Chinese description, so the schema does the heavy lifting. The description adds no extra semantics such as token lifetime or how matchMode interacts with result counts, so baseline 3 is correct.
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?
States a specific verb and resource (search cloud-drive resources by keyword across named platforms) and returns 'results with token'. It explicitly distinguishes itself from the sibling bososo_get_resource, framing itself as step 1 of a two-step workflow, so an agent can tell the two apart without opening either schema.
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?
Explicitly states when to use it (step 1 to obtain tokens), which sibling to call next and under what condition (bososo_get_resource to retrieve savable share links, requiring the token from this tool), and even a when-NOT-to: do not re-invoke just because it is slow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v1.0.0- First observed
bososo_get_resource - First observed
bososo_search
TDQS
A4.5/5.0
Scored across 2 tools
Disambiguation5/5
The two tools map onto distinct, explicitly-numbered stages of a single workflow: bososo_search (step 1, keyword search returning tokens) and bososo_get_resource (step 2, token redemption). Their descriptions explicitly state the dependency (token must come from search), leaving no room for misselection.
Naming Consistency5/5
Both tools use the same bososo_ snake_case prefix with a clear action component (search, get_resource). The pattern is predictable and consistent.
Tool Count4/5
Two tools is on the lean side, but for a narrowly-scoped search-then-redeem pipeline each one earns its place with a distinct role. It is slightly under the typical 3-15 range but not a mismatch for the stated purpose.
Completeness4/5
The full end-to-end flow (find resources, exchange token for a savable share link) is covered with no dead ends. Minor gaps exist — no pagination, result filtering, or resource metadata/browsing — but agents can work around these via the search tool.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Search public AI capabilities and coordinate approved work through Darwin's Search to Act interface.
Connect AI to Stelllink to organize, access, manage and share files, links, and digital workspaces.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Securely search and manage workspace context files for AI agents and teams.
Related MCP Servers
- FlicenseAqualityDmaintenanceEnables AI assistants to interact with Google Drive, including reading, searching, listing folders, and uploading files.71-
- FlicenseNot gradedqualityDmaintenanceEnables MCP-compatible AI assistants to interact with a user's Google Drive, including listing, searching, reading, creating, updating, and deleting files, with authentication via Google OAuth.-
- AlicenseAqualityAmaintenanceEnables AI apps to work with Google Drive in plain language, including searching, organizing, uploading, downloading, exporting, sharing, and commenting on files, with reversible trash and configurable access scopes.2169 npmMIT