TrendRadar

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation4/5
Tools have mostly distinct purposes, though there is slight overlap between search_news and search_related_news_history, and between get_latest_news and get_news_by_date. However, descriptions and arguments clearly differentiate them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., analyze_sentiment, get_latest_news, search_news). No mixing of camelCase or other styles.
Tool Count5/5
13 tools cover the domain of news/trend analysis comprehensively without feeling excessive. Each tool serves a clear purpose, and the number is well-scoped for the server's functionality.
Completeness5/5
The tool set covers the full lifecycle of news analysis: fetching (latest, by date), searching (keyword, fuzzy, entity), analyzing (sentiment, trends, insights), finding similar, generating reports, and managing system configuration. No obvious gaps for the intended purpose.
Average 4.1/5 across 13 of 13 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 78 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
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 output format (JSON with Markdown) but fails to disclose any behavioral traits such as side effects, permissions, or constraints on inputs. This is insufficient for an unannotated tool.
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 with a title, Args, and Returns sections, making it easy to scan. It is relatively concise and front-loaded with the purpose, though some formatting (bold, code blocks) adds minor overhead.
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?
The description covers the core functionality, parameters, and output format. However, it lacks details on default behavior when date_range is null, and it does not indicate if report_type is strictly limited to 'daily' and 'weekly'. The existence of an output schema reduces the need to explain return values, but behavioral completeness is still lacking.
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 0% description coverage, so the description must compensate. It explains both parameters: report_type as 'daily/weekly' and date_range as an object with format and example, plus a note about not passing integers. This adds significant meaning beyond the schema, though an explicit enum for report_type would improve it.
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 it is a daily/weekly summary generator that automatically generates hot spot summary reports. The verb 'generate' and resource 'summary report' are specific, and the tool is distinct from sibling analysis tools, though no explicit distinction is made.
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 does not provide any guidance on when to use this tool versus alternatives. It only states its function, leaving agents without context on prioritization or exclusion.
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, and the description only states it returns system info. It does not disclose whether the operation is read-only, has side effects, or requires authentication. This is a significant gap for a tool with no annotation support.
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 with two sentences covering the tool's purpose and return format. The bilingual content slightly reduces efficiency but does not waste words.
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 tool with an output schema, the description provides sufficient detail about the returned data (system version, data stats, cache status). It could mention error scenarios or performance considerations for completeness.
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 has no parameters, and the input schema coverage is 100% trivially. The description does add value by listing the types of information returned, which compensates for the lack of parameter documentation.
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 retrieves system status and health check information, specifying returned fields like version, data stats, and cache status. It is distinct from siblings like get_current_config, which focuses on configuration.
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 provided on when to use this tool versus alternatives such as get_current_config or other status-related tools. The description does not include any context about prerequisites or exclusions.
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 provided; the description does not disclose whether the operation is read-only, requires permissions, or any side effects. It only states it returns JSON.
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 with a clear structure (description, Args, Returns). It could be slightly more compact but is well-organized.
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 the tool has only one optional parameter and an output schema exists, the description sufficiently covers the parameter semantics. It does not need to explain return format since output schema is present.
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 description adds full meaning beyond the schema by listing all possible values for the section parameter and their corresponding configurations. Schema description coverage is 0%, so this compensates completely.
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 specifies the verb '获取' (get) and resource '系统配置' (system configuration). It distinguishes from sibling tools which are about analysis, news, and crawling.
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 explicit guidance on when to use this tool versus alternatives. No mention of 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?
Describes return format (JSON), default limit, max limit, actual count may be less, and token-saving option (include_url). No annotations exist, so the description carries the burden; it covers key behavioral traits well. Missing explicit idempotency or side-effect statements but still strong.
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?
Purpose stated upfront; parameter descriptions are clear. The long display-suggestions section adds value for the agent but could be more concise. Overall well-structured and 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?
Covers parameters, defaults, and usage advice. With an output schema present, the missing return-value description is mitigated. Lacks error handling and sorting details but sufficient for a simple read 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?
With 0% schema description coverage, the description fully compensates: explains platforms as list with defaults from config, gives examples (['zhihu', 'weibo', 'douyin']), clarifies limit behavior (max 1000, actual may be less), and explains include_url's purpose. Adds significant value beyond the 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?
Clearly states the tool gets the latest batch of crawled news ("获取最新一批爬取的新闻数据") and implies it's for current hot topics. However, it doesn't explicitly differentiate from siblings like get_news_by_date or get_trending_topics, which could cause confusion.
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 on when to use this tool vs. alternatives. Lacks explicit context like 'Use this for unfiltered latest news; for date-filtered news, use get_news_by_date', leaving the agent to infer usage from the name alone.
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 full burden. It details parameter behavior (e.g., date_range format constraint) and notes return type as JSON. However, it does not disclose whether the tool is read-only, any potential side effects, or authentication needs.
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 sections for purpose, Args, Returns, and Examples. While comprehensive, it could be slightly more concise; but the front-loaded purpose and clear organization justify a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, an output schema (exists), and no annotations, the description covers parameter details, constraints, and examples. It lacks information on error scenarios and output structure beyond 'JSON format', but the presence of an output schema reduces the need for full return value description.
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 Args section thoroughly explains each parameter: enum values for insight_type with meanings, topic as optional, date_range with format example, min_frequency default, top_n 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '统一数据洞察分析工具 - 整合多种数据分析模式', indicating a unified tool for multiple data analysis modes. It lists three specific insight types, distinguishing it from sibling tools like analyze_sentiment or analyze_topic_trend which are more specialized.
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 provides explicit insight_type options and examples showing parameter usage for different scenarios. However, it lacks explicit guidance on when not to use this tool or direct comparisons to alternatives, leaving usage context somewhat implied.
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 that limit is a maximum (actual returns may be less) and that include_url defaults to false to save tokens. These traits help the agent anticipate behavior. However, it doesn't mention any side effects or authorization needs, which is acceptable for a read-like operation.
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 moderately concise but includes a data display strategy section that is somewhat extraneous for tool invocation. It front-loads the purpose and parameter explanations, but the display strategy could be moved to a separate guidance. It is not overly verbose, but every sentence is not strictly necessary.
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 the existence of an output schema (not shown but signaled), the description does not need to detail return fields. It covers all input parameters, explains the output format as JSON with similarity scores, and includes a display strategy that guides the agent on how to present results. This makes the tool well-documented for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well. It explains the meaning of threshold (higher = stricter matches), limit (max 100, actual may be lower), and include_url (token saving). For reference_title, it only states 'full or partial', which is adequate. Overall, it adds significant value over 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 finds news similar to a specified title, using a distinct approach from siblings like search_news or get_latest_news. The verb and resource are specific, and the purpose is unambiguous.
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 provides parameter-level guidance (e.g., threshold affects strictness, limit may return fewer results) but lacks explicit when-to-use vs. alternatives. No comparison with sibling tools like search_related_news_history is given, so usage context is implied but not fully clarified.
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 full burden. It discloses return format (JSON with title, platform, rank), default behavior (limit=50, date_query defaults to '今天'), and includes important advice on data display (show all unless user requests summary). It does not mention destructive actions or auth, but covers key behavioral aspects well.
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 clear sections (Args, Returns, notes). The note about data display is relevant but somewhat lengthy. Overall, it is efficient and informative, though a bit verbose in the display advice section.
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 presence of an output schema (mentioned in context), the description does not need to detail return values. It thoroughly explains all input parameters, provides usage advice, and addresses potential AI behavior (avoiding unnecessary summarization). The description is complete for a historical news retrieval tool with good context for agents.
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 fully compensates. Each parameter is explained with examples and context: date_query with natural language and date formats and default, platforms with config reference, limit with default and max and note about possible fewer results, include_url with default and token-saving rationale. This adds significant meaning beyond the 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 '获取指定日期的新闻数据，用于历史数据分析和对比', which specifies the verb (获取), resource (新闻数据), and scope (指定日期). It distinguishes from sibling tools like get_latest_news and search_news by emphasizing historical analysis and date-based retrieval.
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 does not explicitly guide when to use this tool over alternatives like get_latest_news or search_news. While it implies use for historical data, it lacks direct 'when-to-use' or 'when-not-to-use' statements, and no exclusions or alternatives are mentioned.
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 full burden. It discloses important behaviors: deduplication of news titles ('对新闻标题进行去重'), default display strategy (show all vs. summary only on user request), and the date_range format requirement. It does not mention rate limits, authentication needs, or side effects, but for a non-destructive analysis tool, the disclosures are adequate.
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 '重要' sections. However, it is somewhat verbose, especially in the platforms description (repeating config file details). Every sentence adds value, but the length could be trimmed by 20-30% without losing clarity.
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 the complexity (6 parameters, no annotations, and a comprehensive output schema exists), the description covers most essential aspects: parameter details, return format, and display strategy. It does not explicitly state the return schema structure or error handling, but the output schema is available. The dedup and default display strategy add practical completeness. Sibling tools exist but the description sets clear scope.
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 comprehensively. For each parameter, it provides clear meaning: topic (keyword), platforms (list with source config reference), date_range (object format with example), limit (with dedup note), sort_by_weight (boolean), include_url (token saving). This goes beyond the schema's minimal type definitions.
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's purpose: '分析新闻的情感倾向和热度趋势' (analyze news sentiment and trend). It specifies the resource (news) and the action (analyze sentiment and trend). Among sibling tools like 'analyze_data_insights' and 'analyze_topic_trend', this tool is distinctly focused on sentiment and heat trends, making it distinguishable.
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 provides detailed usage guidance for parameters (e.g., platforms default to config, date_range must be an object). However, it does not explicitly state when to use this tool versus alternatives like 'generate_summary_report' or 'get_latest_news'. The '重要' section touches on display strategy but not on when to choose this tool over siblings. Lacks explicit when/when-not/alternatives.
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 fully carries the burden. It discloses the threshold calculation (70% keyword overlap + 30% text similarity), limit behavior (max 100, actual returns may be fewer), include_url token savings, and time_preset options. No contradictions.
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 sections for purpose, args, returns, and display strategy. It is verbose but every sentence adds value. A slight reduction could improve conciseness.
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 5 parameters, no schema descriptions, and no annotations, the description covers inputs and display strategy comprehensively. It references the output format but does not detail output schema fields (though an output schema exists). Missing error handling or edge cases, but overall sufficient for agent use.
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 by detailing every parameter: reference_text as news title, time_preset with enum values, threshold with formula, limit with default/max, and include_url token savings. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching for related news in historical data based on a seed news reference. It specifies the reference_text as a seed and distinguishes from siblings by focusing on historical data and providing a display strategy.
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 implicit usage context (historical data search) but lacks explicit guidance on when to use this tool vs. siblings like find_similar_news or search_news. The display strategy is described, but no when/not-when instructions are provided.
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. It discloses that the tool reads from a config file (config/frequency_words.txt) and is not auto-extracting, which adds transparency. While it does not mention rate limits or side effects, the tool appears to be read-only and non-destructive, making this level of disclosure adequate.
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 reasonably concise, with the main behavior explained in one sentence followed by parameter details. However, it includes a note about not being auto-extraction that could be integrated more tightly. Still, it is clear and well-structured.
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 only has two optional parameters and an output schema (implies return structure is documented), the description covers the source of words, the two modes, and the return format. It is complete for an agent to understand and invoke the tool 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?
The input schema has 0% description coverage (no field descriptions), but the tool description fully explains both parameters: top_n returns top N words (default 10) and mode has daily (cumulative day) and current (latest batch) options. This adds significant meaning beyond the schema types and defaults.
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 it retrieves frequency statistics for user-defined personal focus words from a configuration file, distinguishing it from automatic hot topic extraction. The verb '获取' (get) and resource '关注词的新闻出现频率统计' (news appearance frequency statistics of focus words) are specific and 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 explicitly clarifies that this tool is not for automatic hot topic extraction but for custom word frequency statistics, providing context on when to use it. However, it does not mention alternative sibling tools like analyze_topic_trend or search_news, which could be used for related but different purposes.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explains the return format, data display strategy, and the effect of threshold on filtering. It also notes that include_url defaults to False to save tokens. However, it does not discuss rate limits, authentication requirements, or whether the tool has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections (Args, Returns, important notes, AI instructions, calculation rules, examples). It is front-loaded with the core purpose. While some details could be condensed, the structure aids readability. The inclusion of examples and rules adds value without being overly verbose.
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 complexity (8 parameters, multiple modes, date handling) and the presence of an output schema (not shown), the description is highly complete. It covers all parameter semantics, usage guidelines, edge cases (e.g., single-day queries), and even provides explicit examples. The description leaves no obvious gaps for an AI agent to use the tool 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%, meaning the schema provides no parameter explanations. The description compensates fully by detailing each parameter, including search_mode values, date_range format and examples, platform usage, limit, sort_by, threshold, and include_url. This provides rich semantic context beyond the raw 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 it is a unified search interface supporting multiple search modes. It defines the tool's purpose as searching news with various modes like keyword, fuzzy, and entity, making it distinct from sibling tools such as get_latest_news or get_news_by_date.
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 detailed guidance on when to use each search mode and how to handle relative date expressions. It includes examples of mapping user phrases to date ranges. However, it does not explicitly compare against sibling tools, so an AI agent might be unclear when to choose search_news over alternatives like get_news_by_date.
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. It explains that failed platforms appear in failed_platforms, and describes the effects of each parameter. It does not disclose rate limits or destructive behavior, but it covers the main behavioral traits adequately.
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 sections, args, returns, and examples. It is front-loaded with the core purpose. While slightly lengthy, each section earns its place 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?
Given no annotations and an existing output schema, the description explains the return format and key behavioral aspects. It covers all necessary context for an agent to use the tool correctly, including default behavior and failure handling.
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 compensates fully. It explains the platforms parameter (list or null for all), default values, and side effects (failed_platforms). Examples show realistic usage, making parameter semantics clear.
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 triggers a crawl task with optional persistence, using a specific verb ('trigger') and resource ('crawl task'). It distinguishes from sibling tools like analyze_data_insights or get_latest_news, which are analysis or retrieval tools, not crawl triggers.
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 clear usage context, including when to specify platforms and when to use defaults, along with examples. It does not explicitly mention when not to use this tool or list alternatives, but the context makes the usage pattern obvious.
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 fully discloses behavioral traits: it states that granularity only supports 'day' due to data aggregation, that date_range must be in YYYY-MM-DD format (no natural language), and the return format is JSON. No contradictions.
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 with sections, bullet points, and examples, making it easy to parse. It is slightly lengthy but every sentence contributes meaningful guidance. Could be slightly more streamlined but still effective.
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 output schema exists, the description does not need to detail return values. It covers all 8 parameters, usage patterns, edge cases (like calculating dates), and includes multiple examples. It is complete for an AI agent to invoke the tool 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 thoroughly explains each parameter: analysis_type with all four values and their meanings, date_range format and calculation rules, granularity constraint, threshold, time_window, lookahead_hours, confidence_threshold. It adds significant value 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 '统一话题趋势分析工具' (unified topic trend analysis tool) and lists multiple analysis modes (trend, lifecycle, viral, predict), distinguishing it from sibling tools like analyze_sentiment or get_trending_topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each analysis_type, and crucially instructs the AI to calculate date_range from relative time expressions using the current date, with examples. This goes beyond basic usage to handle a common user input pattern.
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

Copy to your README.md:

[![TrendRadar MCP server](https://glama.ai/mcp/servers/lizouzt/TrendRadar/badges/card.svg)](https://glama.ai/mcp/servers/lizouzt/TrendRadar)

Score Badge

Copy to your README.md:

[![TrendRadar MCP server](https://glama.ai/mcp/servers/lizouzt/TrendRadar/badges/score.svg)](https://glama.ai/mcp/servers/lizouzt/TrendRadar)

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/lizouzt/TrendRadar'

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