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.3
Disambiguation5/5
Each tool has a clearly distinct purpose. For example, analyze_data_insights offers multiple analysis modes, whereas analyze_sentiment focuses on sentiment and trend, and analyze_topic_trend handles trend/lifecycle/viral/predict patterns. No two tools have ambiguous boundaries.
Naming Consistency5/5
All tool names follow a consistent `verb_noun` pattern using snake_case, such as analyze_sentiment, get_latest_news, search_news, and trigger_crawl. The naming is predictable and uniform across all 14 tools.
Tool Count5/5
14 tools is well-scoped for a trend radar server. The set covers news retrieval, analysis, configuration, crawling, and date resolution without being excessive or too few.
Completeness5/5
The tool surface appears complete for its domain: news acquisition (get_latest_news, get_news_by_date, trigger_crawl), multiple search and analysis modes (search_news, analyze_sentiment, analyze_topic_trend, find_similar_news), reporting (generate_summary_report), configuration (get_current_config, get_trending_topics), and system status. No obvious gaps.
Average 4.3/5 across 14 of 14 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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?
With no annotations, the description fails to disclose key behavioral traits such as idempotency, authentication requirements, or rate limits. It only states the return format and content.
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 brief and covers the core purpose, but the mixed Chinese and English text and the 'Returns:' line could be streamlined. Still, it is efficient.
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 zero-parameter tool with an output schema, the description adequately explains what the tool does and what it returns. No major gaps are present.
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?
No parameters exist, so the baseline score of 4 applies. The description correctly mirrors the input schema's emptiness.
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 retrieves system runtime status and health check information, listing specific data points like version, statistics, and cache status. It distinguishes from sibling 'get_current_config' by focusing on health rather than 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 on when to use this tool versus siblings like 'get_current_config' or other informational tools. The description does not specify context or exclusion criteria.
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 full burden. It does not explicitly state that the operation is read-only, nor does it disclose any side effects or permissions needed. The return type is mentioned but not detailed.
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 concise and well-structured, with separate sections for Args and Returns. Every sentence adds value without redundancy.
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 adequately covers the single optional parameter but provides minimal detail about the return format beyond 'JSON格式的配置信息'. Given the tool's simplicity and presence of an output schema (not shown), this is acceptable but not exceptional.
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?
Although the input schema has 0% description coverage, the description compensates by listing possible values for the 'section' parameter with clear explanations (all, crawler, push, keywords, weights). This adds meaningful semantics 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 the tool's purpose: '获取当前系统配置' (Get current system configuration). It specifies the resource (system configuration) and the action (get), and distinguishes from sibling tools that focus on news, analysis, 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?
The description does not provide guidance on when to use this tool versus alternatives, nor does it mention when not to use it. It only lists parameter options, missing context for decision-making.
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, so the description must disclose behavioral traits. It only states that the tool generates a report and returns JSON with Markdown. No mention of side effects, authentication, rate limits, or data permanence. Minimal transparency beyond basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear header, args section, and returns. Every sentence is informative. No fluff. Front-loaded with purpose.
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 an output schema, the description covers purpose, parameters, and return format. It is complete for basic usage, though missing guidance on report type selection and potential constraints.
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 has 0% description coverage, so the description heavily compensates. It explains report_type as 'daily/weekly' and date_range with format example and an important note about object type. This adds significant value 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?
Description clearly states the tool generates daily/weekly summary reports, distinguishing it from siblings like analyze_sentiment and analyze_topic_trend. The verb 'generate' and resource 'summary report' are specific, and the Chinese text '每日/每周摘要生成器' adds clarity.
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 versus alternatives. Does not mention when to choose daily vs weekly, nor when not to use it. Siblings serve different purposes, but no explicit direction is given.
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 full burden. It details the threshold calculation (70% keyword overlap + 30% text similarity), the behavior of the limit parameter (actual returns may be less), and the default for include_url. This gives the agent a good understanding of the tool's operation.
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 a clear purpose statement, bulleted parameter explanations, and a separate display strategy section. While it is somewhat lengthy, every sentence adds value. Slight redundancy in the '注意' sections could be trimmed.
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's complexity (5 params, output schema exists), the description covers parameter semantics, return format, and display strategy. It lacks explicit error handling or prerequisites, but overall it provides sufficient context for an agent to use the tool effectively.
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 by explaining each parameter in detail, including the time_preset options, threshold formula, limit behavior, and purpose of include_url. This provides essential meaning beyond the raw 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 that the tool searches for related news in historical data based on a seed news reference. It specifies the data source and parameters. However, it does not explicitly differentiate itself from sibling tools like 'find_similar_news' or 'search_news', 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance within the parameter explanations and the display strategy section. It tells when to show all results vs. summarize, but does not advise when not to use this tool or compare it to alternatives. This leaves the agent to infer usage context.
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 burden. It discloses the date_range format constraint and provides examples, but lacks details on side effects, authentication, or rate limits. It adequately covers input behavior but not overall operational traits.
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 an Args header, bullet points, and examples. It is front-loaded with a summary. While thorough, a bit more conciseness could be achieved without losing essential details.
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 output schema exists, return values need not be explained. The description covers all input parameters effectively, including three modes with examples. Missing are edge cases or error handling, but overall completeness is high for a multi-mode analysis 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?
The schema has 0% description coverage, so the description fully compensates by explaining each parameter's meaning, valid values for insight_type, format and example for date_range, and mode-specific defaults for min_frequency and top_n. This adds significant value 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 data insight analysis tool integrating multiple analysis patterns, and lists three distinct insight types (platform_compare, platform_activity, keyword_cooccur) with explanations. This provides a specific verb+resource and differentiates from sibling tools like analyze_sentiment or analyze_topic_trend.
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 for each insight type, allowing the agent to infer when to use each mode. However, it does not explicitly state when not to use or name alternative tools, which would further improve guidance.
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 that the tool returns a list of news, with optional platform filtering, limit (default 50, max 1000, actual may be less), and include_url. It lacks details on ordering, error states, or rate limits, but is adequate for a read-only tool.
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 front-loaded with the main purpose, but includes a lengthy '数据展示建议' section that is more about agent behavior than tool definition. This could be trimmed or moved to a separate note to 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 the tool has an output schema, the description need not detail return values. It covers purpose, parameters (including defaults and behavior), and provides agent guidance on data presentation. It does not mention pagination or ordering, but overall is complete enough 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 coverage is 0%, so the description must compensate. It explains the platforms parameter in detail: example IDs, default behavior (use config), supported platforms from config. It explains limit default, max, and actual count may vary. It explains include_url default false and token savings. This adds significant meaning beyond property names.
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 sentence clearly states the tool gets the latest batch of crawled news data to quickly understand current hotspots, specifying the verb (get) and resource (latest news). It is distinct from sibling tools like search_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 provides extensive context on when and how to present data to users, including when to summarize (e.g., when user explicitly asks) and when to show full data. However, it does not explicitly contrast with sibling tools like search_news for specific scenarios.
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 covers key behaviors: natural language and date formats, default platforms from config, limit may return fewer, and token-saving options. It lacks details on errors or auth.
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 verbose, especially with lengthy advice on data presentation that could be shortened or moved to notes. The core purpose and parameters are clear but wordy.
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 (4 parameters, no annotations, output schema exists), the description is comprehensive: covers parameter details, return behavior, and usage advice. No gaps.
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 explains each parameter: date_query formats, platforms defaults and source, limit behavior, and include_url purpose. Adds significant value beyond 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 retrieves news data for a specified date, used for historical analysis and comparison. It distinguishes from sibling 'get_latest_news' by focusing on date-specific data.
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 context on when to use (historical data) and includes detailed advice on data presentation and summarization. However, it does not explicitly mention alternatives or when not to use.
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?
Discloses that it triggers a crawl, returns JSON status with failed_platforms, and mentions optional saving to local directory. Without annotations, it covers key behavior but omits potential auth needs 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args, Returns, and Examples sections, front-loading the main action. Slightly verbose but appropriate for a tool with multiple parameters.
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 no annotations and output schema present, the description adequately covers the tool's behavior (inputs, returns, defaults). Could add more on error handling or performance, but 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?
All three parameters are thoroughly explained: platforms with examples and default, save_to_local and include_url with their effects. This adds significant meaning beyond the schema which has 0% description coverage.
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 triggers a crawl task with optional persistence, specifying the verb ('触发') and resource ('爬取任务'). It distinguishes from sibling tools that are analytical/retrieval, as no other tool performs crawling.
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?
Provides explicit examples and explains default behavior (using config.yaml platforms when not specified). Implicitly clear when to use (when a crawl is needed), but no explicit when-not or alternative sibling tool comparison.
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 shoulders the transparency burden. It covers all important behavioral aspects: search modes and their effects, date range handling, platform defaults, limit behavior with a note about fuzzy filtering, sorting options, threshold applicability, and a display strategy. This gives the agent a thorough understanding of the tool's 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 well-structured with sections, bullet points, and examples, and it front-loads the critical date range workflow. It could be slightly more concise (e.g., the display strategy note might be considered extra), but overall it is efficient and easy to parse.
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, dependency on another tool), the description is remarkably complete. It covers all parameter behaviors, provides example workflows, explains return format, and even advises on display strategy. No gaps are apparent for an AI agent to use 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?
Despite 0% schema coverage, the description explains every parameter with clear semantics, examples, and constraints. For instance, it describes fuzzy mode's threshold, the default for date_range, and the token-saving purpose of include_url. This fully compensates for the lack of schema 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?
Description clearly states it is a 'unified search interface' supporting multiple search modes, which establishes its purpose well. However, it does not explicitly distinguish itself from sibling tools like get_latest_news or get_news_by_date, so the differentiation is implicit rather than explicit.
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 the resolve_date_range tool in conjunction with search_news for natural language dates, and includes examples. However, it lacks explicit guidance on when to prefer sibling tools over search_news, which limits completeness.
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 discloses that the tool reads from a config file, operates in two modes (daily and current), and returns a JSON list. It is clear about the read-only nature and data source, though it omits details like sorting or pagination.
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 multi-paragraph but well-structured with a note, Args, and Returns sections. It is slightly verbose for a simple tool, but the structure aids readability.
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 the data source, behavior, parameters, and return format. Given the available output schema, it is mostly complete, though some behavioral details (e.g., sorting) are 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%, but the description fully explains both parameters: top_n (default 10, return top N) and mode (daily or current, default current). This adds complete 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 the verb '获取' (get) and the resource '个人关注词的新闻出现频率统计'. It explicitly distinguishes itself from auto-extracting hot topics, which differentiates it from siblings like 'analyze_topic_trend'.
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 the tool: it is for counting user-defined keywords from a config file, not for automatic hotspot extraction. It also explains how to customize the config file, offering clear context.
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 covers behavioral traits: threshold controls match strictness, limit may not be met, include_url saves tokens, and the display strategy clarifies default behavior. All important traits are disclosed.
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 Args, Returns, and a strategy note. While clear and front-loaded, the strategy section is somewhat lengthy for a parameter definition but adds value. Minor improvement could be to separate strategy into usage notes.
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 (context signal), the description covers return format, parameter behavior, and display strategy. It provides complete guidance for an agent to understand invocation and result 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 description must add meaning. It explains each parameter: threshold with effect and range, limit with caveat, include_url with token-saving rationale. The description compensates fully for lacking schema descriptions.
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 tool name 'find_similar_news' and description '查找与指定新闻标题相似的其他新闻' clearly state the action (find) and resource (similar news). It distinguishes itself from sibling tools like search_news (general search) and get_latest_news (recent news) by focusing on similarity matching.
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 parameter details and a display strategy ('默认展示方式' vs user request for summary), but does not explicitly state when to use this tool over alternatives like search_news or search_related_news_history. Usage context is implied but not directly guided.
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 provided, so description carries full responsibility. It discloses server-side time computation, supported expression types, and return format. It does not mention error handling for unsupported expressions or edge cases, but overall it is transparent about its behavior and output.
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?
Description is well-structured with headings, bullet points, and examples, making it easy to read. However, it is somewhat verbose; the 'Why need' and usage flow sections could be slightly condensed without losing value.
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 simplicity (one parameter), the description covers everything: purpose, parameter details, return format with example, recommended usage with other tools, and output schema (inferred from Returns section). It is fully sufficient for correct tool 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 only parameter 'expression' has no schema description, but the description provides extensive documentation: supported expression categories (single day, week, month, last N days), examples, and format. This adds significant meaning beyond the bare schema 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?
Description clearly states that the tool resolves natural language date expressions to standard date ranges. It distinguishes from sibling tools by its unique function and provides specific use cases for date conversion, which is not covered by any other tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends the tool as the first call in a workflow, provides a step-by-step usage flow, and explains why it is needed for consistency across different AI models. Examples illustrate when and how to use it with other tools like analyze_sentiment and 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 provided, the description carries full burden. It discloses that granularity only supports 'day' due to daily data aggregation, defaults for all parameters, and the role of date_range. It does not address auth needs, rate limits, or side effects, but the analysis nature implies a read-only operation.
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 brief title, an important note on date handling, a clearly labeled args section with bullet points, return type, and examples. It front-loads critical workflow instructions and avoids redundancy, earning its length for a complex multi-mode tool.
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 appropriately omits detailed return value explanations. It covers all parameters, provides default behaviors, and includes usage examples. It does not address error handling for invalid topics, but the overall coverage is high for the tool's complexity.
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 explains every parameter in detail: topic is required, analysis_type enumerates options, date_range format with reference to resolve_date_range, granularity constraint, and mode-specific parameters (threshold, time_window, etc.) with defaults and meanings. This far exceeds what schema alone provides.
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 as '统一话题趋势分析工具' (unified topic trend analysis tool) and lists four specific analysis modes (trend, lifecycle, viral, predict), distinguishing it from siblings like 'get_trending_topics' which likely provide pre-computed trends rather than customizable analysis.
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 explicitly instructs agents to call 'resolve_date_range' when users provide natural language dates (e.g., '本周'), including a step-by-step workflow and examples. It also specifies when to use each analysis mode and defaults, though it lacks explicit when-not conditions.
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 provided, the description fully discloses behavioral traits: deduplication of news titles, default platform selection from config, default date range as today, limit cap at 100, token-saving behavior for 'include_url', and a return format including sentiment distribution and heat trends. It is comprehensive.
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, bold headings, lists, and examples. Despite its length, every sentence adds value. It is front-loaded with the main purpose and uses formatting to enhance readability.
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 (6 parameters, behavioral nuances, and prerequisite step), the description covers all necessary aspects. The presence of an output schema reduces the need to detail return values, but the description still summarizes the return format. It leaves no gaps for an AI agent.
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 adds full meaning for all 6 parameters: each parameter is explained with examples, defaults, constraints (e.g., limit max 100), and format details for 'date_range'. It also explains the dedup effect on limit and how platforms are sourced from config.
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 sentiment and heat trends of news). This is a specific verb+resource combination that distinguishes it from siblings like 'analyze_topic_trend' and 'analyze_data_insights'.
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 usage guidelines, including a prerequisite: for natural language dates, first call 'resolve_date_range'. It gives examples and a recommended workflow, and specifies when to show all results vs. a summary. It effectively differentiates usage from siblings.
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/YangLang116/TrendRadar/badges/card.svg)](https://glama.ai/mcp/servers/YangLang116/TrendRadar)

Score Badge

Copy to your README.md:

[![TrendRadar MCP server](https://glama.ai/mcp/servers/YangLang116/TrendRadar/badges/score.svg)](https://glama.ai/mcp/servers/YangLang116/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/YangLang116/TrendRadar'

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