TrendRadar MCP

Server Quality Checklist

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

Latest release: v6.10.0
Disambiguation2/5
Multiple tools operate on overlapping news data, such as get_latest_news vs get_news_by_date and analyze_topic_trend vs analyze_sentiment, both of which provide trend analysis with similar parameters. The boundaries between these tools are not always clear, which could lead agents to misselect the wrong one.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern (e.g., get_system_status, trigger_crawl, search_news, send_notification). There is no mixing of styles or unpredictable deviations, making the naming highly predictable.
Tool Count2/5
With 27 tools, the server exceeds the 25+ threshold for 'too many' tools. The broad scope of news aggregation, analysis, storage, and notification somewhat justifies the quantity, but the sheer number creates a heavy surface that can overwhelm agents when selecting the right tool.
Completeness4/5
The tool set provides end-to-end coverage of the core workflow: crawling, syncing, retrieving, searching, reading, analyzing, aggregating, comparing, and sending notifications. Minor gaps exist, such as no way to update configuration or manage keywords, but these do not block the primary use cases.
Average 4.3/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
- 2 commits 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It does add useful context: the return format (JSON with Markdown) and a critical constraint on date_range (must be an object, not an integer). However, it does not state whether the operation is read-only, any dependencies on data availability, or error behavior, leaving significant transparency 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 concise and well-structured with a summary line, Args section, and Returns section. It front-loads the purpose. Minor redundancy exists between '每日/每周摘要生成器' and '自动生成热点摘要报告', but overall it is efficient and easy to scan.
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 tool with 2 parameters and an output schema, the description covers the essentials: purpose, parameters, and return type. However, it lacks usage guidance (when to use vs alternatives), behavioral side-effect disclosure, and clarity on how it differs from similar summary/aggregation tools, making it only partially 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?
The schema has 0% description coverage, so the description compensates well. report_type is explained as daily/weekly; date_range gets a format specification, an example, and an explicit warning about object type. This adds meaning beyond the raw schema, though it could be even richer (e.g., allowed date formats or range limits).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a daily/weekly hot-topic summary report, using a specific verb ('generates') and resource ('summary report'). It distinguishes from siblings by specifying the daily/weekly scope, though it doesn't explicitly contrast with alternatives like aggregate_news or analyze_topic_trend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the report_type parameter (daily/weekly) but provides no explicit guidance on when to choose this tool over siblings, no alternative names, and no context such as prerequisites or typical scenarios. The only guidance is the parameter format, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that this is a 'get' operation (read-only) and describes the kind of information returned (version, data stats, cache status). However, it does not mention any potential side effects (e.g., performing a live health probe, cost/performance implications) or auth requirements. The description is adequate but not rich.
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 front-loaded with the main purpose, followed by a returns list. Bilingual repetition (Chinese/English) adds slight redundancy but does not create bloat. It earns its place with no 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?
For a simple, zero-parameter status tool, the description is fairly complete: it names the purpose and the key output fields. An output schema is present, so the description does not need to detail the full return structure. It could mention whether the check is instantaneous or might be slow, but overall it meets a reasonable bar.
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, so the schema is trivially complete. The description does not need to explain any inputs, and the baseline for 0-param tools is 4. No additional parameter documentation 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's function: '获取系统运行状态和健康检查信息' (get system running status and health check info) and lists what it returns (system version, data statistics, cache status). It is distinct from siblings like get_storage_status or check_version, which are more specific. However, it does not explicitly call out this differentiation, so it's not a 5.
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. While the name and description imply a general health/status check, there is no mention of edge cases, prerequisites, or contrast with sibling tools. Users must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It indicates a read-only 'view' operation and specifies the return format (JSON with local/remote status and pull config). However, it doesn't disclose potential side effects, permissions, or external interactions, though this is likely a simple status query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and includes a title, a clarifying sentence, and a Returns note. There is minor redundancy between the first two sentences, but overall it is efficient and well-structured for a simple tool.
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 0-parameter status tool with an output schema, the description provides adequate context on what the tool returns and covers. It doesn't explain when to use it (already penalized in usage guidelines), but is otherwise complete given the tool's simplicity.
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 0 parameters, so there are no parameter semantics to explain. The schema is empty and the description doesn't need to add parameter details. Per the baseline for 0 params, this scores 4.
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 ('获取存储配置和状态'), specifically covering local and remote storage status and pull configuration. This distinguishes it from generic config/status siblings like get_current_config and get_system_status by focusing on storage.
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 explicit guidance on when to use this tool versus alternatives. It doesn't mention any conditions, exclusions, or comparisons to siblings such as sync_from_remote or get_rss_feeds_status. The usage context is implied but not stated.
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 the full burden. It discloses the behavior of each analysis mode and important constraints (e.g., date_range must be an object, not integer), but it does not mention error conditions, prerequisites, or potential side effects. It covers core functionality but not 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?
The description is well-structured with Args, Returns, and Examples sections, front-loading the purpose. It is somewhat lengthy but every section adds essential information; the examples, while not strictly necessary, are valuable for clarifying usage patterns.
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 multi-mode complexity, no annotations, zero schema descriptions, and presence of an output schema, the description provides a solid outline of modes, parameters, and examples. It lacks details on error handling and return structure specifics, but the output schema covers return values, making the description reasonably 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?
The input schema has 0% description coverage, but the description fully compensates by explaining every parameter: insight_type with enumerations and purpose, topic with applicability, date_range with format and example, min_frequency default, and top_n default. Practical usage examples further clarify parameter interactions.
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 is a unified data insight analysis tool integrating multiple analysis modes, and it enumerates the three specific modes (platform_compare, platform_activity, keyword_cooccur). While it names the resource and verb, it could more sharply differentiate itself from sibling analysis tools like analyze_topic_trend or analyze_sentiment.
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 context by defining each insight_type and providing examples, which shows when to use each mode. However, it does not explicitly state when to choose this tool over alternatives or provide exclusions, leaving the agent to infer usage from mode descriptions.
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 of behavioral disclosure. It clearly explains the difference between 'daily' and 'current' modes, and between 'keywords' and 'auto_extract' extraction methods, including that auto_extract automatically discovers hot topics from new headlines. This provides meaningful behavioral context. It does not mention side effects or permissions, but as a read-like operation that 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Examples sections, and it front-loads the main purpose. It is slightly longer than necessary but every section provides value. The examples reinforce parameter usage without being redundant, 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?
The tool has a simple interface (3 optional parameters) and the description covers all key aspects: input parameters, return type, and use-case examples. An output schema exists, so detailed return values are already defined. However, it does not mention data availability prerequisites or how this tool relates to sibling trend-analysis tools, leaving minor gaps in overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides zero description coverage, so the tool description must fully explain the parameters. It does: top_n is described as 'return TOP N topics', mode has enumerated values with definitions, and extract_mode explains both options and the reliance on a config file for 'keywords'. Examples further clarify usage. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title '获取热点话题统计' clearly states the tool fetches hot topic statistics. It uses a specific verb (获取/get) and resource (热点话题统计/hot topic statistics), making its primary function obvious. However, it does not explicitly distinguish itself from sibling tools like analyze_topic_trend or analyze_data_insights, which could overlap in purpose.
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 how to configure the tool via parameters (mode, extract_mode) and provides examples, implying its use for retrieving topic frequency counts. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention exclusions or prerequisites. Usage context is only implicitly conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose the return format (JSON with date info and comparison) and the behavior of the 'both' option, which adds some transparency. But it doesn't explicitly state whether this is a read-only operation, any permissions needed, or behavior when no data exists.
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 structure is clear with labeled sections (Args, Returns, Examples), making it easy to scan. However, the first two lines are semantically redundant ('列出本地/远程可用的日期范围' and '查看本地和远程存储中有哪些日期的数据可用'), which adds unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and a likely output schema, the description covers purpose, parameter semantics, and return format. It lacks guidance on edge cases or fallback behavior, but is otherwise complete enough for an agent to understand and invoke it.
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 fully explains the source parameter, enumerating the three possible values ('local', 'remote', 'both') and the default, which goes well beyond the bare schema that only has a type and default. This is especially valuable given 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 lists available date ranges from local/remote storage, using a specific verb ('列出'/'list') and resource ('可用的日期范围'), and the explanation '查看本地和远程存储中有哪些日期的数据可用' reinforces its inventory purpose. It distinguishes itself from siblings like get_storage_status by focusing on date availability rather than storage capacity.
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 context about the source parameter (local/remote/both) and gives examples, implying when it might be used (e.g., to check data coverage). However, it does not explicitly state when to use this tool versus alternatives like resolve_date_range or get_storage_status, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses behavioral traits such as title deduplication ('会对标题去重'), token saving for include_url ('节省token'), defaults like '默认今天' and '最大100'. It does not explicitly state read-only status or side effects, but the '分析' wording implies a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a short intro, a recommendation, an Args list, Returns, and an Example. Every section serves a clear purpose without redundancy, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all six parameters, describes the return value generically ('包含情感分布、热度趋势和相关新闻'), and provides a concrete example. With an output schema available, it does not need to detail every field. It lacks error-handling or edge-case information, but for an analysis tool with optional parameters, it is sufficiently 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?
Although schema_description_coverage is 0%, the description's Args section explains each parameter thoroughly, including formats, defaults, and behaviors (e.g., date_range format, limit max, sort_by_weight default, include_url purpose). This fully compensates for the missing schema descriptions and adds significant semantic value.
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 states '分析新闻的情感倾向和热度趋势' (analyze sentiment tendency and popularity trend of news), which is a specific verb+resource combination that clearly conveys the tool's function. It does not explicitly contrast with sibling tools like analyze_topic_trend or analyze_data_insights, so it lacks explicit differentiation.
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 usage recommendation for natural language dates ('建议：使用自然语言日期时，先调用 resolve_date_range 获取精确日期范围'), which helps with a prerequisite step but does not explain when to use this tool over alternatives or exclusions. Usage context is implied by the purpose statement but not made 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?
With no annotations, the description carries the full burden. It discloses return format (JSON list), defaults, and constraints (max days, limit, include_summary), and examples show expected usage. However, it doesn't explicitly state it's a read-only operation, prerequisites, or behavior on invalid feeds/empty results, leaving some gaps.
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. The main purpose is front-loaded in the first sentence, and every line provides value—parameter details and examples are concise yet complete. It is appropriately sized for the tool's 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?
The description covers all parameters, return format, and provides examples, which is largely complete for a search tool. It lacks explicit sibling differentiation and edge-case behavior (e.g., empty results, invalid feeds), but given the output schema exists, the agent can infer return details. Minor 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?
Schema coverage is 0%, but the description thoroughly explains all 5 parameters with types, defaults, and examples (e.g., feeds as a list of IDs defaulting to all, days with range 7-30, limit default 50). 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.
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 subscription data for articles containing a specific keyword, using the verb 'search' and resource 'RSS data'. It distinguishes from siblings through parameters like feeds and days, but does not explicitly name alternative tools 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 clear usage context: it explains parameter defaults (days 7 max 30, limit 50, feeds default to all), gives examples, and implicitly indicates when to use it (keyword search in RSS). It does not explicitly mention when not to use it or alternative tools, but the intended scenario is clear.
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 is responsible for behavioral disclosure. It adds context about default date range (7 days), mode-specific parameters (spike_threshold for viral, lookahead_hours for predict), and a dependency on resolve_date_range for date processing. However, it does not mention potential side effects, data freshness requirements, or performance implications.
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-organized with a title, usage suggestion, parameter list, return note, and two examples. It is moderately concise and front-loaded with the tool's purpose. The parameter list is dense but clear, and every section earns its place.
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 (8 params, no annotations), the description covers the full parameter space, usage patterns, and return format (JSON). It also provides two representative examples. Since an output schema exists, detailed return field explanations are unnecessary. Minor gap: no mention of error conditions or data availability prerequisites.
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 description coverage, so the description carries the full burden. It explains all 8 parameters, including the exact string format for date_range, the enum-like values for analysis_type with their purposes, and mode-specific defaults for spike_threshold, time_window, lookahead_hours, and confidence_threshold. This thoroughly compensates 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 identifies the tool as '统一话题趋势分析工具' (unified topic trend analysis tool) with explicit analysis modes: trend, lifecycle, viral, and predict. It specifies the action (analyze), resource (topic trend), and distinguishes from sibling tools like analyze_sentiment or analyze_data_insights by focusing on trend-specific patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a practical usage tip to call resolve_date_range for natural language dates, and explains when each analysis_type is appropriate (e.g., viral for anomaly detection, predict for forecasting). However, it does not explicitly contrast with sibling tools like analyze_data_insights or suggest when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that include_url default False is for saving tokens, and it provides display behavior guidelines (show all data by default, only summarize when explicitly requested). These are valuable behavioral traits beyond simple parameter listing. However, it does not mention rate limits, error cases, or side effects, though this is a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for Args, Returns, and display suggestions. The purpose is front-loaded in the first sentence. The three bullet points for display suggestions are slightly verbose but each adds actionable guidance. Overall, it is concise and every part serves a purpose, though it could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 optional parameters, output schema present), the description covers the purpose, parameter semantics, return type, and even agent-facing display behavior. It is missing edge-case guidance (e.g., what happens if no data is available) and explicit comparison to alternatives, but for a simple retrieval tool it is quite 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?
The schema provides zero description coverage, but the description fully compensates by explaining each parameter: platforms (list of IDs, default all), limit (default 50, max 1000), include_url (whether to include URLs, default false, saves tokens). It includes concrete examples and usage rationale, adding significant meaning beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '获取最新一批爬取的新闻数据，快速了解当前热点' (get the latest batch of crawled news data for quick understanding of current hot topics). It uses a specific verb+resource construction and distinguishes from siblings like get_news_by_date (specific date) and search_news (search) by emphasizing 'latest' and 'hot topics'.
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 retrieving the most recent news ('最新一批') and for quick insight into hot topics, but it does not explicitly compare with alternatives or state when not to use this tool. The '数据展示建议' section provides guidance on how to present results to users, which is useful but not about tool selection. Thus, usage context is implied but not fully 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?
With no annotations, the description carries the full burden. It discloses parameter defaults (limit=50, include_url=False), platform behavior, and return format. However, it does not explicitly state that the operation is read-only, nor does it mention error handling, rate limits, or any side effects. The read-only nature is implied by '获取' but not explicitly confirmed.
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 one-line purpose followed by a clear Args section. Each parameter is explained concisely. The date_range section is somewhat detailed, but justified given its complex multi-format support. Overall, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with four optional parameters and an output schema, the description covers the essential usage, defaults, and return type. It could be enhanced by explicitly noting any error conditions or by mentioning how it differs from get_latest_news or search_news, but it is largely sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining all four parameters in detail. It describes the various formats for date_range, the behavior of platforms when unspecified, the default and maximum for limit, and the token-saving rationale for include_url. This goes far beyond the basic schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves news data for a specified date ('获取指定日期的新闻数据') and positions it for historical data analysis and comparison ('用于历史数据分析和对比'). This distinguishes it from sibling tools like get_latest_news and search_news, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates the tool is for historical data analysis ('用于历史数据分析和对比'), providing clear context on when to use it. It does not name alternative tools for exclusion, but the use case is clear enough to guide selection among 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 must carry the burden of behavioral disclosure. It explicitly states that the tool returns JSON configuration info, and the verb '获取' (get) implies a read-only operation. It also lists valid input sections, helping the agent avoid invalid calls. However, it does not explicitly mention that the operation is safe or has no side effects, which is a minor 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 concise and well-structured, with a clear title sentence followed by Args and Returns sections. Every sentence adds value: the purpose, the parameter choices, and the output format. There is no fluff or repetition.
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 tool is simple (one optional parameter) and an output schema exists, so the description need not detail return values exhaustively. It covers the parameter semantics and return type sufficiently. However, it could have provided a brief note about error handling or the structure of the 'all' response, but this is a minor omission given 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 schema has only one parameter with no description (coverage 0%), but the tool description fully compensates by enumerating all possible values ('all', 'crawler', 'push', 'keywords', 'weights') and explaining the default. This gives the agent complete understanding of the parameter beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with '获取当前系统配置' (Get current system configuration), which is a specific verb + resource. It clearly distinguishes this tool from siblings like get_system_status and get_storage_status by focusing on configuration, and it further enumerates specific config sections (crawler, push, keywords, weights), leaving no ambiguity about what the tool does.
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 guidance on the section parameter with valid values and a default, but it does not explicitly state when to use this tool versus alternatives like get_system_status or get_storage_status. The usage context is implied rather than spelled out, so the tool-selection guidance is minimal.
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 behavioral disclosure burden. It discloses that the tool reads configuration from config.yaml and .env, supports a specific list of 9 channels, and returns JSON status including configuration source. While it does not explicitly state that it is read-only, the non-destructive nature is clear from the wording, and it provides useful context about configuration sources.
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: a primary sentence, a supporting detail sentence, a Returns section, and an Example. Every sentence adds value, with no redundant fluff. The list of channels is informative and not excessive for a tool meant to enumerate channels.
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 zero-parameter tool with an output schema, the description is complete. It explains what the tool does, where it reads configuration from, which channels are covered, and provides an example. There are no missing prerequisites or ambiguous edge cases, and it fits well alongside sibling tools.
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 effectively 100% (empty object). The description adds no parameter details, but none are needed. Per the rubric, a 0-parameter tool receives a baseline of 4, and the description does not detract from this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get) and the resource '所有已配置的通知渠道及其状态' (all configured notification channels and their status), establishing a specific, distinct purpose. It stands out from sibling tools like get_system_status or send_notification by focusing solely on channel configuration and 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 implies its usage through the nature of the operation (checking configured channels), but it does not explicitly state when to use this tool versus alternatives like get_current_config or send_notification. It provides technical context (reads config.yaml and .env) but lacks explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It provides a detailed return structure (available_dates, total_dates, today_feeds, generated_at) and indicates a read-only status check. It does not explicitly mention side effects or permissions, but the output detail and 'status' wording make the non-destructive nature clear.
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 and front-loaded: a concise purpose statement, a clear return format breakdown, and an example. Every section serves a purpose with no redundant text. The format is easy to parse for an AI agent.
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 parameterless status tool, the description is complete. It thoroughly explains the output schema even though an output schema is present, and the example clarifies usage. No gaps that would prevent correct selection and invocation.
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 input schema is empty. The description adds value by showing an example call with no arguments, confirming no input is needed. This meets the baseline for 0-param tools and the example slightly enhances clarity.
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, with a specific verb ('获取'/'查看') and resource (RSS 源状态). It distinguishes itself from sibling status tools like get_system_status by focusing specifically on RSS feeds and their data statistics.
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: call this tool to view RSS feed status. The example shows how to invoke it with no arguments, but there is no explicit guidance on when to use this vs alternatives like get_system_status or get_storage_status, nor any when-not-to-use conditions.
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 of behavioral disclosure. It mentions optional persistence to a local directory and that include_url saves tokens, which are useful details. However, it does not disclose potential side effects like network load, execution duration, or whether the crawl writes to persistent storage beyond the optional local save. This is a moderate level of transparency for a state-changing action.
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 as a docstring with Args, Returns, and Examples sections. Every sentence provides useful information with no filler or redundancy. It is concise yet sufficiently detailed for the tool's simple parameter set.
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 low complexity, the description covers the purpose, all parameters, and return format sufficiently. The output schema exists (though not shown), so the return overview is a bonus. It lacks a note about whether the crawl runs synchronously or asynchronously, and any caveats about resource usage, which would improve completeness for a trigger action.
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%, and the description compensates fully. It explains that platforms defaults to all platforms when not specified, save_to_local saves to the output directory, and include_url includes links while helping save tokens. Examples illustrate valid values and combinations, giving the agent a clear understanding 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 opens with '手动触发一次爬取任务' (manually trigger a crawl task), using a specific verb and resource that clearly distinguishes it from sibling data-reading tools. The optional persistence note further clarifies its scope. The purpose is unambiguous and not just a restatement of the tool name.
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 phrase '手动触发' clearly implies this is for initiating a crawl on demand, providing context for when to use it. However, it does not explicitly state when not to use it or mention alternatives, such as relying on automatic crawls or using get_latest_news. The examples give concrete usage patterns, but the 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It reveals default date behavior (today), similarity threshold semantics, sorting by similarity, and the token-saving rationale for include_url. This adds useful context beyond basic function.
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—parameter details, defaults, and return format are presented succinctly without unnecessary fluff.
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 5 parameters, no annotations, and an output schema, the description covers the operation, all parameters, return format, and example invocations. It is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions for its properties, but the description comprehensively explains every parameter: reference_title partial matching, date_range presets and custom format, threshold scale/default, limit default, and include_url purpose. This fully compensates 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 it finds news related to a specified title, with support for today and historical data. The verb '查找' (find) and resource 'related news' are specific and distinguish it from siblings like search_news or get_news_by_date.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/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 (given a reference title) and includes usage examples, but it does not explicitly mention when not to use it or compare it with alternative sibling tools. The guidance is implied rather than 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?
With no annotations provided, the description carries the full burden and largely succeeds: it discloses the all-sources default when feeds is omitted, the token-saving behavior of include_summary, max day/limit boundaries, and JSON return format. It doesn't mention error handling or rate limits, but for a read-only retrieval tool this is solid coverage.
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 uses a clean docstring-style structure with summary, Args, Returns, and Examples sections. Every section earns its place, especially the parameter details that compensate for the schema's 0% coverage. It's slightly longer than minimal, but nothing is wasted.
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 to handle return value details, the description appropriately focuses on behavior: purpose, differentiation, all parameter semantics, and usage examples. Minor gaps like per-feed vs. total limit interpretation and error scenarios are acceptable for this moderate-complexity read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate, and it does. Each of the 4 parameters gets meaning, defaults, valid ranges (days max 30, limit max 500), and concrete feed ID examples (['hacker-news', '36kr']), plus the cost implication of include_summary. This exceeds what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: '获取最新的 RSS 订阅数据' (get latest RSS subscription data). It explicitly distinguishes from siblings by stating 'RSS 数据与热榜新闻分开存储' (RSS data is stored separately from hot news), which differentiates it from get_latest_news and get_trending_topics in the sibling list.
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: '适合获取特定来源的最新内容' (suitable for getting latest content from specific sources) and the RSS-vs-hot-news separation implies when not to use this tool. However, it doesn't explicitly name alternative tools or provide formal exclusion criteria, falling short of the 5-level bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool accesses GitHub, supports an optional proxy URL, and returns JSON with version comparisons. It implies a read-only check operation and provides the key network-access detail.
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 compact, clearly structured with Args, Returns, and Examples sections. Every sentence adds value, and the examples are helpful without being redundant.
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 and an output schema, the description fully covers what it does, what it returns, and how to use the proxy parameter. It is complete and self-contained.
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 provides no description for proxy_url (0% coverage), but the description explains its purpose (optional proxy for GitHub access) and gives a concrete example. This adds meaningful guidance beyond the schema's type/default fields.
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 for version updates, specifying it checks both TrendRadar and MCP Server. It distinguishes the tool by comparing local versions with GitHub remote versions, which is a specific verb+resource scope not shared by siblings.
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: use it to check for updates for both components. It does not explicitly mention exclusions or alternatives, but no sibling tool appears to overlap with this functionality, so the implied usage is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses critical behavior: automatic format adaptation per channel with specific transformations (e.g., Telegram converts to HTML, Slack to mrkdwn), default behavior of sending to all configured channels, and return format as JSON with per-channel status. It doesn't mention error handling or idempotency, but the core behavior is well covered.
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 organized with clear sections: purpose, channel-specific format details, a tip, Args, Returns, and Examples. Every sentence adds value—the channel list is informative, and the examples illustrate usage. It's slightly long but well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of multi-channel notification with per-channel format adaptation, the description is remarkably complete. It covers parameters, behaviors, defaults, return format, and provides a tip for best practices. It also references a sibling tool (get_channel_format_guide) for deeper guidance, filling any gaps.
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 provides a dedicated Args section explaining message (required, markdown), title (default), and channels (optional list with allowed values). This adds semantic meaning beyond the raw schema types and defaults. It also includes examples showing usage patterns.
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 '向已配置的通知渠道发送消息' (send messages to configured notification channels), which is a specific verb+resource. It distinguishes from sibling tools like get_channel_format_guide and get_notification_channels, which are about querying formatting guidance and channel configurations, not sending.
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?
It provides context by suggesting '发送前可调用 get_channel_format_guide 获取目标渠道的详细格式化策略' (call get_channel_format_guide before sending for detailed formatting strategy). This implies when to use this tool (to send) and points to an alternative for formatting guidance. It doesn't explicitly exclude other tools, but the context is 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 the burden of disclosing behavior. It explains that it merges similar news, uses a similarity threshold (with default and range), and returns dedup statistics and platform coverage. It does not mention potential edge cases like rate limits or pagination, but for an aggregation tool this is sufficient and adds meaningful value beyond the schema.
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 clear title, body, args list, returns, and examples. It is front-loaded with the core purpose and provides just enough detail without redundancy. Each section earns its place 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?
For a tool with 5 parameters and an output schema, the description covers all necessary aspects: parameter semantics, return structure, and usage examples. It does not need to explain the full output schema since one exists, and the summary of returns ('dedup statistics, aggregated news list, platform coverage') is sufficient for an agent to understand what to expect.
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 provides no descriptions, but the description compensates fully. It explains every parameter (date_range, platforms, similarity_threshold, limit, include_url) with defaults, accepted values, and meaning (e.g., 'similarity_threshold: 0.3-1.0, default 0.7, higher is stricter'). Examples also clarify 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 a specific verb 'merge' with a resource: 'different platforms reporting the same event' and specifies the output (cross-platform coverage and heat). This distinguishes it from sibling tools like get_latest_news or search_news, which focus on retrieving or searching individual news items rather than aggregating and deduplicating across platforms.
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: use this when you want a deduplicated, cross-platform view of an event. It does not explicitly name alternatives or say when not to use it, but the purpose is self-evident given the aggregation focus and the sibling tools list. The examples further illustrate typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the return structure (JSON with periods, compare_type, and result) and details the three compare_type modes with their outputs. It does not explicitly state that the operation is read-only or describe error cases, but the analytical purpose implies no side effects and the return section adds meaningful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, usage scenarios, parameters, returns, and examples. It is front-loaded with the main purpose, and every section serves a clear function. Despite its length, it is appropriately sized for a tool with six parameters and three compare modes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and an output schema, yet the description still explains the return structure and provides three examples covering different compare_type values. It covers all essential aspects for correct invocation, including period formatting options and optional filters, making it 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero descriptions, but the description thoroughly documents all six parameters: period1/period2 accept either preset strings or date objects with start/end, compare_type has three documented values with a default of 'overview', platforms is shown as an example list, and top_n has a default of 10. This fully compensates for the schema's lack of detail.
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 '时期对比分析' and lists specific comparison dimensions (热点话题、平台活跃度、新闻数量). It distinguishes itself from sibling tools like analyze_topic_trend by explicitly focusing on comparing two discrete periods, and from get_news_by_date by focusing on multi-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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The '使用场景' section provides concrete examples (本周vs上周, 某个话题两个时期, 各平台周期变化) and the compare_type parameter documents when each mode is appropriate (overview, topic_shift, platform_activity). It lacks explicit 'when not to use' alternatives, but the context is clear enough for correct selection.
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, so the description carries full burden. It discloses the use of Jina AI Reader, the stripping of ads/navigation, built-in rate control (5-second interval, 100 RPM limit), and potential failure on paywalled pages. This is rich behavioral context beyond what the tool name alone imparts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multi-paragraph but well-structured with clear sections (main purpose, use cases, flow, args, returns, note). It is somewhat longer than strictly necessary, but every section adds value and it is 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?
With a rich description covering purpose, parameters, return type, rate limits, and limitations, it is complete for a tool with 2 parameters and an output schema. It does not explicitly differentiate from read_articles_batch, but the typical flow provides contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must and does explain both parameters. It states url is required and must start with http(s)://, and timeout has a default of 30 seconds and max of 60. This adds meaningful meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads article content from a specified URL and returns LLM-friendly Markdown, specifying both the verb and resource. It distinguishes itself from siblings like read_articles_batch by focusing on singular article retrieval and providing a typical use case flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context, recommending it for reading news articles and analyzing content, and outlines a typical flow with search_news first. However, it does not explicitly mention when not to use it or direct users to alternatives like read_articles_batch for multiple articles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses defaults (date_range=today, limit=50, threshold=0.6), mode-specific behavior (threshold only for fuzzy), return format (JSON with hotlist and optional RSS), and platform handling (default all platforms). It does not mention rate limits or side effects, but such are not critical 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line summary, a usage tip, a comprehensive Args list, Returns, and Examples. It is detailed due to 10 parameters but every sentence adds value; no fluff or 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 (10 params, no annotations), the description covers all parameters, return structure, and usage examples. The presence of an output schema also means return values need not be over-explained, and the description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), so the description fully compensates by detailing every parameter: valid search_mode values, date_range format, platforms as list, sort_by options, threshold semantics, and boolean flags. Examples further clarify 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 opens with '统一搜索接口，支持多种搜索模式，可同时搜索热榜和RSS', which clearly states a specific verb (search), resource (unified interface for hotlists and RSS), and differentiates from siblings like search_rss by emphasizing both sources and multiple modes.
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?
It provides explicit guidance to call resolve_date_range for natural language dates, addressing a common prerequisite. It also implies usage for combined hotlist/RSS searches, though it does not explicitly exclude alternatives like search_rss for RSS-only queries.
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 transparency burden. It discloses that the tool skips dates already present locally (skipped_dates), reports failures (failed_dates), and requires specific configuration (S3 endpoints/keys). It does not explicitly discuss overwrite behavior, but overall it provides meaningful behavioral insight beyond the raw operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-sectioned into purpose, args, returns, examples, and configuration notes. Each section contains necessary information and no filler. Though longer than some, it remains efficient and each sentence earns its place.
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 only one parameter and no annotations, the description is exceptionally complete: it explains the purpose, parameter semantics, prerequisites (config/env vars), return structure, and examples. The output schema exists, but the description still summarizes the result fields, which is helpful.
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 only defines 'days' as an integer with default 7 and no description. The tool description compensates fully by explaining the meaning of 0 (no pull), 7, and 30, and provides examples. This adds significant value over the schema and clarifies allowed 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 explicitly states '从远程存储拉取数据到本地' (pull data from remote storage to local), which is a specific verb+resource. It also provides a concrete use case (MCP Server scenario) that clarifies its distinct role among siblings like get_storage_status or list_available_dates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (e.g., when a crawler stores data to remote cloud storage and needs to be pulled locally for analysis). It does not explicitly mention alternatives or when NOT to use it, but the scenario-based guidance is sufficient for most contexts.
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 the return format (JSON with supported features, restrictions, prompts) and provides a per-channel feature overview, making read-only behavior implicit. However, it does not explicitly state that the tool is purely informational with no side effects, though this is strongly implied by the guide-like nature.
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 purpose statement, a channel comparison table, Arg definitions, Returns, and Examples. Every section conveys unique information without redundancy. The front-loaded purpose sentence immediately communicates the tool's function, and the channel table is compact yet highly informative.
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 its simplicity (one optional param, read-only, no side effects), the description is complete. It covers purpose, usage timing, valid channel values, return format, and examples. The presence of an output schema is noted, so the description need not detail return fields exhaustively. This is fully sufficient 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 input schema provides only a parameter name and type without description or enum, giving 0% schema coverage. The description fully compensates by listing all valid channel values (feishu, dingtalk, wework, telegram, email, ntfy, bark, slack, generic_webhook) and explaining that omitting the parameter returns all channels. This adds essential 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 that the tool retrieves formatting strategy guides for notification channels, listing supported Markdown features, format restrictions, and formatting prompts. It distinguishes itself from siblings like send_notification and get_notification_channels by focusing on format guidance rather than sending or listing channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool before calling send_notification to understand target channel format requirements, providing a clear workflow. It also notes the optional channel parameter and that omitting it returns all channel strategies, giving conditional usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behavioral traits: automatic 5-second intervals to respect rate limits, a hard cap of 5 articles (excess skipped), per-article timeout with default, failure isolation ('single failure doesn't affect others'), and an approximate total time (25-30 seconds for 5 articles). This is exceptional transparency beyond the schema.
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 (typical flow, args, returns, example, notes). Every sentence earns its place—no filler, yet it manages to convey limits, time estimates, and failure semantics in a compact format.
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 (batching, rate limiting, error handling), the description is complete: it covers use case, input parameters, return format, time expectations, and edge behavior (skip over 5, partial failures). The presence of an output schema is confirmed, and the description appropriately summarizes the return without needing to list fields.
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 types and a default; the description compensates fully by explaining urls as a required list of article links (max 5) and timeout as per-request seconds (default 30). It also includes a concrete example. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: batch reading multiple articles (max 5) with a 5-second interval. It distinguishes itself from the singular 'read_article' sibling by emphasizing the batch nature and the rate-limit spacing, making the scope and resource unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a typical usage flow with explicit steps: first search_news, then read_articles_batch, for multi-article comparison or synthesis. This gives clear context and expected prerequisites. However, it does not explicitly contrast with 'read_article' for single-article cases or state when-not-to-use, so it stops short of full alternative differentiation.
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 of disclosure. It reveals that the tool uses server-side current time, returns a structured JSON with start/end dates, current_date, and a human-readable description, and explains the consistency benefit. However, it does not mention error handling, edge cases for unsupported expressions, or potential return failure modes, which is a minor gap for a date-parsing utility.
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 structured with clear headers (why, flow, args, returns, examples), bullet points, and code blocks. Every sentence contributes to comprehension: rationale, usage pattern, parameter details, return format, and a worked example. It is appropriately detailed for the tool's complexity 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 modest complexity (1 parameter, simple output), the description is complete: it explains the parameter, the return structure, the reason for using it, and the integration flow with other tools. The output schema is present and the description also provides an example return JSON, so there are no critical gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'expression' as a string with 0% coverage, so the description must compensate. It does so thoroughly by listing supported expression categories (single day, week, month, recent N days, dynamic) with examples in both Chinese and English, and even shows an example JSON output. This fully compensates for the schema's lack of detail.
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 opens with a clear Chinese verb+resource: '将自然语言日期表达式解析为标准日期范围' (parse natural language date expressions into a standard date range). It also explains why the tool exists (server-side time calculation ensuring consistent results) and distinguishes it from sibling tools by its specific role in the workflow, making the purpose unmistakable.
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 provides '为什么需要这个工具' (why this tool is needed) and a '推荐使用流程' (recommended usage flow) with numbered steps, plus two concrete examples showing when to call it and how to chain it with other tools (analysize_sentiment, search_news). This is clear when-to-use guidance, though it doesn't explicitly state when not to use it, the context makes it obvious.
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/qqluohao1234/TrendRadar/badges/card.svg)](https://glama.ai/mcp/servers/qqluohao1234/TrendRadar)

Score Badge

Copy to your README.md:

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

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