TrendRadar MCP Server

Server Quality Checklist

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

Latest release: v6.9.1
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists: get_latest_news vs get_news_by_date both retrieve news, and search_news vs search_rss both search over different data sources. The analysis tools are well-differentiated through specific parameters.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., aggregate_news, analyze_sentiment, get_latest_news). The only minor deviation is read_articles_batch, which appends a qualifier but remains clear and predictable.
Tool Count4/5
27 tools is at the higher end but justified by the server's broad scope: news aggregation, multiple analysis types, storage management, notifications, RSS, date resolution, and system checks. A few tools could potentially be merged, but the count is not excessive.
Completeness5/5
The tool set covers the full lifecycle: data retrieval (multiple methods), analysis (sentiment, trend, comparison, aggregation), storage sync, notification sending, configuration checks, and even date resolution. No obvious gaps for a news monitoring and notification system.
Average 4.1/5 across 27 of 27 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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 bears the full burden of disclosing behavioral traits. It only states that the tool outputs a JSON report with Markdown content. It does not mention whether the tool is read-only, has side effects (e.g., creating storage), requires authentication, or has rate limits. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a header line and structured Args/Returns sections. Every sentence adds value, though the date_range explanation could be slightly more compact. No redundant or vague statements.
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 presence of an output schema (not shown but indicated), the description covers the input parameters adequately but misses usage guidance and behavioral context. The tool is relatively simple (2 optional params), so completeness is moderate. The return format is mentioned, so the agent understands what to expect.
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?
Despite 0% schema description coverage, the description adds substantial meaning. It explains report_type as 'daily' or 'weekly', and date_range as a specific object format with an example and a warning that it must be an object. This compensates well for the sparse schema, though no constraints like allowed values for report_type are given beyond the parameter type.
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 generates daily/weekly summary reports ('每日/每周摘要生成器 - 自动生成热点摘要报告'). The verb 'generate' and the resource 'summary report' are specific. While it does not explicitly differentiate from siblings like aggregate_news or analyze_data_insights, the distinct output (summary report in Markdown) implies a unique purpose.
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 only mentions the tool generates daily or weekly summaries. It provides no guidance on when to use this tool versus alternatives (e.g., aggregate_news for raw news, analyze_topic_trend for trends), nor any conditions or exclusions. The agent receives no 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?
With no annotations, the description must disclose side effects, but it only mentions optional persistence and return of task status. It omits details on data overwrites, network usage, duration, cancellation, or permissions. This is insufficient for safe agent use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with sections for purpose, args, returns, and examples. No redundant sentences. The use of Chinese in the intro may slightly hinder global readability but does not reduce structural quality.
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 an output schema exists and sibling tools are available, the description covers parameters and return format adequately. However, operational context (e.g., how long a crawl takes, concurrency limits) is missing, making it just adequate for a moderately complex action.
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 description adds meaningful explanations for all three parameters: platforms (list of IDs), save_to_local (boolean for output directory), include_url (boolean for URL inclusion). Since the schema has 0% description coverage, this added value is significant and clear.
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 triggers a manual crawl task with optional persistence. It lists parameters and examples, making the purpose evident. However, it could be more explicit about what 'crawl' means in context (e.g., data source) to distinguish from similar tools like get_latest_news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus siblings like sync_from_remote or get_latest_news. The examples show basic usage but do not explain scenarios where manual triggering is appropriate or preferable.
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 bears full responsibility for behavioral disclosure. It states the tool returns status information but does not indicate whether it is read-only, idempotent, or has any side effects. For a tool that retrieves configuration and status, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two clear sentences plus a return value description. Every piece of text adds value, and there is no redundancy or filler.
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 that the tool has no parameters and an output schema exists, the description adequately explains what the output contains (local/remote storage status and pull configuration). However, it does not explicitly clarify that the tool is read-only, which could be inferred from the name but should be stated for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% by default. The description does not need to explain parameters, and it adds no parameter information, which is acceptable. Baseline for 0 parameters is 4.
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 storage configuration and status, specifying 'current storage backend configuration, local and remote storage status.' While it distinguishes from broader system status tools like get_system_status, it does not explicitly differentiate from other storage-related tools like sync_from_remote.
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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when to use it (e.g., to check storage health), or when not to use it.
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 present, so the description carries full burden. It only describes the output fields and gives an example. It does not disclose whether the operation is read-only, whether it requires special permissions, if it is expensive to call, or any side effects. For a status tool, basic safety and cost information is missing.
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 mostly concise, with purpose stated in the first line, followed by a structured list of return fields. It includes an example. It could be slightly shorter by removing redundant line breaks, but overall it is well-organized and front-loaded.
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?
For a parameterless status tool with no output schema, the description adequately explains the return structure. However, it omits potential error cases (e.g., no feeds configured), performance characteristics, and does not clarify that it is a lightweight read. Given the tool’s simplicity, it is functional but not fully comprehensive.
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?
There are zero parameters, so the input schema is fully covered (100% vacuously). Per the calibration rules, baseline is 4 for zero parameters. The description does not need to add parameter-level details; it focuses on output structure and example, which is appropriate.
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 RSS feed status information, including configured feeds and data statistics (available_dates, total_dates, today_feeds). This is distinct from sibling tools like get_latest_rss (get feed items), get_storage_status (storage), or get_system_status (system). The verb 'get' and resource 'rss feeds status' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 explain that this tool provides an overview of feed health or that it is not for retrieving individual news items. The example shows a simple call without arguments, but no contextual cues help the agent decide between this and get_latest_rss, search_rss, or get_storage_status.
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. The description implies a read operation and specifies return format, but does not disclose additional behavioral traits such as caching, performance, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded, and wastes no words. The bullet list for parameter options is efficiently structured.
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 and the tool is simple (one optional parameter), the description covers the key aspects adequately. Minor lack of behavioral context is acceptable.
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 has 0% description coverage, but the description compensates by listing valid values and their meanings, adding clear semantics 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?
The description clearly states it retrieves current system configuration and lists specific sections. It is clear but does not explicitly differentiate from sibling tools like get_system_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. The description lists options but does not provide context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it compares local and remote versions and checks for updates, but does not mention side effects, network usage, or whether it modifies anything. The behavior is somewhat transparent but lacks depth.
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 concise with clear structure: purpose, Args, Returns, Examples. No wasted words, though the examples could be seen as slightly redundant given the simplicity. Front-loaded with the main 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?
Given there is an output schema, the description's mention of return format suffices. It covers the tool's inputs and purpose. Could mention that it makes network calls, but overall adequate for a simple check tool.
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 single parameter proxy_url is well explained: 'optional proxy URL for accessing GitHub' with an example. Since schema description coverage is 0%, the description adds significant value by providing usage context and a concrete example.
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 checks version updates for both TrendRadar and MCP Server by comparing local version with GitHub remote version. The verb 'check' and resource 'version' are specific, and the description distinguishes it from siblings by naming the two components.
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 vs alternatives like sync_from_remote or get_current_config. It does not mention prerequisites (e.g., network access) or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains parameters and return format but does not disclose potential side effects, required permissions, rate limits, or data freshness. It adequately describes behavior for a read-analysis tool but lacks depth.
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 (overview, suggestion, Args, Returns, Examples). It is informative without being overly verbose. A small amount of redundancy exists, but overall it is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, required 1, and existence of output schema, the description covers all parameters and provides examples. The return value is mentioned as JSON but not detailed; however, output schema exists to complement. The tool is well-documented for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides detailed explanations for all 8 parameters, including default values, formats, and mode-specific details (e.g., spike_threshold for viral, lookahead_hours for predict). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a unified topic trend analysis tool integrating multiple analysis modes. The verb 'analyze' and resource 'topic trend' are specific. While it distinguishes subtypes within the tool, it does not explicitly differentiate from sibling tools like analyze_sentiment or get_trending_topics, but the purpose is clear.
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 advises using resolve_date_range for natural language dates, which is helpful. It provides examples but does not explicitly state when not to use this tool or name alternatives. The guidance is present but not exhaustive.
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 fully disclose behavioral traits. It specifies that returns are in JSON format and includes important parameter constraints (e.g., date_range must be an object, not an integer). However, it does not address side effects, permission requirements, rate limits, or error behavior. The description is adequate but not comprehensive, leading to a score of 3.
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 (general description, Args, Returns, Examples). Every sentence is informative and contributes to understanding. It is concise (about 150 words in Chinese) without redundancy. The use of bullet points and formatting (bold, line breaks) enhances readability. This is an excellent example of conciseness and structure.
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 parameters, multiple modes) and the presence of an output schema (though not fully visible), the description covers all essential aspects: parameter definitions with defaults, examples, and a brief return type. It does not explain error handling or behavior with invalid inputs, but this is acceptable for a read-only analysis tool. The completeness is high, lacking only minor edge-case details, hence a score of 4.
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 carries the full burden. It thoroughly explains each parameter: insight_type with enumerated options and mode descriptions, topic as optional, date_range with required format and important note, min_frequency and top_n with defaults and applicable modes. Examples further clarify parameter usage. This exceeds basic requirements and adds significant meaning, warranting a score of 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a unified data insight analysis tool integrating multiple analysis modes (platform_compare, platform_activity, keyword_cooccur). The purpose is specific and actionable, but it does not explicitly differentiate from sibling analysis tools such as 'analyze_sentiment' or 'compare_periods', which have overlapping functions. The lack of sibling differentiation lowers the score from 5 to 4.
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 examples for each insight_type, implying when to use each mode (e.g., for platform comparison, platform activity, or keyword co-occurrence). However, it does not state when NOT to use this tool or mention alternative sibling tools. For instance, it does not clarify when to use this tool versus 'analyze_sentiment' for sentiment analysis. The guidance is implied but not explicit, earning a score of 3.
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 discloses key behaviors: deduplication of titles, default parameter values, and token-saving via 'include_url'. It does not mention authentication, rate limits, or error conditions. The output format is briefly described 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 well-structured: purpose, guidance, parameter list, return type, and an example. Every sentence adds value, and it is front-loaded with the core purpose. The length is appropriate for the complexity.
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 6 parameters, no annotations, and an output schema that exists, the description covers all user-facing aspects: parameter semantics, return structure, and a usage suggestion. It lacks details on error handling or edge cases, but it is mostly complete for a tool with an output schema.
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 has 0% description coverage, but the description compensates by explaining each parameter's meaning, format, and defaults. It provides examples for 'platforms' and 'date_range', though it omits the 'string' variant for 'date_range' allowed by the schema. Overall, it adds significant value.
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 analyzes sentiment and heat trends of news. It uses a specific verb ('分析') and resource ('新闻的情感倾向和热度趋势'), which distinguishes it from siblings like 'search_news' or 'get_latest_news' that lack sentiment analysis focus.
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 recommendation to use 'resolve_date_range' for natural language dates, which is useful. However, it does not explicitly state when to prefer this tool over alternatives like 'analyze_topic_trend' or 'find_related_news', nor does it mention contraindications.
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 handles transparency. It describes parameters and return format but lacks details on behavior like sorting, caching, or error states. Adequate but not exhaustive.
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?
Structured with purpose, args, returns, and a display suggestion section. Not overly long, but the display suggestions add slight overhead. 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?
Simple tool with 3 optional params and an output schema. Description covers the essentials, but could be more specific about the return structure (though output schema exists to fill 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 coverage is 0%, but the description fully explains all 3 parameters: platforms (list or null), limit (default 50, max 1000), include_url (boolean). Clear and complete.
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 fetches the latest batch of crawled news data to understand hot topics. It distinguishes from siblings like get_latest_rss (RSS vs crawled) and search_news (query-based).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives default behavior and display suggestions but does not explicitly compare to alternatives or state when to use this tool over others like search_news. Usage is implied but lacks exclusion guidance.
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 partially compensates by indicating returns include system version, data stats, and cache status. However, it does not disclose potential side effects (likely none for a read-only status) or authorization requirements. Adequate but not thorough.
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, using two sentences plus a return line. Every sentence adds value: purpose, content, and output format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema, the description covers the essential purpose and return data. It could be more specific about what 'data stats' includes, but is sufficient for a simple status tool.
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?
There are zero parameters, so the schema provides full coverage. The description adds no parameter info beyond what is already clear. Baseline of 4 is appropriate as no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves system runtime status and health check information, listing specific categories (version, data stats, cache status). This distinguishes it from sibling tools like check_version or get_storage_status which focus on narrower scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies general health monitoring but provides no explicit guidance on when to use this tool versus alternatives such as check_version or get_storage_status. Usage context is implied but not clarified.
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 full transparency burden. It discloses sorting by similarity, default behaviors (include_url=false saves tokens), and parameter ranges. However, it omits details on error handling, required permissions, or whether the operation is read-only (though inferable). Could be more 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 Args, Returns, and Examples sections. Every sentence adds value, and the key purpose is front-loaded. It is efficiently concise without missing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters) and presence of an output schema, the description covers all parameters, defaults, and usage examples. It lacks mention of error cases or behavior when no results are found, but overall it is sufficiently complete for an AI agent to use confidently.
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 compensates fully. It provides detailed explanations for all 5 parameters: reference_title (partial/full), date_range (with presets and custom format), threshold (range and meaning), limit (default 50), and include_url (default false, token saving). This adds significant value beyond the schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds related news based on a reference title, supporting current and historical data. It distinguishes itself from sibling tools like search_news and get_latest_news by focusing on finding similar content to a given article.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding related news when given a reference title, and provides options for date range. However, it does not explicitly state when not to use this tool or mention alternative siblings like search_news for broader queries.
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 full burden. It describes parameters and return format but does not disclose potential errors, authentication needs, rate limits, or side effects. It is 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?
The description is well-structured with a clear purpose sentence followed by explicitly labeled parameter explanations and return type. It is slightly lengthy but efficiently 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 has four optional parameters and an output schema exists, the description fully covers the essential aspects for correct invocation, including parameter formats, defaults, and 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?
The description adds substantial meaning beyond the input schema, detailing acceptable formats for date_range, default values, max limit, and rationale for include_url. This compensates for the 0% schema 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 explicitly states that the tool retrieves news data by specified dates for historical analysis, clearly distinguishing 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies usage for historical analysis, it does not provide explicit guidance on when to use this tool versus alternatives such as search_news or get_latest_news, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注解，描述承担完全责任。说明了返回结果为JSON格式及对比功能，但未提及权限、副作用或速率限制。作为列举工具，安全性尚可。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
结构清晰：摘要有中英文，然后是Args、Returns、Examples。虽然包含中英双语略长，但信息完整且前置了关键目的。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具简单（1参数），描述涵盖了参数选项和示例。存在输出模式（虽未提供），但描述提示了返回JSON日期列表及比较结果，足够用于调用。
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?
输入模式仅有source参数且无枚举值，描述补充了三个有效值及其含义，增加了模式之外的语义。模式描述覆盖率为0%，描述充分补偿。
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?
明确陈述了工具功能：列出本地和远程可用的日期范围。使用了具体动宾结构（列出+可用日期范围），并与兄弟工具（如resolve_date_range）自然区分。
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?
提供了使用示例和参数说明，但没有明确说明何时避免使用或与兄弟工具的替代关系。上下文信号中兄弟工具列表暗示了相关但有区别的工具。
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 full burden. It discloses that it merges similar news and shows cross-platform coverage, but lacks details on side effects, permissions, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Examples sections. While slightly lengthy, every sentence adds value and the formatting 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?
Given the tool's complexity (5 parameters, output schema exists), the description covers the main functionality and parameters adequately. It does not discuss error handling or edge cases, but is complete for typical 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?
With 0% schema description coverage, the description fully explains each parameter (date_range, platforms, similarity_threshold, limit, include_url) including defaults, meaning, and example values, adding 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 aggregates news across platforms and deduplicates similar news, distinguishing it from sibling tools like get_latest_news or 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 context for usage (e.g., defaults for date_range, platforms) and examples, but does not explicitly state when to use this tool versus alternatives or when not to use it.
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 effectively discloses behavioral traits: it returns JSON, supports parameters like include_summary to save tokens, and imposes limits. It implies a read-only operation and provides examples of usage.
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, context, Args, Returns, and Examples sections. It is mostly concise, though the first sentence about storage could be considered slightly extraneous but not detrimental.
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 simplicity (4 params, none required, output schema exists), the description covers purpose, parameters, return format, and examples. It is complete enough for an agent to use correctly, though the 'Returns' is vague but compensated by the output schema.
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, but the tool description includes a detailed Args section explaining each parameter (feeds, days, limit, include_summary), including defaults, maximums, and effects, adding significant value 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 that the tool retrieves the latest RSS subscription data with multi-day query support. It distinguishes itself from sibling tools like get_latest_news by emphasizing that RSS data is stored separately from hot news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates suitability for getting latest content from specific RSS sources but does not explicitly compare with alternatives like search_rss or get_latest_news. Usage guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It explains the behavior (returns JSON frequency list) and default parameters, but does not mention potential limitations, error conditions, or data freshness. For a read-only tool, this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Examples) and uses bullet points consistently. It is somewhat verbose (e.g., repeating '默认' multiple times) but remains readable and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, multiple modes) and the existence of an output schema, the description covers parameter semantics, return format, and usage examples adequately. It could be improved by mentioning when data is refreshed or how the config file works, but overall it is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description fully explains all three parameters: top_n (default 10), mode (daily vs current), and extract_mode (keywords vs auto_extract), including their default values and concrete options. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves trending topics statistics, with specific verb 'get' and resource 'trending topics'. It distinguishes from sibling tools like get_latest_news and search_news by focusing on trending analysis. The modes (daily/current) and extraction methods (keywords/auto_extract) provide additional specificity.
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 when to use each mode and extract_mode, including examples. However, it does not explicitly mention when not to use this tool or compare to alternatives like analyze_topic_trend or compare_periods, which could be considered for deeper analysis.
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 reveals it only reads configurations, returns JSON status and source, and lists supported channels. No side effects mentioned, consistent with a read-only operation. Adds detail beyond structural fields.
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 at 4 sentences, including a clear purpose, configuration detection, supported channels, return format, and an example. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema present, the description fully covers what the tool does, what it returns, and usage hints. The example clarifies calling syntax. No gaps for this simple tool.
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 (0), so schema coverage is 100%. Description adds value by explaining the return format (JSON with status and source) and listing channels, which enriches understanding beyond the empty 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 explicitly states the tool retrieves all configured notification channels and their status, using verbs like '获取' (get) and specifying the resource '通知渠道' (notification channels). It distinguishes from siblings like 'send_notification' and 'get_current_config' by focusing on channel configuration status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates it detects configuration from config.yaml and .env, implying use for checking channel setup before sending. However, no explicit guidance on when to use vs alternatives like 'get_current_config' or 'send_notification', nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the behavior (pull data, skip existing local files) and prerequisites (config). It does not mention potential side effects like overwriting, but skipping existing files implies non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Examples, Note) but is somewhat lengthy. Every sentence contributes value, though minor trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description adequately covers parameter details, configuration, and examples. It lacks info on error handling or edge cases beyond 'failed_dates', but overall is sufficient for a single-parameter 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 input schema only provides a default and type for 'days'. The description adds significant meaning by specifying valid values (0, 7, 30) and their effects, which is essential for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: pulling data from remote storage to local. It distinguishes itself from sibling tools (e.g., search, aggregate) by focusing on data synchronization.
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 specifies the intended usage scenario (MCP Server) and provides configuration prerequisites. While it doesn't explicitly state when not to use this tool or list alternatives, the context makes its unique role clear.
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 fully carries the burden. It explains the tool's behavior: it compares two periods and returns a JSON result with structured fields based on compare_type. It implies read-only analysis (no mention of modification), but could explicitly state it is non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (main purpose, use cases, args, returns, examples). It is relatively long but each sentence adds value. Minor redundancy could be trimmed, but overall it is efficiently 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 6 parameters, no schema descriptions, and a complex structured output, the description is extremely thorough. It explains input formats, output fields per compare_type, and provides three concrete examples. The output schema is mentioned and the return structure is described adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates completely. It details every parameter: period1/period2 formats (object or presets), topic optionality, compare_type with enumerated values and their meanings, platforms as a filter list, and top_n integer. Examples illustrate usage, making the semantics crystal clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: comparing news data between two time periods. It specifies the verb 'compare periods' and the resource 'news data'. The examples (e.g., week-over-week comparison, topic shift analysis) further clarify its distinct role among sibling tools 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated '使用场景' section with concrete scenarios (e.g., comparing weekly changes, topic heat differences) and multiple examples. However, it does not explicitly state when not to use this tool or mention alternative sibling tools, missing some guidance on tool selection.
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 burden. It clearly describes search behavior, modes, defaults, and return format. Read-only nature is implicit but not stated, which is acceptable for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for args and examples. It is appropriately sized given the parameter count, though 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 10 parameters, 1 required, no output schema, the description covers all parameters, search modes, and provides examples. 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description fully explains all 10 parameters with types, defaults, and meanings, adding significant value 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 it's a unified search interface for news, supporting multiple search modes, hotlists, and RSS. It distinguishes from siblings like search_rss and get_latest_news by mentioning simultaneous searching of hotlist and RSS.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a useful suggestion to call resolve_date_range for natural language dates. It explains the search modes and parameters but lacks explicit when-not-to-use guidance compared to 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?
No annotations are provided, so the description carries the full burden. It describes the search operation, return format (JSON list), and parameter constraints (max 30 days). It implies a read-only operation without side effects, but does not explicitly state the lack of destructive actions.
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: a brief purpose line, then Args section, Returns section, and Examples. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description appropriately mentions the return format. It covers all parameters, examples, and usage context. No gaps are identified for a 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?
Schema description coverage is 0%, but the description provides detailed explanations for all 5 parameters, including defaults, constraints (e.g., max 30 days), and examples. This adds significant value beyond the input schema, which only defines types.
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 searches RSS feeds for articles containing a keyword. It specifies the exact resource (RSS data) and action (search), distinguishing it from other tools like get_latest_rss or 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 clear context for when to use the tool (searching RSS data for keyword) and includes examples. However, it does not explicitly mention when not to use it or compare it to alternative sibling tools like search_news or get_latest_rss.
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, but the description fully discloses the return format (JSON with features, limitations, prompts) and that it is a read-only query. It does not explicitly state 'no side effects', but the nature is clear.
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 (purpose, usage, channel list, args, returns, examples) and front-loaded. However, it is somewhat verbose with the extensive channel format comparisons; could be slightly 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?
With an output schema present, the description covers all necessary information: purpose, usage timing, parameter details, return structure, and examples. It fully equips 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?
The only parameter 'channel' is fully explained: optional, defaults to returning all channels, and a complete list of possible values is provided in the description, compensating for 0% schema 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 the tool retrieves formatting strategy guides for notification channels, including Markdown features, limitations, and best prompts. It distinguishes itself from sibling tools like send_notification by positioning itself as a pre-send helper.
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 states '在调用 send_notification 之前使用此工具' (use before calling send_notification). Provides examples for retrieving all or specific channel guides, making the usage context absolutely clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses key behavioral traits: uses Jina AI Reader, converts to Markdown, auto-removes noise, has 100 RPM rate limit, built-in 5-second interval, and potential limitations with paywalled pages. This exceeds the burden for unannotated tools.
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 (purpose, typical flow, args, returns, examples, notes) and front-loaded with the main action. While slightly verbose, each sentence adds value and aids comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and an existing output schema, the description covers all necessary aspects: input parameters, behavior, rate limits, examples, and limitations. It provides a comprehensive understanding of the tool's operation and constraints.
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 adds crucial meanings: url must start with http/https, timeout defaults to 30 and max is 60. It explains the purpose of each parameter beyond the raw schema, fully compensating for the lack of property 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 that the tool reads article content from a URL and returns LLM-friendly Markdown. It distinguishes itself from sibling tools like read_articles_batch by specifying single-article reading, and from search_news by being the subsequent step in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear typical usage flow (search_news then read_article) and states appropriate use cases (reading news, analyzing content). However, it does not explicitly mention when NOT to use the tool or direct alternatives for similar tasks.
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?
由于无注释，描述承担全部行为披露责任。详细说明了自动间隔5秒的速率限制、最多5篇、超时默认30秒、单篇失败不影响其他、预计耗时等，透明性极高。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述结构清晰：一行摘要、典型流程、参数说明、返回格式、示例、注意事项。每句话都有价值，无冗余，信息密度高。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
对于这个相对简单的工具，描述覆盖了输入、行为、限制、错误处理、耗时估计，并配合输出模式无需额外说明，完成度很高。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入模式中参数无描述（coverage 0%），描述明确解释了urls（必需，列表）和timeout（默认30），并给出示例和限制，完全补偿了模式缺失。
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?
描述明确说明工具用于批量读取多篇文章内容，最多5篇，间隔5秒。与兄弟工具read_article（单篇）形成鲜明对比，使用流程中强调了先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?
描述了典型使用流程（搜索-批量-分析），暗示了何时使用该工具。但未明确说明在单篇文章场景下应使用read_article，也未列举排除情况，指南性略有不足。
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?
No annotations are provided, but the description fully discloses the tool's behavior: it uses server-side current time for consistent results, returns a JSON date range, and explains the return fields including success, expression, date_range, current_date, and description.
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. It is front-loaded with the recommendation. However, it is slightly verbose with repeated examples; could be tightened while retaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description is exceptionally complete. It explains why the tool exists, when to use it, how to use it, and what it returns. No gaps remain.
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 description coverage, but the description compensates by listing supported formats (single day, week, month, last N days) with examples. This adds far more meaning than the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: parsing natural language date expressions into standard date ranges. It distinguishes itself from sibling tools by being a utility date resolver, not a news or analysis 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?
The description explicitly recommends this tool as a 'preferred first call' and provides a clear step-by-step workflow with examples showing how to integrate 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details how messages are adapted per channel (e.g., markdown conversion, formatting restrictions), includes return format (JSON with per-channel status), and mentions the default behavior when no channels specified.
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?
Front-loaded with the core function, followed by structured bullet points for channel specifics, a tip referencing a sibling tool, and clear Args/Returns/Examples sections. No wasted 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?
Given the tool's complexity (8+ channels with format conversions), the description is exhaustive, including examples and exact behavior per platform. Output schema exists but description already specifies return format.
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 fully explains all three parameters: message (required, markdown), title (default), and channels (list with enumerated values, default all). It compensates completely for the lack of 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 description clearly states it sends messages to configured notification channels, listing specific platforms. It distinguishes from siblings like get_channel_format_guide, which is mentioned as a complementary 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?
Explicit guidance is given: when to use the tool (to send notifications) and a recommendation to call get_channel_format_guide first for optimal formatting. No when-not conditions are needed given its clear purpose.
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/cutejhy-code/TrendRadar/badges/card.svg)](https://glama.ai/mcp/servers/cutejhy-code/TrendRadar)

Score Badge

Copy to your README.md:

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

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