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., "@hot-content-mcp Get top 10 Baidu hot searches"
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.
🔥 为 Claude 和 Cherry Studio 提供多平台热门内容数据的 Model Context Protocol (MCP) 服务器。
支持平台：
🔥 百度热搜榜
📺 B站热门视频
后续可能会支持更多平台
Related MCP server: Bilibili API MCP Server
⚠️ 重要：请先设置环境变量或创建配置文件再运行命令！
获取 API 凭据：请访问 API盒子 获取您的 API ID 和密钥。
方法1：设置环境变量（最简单）
# Linux/Mac
export HOT_CONTENT_API_ID="your_actual_api_id"
export HOT_CONTENT_API_KEY="your_actual_api_key"
# Windows
set HOT_CONTENT_API_ID=your_actual_api_id
set HOT_CONTENT_API_KEY=your_actual_api_key使用cherry studio时，在环境变量内配置也可运行
HOT_CONTENT_API_ID=your_actual_api_id
HOT_CONTENT_API_KEY=your_actual_api_key方法2：创建配置文件（传统方式）
如果不使用环境变量，可以创建 config.json 文件：
{
"api": {
"id": "your_actual_api_id",
"key": "your_actual_api_key"
}
}环境变量或配置文件设置完成后，即可运行：
# 直接运行（无需安装）
npx hot-content-mcp@2.4.0
# 启动SSE模式用于Web应用
npx hot-content-mcp@2.4.0 sse 3000
# 使用自定义配置文件位置
npx hot-content-mcp@2.4.0 --config /path/to/config.json# 确保已设置环境变量或创建 config.json 文件后再运行
npm install && npm run build && npm run startget_baidu_hot_search - 获取百度热搜榜数据（支持count参数，默认10条，最大50条）
search_baidu_hot_search - 搜索包含特定关键词的百度热搜
clear_baidu_cache - 清除百度热搜数据缓存
get_bilibili_hot - 获取B站热门视频数据（支持count参数，默认10条，最大50条）
search_bilibili_videos - 搜索B站视频（根据标题或UP主名称）
clear_bilibili_cache - 清除B站视频数据缓存
baidu://hot-search/current - 当前完整热搜榜数据
baidu://hot-search/top5 - TOP5热搜数据
bilibili://videos/current - 当前B站热门视频数据
bilibili://videos/top5 - TOP5 B站热门视频
配置文件位置: Cherry Studio 设置 → MCP服务器
方式1：环境变量配置（推荐）
设置系统环境变量：
HOT_CONTENT_API_ID = your_actual_api_id
HOT_CONTENT_API_KEY = your_actual_api_key
Cherry Studio MCP配置：
{
"mcpServers": {
"hot-content": {
"command": "npx",
"args": ["hot-content-mcp@2.4.0"]
}
}
}方式2：配置文件
首先创建配置文件 config.json：
{
"api": {
"id": "your_actual_api_id",
"key": "your_actual_api_key"
}
}将配置文件保存到以下任一位置：
用户目录 (推荐): C:\Users\用户名\config.json (Windows) 或 ~/config.json (Mac/Linux)
应用数据目录: %APPDATA%\hot-content-mcp\config.json (Windows) 或 ~/.config/hot-content-mcp/config.json (Mac/Linux)
Cherry Studio MCP配置：
{
"mcpServers": {
"hot-content": {
"command": "npx",
"args": ["hot-content-mcp@2.4.0"]
}
}
}配置步骤:
打开 Cherry Studio 设置
找到 MCP 服务器 选项
点击 添加服务器
填写：
名称: hot-content
命令: npx
参数: hot-content-mcp@2.4.0 （建议指定版本号确保使用最新版）
保存并重启
版本更新说明：
如果遇到版本显示不正确，请在配置中指定版本号：hot-content-mcp@2.4.0
或者清除npx缓存：npx clear-npx-cache 或 npm cache clean --force
高级选项：如需自定义配置文件位置，可以使用：
{
"mcpServers": {
"hot-content": {
"command": "npx",
"args": ["hot-content-mcp@2.4.0", "--config", "/path/to/your/config.json"]
}
}
}配置文件位置: ~/.claude/claude_desktop_config.json
{
"mcpServers": {
"hot-content": {
"command": "npx",
"args": ["hot-content-mcp"]
}
}
}从 v2.3.1 开始，支持环境变量配置，无需创建配置文件！
环境变量（推荐） - 更安全、更方便
配置文件 - 传统方式
设置以下环境变量即可直接使用，无需创建配置文件：
# 设置环境变量
export HOT_CONTENT_API_ID="your_actual_api_id"
export HOT_CONTENT_API_KEY="your_actual_api_key"
# 直接运行
npx hot-content-mcp@2.4.0Windows 用户：
set HOT_CONTENT_API_ID=your_actual_api_id
set HOT_CONTENT_API_KEY=your_actual_api_key
npx hot-content-mcp@2.4.0如果未设置环境变量，系统会自动查找配置文件：
当前配置格式（推荐）
{
"api": {
"id": "your_actual_api_id",
"key": "your_actual_api_key"
}
}默认位置: 运行命令的目录下的 config.json
自定义位置: 使用 --config 参数指定路径
✅ 配置文件必须存在
✅ API ID 和 Key 不能为空或纯空格
✅ 不能使用示例值（如 your_api_id、your_actual_api_id 等）
如果配置不符合要求，服务器将拒绝启动并显示详细的错误信息。
请获取当前百度热搜榜前10条内容，并分析热点话题类型。获取B站当前热门视频TOP5，分析内容类型和创作者特征。作为内容趋势分析师，请：
1. 获取百度热搜榜TOP5
2. 获取B站热门视频TOP5
3. 对比分析两个平台的热点内容差异
4. 提供平台特色分析报告搜索关键词"游戏"在百度热搜和B站热门视频中的相关内容。hot-content-mcp/
├── src/
│ ├── cli.ts # CLI入口文件
│ ├── index.ts # 主入口文件
│ ├── mcp-server.ts # MCP服务器实现
│ ├── api.ts # API服务（百度+B站）
│ └── config.ts # 统一配置管理
├── dist/ # 编译输出
├── mcp-config.json # MCP配置示例
├── bilibili_api_doc.md # B站API技术文档
└── package.json # 项目配置MIT License
本项目使用第三方 API 服务（API Hub）获取热门内容数据，仅供学习和研究使用。使用本项目时请注意：
API 服务：本项目依赖第三方 API 服务，我们不对其可用性、稳定性或准确性承担责任。
数据来源：热门内容数据来源于各平台（百度、B站），本项目不对数据内容的真实性、完整性或时效性负责。
使用风险：用户自行承担使用本项目的风险，包括但不限于数据丢失、服务中断等。
商业使用：如需商业使用，请自行评估风险并遵守相关法律法规。
API 费用：第三方 API 可能产生费用，请用户自行了解并承担相关成本。
本项目按"现状"提供，不提供任何明示或暗示的保证。
清除百度热搜数据缓存
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It does not mention that clearing the cache is destructive, irreversible, or that it invalidates data for get_baidu_hot_search. The agent cannot infer side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the operation. Every word is informative, and there is no wasted text.
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, the description is minimal but does not explain why or when to clear the cache, nor what impact it has on other tools like get_baidu_hot_search. The lack of annotations and output schema makes this an incomplete context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already trivially covers everything. The description adds no parameter details, but none are needed. Baseline of 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('清除' - clear) and the resource ('百度热搜数据缓存' - Baidu hot search data cache). It is specific and distinguishes itself from sibling tools like get_baidu_hot_search and clear_bilibili_cache.
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 guidance on when to use this tool, such as after stale data or before regenerating cache. No alternatives or exclusions are mentioned, leaving the agent without context for choosing between this and related cache clearing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
清除B站视频数据缓存
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'clear cache' without detailing whether data is permanently deleted, whether user settings are affected, whether the action is reversible, or if any confirmation is required. This is a significant gap for a potentially destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly communicates the tool's purpose without any redundant or filler content. It is perfectly sized for its trivial parameter structure.
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 absence of annotations and an output schema, the description should compensate by explaining the implications of clearing the cache (e.g., data loss, scope, reversibility). It currently only states the action, which is insufficient for an agent to fully understand the consequences and safe usage of a destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema fully documents everything. The description correctly adds no parameter details, and the baseline score of 4 applies since there is nothing additional to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (清除 = clear) and the target (B站视频数据缓存 = Bilibili video data cache), distinguishing it from sibling search and hot-list tools as well as the analogous clear_baidu_cache tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like clear_baidu_cache, nor any prerequisites, situations where it should be avoided, or expected side effects. The description is purely functional without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取百度热搜榜数据
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | 要获取的热搜条数，默认为10，最大50 | |
| use_cache | No | 是否使用缓存数据，默认为true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. It only says 'get data' and does not mention that results may be cached (despite the use_cache parameter), potential rate limits, network dependency, or what the response looks like. This is minimal disclosure beyond the obvious read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose. It is not verbose and the content is front-loaded. However, it is somewhat under-specified for a tool with two parameters, but the conciseness itself is good.
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?
With no output schema and no annotations, the description should explain what data is returned, but it only says 'data' without any structure. It also omits behavior related to the count and cache parameters, and provides no alternative guidance. The description is adequate for the simplest use but incomplete for an agent to fully understand 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?
The input schema has 100% coverage with descriptions for both parameters (count and use_cache). The tool description adds no parameter information beyond what the schema already provides. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取百度热搜榜数据' clearly states the verb (获取/get) and resource (百度热搜榜数据/Baidu hot search data). It distinguishes from get_bilibili_hot by specifying Baidu, but does not clarify how it differs from the sibling search_baidu_hot_search, so it lacks full sibling differentiation.
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 guidance on when to use this tool versus alternatives such as search_baidu_hot_search or the cache clearing tools. There is no mention of prerequisites, intended use cases, or exclusions. The tool name and schema hint at caching and count, but the description itself gives no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取B站热门视频数据
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | 要获取的视频数量，默认为10，最大50 | |
| use_cache | No | 是否使用缓存数据，默认为true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It only states 'get hot video data' and does not mention caching behavior, return format, data freshness, or the fact that use_cache defaults to true.
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 redundant wording. It is concise but very brief, omitting behavioral context that other dimensions capture; still, it is not padded or unclear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and sibling tools for search and cache clearing, the description is incomplete. It leaves out caching semantics, what the returned data looks like, and how it differs from search_bilibili_videos.
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 schema provides 100% description coverage for both parameters: count and use_cache. The tool description adds no parameter-level context beyond what the schema already explains, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses an explicit verb '获取' (get) and a specific resource 'B站热门视频数据' (Bilibili hot video data). This clearly distinguishes it from sibling tools such as get_baidu_hot_search (different platform) and search_bilibili_videos (search vs. hot rankings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention that it retrieves a trending/hot list rather than search results, nor any relationship to clear_bilibili_cache or search_bilibili_videos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索包含特定关键词的百度热搜
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 搜索关键词 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states that the tool searches for entries matching a keyword, but does not disclose any behavioral traits such as result limits, ordering, data freshness, or whether it is read-only. The description adds minimal value beyond the tool's name.
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, compact sentence that conveys the essential purpose. No wasted words; it is appropriately sized for a simple one-parameter 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?
With no output schema and no annotations, the description should clarify what results look like or how they are ordered. It does not explain the return format, pagination, or how 'hot search' is defined. Given the simplicity of the tool, this is a minimal but incomplete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as the only parameter 'keyword' has a description ('搜索关键词'). The tool description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('搜索' - search) and resource ('百度热搜' - Baidu hot search), with a clear scope: items containing a specific keyword. This distinguishes it from the sibling get_baidu_hot_search, though it does not explicitly name that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_baidu_hot_search. The description does not state that this tool is for filtering a full list, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索B站视频（根据标题或UP主名称）
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 搜索关键词 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states the search function and criteria, but does not mention whether results are read-only, pagination, output format, or any constraints. This leaves significant behavioral ambiguity for an agent.
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 short sentence that immediately conveys the tool's purpose and search criteria. There is no filler, redundant information, or unnecessary detail—every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description does not mention what the response contains (e.g., list of videos, metadata, sorting). Without annotations or an output schema, the lack of return information leaves the agent guessing about the result format, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines 'keyword' only as '搜索关键词' (search keyword). The description adds that the keyword matches title or UP主 name, giving meaningful semantic context beyond the bare parameter description. This helps the agent understand how to construct the keyword value.
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 '搜索B站视频（根据标题或UP主名称）' clearly states the action (search), the resource (Bilibili videos), and the specific scope (by title or UP主 name). This distinguishes it from siblings like get_bilibili_hot, which retrieves hot videos, making the purpose unambiguous.
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 parenthetical '根据标题或UP主名称' provides clear context for when to use this tool—when searching by title or uploader name. However, it does not explicitly mention alternatives or scenarios to avoid, so it lacks the explicit exclusions that would earn a 5.
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.
v2.4.0clear_baidu_cacheclear_bilibili_cacheget_baidu_hot_searchget_bilibili_hotsearch_baidu_hot_searchsearch_bilibili_videosScored across 6 tools
Each tool has a clear, distinct purpose: fetching hot content, searching within it, and clearing cache for each platform (Baidu and Bilibili). No overlap or ambiguity between tools.
Tool names follow a consistent verb_platform_object pattern (get/search/clear). Minor inconsistency: Baidu uses 'hot_search' while Bilibili uses 'hot' and 'videos', but this is understandable and does not cause confusion.
Six tools is well-scoped for a hot-content aggregation server covering two platforms. Each tool has a specific purpose and the count feels appropriate, not excessive or thin.
The server covers the essential operations for a hot content service: retrieving hot items, searching, and cache management for both Baidu and Bilibili. There are no obvious missing features for the stated purpose.
MCP server aggregating hot-search boards from 8 Chinese platforms (Weibo, Zhihu, Bilibili, Douyin).
Track Bilibili creators and get the latest updates on videos, dynamics, and articles. Fetch user p…
Trend data from Google, TikTok, Amazon, Reddit, YouTube, Steam, npm and more as JSON
YouTube transcripts, search, channel/playlist listings and upload tracking for AI agents.
