trendradar-mcp

Server Quality Checklist

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

Latest release: v6.10.0
Disambiguation3/5
There is noticeable overlap between search_news (which can also search RSS) and search_rss, as well as between get_latest_news, get_news_by_date, and get_latest_rss. The analysis tools also share similar territory, but their descriptions are detailed enough that an agent can usually resolve the intent.
Naming Consistency4/5
Tool names mostly follow a consistent lowercase verb_noun pattern such as get_, search_, analyze_, and read_. The heavy use of the generic get_ prefix and some asymmetries like get_latest_news vs get_news_by_date reduce perfect predictability, but there is no mixed casing or chaotic verb usage.
Tool Count2/5
At 27 tools, the server exceeds the 25-tool threshold and spans crawling, storage, retrieval, analysis, article reading, notifications, and system administration. Several near-duplicate pairs such as search_news/search_rss, read_article/read_articles_batch, and get_latest_news/get_news_by_date make the surface feel over-scoped for a focused MCP.
Completeness4/5
The server covers a broad news-monitoring workflow: ingestion, data availability checks, retrieval, analysis, reporting, and notification. Minor gaps exist, such as no dedicated platform/feed listing tool and no configuration editing, but these can be worked around using the existing status and search tools.
Average 4.2/5 across 26 of 27 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 20 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It indicates a read-only operation through '获取' and '返回', and lists what data is returned. However, it does not explicitly state that the operation is non-destructive, or disclose any side effects, auth requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but somewhat repetitive: '返回系统版本、数据统计、缓存状态等信息' and 'Returns: JSON格式的系统状态信息' overlap. Given that an output schema exists, the final 'Returns' line adds marginal value and could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple parameterless status tool with an output schema, and the description covers what the status includes and the return format. However, it lacks guidance on how this tool relates to overlapping siblings and does not compensate for the absence of annotations with additional behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and schema coverage is 100%, so no parameter documentation is needed. The description adds no parameter semantics, but the baseline for a parameterless tool is 4, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: '获取系统运行状态和健康检查信息' (get system running status and health check info) and lists concrete contents (system version, data statistics, cache status). This is clear, though it does not explicitly differentiate itself from siblings like get_storage_status or check_version beyond the broad scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the many related siblings such as get_rss_feeds_status, get_storage_status, get_current_config, or check_version. The description implies general system status retrieval but provides no conditions, exclusions, or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose that the tool reads config.yaml and .env and returns a JSON status with configuration source, which is useful. However, it does not explicitly state that the operation is read-only, makes no external calls, or sends no notifications, which would be valuable given the sibling send_notification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and key details are front-loaded, with the Returns and Examples sections adding clarity without excessive verbosity. Listing nine channels is necessary context, and the structure is easy to scan. Minor redundancy exists because the return format is already captured by the output schema, but it does not hurt usability.
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?
The description covers what the tool returns, which config files are inspected, the list of supported channels, and a usage example. Since the tool has no parameters and an output schema exists, this is nearly complete. The main missing element is explicit guidance about how this tool relates to sibling notification tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and 100% schema coverage, so there is no parameter detail for the description to add. The description includes an example invocation `get_notification_channels()` that confirms no arguments are required, satisfying the baseline for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: “获取所有已配置的通知渠道及其状态” (get all configured notification channels and their status). It further clarifies scope by listing 9 supported channels and the config sources checked. It does not explicitly differentiate from sibling tools like get_channel_format_guide, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage context by mentioning config.yaml and .env detection, but it never states when to use this tool versus alternatives such as send_notification or get_channel_format_guide. There are no explicit exclusions or conditions that would help an agent decide between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It clearly indicates a read-only 'get' operation and mentions the JSON return format, but does not address potential authentication requirements, whether the config reflects live or cached state, or any other side effects. Sufficient for a simple getter, but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a front-loaded purpose and clear Args/Returns sections. It contains no fluff, though it slightly repeats the default value already present in the schema.
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 simple tool with one optional parameter and an output schema, the description is nearly complete. It documents all section choices and the return type. The only minor gap is not clarifying what 'current' means (e.g., live system state vs. persisted config), but this is not critical for a config getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides a default value and type for `section`, while the description adds all valid values: 'all', 'crawler', 'push', 'keywords', and 'weights'. Since schema description coverage is 0%, this description fully compensates by giving the agent the exact enumeration needed to call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current system configuration, with a specific resource (config) and verb (获取/get). It lists distinct config sections, which helps differentiate it from siblings like get_system_status or get_storage_status, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the `section` parameter and its allowed values, but it does not provide guidance on when to use this tool versus the many sibling tools. No exclusions or alternative tool references are given, leaving usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that results are returned as JSON and describes analysis modes, but it never clarifies whether the tool is read-only, whether it triggers expensive computation, whether it depends on external data sources, or whether any state is changed. This leaves a meaningful transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized with an intro, Args, Returns, and Examples sections. Every line adds value: mode definitions, parameter constraints, and concrete usage examples are all present without redundant filler. It is long enough to be useful and compact enough to scan quickly.
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 tool with three modes, conditional parameters, and subtle date_range typing, the description covers the essential invocation knowledge: which parameters apply to which mode, defaults, formats, and example calls. It does not explicitly explain what happens when irrelevant parameters are passed or describe error cases, but an output schema exists and the provided information is sufficient for basic correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides rich semantics for all five parameters: allowed insight_type values with mode meanings, optional topic, strict date_range object format with example and a warning against integers, plus defaults for min_frequency and top_n. This is exactly what an agent needs to construct valid calls and goes far beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies an analysis tool for multiple data insight modes, enumerating three specific insight types with plain-language explanations. It does not explicitly differentiate itself from overlapping sibling tools like analyze_topic_trend or analyze_sentiment, so it misses a bit of sibling-targeted clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description shows when to use each mode through the insight_type options and concrete examples, but it never states when not to use the tool or which alternative sibling covers a similar case. Usage guidance is implied rather than explicit, especially given the large sibling set with analysis-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds useful details: the output is JSON containing Markdown, and date_range must be an object rather than an integer. It does not disclose side effects, permissions, or any processing limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: a one-line purpose, then Args with clear formatting, then Returns. Every line adds value, and the object-format warning is high-signal.
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 tool with only two optional parameters and an output schema, it covers parameter formats and the return shape well. The main omissions are when-to-use guidance and side-effect/permission hints, which would make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema is under-specified: report_type is a plain string and date_range is a loose anyOf. The description compensates strongly by defining report_type values as daily/weekly and giving the exact date_range object format, an example, and a warning against passing integers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it generates daily/weekly hotspot summary reports. The daily/weekly scope is concrete, though it does not explicitly distinguish itself from sibling analysis tools like analyze_topic_trend or aggregate_news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool instead of siblings such as analyze_data_insights or aggregate_news. It only lists parameter values, not use conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses return format, default limit, platform handling, include_url token-saving behavior, and explicit display expectations for the agent. It does not cover error behavior or data freshness guarantees, but the read-only nature is clear from the get verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and display guidance sections. The main purpose is front-loaded, and each section earns its place, though the display-suggestion block is slightly beyond tool invocation semantics.
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 simple read tool with three optional parameters and an output schema, the description is largely complete: it covers parameter behavior, defaults, return format, and agent-facing display policy. It could still mention ordering of results or what news fields are returned, but the output schema likely covers those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by explaining all three parameters: platforms, limit with default and max, and include_url with its token-saving rationale. This is exactly the semantic content the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: it fetches the latest batch of crawled news data to quickly understand current hotspots. It is distinguishable from siblings like get_latest_rss and get_news_by_date, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as search_news, get_news_by_date, or get_trending_topics. The only usage-related context is the display suggestion block, which addresses how to present results rather than when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the behavioral disclosure burden. It discloses that the tool reads local/remote storage, can compare both, and returns JSON date lists, which is adequate for a non-destructive listing tool. However, it does not mention date format, empty-result behavior, or network/error implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured with summary, Args, Returns, and Examples sections, making it easy to scan. There is minor redundancy between '列出本地/远程可用的日期范围' and '查看本地和远程存储中有哪些日期的数据可用', but no wasteful content.
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 tool with one optional parameter and no required fields, the description covers purpose, source values, return shape, and examples; an output schema also exists. It could add exact date range format or behavior when no data is available, but nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only says source is a string with default 'both' and has 0% description coverage. The description compensates by enumerating valid values local/remote/both, stating the default, and giving examples. There is no ambiguity about how to use the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first line names a specific operation (列出) and resource (local/remote available date ranges), and the description expands on distinct scopes. It stands apart from siblings like get_news_by_date or resolve_date_range because it focuses on availability of dates in storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the source parameter and what each value does, but it does not explicitly state when to use this tool instead of siblings such as resolve_date_range or get_news_by_date. Usage is implied through '查看本地和远程存储中有哪些日期的数据可用', but no exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无任何注释，描述需承担行为披露责任。描述说明了去重合并行为、返回内容包含去重统计和平台覆盖统计，但未提及是否有副作用（如触发抓取）、是否需要提前抓取数据、是否有速率限制等。对于只读聚合工具，基本行为已透明，但缺少额外细节。
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?
描述以标题、Args、Returns、Examples分节，结构清晰，每个句子都有信息量，没有冗余。参数说明采用列表形式，并给出两个示例调用，简洁易读。
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?
所有参数均有解释，返回结构有概述，且有示例。存在输出schema，因此无需详述返回字段。唯一小缺失是date_range的具体格式（允许字符串或对象但未举例），但整体信息足够代理正确调用。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入schema的覆盖率为0%，但描述对所有5个参数都做了详细说明，包括类型、默认值、示例和含义（如similarity_threshold范围0.3-1.0，include_url控制是否包含链接）。描述完全补偿了schema的缺失，参数语义非常清晰。
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?
描述以明确的动词'聚合'和资源'新闻'开头，说明将相似新闻去重合并，并显示跨平台覆盖和综合热度。与兄弟工具如search_news、get_latest_news相比，功能边界清晰，可直接区分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述通过功能说明隐含了使用场景（跨平台新闻去重聚合），但未明确说明何时应使用此工具而非其他工具（如search_news或find_related_news），也没有给出排除条件。缺乏显式的when/when-not指引。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the JSON return format, the default date range, and mode-specific parameter behavior (viral thresholds, prediction lookahead, confidence). It does not mention rate limits, auth, or side effects, but for an analysis tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a title line, a usage tip, a compact Args block, Returns, and Examples. Every section adds value and the format is easy for an agent to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, 0% schema description coverage, no annotations, and an output schema, the description is largely complete: it explains parameter semantics, defaults, mode-specific options, and gives examples. Minor gaps remain, such as valid granularity values and explicit sibling-tool selection guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description documents every parameter: topic as required, analysis_type with its four accepted values, date_range format, granularity, spike_threshold, time_window, lookahead_hours, and confidence_threshold. It fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies it as a topic-trend analysis tool ('统一话题趋势分析工具') and enumerates four analysis modes. It states a specific verb and resource, but it does not explicitly contrast it with sibling analysis tools like analyze_data_insights or analyze_sentiment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives one practical workflow hint: call resolve_date_range for natural-language dates. However, it does not say when to prefer this tool over its analysis siblings or when not to use it, so the usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description conveys that this is a read-only status view through '查看' and details of generated statistics. However, it does not explicitly state side-effect-free behavior, whether data is cached, or how it behaves when no feeds exist, so the burden is only partially met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured and front-loaded with purpose, followed by a compact Returns list and an example. The opening line '获取 RSS 源状态信息' is mildly redundant with the name and second sentence, but overall there is no wasted bulk.
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 no-parameter status tool, the description is largely complete: it states scope, return structure, and an example invocation. It could be more complete by explicitly distinguishing when to use this over sibling tools like get_system_status or list_available_dates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the example get_rss_feeds_status() confirms no arguments are required. With schema coverage at 100% and no params, the description adds no parameter semantics but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('获取/查看') and a specific resource (RSS feeds status and their data statistics), and the Returns section defines exactly what is included. It differentiates from siblings like get_system_status/get_storage_status by scoping to configured RSS sources and their stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: use this to view currently configured RSS sources and their data statistics. It does not explicitly name alternative tools or provide when-not-to-use conditions, but the context is specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注释提供，描述承担了行为披露的负担。描述了返回内容和格式（JSON状态信息），但未明确说明操作是否只读、是否会触发副作用或需要权限。不过“查看”和“获取”暗示了非破坏性，基本行为是清晰的。
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?
描述简洁高效，第一句即点明核心功能，随后补充返回内容，每句话都有价值，没有冗余信息。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具无参数、有输出模式，描述已涵盖返回格式和主要内容。对于这种简单查询工具，没有遗漏关键信息，描述足以让代理正确调用。
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?
该工具没有参数，输入模式为空，因此描述无需补充参数语义。根据规则，0参数时基线得分为4。
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?
描述明确使用了具体动词“获取/查看”，资源是“存储配置和状态”，并具体说明包含本地/远程存储状态和拉取配置。与兄弟工具如get_rss_feeds_status、get_system_status在名称和描述上都能清晰区分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述隐含了用途（查看存储状态），但没有明确说明何时使用此工具而非其他工具，也没有提及替代方案或排除条件。虽然功能自明，但缺少显式的使用情境指导。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It explains that the tool returns JSON with hot searches and optional RSS results, and describes search modes and filtering. It does not disclose potential side effects, rate limits, or result ordering behavior beyond the sort_by parameter, so coverage is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: a purpose statement, a cross-tool suggestion, a parameter reference, return description, and examples. Every section adds value, and the structure makes the long parameter list scannable.
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?
The tool is complex with 10 parameters, but the description covers parameters, defaults, modes, and examples, while an output schema exists for return values. The only meaningful gap is the lack of explicit guidance on when to choose this tool versus closely related sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description fully compensates with a detailed Args block explaining every parameter, including search_mode variants, threshold semantics, date_range format, and default values. This goes well beyond the schema and gives agents actionable parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a unified search interface that searches both hot lists and RSS, with multiple search modes. It is distinguishable from siblings like search_rss and get_latest_news, though it does not explicitly name them or contrast itself against them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage suggestion to call resolve_date_range for natural language dates, which gives useful cross-tool guidance. However, it does not explicitly state when to prefer this over sibling tools such as search_rss or get_trending_topics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It covers feed scoping behavior, default and maximum days, limit default, include_summary default, and the JSON return format. It does not mention sorting, matching semantics, or error behavior, but these are relatively minor for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, an Args block, Returns, and Examples. Every section earns its place, there is no filler, and the most important scoping information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter search tool with no annotations, the description covers parameter semantics, defaults, return type, and provides two concrete invocation examples. It omits details like valid feed identifiers and sort order, but these are largely discoverable from sibling tools and do not prevent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description fully compensates by explaining every parameter: keyword is required, feeds has an example and default behavior, days has default/max, limit has default, and include_summary has default. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: searching RSS subscription data for articles containing a keyword. It is unambiguous about the resource (RSS 订阅数据) but does not explicitly distinguish itself from sibling tools like search_news or get_latest_rss, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful behavioral context such as 'search all RSS feeds when feeds is not specified' and includes examples, which imply typical usage. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, leaving some routing decisions to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by revealing meaningful behaviors: default date range is today, limit defaults to 50 and max 100, titles are deduplicated, platforms default to all, sorting defaults by heat weight, and include_url defaults to false to save tokens. It does not mention error cases or data-freshness limitations, but for a read-style analysis tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured and front-loaded: purpose, routing advice, parameter list, return summary, and example. It contains no filler or redundant explanation, and every section serves a practical purpose. The format makes it easy for an agent to scan and extract the needed information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no annotations, and an output schema, the description is largely complete: all parameters are documented, return contents are summarized, an example is provided, and sibling routing is mentioned. The output schema exists, so detailed return fields do not need to be enumerated. The main missing element is clearer guidance on when to choose this tool over sibling analysis tools, and the available platform IDs are not listed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully document the parameters, and it does. Every argument is explained with concrete details: date_range gets an explicit JSON format, platforms gets a realistic example, limit gets a maximum and deduplication note, and boolean flags get their default behavior. This fully compensates for the schema's lack of descriptive text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: analyze news sentiment and heat trends (分析新闻的情感倾向和热度趋势). It names a specific action and resource, and the parameter list clarifies that it works on a topic/platform/date range. However, it does not explicitly distinguish itself from similar sibling tools like analyze_topic_trend or analyze_data_insights, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit routing suggestion: if using natural-language dates, call resolve_date_range first. This is direct, actionable guidance for a specific alternative. It does not, however, discuss when this tool should be preferred over the other analysis-oriented siblings, so the usage guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It transparently explains date_range formats, platform filtering behavior, limit maximums, and the include_url token-saving default. It does not mention error handling, rate limits, or authentication, but the read-only nature of 'fetch' is clear and the parameter behaviors are well documented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise purpose sentence followed by a clean Args/Returns breakdown. Every argument is explained with practical examples and defaults, with no filler or redundant content.
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?
The tool has four optional parameters and an output schema, and the description covers all parameters, defaults, and return fields. It lacks edge-case details such as empty-result behavior or timezone handling, but for a read-only historical query tool, the description provides enough for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate for parameter semantics. It does this excellently: date_range has multiple explicit format examples, platforms has an example list, limit has default and max values, and include_url states its default and rationale. This is more informative than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool fetches news data for a specified date range for historical analysis and comparison. This is a specific verb+resource pair that distinguishes it from get_latest_news, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: historical data analysis and comparison. It implies this tool is for date-bound queries rather than real-time or keyword searches, but it does not explicitly state when to prefer alternatives like get_latest_news or search_news.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden and does a good job: it reveals that this is a manual/mutating crawl action, that persistence is optional via save_to_local, that include_url=False saves tokens, and that the return is JSON task status with success/failure platform lists. It does not cover rate limits, duration, or whether the crawl may overwrite existing data, but it provides materially more than a bare mutation label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line summary, labeled Args with defaults/meaning, a Returns note, and two concrete examples. No redundant filler appears, and the key scoping behavior (default all platforms) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter tool with an output schema and clear examples, the description covers invocation, defaults, and return shape sufficiently. It could be even more complete by noting whether the crawl runs synchronously/asynchronously and how invalid platform IDs are handled, but nothing an agent strictly needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must document parameters, and it does: platforms is explained with domain examples and a default ('use all platforms'), save_to_local is tied to the output directory, and include_url is explained with a token-saving rationale. This adds real semantic meaning beyond the raw JSON schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line states a specific verb and resource: '手动触发一次爬取任务' (manually trigger a crawl task), with optional persistence. This clearly identifies it as the direct crawl-trigger action and distinguishes it from the read/analysis tools among its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining default behavior (all platforms when platforms is unspecified) and providing two examples, but it never explicitly says when to choose this tool over alternatives. No exclusions or 'use X instead' guidance is given, though the manual-trigger wording makes the basic intent reasonably inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool compares local and GitHub remote versions, checks both TrendRadar and MCP Server, supports an optional proxy for GitHub access, and returns JSON with comparison and update-needed status. This is reasonably transparent, though it does not explicitly state side-effect-free behavior or network failure characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Purpose, Args, Returns, and Examples sections. It is compact, front-loaded with the main purpose, and every section contributes useful information without padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema available, the description is complete enough to invoke correctly. It explains the return format, the optional argument, and provides two concrete call examples. Nothing essential is missing for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. The Args section fully explains proxy_url as an optional proxy URL to access GitHub, provides a concrete example, and the schema supplies the default null. This adds clear meaning beyond the bare type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: it checks version updates by comparing local versions with GitHub remote versions, covering both TrendRadar and MCP Server. This makes it immediately distinguishable from sibling tools like sync_from_remote or get_system_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the purpose and examples, but the description does not explicitly state when to prefer this tool over alternatives or when not to use it. There is no mention of sibling tools or exclusion cases, so guidance is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and covers defaults (date_range, limit, include_url), the semantics of threshold, and that results are sorted by similarity. It does not mention failure or edge-case behavior, but the disclosed defaults and return behavior are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with clear Args/Returns/Examples sections, uses short bullet-style entries, and includes two practical examples. Every line adds value and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter tool with no annotations, the description is complete: all parameters, return format, sorting behavior, and sample calls are provided. Given an output schema also exists, no critical calling information appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by explaining every parameter: reference_title, date_range variants, threshold scale and default, limit, and include_url token-saving purpose. This exceeds the structured schema, which only provides types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and resource ('查找与指定新闻标题相关的其他新闻') and clarifies it covers today and historical data. It distinguishes itself from generic search in the sibling list by emphasizing relatedness to a reference title, though it does not explicitly name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: unspecified date means today, presets and custom ranges are available, and threshold controls strictness. It does not explicitly state when not to use this tool or compare it with search_news, but the related-news framing implies the intended scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the two extraction modes, references the config/frequency_words.txt source, and states that the return is a JSON frequency list. It does not discuss side effects, but for a getter-style statistics tool the disclosed behavior is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Examples sections. Every sentence adds value, the main purpose is front-loaded, and the examples are concise illustrations rather than repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional parameters and no annotations, the description is complete: it defines all parameters, their defaults, mode semantics, extraction sources, return format, and usage examples. Nothing an agent needs to call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions at all, yet the description documents every parameter: top_n with its default, mode with both allowed values and their meanings, and extract_mode with both options plus the config file dependency. Examples reinforce the parameter combinations, fully compensating for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving hot-topic frequency statistics, and the examples make the purpose concrete. It does not explicitly distinguish itself from siblings such as analyze_topic_trend, so it misses the top score, but the verb+resource combination is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by explaining the mode options and showing concrete examples for preset keywords and auto extraction. It does not explicitly state when not to use this tool or name alternatives, so the guidance is strong but not fully exclusionary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses storage separation, time-flow display, default/maximum values, and the token-saving effect of include_summary. As a read-only fetch tool, this is adequate, though it does not mention error or authentication behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with a clear purpose, structured Args, Returns, and Examples sections. Minor redundancy like 支持多日查询 repeating the days parameter details is acceptable but slightly unnecessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All four parameters are documented with defaults and limits, return format is specified as JSON, and examples demonstrate typical calls. The presence of an output schema means detailed return-field documentation is unnecessary, making this complete for a read-only RSS fetching tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining every parameter: feeds with ID examples, days with range and default, limit with cap, and include_summary with its purpose. This goes far beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 获取最新的 RSS 订阅数据, and further clarifies that RSS data is stored separately from hot-list news and displayed as a time stream. This makes it easy to distinguish from siblings like get_latest_news and search_rss.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear use case: retrieving recent content from specific RSS sources, and notes that RSS data is separate from hot-list news. However, it does not explicitly name alternatives such as search_rss or state when not to use this tool, so exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses server-side computation using precise current time, consistency across AI models, supported expression categories, and the exact return JSON shape. It does not discuss failure behavior or timezone assumptions, but it provides substantial behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal, but it is well-structured with headers, bullet lists, and examples, and each section adds value. The workflow and duplicate examples are somewhat repetitive, but the structure is scannable and front-loaded with the recommended-priority guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter helper tool with no annotations but an output schema, the description is complete: it covers why the tool exists, when to call it, how to call it, supported inputs, return format, and worked examples chaining into other tools. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain the parameter, and it does. It documents the single 'expression' parameter with categorized supported formats, examples, and dynamic 'last N days' support, adding clear meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves natural language date expressions into a standard date range using a specific verb and resource. It distinguishes itself by explaining this is the recommended first call before date-consuming tools like analyze_sentiment, and the scope is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends prioritizing this tool when users express dates naturally and provides a step-by-step workflow with concrete examples. It does not explicitly state when not to use it or name alternative date-related tools, but the usage context is strong and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It explains that compare_type selects different analyses (overview, topic_shift, platform_activity), that platforms filters sources, and that the result is JSON with period and type fields. It stops short of discussing failure modes, rate limits, or explicit read-only guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with clear sections (purpose, use cases, arguments, returns, examples) and front-loads the core purpose. Despite covering six parameters, every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter analytical tool with no annotations but an output schema, the description is complete: all parameters are specified, supported values are listed, return shape is summarized, and three usage examples are provided. Nothing necessary to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully document parameters. It does: period1/period2 accept either object ranges or presets, topic is optional, compare_type enumerates all three values with meanings, platforms provides a concrete example, and top_n has its default. Examples reinforce the parameter formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '时期对比分析 - 比较两个时间段的新闻数据', which names a specific verb (compare) and resource (news data across two periods). The use-case bullets further distinguish it from single-period or trend-only siblings by focusing on dual-period comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
A dedicated '使用场景' section lists concrete scenarios such as comparing this week vs last week and analyzing topic heat differences across periods. It gives clear when-to-use context but does not explicitly name excluded alternatives or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It clearly conveys a read-only, informational operation ('获取', '返回'), describes the JSON return format, and enumerates the detailed behavior across channels. It does not explicitly state 'read-only' or discuss side effects, but the non-mutating nature is strongly implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but highly structured and information-dense. It front-loads the purpose, then organizes channel differences, arguments, return type, and examples into clearly labeled sections. Every sentence contributes actionable information, and the per-channel breakdown is directly useful for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, and the description still supplies essential context: optional behavior, valid channel IDs, return format, and usage examples. Given the tool's simple single-parameter interface, nothing an agent needs to select and invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully compensate. It defines the channel parameter, lists all valid values (feishu, dingtalk, wework, telegram, email, ntfy, bark, slack, generic_webhook), explains that omitting it returns all channel policies, and gives concrete usage examples. This exceeds what the minimal schema alone would provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: '获取通知渠道的格式化策略指南' (get notification channel formatting policy guide), and explicitly states it returns Markdown features, formatting restrictions, and best-practice prompt suggestions per channel. This clearly differentiates it from sibling tools like send_notification and get_notification_channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool before calling send_notification to understand the target channel's format requirements. It provides clear context for when it is relevant, though it does not explicitly discuss when not to use it or name alternatives beyond its relationship to send_notification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by detailing how markdown is adapted per channel (e.g., Telegram converts ** to <b>, Slack converts ** to *), stating that channels default to all configured channels, and noting that the return is JSON with per-channel status. It could be more transparent about failure behavior and rate limits, but the given detail is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with sections: purpose, per-channel formatting details, a helpful tip, args, return value, and examples. Every section earns its place, and the most important information is front-loaded. The per-channel list is dense but directly useful for predicting tool behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of multi-channel formatting and zero schema coverage, the description is remarkably complete. It explains what the tool does, how it transforms content for each channel, what parameters are accepted, what the return value looks like, and gives examples. The mention of get_channel_format_guide also connects it to related tooling. No critical information needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameter meaning. It does so thoroughly: message is marked as required markdown content, title has a default of 'TrendRadar 通知', and channels lists all valid values. Examples further clarify usage. This fully bridges the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: '向已配置的通知渠道发送消息' (send messages to configured notification channels). It clearly distinguishes itself from sibling tools like get_channel_format_guide and get_notification_channels by focusing on the sending action rather than retrieval or guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it sends markdown-formatted messages to channels, optionally specifying channels, and explicitly recommends calling get_channel_format_guide before sending for optimal formatting. It does not explicitly state when not to use this tool, but the purpose is distinct enough among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden, and it largely does. It explains that dates already present locally are skipped (skipped_dates), failed dates are reported with errors, and the operation requires specific S3 configuration. It does not explicitly warn about network load or whether it modifies existing files beyond skipping, but the skip behavior implies non-destructive sync.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: overview, Args, Returns, Examples, and Note. Every section contributes necessary information — parameter semantics, return schema, usage examples, and configuration requirements — with no redundant filler. The purpose sentence is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description covers everything needed to invoke it correctly: parameter meaning and default, return format with all fields, configuration requirements, and usage examples. The output schema exists, but the description already details the return structure sufficiently, and the sibling context shows this is a standalone sync operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'days' as an integer with default 7 and 0% description coverage. The tool description fully compensates by explaining the meaning ('pull data from the last N days'), enumerating common values (0, 7, 30) with concrete interpretations, and providing examples for both default and explicit usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: '从远程存储拉取数据到本地' (pull data from remote storage to local), making the tool's core action unmistakable. It also situates the tool in the MCP Server workflow (crawlers store to remote cloud storage, server pulls for local analysis), which clearly distinguishes it from siblings like trigger_crawl, get_storage_status, or list_available_dates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: pulling crawler data from remote cloud storage (e.g., Cloudflare R2) into local for analysis. It does not explicitly name alternative tools or state when-not-to-use conditions, but the scenario and prerequisites (config file or S3 environment variables) are clear enough for an agent to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description bears the full burden of behavior disclosure and succeeds: it reveals automatic 5-second spacing for rate-limit compliance, a hard cap of 5 articles with excess skipped, per-article failure isolation, expected duration, and the nature of the JSON return. This is substantial valuable context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with sections for Args, Returns, Examples, and Notes, making it scannable. It loses a point for redundancy: the 5-article limit and 5-second interval are repeated in the opening sentence, the following paragraph, and the Notes section, but the overall size remains reasonable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, two parameters, no annotations, and the presence of an output schema, the description covers every practical need: selection workflow, limits, timing, timeout, partial failure behavior, and return shape. An agent can correctly invoke this tool without further information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates: urls is explained as a required list of article links with a maximum of 5, and timeout is defined as per-request timeout in seconds with default 30. This adds semantic meaning the bare input schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: '批量读取多篇文章内容（最多 5 篇，间隔 5 秒）'. It clearly differentiates from the sibling read_article by emphasizing batch processing, and even provides a workflow where it follows search_news, making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete '典型使用流程' with an explicit before-step: first search_news(include_url=True) to get URLs, then read_articles_batch(urls=[...]). It does not explicitly contrast with read_article or list exclusions, but the workflow and batch scope make the primary use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does so well. It discloses the underlying Jina AI Reader service, automatic noise removal, the free-tier 100 RPM limit, built-in 5-second rate control, and the fact that paywalled/login-walled pages may not be fully retrievable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized with sections for purpose, use cases, workflow, arguments, return format, and limitations. Every section adds practical information for an agent, and the primary purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core return value (JSON containing Markdown), the expected usage flow, rate limits, and failure caveats. For a small two-parameter tool, this is sufficient for an agent to select and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully. It specifies that url is required and must start with http:// or https://, gives timeout semantics with default 30 and max 60, and includes a concrete example call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: reading the content of a given URL and converting it to LLM-friendly Markdown. It clearly differentiates from search-oriented siblings by focusing on fetching and cleaning page content rather than discovering or aggregating news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context: use after search_news(include_url=True), and for reading news正文, getting article details, or analyzing content. It does not explicitly contrast with read_articles_batch, so it lacks a direct exclusion for multi-URL cases, but the intended workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

TrendRadar-autoglobalai-radar MCP server

Copy to your README.md:

[![TrendRadar-autoglobalai-radar MCP server](https://glama.ai/mcp/servers/iPythoning/TrendRadar-autoglobalai-radar/badges/card.svg)](https://glama.ai/mcp/servers/iPythoning/TrendRadar-autoglobalai-radar)

Score Badge

Copy to your README.md:

[![TrendRadar-autoglobalai-radar MCP server](https://glama.ai/mcp/servers/iPythoning/TrendRadar-autoglobalai-radar/badges/score.svg)](https://glama.ai/mcp/servers/iPythoning/TrendRadar-autoglobalai-radar)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/iPythoning/TrendRadar-autoglobalai-radar'

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