TrendRadar MCP Server

Server Quality Checklist

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

Latest release: v6.10.0
Disambiguation4/5
Tools are generally distinct with clear purposes, but some overlap exists between search and related-news tools, and between multiple analyze tools. Descriptions help disambiguate.
Naming Consistency5/5
All tools use consistent verb_noun snake_case naming (e.g., aggregate_news, get_latest_news, search_news), making them predictable and easy to understand.
Tool Count4/5
27 tools is slightly high for a news monitoring server, but each tool serves a distinct function across news aggregation, analysis, search, RSS, notifications, and configuration. Some consolidation could reduce count.
Completeness4/5
Core workflows are well-covered: fetching, searching, analyzing, aggregating, and notifying. Minor gaps include no tool for modifying configuration or managing keywords, but the surface is largely complete for its purpose.
Average 4.1/5 across 27 of 27 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- 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 should fully disclose behavioral traits. It only describes the return content without stating that the operation is read-only, non-destructive, or any other behavioral context.
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 short and to the point, but includes bilingual text which adds slight redundancy. Still efficient.
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 simple tool with no parameters and an output schema, the description covers the basic return information. However, it lacks usage guidelines and behavioral context, making it minimally viable but not robust.
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 zero parameters, so schema coverage is effectively 100%. The description adds no param info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets system status and health check information, returning version, stats, and cache status. It effectively communicates the purpose, but does not explicitly differentiate from sibling tool 'check_version'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'check_version'. There is no mention of prerequisites or context for invocation.
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 convey behavioral traits. It explains parameter behavior and return format but does not explicitly state that the tool is read-only (no side effects) or discuss any destructive actions. It also lacks disclosure of authorization needs or rate limits. The description is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately structured with a title, suggestion, Args list, Returns, and Examples. However, it mixes Chinese and English, which may be confusing, and the Args list is somewhat lengthy. While not overly verbose, it could be more concise by removing redundant phrasing.
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 8 parameters, 1 required, and no annotations, the description covers the parameter usage, return type, and provides examples. However, it lacks information about error handling, edge cases, or behavior when parameters are omitted. The output schema exists but is not detailed in the description, leaving some gaps in 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?
With 0% schema description coverage, the description compensates well by explaining each parameter's purpose, including analysis_type enum values (trend, lifecycle, viral, predict), date_range format, and specific parameters for viral and predict modes (spike_threshold, time_window, lookahead_hours, confidence_threshold). This adds significant meaning beyond the schema's bare 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's purpose: unified topic trend analysis with multiple modes (trend, lifecycle, viral, predict). It specifies the resource (topic trends) and the verb (analyze). While it does not explicitly differentiate from sibling tools like get_trending_topics or search_news, the purpose is distinct enough for an agent to understand its function.
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 a suggestion to call resolve_date_range for natural language dates, which is helpful. However, it does not provide explicit guidance on when to use this tool versus alternatives, nor does it discuss when not to use it (e.g., for simpler trend queries or other analysis types from siblings). The guidance is partial.
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?
Without annotations, the description must disclose behavior. It notes that 'include_url' defaults to False to save tokens and mentions title deduplication for 'limit'. However, it does not explicitly state that the tool is read-only, nor does it cover authentication, rate limits, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief summary, usage suggestion, parameter list, return description, and example. It is concise without unnecessary redundancy, using bullets and clear formatting.
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 moderate complexity and the presence of an output schema, the description covers essential aspects including parameter details and output structure. It lacks error handling or edge cases, but is otherwise complete for an AI agent.
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?
With 0% schema description coverage, all six parameters are explained in the description, including defaults and constraints (e.g., 'limit' max 100, 'date_range' format). The explanations are clear, though possible platform values are not enumerated.
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 specifies the tool's function: analyzing sentiment tendency and heat trends of news. It uses a specific verb and resource ('analyze sentiment and heat trends'), but does not explicitly differentiate from sibling tools like 'analyze_topic_trend' that may perform similar analyses.
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 suggestion to use 'resolve_date_range' for natural language dates and includes an example. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'search_news' for raw news retrieval) or conditions where it might not be appropriate.
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 should fully disclose behavioral traits. It mentions the return format (JSON with Markdown) and parameter constraints (date_range must be an object), but does not discuss side effects, destructive actions, authentication needs, rate limits, or whether it reads cached data. The description partially compensates but has significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with an Args section, but the date_range explanation is verbose and includes examples and warnings. Could be more concise, but the structure is good and information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no required fields, the description covers the main functionality and return format. However, it lacks prerequisites or limitations (e.g., data source, availability). The output schema exists but is not provided here; assuming it works, the description is nearly 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 description coverage is 0%, making the description the sole source of parameter meaning. It clearly explains 'report_type' (daily/weekly) and 'date_range' (optional object format with examples and warnings). This adds substantial 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?
Clearly states the tool generates a daily/weekly summary report (热点摘要报告). The verb 'generate' and resource 'summary report' are explicit. It distinguishes from sibling tools like aggregate_news or analyze_data_insights, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the parameters but does not explicitly state when to use this tool versus alternatives. Usage is implied (for generating summaries), but there are no when-not conditions or alternative tool suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the return structure, suggesting a read-only operation, but does not explicitly state side effects, permissions, or error conditions. The behavioral traits are somewhat implied but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a heading, explanation, detailed return format, and example. It is appropriately sized for the tool's simplicity, though could be slightly more streamlined.
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 an output schema effectively described in the description, it is fairly complete. However, it lacks mention of potential empty results or error states, which would be beneficial.
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 no parameters, so the baseline is 4. The description adds no param-specific info, but that is acceptable given the zero parameters.
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 RSS feed status information, including data statistics. The verb '获取' (get) and resource 'RSS 源状态' (RSS feed status) are specific, and the detailed return format distinguishes it from sibling tools like 'get_latest_rss' or 'search_rss'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It implies usage for checking status, but lacks comparisons or conditions for when not to use it, which is a gap.
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 full burden. It describes the parameters and return format (JSON) but does not disclose whether the operation is read-only, destructive, or requires authentication. The behavior is partially transparent but lacks safety context.
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 sections for Args, Returns, and Examples. Every sentence adds value, and the key details are front-loaded. It is concise yet informative, with no extraneous 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 that there is an output schema (though not shown), the description explains the return type (JSON list of topic frequencies) adequately. The parameter descriptions and examples cover typical scenarios. It is sufficiently complete for a tool of this complexity, though one might desire more detail on the output 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 input schema has 0% description coverage, meaning the schema provides no parameter explanations. The description fully compensates by detailing each parameter: top_n (default 10), mode (daily vs current), and extract_mode (keywords vs auto_extract). This 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?
The description clearly states it retrieves trending topic statistics, with explicit parameter details. While it doesn't explicitly distinguish from siblings like aggregate_news or analyze_topic_trend, the verb 'get' and resource 'trending topics' make the purpose 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 includes usage examples but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. No exclusions or prerequisites are mentioned, leaving usage context partially implied.
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, description bears full burden. It details parameter defaults and token savings but does not disclose error handling, authentication needs, rate limits, or side effects. For a read-like operation, 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?
Well-structured with purpose sentence upfront and clear Args/Returns sections. Slightly verbose but each part adds value; no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and presence of output schema, description covers parameters and returns adequately. Lacks error scenarios but is complete for typical usage. Could include more on invalid inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description provides all meaning. It explains date_range formats (range object, natural language, single date), platforms as list, limit with default and max, include_url with reason for default. Adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves news data for a specified date for historical analysis and comparison. The verb '获取' (get) and resource '新闻数据' (news data) are specific. Distinguishes from siblings like get_latest_news or search_news by emphasizing historical data.
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?
Implies use for historical analysis but lacks explicit when-to-use or when-not-to-use guidance. No mention of alternatives among siblings like get_latest_news for current news or search_news for keyword search.
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 states the tool returns JSON with storage status, implying a read-only operation. However, it does not disclose behavioral traits such as required permissions, potential delays, error handling, or any effects on storage state. The description is adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with two sentences and a Returns clause, front-loading the main purpose. Every sentence adds value without redundancy. The structure 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 tool's simplicity (no parameters, output schema present), the description covers the essential information: what it retrieves and the return format. It does not elaborate on error cases or interpretation of status values, but with an output schema, the completeness is adequate for an agent to use the tool correctly in most scenarios.
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 schema description coverage is 100% (trivially). The description appropriately adds no parameter details since there are none. It explains what the tool returns (JSON format with local/remote storage status and pull configuration), which adds value beyond the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves storage configuration and status, including local and remote storage. It uses specific verbs '获取' (get) and '查看' (view) which indicate a read-only operation. Among siblings like get_system_status and get_rss_feeds_status, it is uniquely identifiable as the storage-focused status tool.
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 use for checking storage status but provides no explicit guidance on when to use this tool versus alternatives like get_system_status or when not to use it. There is no mention of prerequisites or conditions that make this tool appropriate or inappropriate.
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 the action (trigger crawl) and parameters, but does not disclose side effects, prerequisites, or non-obvious behaviors beyond the basic functionality.
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. It is clear but slightly verbose (e.g., '（可选持久化）' could be removed). Still, it efficiently conveys the 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 simplicity (3 optional params), the description covers the core functionality and provides examples. It lacks information on error handling or authentication, but the output schema is mentioned. Overall, it is adequate 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?
The description explains all three parameters (platforms, save_to_local, include_url) with context beyond the schema, such as default behavior ('不指定则使用所有平台') and reasons ('节省token'). This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '手动触发一次爬取任务' (manually trigger a crawl task), which is a specific verb+resource. It clearly distinguishes from sibling tools like get_latest_news or search_news, which retrieve data, while this triggers the crawl.
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?
Usage is implied but not explicitly stated. The description provides examples but does not say when to use this tool versus alternatives, 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?
With no annotations, the description carries full burden for behavioral disclosure. It indicates the tool returns JSON results and analyzes data, implying read-only behavior, but does not explicitly state it has no side effects or whether it requires specific permissions. This is 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.
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 bullet points for clarity. While slightly verbose, every sentence adds value. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to detail return values. It covers all 5 parameters, explains each insight_type, and provides multiple usage examples. For a multi-mode analysis tool, this is comprehensive.
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 no parameter descriptions, so the description fully compensates by explaining each parameter: insight_type with enumerated options, topic applicability, date_range format with a critical object-type note, and defaults for min_frequency and top_n. Examples further clarify usage.
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's a unified data insight analysis tool with three specified modes (platform_compare, platform_activity, keyword_cooccur) and briefly describes each. However, it does not explicitly differentiate from sibling tools like analyze_sentiment or analyze_topic_trend, leaving potential overlap ambiguous.
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 insight_type through its description and examples. However, it lacks explicit guidance on when not to use the tool or alternatives among siblings, which would strengthen 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 fully carries the burden. It discloses that the tool reads configuration from files (config.yaml and .env), returns JSON with channel status and configuration sources, and lists all supported channels. It is a pure read operation with no destructive side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise overall, but the list of channels is somewhat redundant and could be shortened. It is well-structured with a title sentence, details, and return format.
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 an output schema (though not shown), the description provides sufficient detail: it explains what is returned (JSON with channel status and source) and how the configuration is detected. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the baseline is 4. The description adds value by explaining the output format and the configuration sources, which is helpful for understanding what the tool returns.
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 all configured notification channels and their status. It lists 9 specific channels and mentions the configuration sources (config.yaml and .env), distinguishing it from sibling tools like get_current_config or get_system_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does and its configuration sources, but does not provide explicit guidance on when to use it versus alternatives or when not to use it. The purpose is clear enough that an agent could infer usage, but lacks explicit directives.
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 convey behavioral traits. It correctly indicates the tool is a read operation that lists dates, but it does not mention potential side effects, access requirements, or behavior on empty results. The description is adequate but lacks depth for a fully transparent disclosure.
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 separate sections for Args, Returns, and Examples, making it easy to scan. However, the first two lines are redundant ('列出本地/远程可用的日期范围' and '查看本地和远程存储中有哪些日期的数据可用。' essentially repeat the same idea), which slightly reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, the description provides all necessary information: parameter options, return format (JSON with date info and comparison), and two usage examples. Given the low complexity and the presence of an output schema (as per context), the description is complete and sufficient.
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 one parameter 'source' with a default but no description or enum constraints, so schema coverage is 0%. The description compensates fully by listing the three allowed values ('local', 'remote', 'both') and explaining each one's effect, adding critical semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available date ranges from local and remote storage. The verb 'list' and resource 'available dates' are specific and distinct from sibling tools like 'get_storage_status' or 'resolve_date_range', which serve different purposes. The purpose is immediately clear in both Chinese and English.
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 of usage and explains the 'source' parameter options, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. There is no mention of prerequisites or restrictions, leaving the agent to infer usage context from the parameter choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: returns JSON list, requires keyword, optional feeds (default all), days default 7 max 30, limit default 50, summary flag. No contradictions. It does not mention error handling, rate limits, or auth, but covers the primary behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line, Args list, Returns, and Examples. It is compact and efficient, with no redundant information. Every sentence contributes meaningfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, output schema exists), the description covers input constraints, default behaviors, and output format. It includes examples. It could mention error cases or pagination beyond limit, but overall it is sufficiently complete 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%, so the description must compensate. It provides detailed explanations for all 5 parameters: keyword (required), feeds (list or null, default all), days (default 7, max 30), limit (default 50), include_summary (default False). This 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches RSS data for articles containing a keyword. It is specific about the resource (RSS subscription data) and the action. However, it does not explicitly differentiate from sibling tools like search_news or get_latest_rss, which could have overlapping functionality.
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?
Usage is implied through examples and parameter descriptions, but there is no explicit guidance on when to use this tool instead of alternatives, nor any conditions under which it should not be used. The examples provide basic context but no exclusions.
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 details auto-adaptation per channel, which is valuable. However, it does not disclose potential errors, rate limits, message length limits, or authentication requirements. This leaves gaps in behavioral understanding.
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: summary, channel specifics, hint, Args, Returns, Examples. It is front-loaded with key purpose. The bullet points for channels are efficient. Slightly longer than necessary but each part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, return format, and refers to sibling for details. It lacks explanation of error handling or fallback behavior. With no annotations, this is a minor gap, but overall it is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by explaining message format (markdown), title default, and channels list with values. Examples clarify usage. Missing constraints like max length or validation rules.
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 sends messages to configured notification channels. It distinguishes itself from siblings like get_channel_format_guide and get_notification_channels by focusing on actual sending. The verb 'send' and resource 'notification channels' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using get_channel_format_guide before sending for detailed formatting strategies, which is good usage guidance. Examples are provided. However, it does not explicitly state when not to use the tool, though context makes it 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, the description carries full burden. It explains threshold, limit, date_range defaults (today if unspecified), include_url option, and return format (JSON sorted by similarity). This provides good behavioral context.
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. It is front-loaded with purpose. While informative, it could be slightly more concise, but every sentence adds value.
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 5 parameters, 1 required, and an output schema exists, the description covers input details and return format. It does not mention error handling or edge cases, but is adequate 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 coverage is 0%, so description must compensate. It thoroughly explains each parameter: reference_title (complete or partial), date_range (options and defaults), threshold (0-1, default 0.5), limit (default 50), include_url (default False). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds news related to a specified title, supporting current and historical data. It uses a specific verb and resource, distinguishing it from siblings like search_news or get_latest_news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding related news by title but does not explicitly state when to use it over alternatives like search_news or analyze_topic_trend. No when-not or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the tool compares local and remote versions, returns JSON with update info, and mentions the optional proxy parameter. It is transparent about its network-dependent behavior, though it does not discuss error handling (e.g., if GitHub is unreachable).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with clear sections for description, args, returns, 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.
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 and the presence of an output schema, the description sufficiently explains the return format. It could note potential failure modes, but overall it is complete for a version check utility.
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 thoroughly explains the single parameter 'proxy_url' as an optional proxy for GitHub access, adding significant meaning beyond the schema (which only defines it as string|null). Schema coverage is 0%, so the description fully compensates.
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 checks version updates for both TrendRadar and MCP Server, comparing local vs GitHub remote. This is specific and distinct from sibling tools which focus on news, analysis, and RSS operations.
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 basic context and an example, but lacks explicit guidance on when to use vs alternatives or when not to use. For a simple utility, this is adequate but not explicit.
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?
Without annotations, the description fully discloses that the tool returns JSON format strategies including supported features, limitations, and prompts. It is a read-only operation with no side effects, and the description adequately covers expected 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 a clear overview, bullet list of channel differences, and sections for args, returns, and examples. While slightly lengthy, the structure ensures all necessary information is front-loaded 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 (though not shown), the description already details return content. It covers channel options, differences, and usage patterns, making it complete for a guide 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?
Schema coverage is 0%, but the description enriches the channel parameter by listing possible values (feishu, dingtalk, etc.) and providing usage examples. This compensates for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: returning formatting strategy guides for notification channels. It distinguishes itself from sibling tools like send_notification by explicitly advising to use this tool before sending notifications to understand format requirements.
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 when to use this tool ('before calling send_notification'), providing clear context. It does not explicitly state when not to use it or mention alternatives, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that include_url=false saves tokens, and explains default display behavior. It does not explicitly state read-only or nondestructive nature, but the context implies it.
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 structured with Args, Returns, and display suggestions. It is clear but slightly verbose with the display suggestions; 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 output schema exists, return value explanation is sufficient. Parameter descriptions are thorough, and display suggestions complete the usage context. Comprehensive for a list-style 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%, so description fully compensates. Each parameter is explained: platforms (list, defaults all), limit (0-1000, default 50), include_url (default false, token-saving). This adds crucial semantics.
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 gets the latest batch of crawled news data for understanding current hotspots. It uses specific verbs and distinguishes from siblings like get_news_by_date 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?
The description provides display suggestions but does not explicitly compare with sibling tools like get_news_by_date or search_news. The advice on data presentation is helpful, but when-to-use guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full weight. It explains default behaviors (e.g., include_summary saves tokens) and return format, but does not mention potential side effects or rate limits, which are likely minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a title, explanatory paragraph, Args, Returns, and Examples sections. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the sibling tools and presence of an output schema, the description covers essential context. It notes the data separation from hot news, but could be more explicit about when to use RSS vs other news tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description fully compensates by explaining each parameter: feeds (list, default all), days (max 30), limit (max 500), include_summary (saves tokens). This provides complete meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves latest RSS subscription data and notes its separation from hot news. It implies a distinction from get_latest_news but does not explicitly name alternatives, missing a point for differentiation.
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 parameter explanations with defaults and limits, plus examples. It lacks explicit instructions on when not to use this tool or when to prefer siblings, but the context about RSS vs hot news offers implicit 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 provided, the description carries full burden for behavioral disclosure. It explains the return format (JSON with hotlist and optional RSS) and details parameter effects like threshold for fuzzy mode. However, it does not mention read-only nature, rate limits, or response behavior on empty queries. A more explicit statement about side-effects would improve transparency.
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) and front-loads the purpose. Every sentence adds value, but the Args section could be slightly more concise as it partially repeats schema defaults. Overall, it is effective without being 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 complexity (10 parameters, 1 required) and the presence of an output schema, the description is complete. It explains all parameters, provides examples, and clarifies the return structure. No critical gaps are present, making it easy for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It does so by providing detailed explanations for all 10 parameters, including defaults, allowed search_mode values, and the date_range format. This adds significant meaning beyond the bare schema, fully compensating 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 is a unified search interface for news, supporting multiple search modes (keyword, fuzzy, entity) and can search both hotlists and RSS simultaneously. This effectively distinguishes it from specific sibling tools like 'search_rss' or '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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a suggestion to call 'resolve_date_range' for natural language dates and mentions default behavior for platforms. Examples show typical usage. However, it lacks explicit guidance on when NOT to use this tool versus alternatives like 'aggregate_news' or 'get_news_by_date'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full responsibility for behavioral disclosure. While it describes parameters and return structure, it does not mention whether the tool is read-only, any required permissions, data freshness constraints, or potential side effects. This leaves gaps for an agent to safely invoke the 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 clear sections (usage scenarios, args, returns, examples). It is verbose but justified given the schema coverage gap. Minor redundancy exists between the Args list and the schema, but overall it remains readable and front-loaded with the core 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?
The description covers parameters, return format, and provides examples. However, given the tool's complexity (6 parameters, 2 required) and no annotations, it lacks details on error handling, data availability (e.g., what if dates have no data?), and performance considerations. An output schema is mentioned (present), which helps, but the description could be more complete about edge cases.
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 for parameters, but the description thoroughly explains every parameter: period formats (with examples like 'last_week' or date objects), compare_type options (with detailed effects), platform filtering, and top_n. This fully compensates for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares two time periods of news data across multiple dimensions (hot topics, platform activity, news count), using strong verbs like '比较' (compare) and '分析' (analyze). It distinguishes itself from sibling tools like 'aggregate_news' or 'analyze_topic_trend' by focusing specifically on period comparison.
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 includes a dedicated '使用场景' section with concrete use cases (week-over-week comparison, topic shift analysis, platform activity changes) and provides three explicit examples covering different parameter combinations, making it clear when to use this tool and how to configure 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?
No annotations are provided, so the description carries the full burden. It indicates the tool returns JSON configuration but does not disclose read-only behavior, authentication requirements, or any potential side effects. The description is adequate but lacks explicit behavioral cues.
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 with the purpose, and efficiently organized into Args and Returns sections. Every sentence is informative and necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read configuration tool with one parameter and an existing output schema, the description provides complete context. It explains the parameter thoroughly and mentions the return format, despite the output schema being present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for the single parameter 'section', giving 0% schema coverage. The description compensates fully by explaining the allowed values ('all', 'crawler', etc.) and what each returns, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取当前系统配置') and resource (system configuration). It is distinct from sibling tools, which focus on news, analysis, and other functions.
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 detailed Args section listing parameter options and their meanings, giving clear context for when to use the tool. However, it does not explicitly state when not to use it or suggest 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, the description carries full burden; it discloses use of Jina AI Reader, rate limits (100 RPM), built-in rate control, and potential issues with paywalled pages, making behavior transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage flow, args, returns, examples, notes) and is front-loaded, though slightly verbose with redundant bullet points.
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 and only 2 parameters, the description covers usage flow, limitations, and output format sufficiently for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, but the description adds crucial meaning: url must start with http/https, timeout defaults to 30 and max 60, thus fully compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads article content from a specified URL and returns LLM-friendly Markdown, distinguishing it from siblings like search_news (for finding URLs) and read_articles_batch (for batch reading).
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 typical usage flow (search_news then read_article), lists suitable use cases, and notes limitations (paywalls), but does not explicitly state when not to use or list all 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?
Describes server-side exact time calculation for consistency, return format, and supported expressions. No annotations provided, so description carries full burden, but it lacks mention of error handling or edge cases.
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, front-loaded recommendation, and examples. Slightly long but justified by the detail needed for date parsing patterns.
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?
Includes output schema example and return structure, making the tool's behavior fully predictable. No gaps given the tool's simplicity and the presence of 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 single parameter 'expression' is thoroughly explained with examples of supported formats. Schema coverage is 0%, so description fully compensates, adding significant meaning.
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?
Clearly states the tool resolves natural language date expressions into standardized date ranges, with examples showing integration into workflows. Distinguishes itself from siblings by addressing a specific need not covered by other tools.
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?
Explicitly recommends when to use this tool (when users use natural language dates) and provides a step-by-step workflow. Does not explicitly state when not to use, but the use case is narrow and 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?
Without annotations, the description discloses key behaviors: merging similar events, returning dedup statistics and coverage info. It does not mention side effects or auth needs, but as a read-only aggregation tool, this is acceptable.
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: a one-line summary, a brief explanation, bullet-pointed args with clear explanations, return format, and examples. No superfluous information.
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 complexity (5 params, output schema present), the description covers all aspects: purpose, parameters, return structure, and usage examples. It is self-contained and sufficient for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters are explained with defaults, ranges, and examples. The description adds meaning beyond the schema (e.g., 'similarity_threshold: 0.3-1.0, default 0.7'), compensating for the 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 that the tool aggregates news across platforms, deduplicates similar stories, and provides cross-platform coverage and popularity. This distinguishes it from siblings like 'get_latest_news' (simple retrieval) and 'search_news' (query-based 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 specifies default behaviors (e.g., 'today' for date_range, all platforms) and provides examples. However, it does not explicitly state when to use this tool versus alternatives, though the context makes it clear (use for cross-platform aggregation).
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 discloses prerequisites (config or env vars), side effects (pulls data to local storage), and return format (JSON with success, synced files, etc.), which is sufficient for a data synchronization tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Examples, Note), front-loaded with purpose, and 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 the tool's complexity (one parameter, requires configuration), the description covers parameter semantics, return format, usage context, and configuration requirements completely, leaving no ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully explains the 'days' parameter with allowed values (0, 7, 30), default behavior, and examples, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'sync data from remote storage to local'. It uses specific verb ('sync') and resource ('remote storage'), and the context differentiates it from sibling tools like 'trigger_crawl' for crawling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context ('for MCP Server scenarios where crawlers save to remote cloud storage and MCP server pulls to local for analysis'), but does not explicitly state when to avoid using the tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosed rate limiting (5 sec interval), max 5 articles, timeout parameter, failure isolation, time estimate. No annotations, so description fully covers behavioral traits.
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?
Well-structured with sections, front-loaded purpose, concise yet comprehensive. 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?
Covers limits, timing, failure behavior, example. Output schema implied, so return details not needed. Complete for a batch read 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?
Schema coverage 0%, description adds meaning: urls as list of URLs with max 5, timeout with default. Could specify URL format or constraints, but adequate.
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 batch reading of multiple articles, distinguishes from sibling 'read_article'. Includes typical use flow linking search_news and analysis.
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?
Explicitly outlines when to use: after search_news to get URLs, before analysis. Provides limits (max 5, 5-second interval). Lacks explicit when-not-to-use but context is sufficient.
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:

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

Score Badge

Copy to your README.md:

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

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/JoJoStar56/TrendRadar2'

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