TrendRadar

by xhh-im

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v1.0.3
Disambiguation4/5
Most tools have distinct purposes. Potential overlap between analyze_sentiment and analyze_topic_trend (both analyze topics) but they focus on different aspects (sentiment vs. lifecycle/viral/predict). Overlap between get_latest_news and get_news_by_date is clarified by descriptions. Overall, boundaries are clear.
Naming Consistency4/5
All tools use snake_case with a consistent verb_noun pattern (e.g., analyze_sentiment, search_news). A few exceptions like get_news_by_date (includes preposition) and search_related_news_history (longer) break the pattern slightly, but the naming is largely predictable and readable.
Tool Count5/5
14 tools is well-scoped for a trend analysis and news retrieval server. The number covers data retrieval, analysis, reporting, configuration, and system management without being excessive or sparse.
Completeness4/5
The tool surface covers core operations: news retrieval (multiple methods), analysis (sentiment, trends, insights), reporting, and system status. Missing are tools to modify configuration (e.g., update keywords or platforms) or manage data (create/update/delete), but these are not essential for the consumption-oriented domain.
Average 4.3/5 across 14 of 14 tools scored. Lowest: 3.1/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?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions output is JSON with Markdown content but lacks details on side effects, authorization requirements, rate limits, or data persistence.
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 title line, 'Args' section with bullets, and 'Returns' line. It is concise, though the Chinese text could be slightly shorter.
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?
Given the existence of an output schema (not shown), the description appropriately delegates return details. However, it lacks guidance on default behaviors (e.g., if date_range omitted) and does not mention the tool's role relative to sibling tools like resolve_date_range.
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 schema description coverage is 0%, but the description compensates by explaining date_range format (object with start/end, must not be integer) and report_type as daily/weekly. This adds crucial meaning beyond the schema's type-only definitions.
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 generates daily/weekly summary reports ('每日/每周摘要生成器'). The verb 'generate' and resource 'summary report' are specific. It distinguishes from siblings like 'analyze_data_insights' by focusing on periodic report generation.
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. It does not mention prerequisites or scenarios where other tools (e.g., get_latest_news, analyze_sentiment) would be more appropriate.
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?
Description indicates a read operation returning JSON status info. With no annotations, it carries the burden but does not disclose side effects, auth needs, or rate limits. The info is adequate for a simple status check.
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 short and front-loaded with purpose, but includes bilingual repetition. Still clear and concise enough.
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 0 parameters, simple read, and existing output schema, the description fully explains what the tool does and returns, meeting completeness needs.
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 baseline 4 is appropriate. The description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves system status and health info, including version, stats, cache. It is specific and distinct from sibling tools which are news and analysis related.
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. It does not mention when not to use or suggest any other tool, leaving the agent to infer based on tool name alone.
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 bears full burden. It discloses the threshold calculation formula (70% keyword + 30% text similarity), notes that actual return count may be less than the limit, and explains the reason for the include_url parameter (saving tokens). These details help the agent understand behavior 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with sections for Args, Returns, and an important note. However, it could be more concise; for example, the display strategy section could be integrated into the main description. Some redundancy exists.
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 5 parameters and no output schema in the description (though context says there is an output schema), the description covers the output format (JSON list) and key behaviors. The 'data display strategy' adds completeness for user interaction. Still, it could mention error handling or pagination if applicable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It fully explains each parameter: reference_text as news title, time_preset with four explicit preset values, threshold with default and formula, limit with max and note about actual count, and include_url with default and rationale. This goes far beyond the schema's bare type definitions.
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 searches for related news in historical data based on a seed news reference. It specifies the input as 'reference_text' (news title) and the output as a JSON list with relevance scores and time distribution. However, it does not explicitly differentiate 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 a specific display strategy: show all results unless the user asks for a summary. This gives some usage context but lacks explicit when-to-use or when-not-to-use guidance relative to alternatives. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the return is JSON config and lists section options, but does not mention safety, authentication, or rate limits. For a read-only tool, this is adequate but not exceptional.
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, uses a bullet list for parameters, and front-loads the main purpose. Every sentence adds value with no wasted words.
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 low complexity (one optional parameter) and presence of an output schema, the description fully covers what the tool does, what inputs are accepted, and the return format. It is complete for an agent to select and invoke correctly.
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 (0% coverage) has no description for the 'section' parameter. The description adds significant meaning by listing the five valid enum-like values and their meanings, compensating for schema gaps.
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 the current system configuration. The verb 'get' and resource 'current system config' are specific. It distinguishes from sibling tools like 'get_system_status' which likely returns status 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists valid section values, helping users decide which config to retrieve, but does not explicitly state when to use this tool over alternatives or when not to use it. No comparison to similar siblings is provided.
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 must carry the burden. It explains defaults, parameter effects, and return fields including failed_platforms. However, it does not disclose potential side effects (e.g., overwriting files during save), authentication requirements, or rate limits, which would improve transparency for a tool that may have persistent 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 well-structured with sections (args, returns, examples) and uses bullets for clarity. It is front-loaded with the purpose. While comprehensive, it could be slightly trimmed without losing meaning, 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.
Completeness4/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 (not shown but indicated), the description adequately explains return values. It covers core functionality, default behaviors, and error reporting. Missing details like authentication or configuration file paths are acceptable for a mechanism description, but the tool is contextualized within the sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates. It explains each parameter in detail: platforms list with name mapping, save_to_local default False, include_url default False, and provides real-world examples. This adds significant value beyond the raw JSON schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool triggers a crawl task manually, with optional persistence. It specifies the resource (crawl task) and actions (trigger, optionally save). It distinguishes from sibling analysis tools by being the only one that initiates data collection.
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 examples for different use cases (specified platforms, with save, default platforms) and explains default behavior. It mentions that failed platforms are returned. However, it does not explicitly state when not to use this tool or compare to alternatives, though sibling tools are a different category.
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 provided, so description carries full burden. It explains return format (JSON) and parameter constraints (e.g., date_range must be object), but does not disclose side effects, authentication needs, or rate limits. Adequate but not comprehensive.
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 sections (overview, args, returns, examples) and front-loaded. However, it is verbose with mixed languages and could be slightly more concise.
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 5 parameters (none required), output schema exists, and tool covers multiple modes, the description is complete. It explains all parameter uses and return format, with examples for each mode.
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 description provides detailed explanations for all parameters: insight_type values, topic optional, date_range format with examples, min_frequency default, top_n default. This adds substantial meaning 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 it is a unified data insight analysis tool integrating multiple modes (platform_compare, platform_activity, keyword_cooccur), each explained. The purpose is specific and distinguishes from sibling tools by listing distinct analysis types.
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 examples for each insight type, demonstrating usage. However, it does not explicitly state when not to use this tool or compare it to alternatives like analyze_sentiment or analyze_topic_trend, which are siblings.
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 multiple behavioral traits: search modes, date range handling, limit and threshold effects, default platform config, and return format. With no annotations, the description compensates well for safety and behavior. Could mention error behavior or rate limits but overall 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?
Well-structured with sections, bullet points, examples, and important notes. Front-loaded with purpose. Slightly verbose but every sentence adds value. Could be more concise but organization is 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 8 parameters, 1 required, and an output schema, the description covers search logic, date workflow, platform configuration, display strategy, and usage examples. Only missing error handling, but output schema likely covers return values. Highly complete for a complex search 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 coverage, the description fully compensates by explaining every parameter: query, search_mode with options, date_range format and acquisition, platforms with defaults, limit behavior, sort_by options, threshold semantics, and include_url. 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 identifies as a unified search interface with multiple modes (keyword, fuzzy, entity). Distinguishes from siblings like get_latest_news and get_news_by_date by being a general search, but does not explicitly differentiate from find_similar_news or search_related_news_history.
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 guidance on when to use each search_mode and a detailed workflow for date range resolution using resolve_date_range. Includes default behavior and data display strategy. However, does not explicitly mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool uses server-side current time for consistency and returns a standardized JSON format. It explains the behavior fully, including edge cases like dynamic day ranges, but could mention any limitations like unsupported expressions.
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 well-structured with headers, bullet points, and examples, but is somewhat verbose. It contains redundant emphasis (e.g., the 'why' and 'flow' sections repeat similar points). However, the content is valuable and clearly organized.
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) and the presence of an output schema, the description is complete. It covers all necessary aspects: purpose, usage, supported expressions, return format, and examples. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'expression', has 0% schema coverage (no description in schema). The description compensates extensively by listing supported expressions with categories and examples, adding significant meaning beyond the schema's type information.
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: resolving natural language date expressions to standard date ranges. It differentiates from siblings by emphasizing that the tool ensures consistency across AI models by using server-side current time, and provides a recommended usage flow with examples.
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 explains when to use the tool (e.g., when user provides natural language dates) and provides a recommended flow with examples. It does not explicitly mention when not to use it, but the context and examples are sufficient for an agent to understand appropriate usage.
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 present, so description carries full burden. It discloses behavioral traits: topic required, default date range (7 days), granularity limited to 'day', default values for viral and predict modes. Could mention more about output structure or error cases, but output schema exists to supplement.
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 sections, bold emphasis, bullet lists, and examples. Somewhat lengthy but every part serves a purpose. Could tighten the examples slightly.
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 all parameters and provides usage context. With 8 parameters and no schema descriptions, it fills the gap well. Output schema exists, so return value explanation is less critical. Lacks error handling or edge case information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description thoroughly explains each parameter, including enum meanings, date_range format and default, granularity limitation, and mode-specific parameters. 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 it is a unified topic trend analysis tool that integrates multiple analysis modes (trend, lifecycle, viral, predict). It distinguishes itself from sibling tools like analyze_sentiment and search_news by focusing specifically on trend analysis of 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?
Provides explicit instructions for when to use this tool, including a prerequisite step to call resolve_date_range for natural language dates. Includes examples with recommended call flows, and implicitly guides when to use alternative analysis types via parameter descriptions.
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: deduplication of news, default values, data display strategy, and the procedure for obtaining date ranges. This ensures the AI agent can invoke the tool correctly.
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 headers, bullet points, and examples, making it easy to parse. However, it is somewhat lengthy, and the data display strategy section could be more concise.
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 6 parameters and optionality, the description covers all necessary information: parameter details, usage flows, and behavioral notes. The existence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description provides complete semantic meaning for all 6 parameters, including examples and default behaviors. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 function: analyzing sentiment and heat trends of news. It distinguishes itself from sibling tools like 'analyze_topic_trend' by focusing specifically on sentiment and heat. The examples reinforce this purpose.
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 usage guidelines, including when to call 'resolve_date_range' for natural language dates, and default behaviors like platform selection. However, it does not explicitly compare with sibling tools or state when not to use this tool.
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 explains threshold strictness, limit actual vs. requested, include_url for token saving, and a display strategy. This gives comprehensive behavioral insight.
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 but includes a data display strategy section that, while useful, adds length. It is mostly front-loaded and efficient, though slightly 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 parameter count, lack of schema descriptions, and no annotations, the description is highly complete. It covers all parameters, behavior, and output expectation, and there is an output schema to cover return structure.
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 description coverage, the description thoroughly explains each parameter: reference_title (the title), threshold (similarity threshold with note), limit (max 100, actual may be less), include_url (default false for token saving). It adds meaning 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's action: finding similar news based on a specified title. It distinguishes itself from sibling tools like search_news by focusing on similarity rather than general search.
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 context for use (when needing similar news) and includes practical notes (e.g., threshold impact, limit behavior). However, it lacks explicit guidance on when not to use or direct comparison with alternatives.
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 key behaviors such as the limit cap (1000), the optional URL inclusion to save tokens, and the fact that actual returned count may be lower. It does not cover rate limits or authentication, but these are less critical for a read-only news retrieval 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 long but well-structured, with a clear purpose statement followed by parameter details and usage recommendations. The additional guidance on data display is valuable for the agent, though some redundancy (e.g., repeating limit info) could be trimmed.
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 has an output schema (mentioned in context), the description appropriately omits detailed return value documentation. It instead focuses on usage context, including when to summarize data, and addresses potential user expectations. This completeness helps the agent 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?
The input schema has 0% description coverage, so the description fully compensates by explaining each parameter in detail: platforms (list of IDs, default from config), limit (default 50, max 1000), and include_url (default false, token-saving purpose). It also provides context like platform names for AI recognition.
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 the latest batch of crawled news data for quick understanding of current hotspots. It explicitly lists the parameters (platforms, limit, include_url) and describes the return format, distinguishing itself from sibling tools like search_news and get_news_by_date by focusing on the most recent data.
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 show full data vs. summarize, including a dedicated section on when summarization is appropriate. It also explains the behavior when platforms are omitted (uses config defaults) and notes the actual return count may be less than requested.
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 covers behavioral traits: default date, platform configuration, limit behavior (actual may be less), URL inclusion, and display expectations. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, especially the data display advice section which is lengthy and somewhat repetitive. While structured with sections and bullet points, it could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all 4 parameters, provides return format info, and includes practical usage context (e.g., how platforms are sourced, what to do with results). Given the presence of an output schema (not shown), the description is complete.
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 comprehensively. It explains date_query with natural language and standard formats, platforms with examples and config reference, limit with default and max, and include_url with default. Adds significant meaning 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 '获取指定日期的新闻数据，用于历史数据分析和对比', specifying the verb (get), resource (news data), and scope (by date, for historical analysis). This distinguishes it from siblings like get_latest_news and 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 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 this tool (historical data) and extensive advice on data display: when to show full data, when to summarize, and how to respond to user expectations. This helps the agent make appropriate decisions.
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 fully handles transparency. It explains the tool is read-only, processes a config file, and does not mutate data. Slight gap: no mention of behavior if config file is missing, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded main purpose, then note, then parameter details in bullet format. No redundant sentences.
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?
Complete for a simple tool with 2 optional parameters. Explanation of return format (JSON) and parameter defaults. No missing critical context.
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?
Input schema has 0% description coverage, but description fully explains both parameters: mode (daily/current with defaults) and top_n. Adds meaning beyond schema structure.
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 retrieves news frequency statistics for personal watchwords from a config file. It distinguishes from sibling tools like analyze_topic_trend or get_latest_news by specifying it is not automatic hotspot extraction.
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 notes when to use (personal watchwords) and when not (not for automatic hotspot extraction) and provides customization guidance. This is clear and actionable.
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/xhh-im/TrendRadar/badges/card.svg)](https://glama.ai/mcp/servers/xhh-im/TrendRadar)

Score Badge

Copy to your README.md:

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

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