Realtime-News
Provides access to Baidu's hot search trending list (Baidu Hot List) and Baidu Tieba trending topics, enabling retrieval of real-time trending news and discussions.
Retrieves real-time trending content from Bilibili's hot list, providing access to popular videos and topics on the platform.
Accesses Juejin's (Xitu) trending articles and topics, providing real-time hot list data from the developer community platform.
Retrieves real-time trending content from Douyin (TikTok China) hot list, providing access to popular short-form videos and topics.
Accesses Zhihu's trending questions and discussions through the hot list, enabling retrieval of popular content from the Q&A platform.
Click on "Install 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., "@Realtime-Newsshow me the top 10 trending topics on Weibo right now"
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.
实时新闻 Realtime News
获取实时新闻热榜:微博热搜、百度热榜、知乎热榜、今日头条热榜、36氪热榜、腾讯新闻热榜、B站热榜、澎湃新闻热榜、虎扑步行街热榜、抖音热榜、IT资讯热榜、虎嗅热榜、百度贴吧热榜、稀土掘金热榜。 Obtain real-time news trending lists: Weibo Hot Search, Baidu Hot List, Zhihu Hot List, Jinri Toutiao Hot List, 36Kr Hot List, Tencent News Hot List, Bilibili Hot List, The Paper Hot List, Hupu Walking Street Hot List, TikTok Hot List, IT News Hot List, Huoxiu Hot List, Baidu Tieba Hot List, Juejin Hot List.## 工具列表 Tool List
本MCP服务封装下列工具,可让模型通过标准化接口调用以下功能。 本MCP服务封装下列工具,可让模型通过标准化接口调用以下功能。
工具 Tool | 描述 Description |
weibo_news | 实时数据/微博热搜 |
baidu_news | 实时数据/百度热榜 |
zhihu_news | 实时数据/知乎热榜 |
toutiao_news | 实时数据/今日头条热榜 |
36ke_news | 实时数据/36氪热榜 |
tx_news | 实时数据/腾讯新闻热榜 |
bli_news | 实时数据/B站热榜 |
sougou_news | 实时数据/搜狗热榜 |
sougou_a_news | 实时数据/搜狗热榜A |
pengpai_news | 实时数据/澎湃新闻热榜 |
hupu_news | 实时数据/虎扑步行街热榜 |
hupu_a_news | 实时数据/虎扑步行街热榜A |
douyin_news | 实时数据/抖音热榜 |
it_news | 实时数据/IT资讯热榜 |
huxiu_news | 实时数据/虎嗅热榜 |
baidu_tieba_news | 实时数据/百度贴吧热榜 |
xitu_news | 实时数据/稀土掘金热榜 |
检查服务 ## Inspector
工具在线测试: https://mcp.xiaobenyang.com/inspector/1804087353852938
Online Tool test https://mcp.xiaobenyang.com/inspector/1804087353852938
Related MCP server: What Happen MCP
服务配置 MCP Server Config
如何获取 XBY-APIKEY ? How to get XBY-APIKEY ?
访问小笨羊科技网站 https://xiaobenyang.com,注册用户即可获得APIKEY Visit XiaoBenYang website https://xiaobenyang.com, register and get the APIKEY.
SSE
{
"mcpServers": {
"实时新闻": {
"headers": {
"XBY-APIKEY": "<YOUR_XBY_APIKEY>"
},
"type": "sse",
"url": "https://mcp.xiaobenyang.com/1804087353852938/sse"
}
}
}STREAMABLE HTTP
{
"mcpServers": {
"实时新闻": {
"headers": {
"XBY-APIKEY": "<YOUR_XBY_APIKEY>"
},
"type": "streamable_http",
"url": "https://mcp.xiaobenyang.com/1804087353852938/mcp"
}
}
}STDIO
{
"mcpServers": {
"实时新闻": {
"command": "npx",
"args": [
"-y",
"xiaobenyang-mcp"
],
"env": {
"XBY_APIKEY": "<YOUR_XBY_APIKEY>",
"mcpId": "1804087353852938",
},
"transport": "stdio"
}
}
}
Available Tools
17 tools36ke_news36ke_newsC
实时数据/36氪热榜
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. '实时数据' implies real-time data fetching, but it doesn't disclose behavioral traits like rate limits, authentication needs, data freshness, or pagination. The description is too brief to provide meaningful context beyond the basic 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 concise (two Chinese terms) but under-specified rather than efficiently informative. It front-loads the source name but lacks actionable details. While brief, it fails to earn its place by not clarifying the tool's purpose or usage.
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 complexity (a news fetching tool among many siblings), no annotations, and no output schema, the description is incomplete. It doesn't explain what data is returned (e.g., headlines, links, timestamps) or how it differs from other news tools. For effective agent use, more context is needed.
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?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description doesn't need to explain parameters, and it doesn't add or contradict any parameter information. It appropriately avoids unnecessary details for a parameterless tool.
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 '实时数据/36氪热榜' is vague and tautological. It restates the tool name '36ke_news' in Chinese ('36氪热榜') and adds '实时数据' (real-time data), but doesn't specify what action the tool performs (e.g., fetch, list, retrieve). It doesn't distinguish from siblings like 'baidu_news' or 'zhihu_news' beyond the source name.
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 the 15 sibling news tools. The description doesn't indicate what makes '36氪热榜' unique (e.g., tech focus, trending topics) or suggest alternatives for different contexts. This leaves the agent with no basis for selection among similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
baidu_newsbaidu_newsC
实时数据/百度热榜
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions '实时数据' (real-time data), implying freshness, but doesn't disclose behavioral traits like rate limits, authentication needs, data format, or whether it's read-only. For a tool with no annotations, this leaves significant gaps in understanding how it behaves operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two Chinese phrases. It's front-loaded and wastes no words. However, it could benefit from slightly more structure (e.g., separating purpose from context) to improve clarity without losing efficiency.
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 complexity of news/trending data tools and no annotations or output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list format, data fields, update frequency), which is critical for an agent to use it correctly. With 16 similar siblings, more context is needed to differentiate and guide usage.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but with no parameters, the baseline is 4. It appropriately avoids unnecessary parameter details.
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 '实时数据/百度热榜' (real-time data/Baidu hot list) indicates the tool provides real-time data from Baidu's trending topics, which is a specific purpose. However, it doesn't clearly distinguish itself from sibling tools like 'baidu_tieba_news' or 'weibo_news' that also provide news/trending data from different platforms. The purpose is somewhat vague about what type of data or format is returned.
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. With 16 sibling tools, many offering news/trending data from different platforms (e.g., weibo_news, zhihu_news), the description offers no context about when Baidu's hot list would be preferred over other sources. There's no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
baidu_tieba_newsbaidu_tieba_newsB
实时数据/百度贴吧热榜
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states '实时数据' (real-time data), which implies freshness but doesn't disclose behavioral traits like rate limits, authentication needs, data format, or pagination. For a tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two Chinese phrases ('实时数据' and '百度贴吧热榜'), with zero wasted words. It's front-loaded with the key information (real-time data from Baidu Tieba hot list). Every element earns its place by specifying both the data type and source.
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 16 similar sibling tools, the description is incomplete. It doesn't explain what the tool returns (e.g., list format, fields included), how fresh the data is beyond 'real-time', or how it differs from other news-fetching tools. For a tool in this crowded context, more completeness is needed.
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 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter semantics, and it doesn't contradict the schema. Baseline 4 is appropriate for zero-parameter tools where the schema already indicates no inputs required.
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 fetches real-time data from Baidu Tieba's trending/hot list. It specifies the resource (Baidu Tieba hot list) and implies the action (fetch/retrieve). However, it doesn't explicitly distinguish from sibling tools like 'baidu_news' or 'weibo_news' beyond the platform name, missing 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any context, prerequisites, or exclusions. With 16 sibling tools all appearing to fetch news/trending data from different platforms, the agent receives no help in selecting the right tool for a given scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bli_newsbli_newsB
实时数据/B站热榜
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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. While '实时数据' implies fresh, current data, it doesn't specify update frequency, rate limits, authentication requirements, or what format the data returns. For a news tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two Chinese terms separated by a slash, making it front-loaded and efficient. Every element ('实时数据' and 'B站热榜') earns its place by specifying both the data type and source.
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 annotations and output schema, the description should provide more context about what data is returned, format, limitations, or typical use cases. As a news tool among many alternatives, it needs more differentiation and behavioral context to be complete enough for effective agent use.
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 with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema already fully documents this.
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站热榜' clearly states the tool provides real-time data from Bilibili's hot list, specifying both the resource (Bilibili hot list) and the data type (real-time). However, it doesn't explicitly distinguish this tool from its many sibling news tools beyond mentioning Bilibili specifically.
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 the 15 other news tools on the server. It doesn't mention alternatives, prerequisites, or specific use cases for Bilibili hot list data versus other news sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
douyin_newsdouyin_newsC
实时数据/抖音热榜
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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. The description mentions 'real-time data' which implies freshness and potential rate limits, but doesn't specify update frequency, authentication requirements, data format, or whether this is a read-only operation. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two Chinese characters and an English translation ('实时数据/抖音热榜'). Every element earns its place by specifying both the temporal aspect ('real-time') and the specific resource ('Douyin hot list'). No wasted words or unnecessary elaboration.
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 annotations, no output schema, and the tool's apparent purpose of providing trending data from a major platform, the description is incomplete. It doesn't specify what data is returned (e.g., list format, fields included), how current the data is, or any limitations. For a news/trending tool in a crowded sibling space, more context would be helpful.
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 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters since none exist. The baseline for 0 parameters is 4, as there's no need to compensate for missing parameter documentation.
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 '实时数据/抖音热榜' translates to 'real-time data/Douyin hot list', which indicates the tool provides real-time trending content from Douyin (the Chinese version of TikTok). This is a clear purpose statement with a specific resource (Douyin hot list), but it doesn't explicitly state the action verb (e.g., 'fetch', 'retrieve', 'get') or distinguish it from sibling tools that also provide news/trending content from other platforms.
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. With 16 sibling tools that appear to provide similar news/trending content from different platforms (e.g., weibo_news, zhihu_news), there's no indication of when Douyin-specific data is needed versus data from other Chinese social media platforms. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hupu_a_newshupu_a_newsC
实时数据/虎扑步行街热榜A
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions '实时数据' (real-time data) which implies freshness, but doesn't disclose behavioral traits like rate limits, authentication needs, data format, or whether this is a read-only operation. For a tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just two Chinese phrases separated by a slash. While efficient, it might be too terse given the lack of differentiation from sibling tools. Every word earns its place, but more structure could improve clarity.
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 complexity of news data tools and lack of both annotations and output schema, the description is incomplete. It doesn't explain what '热榜A' means, what data format to expect, or how this differs from other Hupu tools. For a tool in a crowded namespace, more context is needed.
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 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter information, but that's appropriate given the empty schema. Baseline for 0 parameters is 4.
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 '实时数据/虎扑步行街热榜A' states the tool provides real-time data from Hupu's '步行街' hot list A, which is a specific resource. However, it doesn't clearly distinguish from sibling tools like 'hupu_news'—the 'A' designation is ambiguous without explanation of what differentiates this from other Hupu news tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With multiple sibling tools including 'hupu_news', there's no indication of whether this tool provides different content, format, or scope. The description offers no context about use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hupu_newshupu_newsB
实时数据/虎扑步行街热榜
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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. While '实时数据' implies fresh, current data, it doesn't specify update frequency, rate limits, authentication requirements, or what format the data returns. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just two Chinese phrases separated by a slash. Every element ('实时数据' and '虎扑步行街热榜') directly contributes to understanding the tool's function without any wasted words. It's front-loaded with the most critical information.
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 annotations and output schema, the description is insufficiently complete. While it states what the tool provides, it doesn't explain the format of the returned data, any limitations or constraints, or how it differs from similar tools. For a data-fetching tool with no structured metadata, more context about the output would be valuable.
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 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. This meets the baseline expectation for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '实时数据/虎扑步行街热榜' clearly states the tool's purpose: providing real-time data from the Hupu Buxingjie hot list. It specifies both the resource (虎扑步行街热榜) and the type of data (实时数据), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'hupu_a_news', leaving room for confusion about the specific scope.
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. With multiple sibling tools including 'hupu_a_news' and other news sources, there's no indication of what makes this tool distinct or when it should be preferred over others. The user must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
huxiu_newshuxiu_newsC
实时数据/虎嗅热榜
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 mentions '实时数据' (real-time data), implying freshness and possible rate limits or update frequency, but doesn't specify details like authentication needs, data format, or any constraints. For a tool with zero annotation coverage, this is inadequate, as it lacks critical behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise ('实时数据/虎嗅热榜'), consisting of a short phrase that front-loads key info (real-time data, Huxiu hot list). It earns its place by conveying the core purpose efficiently, though it could be slightly more structured (e.g., separating concepts). No waste, so it scores high.
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 complexity (a news data tool with real-time aspects), no annotations, no output schema, and 0 parameters, the description is incomplete. It doesn't explain what the output includes (e.g., article titles, links, rankings) or behavioral details, leaving significant gaps for an agent to use it effectively. This falls short of being adequately 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 tool has 0 parameters with 100% schema description coverage, so no parameters need documentation. The description doesn't add param info, but with zero params, the baseline is 4, as there's nothing to compensate for. This is appropriate given the lack of inputs.
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 the tool provides real-time data from Huxiu's hot list, which gives a vague purpose (verb+resource). However, it doesn't clearly differentiate from siblings like '36ke_news' or 'zhihu_news' beyond the source name, lacking specificity about what 'hot list' entails (e.g., trending articles, rankings). This meets the minimum viable level but has gaps in clarity.
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. The description doesn't mention any context, exclusions, or comparisons to sibling tools (e.g., use for Huxiu-specific content vs. other news sources). This leaves the agent without direction on selection, scoring low as it offers no usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
it_newsit_newsC
实时数据/IT资讯热榜
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 mentions '实时数据' (real-time data) and '热榜' (hot list), hinting at dynamic, trending content, but fails to disclose critical behaviors such as data freshness, rate limits, authentication needs, or output format. The description is too brief to provide meaningful behavioral context beyond a basic category.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('实时数据/IT资讯热榜'), but this brevity leads to under-specification rather than efficiency. It is front-loaded with the key terms, but the single phrase fails to provide adequate information, making it feel incomplete rather than optimally structured.
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 complexity implied by real-time data and hot lists, along with no annotations and no output schema, the description is insufficient. It does not explain what the tool returns, how the data is sourced or ranked, or any operational constraints. For a tool that likely involves dynamic data fetching, more context is needed to be 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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter semantics, but this is acceptable given the lack of parameters. A baseline score of 4 is appropriate as the description does not need to compensate for any parameter gaps.
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 '实时数据/IT资讯热榜' is vague and tautological. It restates the tool name 'it_news' in Chinese ('IT资讯热榜' means 'IT news hot list'), providing only a general category without specifying what action the tool performs (e.g., 'fetch', 'list', 'search'). It does not clearly distinguish from sibling tools like 'zhihu_news' or 'weibo_news' beyond the 'IT' focus.
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. With 16 sibling tools all appearing to be news-related (e.g., 'zhihu_news', 'weibo_news'), there is no indication of what makes 'it_news' unique—whether it's for real-time IT news, specific sources, or other contexts. No explicit or implied usage instructions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pengpai_newspengpai_newsB
实时数据/澎湃新闻热榜
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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. '实时数据' (real-time data) suggests fresh, frequently updated content, but doesn't specify update frequency, rate limits, authentication requirements, or what format the data returns. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 7 characters (in Chinese), containing only the essential information: real-time data and the specific news source. There's zero wasted text, and it's front-loaded with the most important information.
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 annotations and output schema, the description is insufficiently complete. While concise, it doesn't explain what '热榜' (hot rankings) contains, how the data is structured, whether it's paginated, or what format it returns. For a news data tool among 16 similar siblings, more context about what makes Pengpai News unique would be helpful.
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 with 100% schema description coverage, so the schema already fully documents the input requirements. The description appropriately doesn't discuss parameters since none exist. A baseline of 4 is appropriate for zero-parameter tools where the schema handles all documentation.
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 provides real-time data from Pengpai News hot rankings. It specifies the resource (Pengpai News hot rankings) and implies the verb 'fetch' or 'retrieve'. However, it doesn't explicitly distinguish itself from sibling tools like 'baidu_news' or 'weibo_news' beyond the source name.
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 the 16 sibling news tools. It doesn't mention any specific use cases, prerequisites, or alternatives. The only implied context is needing Pengpai News data, but no differentiation from other news sources is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sougou_a_newssougou_a_newsC
实时数据/搜狗热榜A
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 mentions 'real-time data' which implies freshness but doesn't disclose behavioral traits like rate limits, authentication needs, data format, or whether it's read-only. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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 very short ('实时数据/搜狗热榜A'), which is concise but under-specified rather than efficiently informative. It's front-loaded but lacks substance, making it more of a label than a helpful description, so it doesn't fully earn its place as a standalone tool explanation.
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 complexity of news data tools and no annotations or output schema, the description is incomplete. It doesn't explain what 'hot list A' entails, the return format, data scope, or how it differs from other tools. For a tool in a crowded sibling set with no structured support, more context is needed to be adequately 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 tool has 0 parameters with 100% schema description coverage, so no parameter information is needed. The description doesn't add any parameter details, which is appropriate here. Baseline is 4 since no parameters exist, and the description doesn't need to compensate for any schema gaps.
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 '实时数据/搜狗热榜A' states it provides real-time data from Sogou's hot list A, which gives a basic purpose but is vague about what 'hot list A' specifically means. It doesn't clearly distinguish from sibling tools like 'sougou_news' (no suffix) or other news tools, making it a tautology that mostly restates the tool name with minimal added clarity.
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. With 16 sibling tools including 'sougou_news' and various other news sources, the description lacks any context about why to choose Sogou's hot list A over other news tools or what specific scenarios it's suited for, offering no usage differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sougou_newssougou_newsC
实时数据/搜狗热榜
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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. The description '实时数据/搜狗热榜' only mentions the type of data (real-time, hot list) but doesn't describe any behavioral traits such as whether it's a read-only operation, potential rate limits, authentication needs, or what the output looks like. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description '实时数据/搜狗热榜' is very concise (two Chinese phrases), but it's under-specified rather than efficiently informative. It lacks a clear verb or action, making it feel incomplete rather than well-structured. While brief, it doesn't front-load key information effectively, earning a mediocre score.
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 complexity (a news-fetching tool with no parameters but likely returning data), the description is incomplete. No annotations are provided, and there's no output schema, so the description should explain more about what the tool returns (e.g., list of headlines, timestamps, links). The phrase '实时数据/搜狗热榜' is too vague to provide adequate context for an agent to understand the tool's full scope.
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 0 parameters, and schema description coverage is 100%, so there's no need for the description to explain parameters. The baseline for 0 parameters is 4, as the description doesn't need to compensate for any missing param info. The description doesn't add parameter semantics, but that's acceptable given the lack of parameters.
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 '实时数据/搜狗热榜' translates to 'real-time data/Sogou hot list' which restates the tool name 'sougou_news' rather than specifying what the tool does. It doesn't clearly state a verb+resource action like 'retrieve' or 'fetch', and while it hints at providing hot news from Sogou, it's vague about the actual function. This is essentially a tautology that doesn't distinguish from sibling tools beyond the source name.
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. With 16 sibling tools (e.g., baidu_news, weibo_news, zhihu_news) that likely serve similar news-fetching purposes, there's no indication of when Sogou news is preferred, what context it applies to, or any exclusions. This leaves the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
toutiao_newstoutiao_newsB
实时数据/今日头条热榜
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 mentions 'real-time data' which implies freshness, but doesn't describe rate limits, authentication needs, data format, update frequency, or what 'hot list' specifically means. The behavioral characteristics are largely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two Chinese phrases separated by a slash. Every element earns its place - '实时数据' (real-time data) and '今日头条热榜' (Toutiao hot list) both contribute essential information with zero waste.
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 15 similar sibling tools, the description is incomplete. It doesn't explain what format the hot list returns, how results are structured, what time period 'real-time' covers, or how this differs from other news tools. For a tool in a crowded namespace, more context is needed.
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?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description doesn't need to explain parameters since there are none, and the schema fully documents the empty input structure.
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 what the tool does (provides real-time data/Toutiao hot list) with specific verb+resource. However, it doesn't distinguish from sibling tools that likely provide similar news/hot list functionality from different platforms, so it's not fully differentiated.
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 the 15 sibling news tools. There's no mention of alternatives, exclusions, or specific contexts where Toutiao news would be preferred over other sources like Weibo, Zhihu, or Baidu.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tx_newstx_newsC
实时数据/腾讯新闻热榜
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 mentions '实时数据' (real-time data), implying freshness and possibly frequent updates, but doesn't cover critical aspects like rate limits, authentication needs, data format, or whether it's read-only or mutative. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just a short phrase—and front-loaded with the core purpose. Every word earns its place by specifying the data source and type, with no wasted text. This is ideal for a simple, parameterless 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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal but incomplete. It lacks details on behavior, output format, or usage context, which are needed for the agent to understand how to invoke it effectively. While concise, it doesn't provide enough completeness for reliable tool use.
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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, which is appropriate here. Baseline is 4 for zero parameters, as it avoids unnecessary details.
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 the tool provides '实时数据/腾讯新闻热榜' (real-time data/Tencent News hot list), which indicates it fetches trending news from Tencent. However, it's somewhat vague about the exact operation (e.g., whether it lists, searches, or streams news) and doesn't explicitly differentiate from siblings like 'weibo_news' or 'toutiao_news' beyond the source. It avoids tautology by not just restating the name/title.
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. The description doesn't mention any context, exclusions, or comparisons to sibling tools (e.g., use for Tencent-specific news vs. other platforms). This leaves the agent without explicit direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
weibo_newsweibo_newsC
实时数据/微博热搜
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions '实时数据' (real-time data), hinting at freshness, but doesn't disclose critical behaviors like rate limits, authentication needs, data format, or whether it's read-only. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two Chinese terms, making it front-loaded and waste-free. However, the brevity might border on under-specification for non-Chinese agents, slightly reducing clarity. Every term earns its place by indicating data type and source.
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 complexity (real-time data tool with no annotations or output schema), the description is incomplete. It lacks details on return values, error handling, or behavioral constraints. While it states the purpose, it doesn't provide enough context for reliable agent invocation without trial and error.
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 0 parameters, and schema description coverage is 100% (empty schema). The description doesn't need to explain parameters, so it meets the baseline of 4 for zero-parameter tools. No additional parameter semantics are required or provided.
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 the tool provides real-time data about Weibo hot searches, which is a clear purpose. However, it doesn't specify a verb (e.g., 'fetch' or 'retrieve') and doesn't distinguish itself from sibling tools that also provide news/trends from different platforms. The Chinese text might be less accessible to some agents.
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 the 15 sibling tools (e.g., baidu_news, zhihu_news). The description implies it's for Weibo-specific data, but there's no explicit comparison or exclusion criteria. Agents must infer usage based on the platform name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xitu_newsxitu_newsB
实时数据/稀土掘金热榜
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 mentions '实时数据' (real-time data), implying freshness, but doesn't disclose behavioral traits like rate limits, authentication needs, response format, or whether it's read-only. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just two Chinese phrases—and front-loaded with the essential information. Every word earns its place by specifying the data type and source without any 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 lack of annotations and output schema, the description is incomplete. It identifies the data source but doesn't explain what the output contains (e.g., list format, fields), how often it updates, or any usage constraints. For a tool with no structured support, more context is needed to be fully helpful.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is given since no parameters exist and the schema fully covers this.
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: it provides real-time data from the Juejin (稀土掘金) hot list. The verb '实时数据' (real-time data) and resource '稀土掘金热榜' (Juejin hot list) are specific, though it doesn't explicitly differentiate from sibling tools that also provide news/trend data from other platforms.
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. With 16 sibling tools for various news sources (e.g., weibo_news, zhihu_news), there is no indication that this tool is specifically for Juejin content versus other platforms, nor any context about when Juejin data would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zhihu_newszhihu_newsC
实时数据/知乎热榜
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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. '实时数据' (real-time data) suggests freshness but doesn't specify update frequency, rate limits, or data format. '知乎热榜' (Zhihu hot list) indicates content type but doesn't describe what 'hot' means (views, upvotes, comments) or how results are structured. No authentication requirements or potential side effects are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two Chinese phrases. While brief, it's front-loaded with the essential information - real-time data from Zhihu's trending content. There's no wasted space, though some might argue it's too terse for a tool with no annotations or output schema to provide additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and zero parameters, the description should provide more complete context. While it states what platform and type of data, it doesn't describe the return format, data freshness guarantees, sorting methodology, or any limitations. For a tool in a crowded namespace with 15 similar siblings, more differentiation would be helpful.
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 with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist. The schema fully documents the empty parameter set, and the description correctly focuses on the tool's purpose rather than non-existent parameters.
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 '实时数据/知乎热榜' translates to 'real-time data/Zhihu hot list' which indicates it provides trending content from Zhihu. However, it's somewhat vague about the exact operation - it doesn't specify if this fetches, lists, or streams the data. The description distinguishes from siblings by specifying the Zhihu platform, but lacks a clear action verb.
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 the 15 other news/social media tools in the sibling list. There's no indication of what makes Zhihu data unique, when it's most relevant, or any prerequisites for usage. The user must infer usage from the platform name alone.
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. Dates show when Glama detected each change.
17 tool updates
v1.0.0- First observed
36ke_news - First observed
baidu_news - First observed
baidu_tieba_news - First observed
bli_news - First observed
douyin_news - First observed
hupu_a_news - First observed
hupu_news - First observed
huxiu_news - First observed
it_news - First observed
pengpai_news - First observed
sougou_a_news - First observed
sougou_news - First observed
toutiao_news - First observed
tx_news - First observed
weibo_news - First observed
xitu_news - First observed
zhihu_news
TDQS
Every tool has a clearly distinct purpose targeting a specific news source or platform (e.g., weibo_news for Weibo, zhihu_news for Zhihu). There is no overlap in functionality as each tool fetches real-time trending news from a unique source, making tool selection straightforward and unambiguous.
Tool names follow a highly consistent pattern throughout, using a source_news format (e.g., baidu_news, douyin_news). This predictable naming convention makes it easy for agents to understand and navigate the tool set without confusion or inconsistency.
With 17 tools, the count is slightly high but reasonable for the server's purpose of aggregating real-time news from multiple platforms. Each tool serves a distinct source, so the number aligns well with the scope, though it might feel heavy compared to simpler servers.
The tool set provides comprehensive coverage for fetching real-time trending news from a wide range of Chinese and tech-related platforms. There are no obvious gaps in the surface, as it includes major sources like Weibo, Zhihu, Baidu, and niche ones like Hupu and Xitu, ensuring agents can access diverse news feeds.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server aggregating hot-search boards from 8 Chinese platforms (Weibo, Zhihu, Bilibili, Douyin).
21Real-time news and trending topics from major sources
Weibo hot search, post search/details, comments/replies, users, posts, transcript.
Trend data from Google, TikTok, Amazon, Reddit, YouTube, Steam, npm and more as JSON
Related MCP Servers
- AlicenseBqualityFmaintenanceOne-stop aggregation service of hot trends across the entire network based on the Model Context Protocol (MCP) protocol, supporting real-time updates and multi-data source expansion.212Apache 2.0
- FlicenseNot gradedqualityNot gradedmaintenanceAggregates news from 70+ platforms across categories like tech, finance, social, entertainment, and sports. Provides access to trending topics from popular Chinese platforms including Weibo, GitHub, Zhihu, Baidu, and Bilibili.122-
- AlicenseBqualityDmaintenanceProvides real-time hot trending topics and heat indices from nine major Chinese social media and news platforms including Weibo, Zhihu, and Bilibili. It enables users to fetch markdown-formatted news summaries and clickable links via the get_hot_news tool.11,7063MIT
- AlicenseAqualityBmaintenanceA real-time news and hot spot aggregation server that monitors multiple platforms like Weibo, Zhihu, and Bilibili. It enables AI assistants to fetch, filter, and analyze trending topics through the Model Context Protocol for personalized information tracking.131GPL 3.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/xiaobenyang-com/1804087353852938'
If you have feedback or need assistance with the MCP directory API, please join our Discord server