TrendRadar MCP

Server Quality Checklist

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

Latest release: v6.10.0
Disambiguation3/5
While many tools have distinct purposes, there are several overlapping search and status tools (search_rss vs search_news with include_rss, get_latest_news vs get_latest_rss vs get_news_by_date, and multiple status tools like get_system_status, get_storage_status, get_rss_feeds_status, get_notification_channels). The detailed descriptions help disambiguate, but the sheer number of similar-sounding tools could cause an agent to select the wrong one.
Naming Consistency5/5
All 27 tools follow a consistent verb_noun pattern using snake_case (e.g., search_rss, get_system_status, analyze_sentiment, send_notification). There are no deviations in style, and the verbs are descriptive of the action. This is a model example of consistent naming.
Tool Count3/5
With 27 tools, the count is slightly above the 16-25 'heavy' range. However, the server covers a wide domain (news ingestion, analysis, reporting, notifications, configuration, storage, and article reading), so each tool has a place. It feels borderline but not excessive given the comprehensive scope.
Completeness4/5
The tool surface appears well-rounded for a news monitoring system: fetching (latest, by date, RSS), searching (keyword, fuzzy, entity), analysis (sentiment, trends, insights, comparison), reporting (summary, aggregation), notifications, configuration retrieval, crawling, storage sync, and article reading. Minor gaps exist (e.g., no tool to modify configuration or add feeds), but these are not fatal and are typically managed by admins outside MCP.
Average 4.1/5 across 27 of 27 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It mentions that the tool returns JSON formatting, but does not state whether the operation is read-only, whether it requires authentication, or whether it has any side effects. It provides minimal insight beyond the literal output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, opening with the core purpose. A minor redundancy exists: the 'Returns:' line repeats the mention of returning version/stats/cache, but the overall structure is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and an output schema exists, the description is adequately complete. It specifies what data is returned (version, stats, cache) and the format (JSON). It might benefit from a note on side effects, but with the output schema covering return details, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this. The description does not need to explain parameter behavior, and the baseline for 0 params is 4. The description adds no parameter-specific information, which is appropriate given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb '获取' (get) and the resource '系统运行状态和健康检查信息' (system running status and health check info), and lists specific data categories (version, stats, cache). This clearly identifies what the tool returns and differentiates it from more specific siblings like get_storage_status or get_rss_feeds_status, though it does not name them explicitly.
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. The description only describes what it does, leaving the agent to infer that this is the general-purpose health check. There are no exclusions, prerequisites, or references to sibling tools.
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 does disclose the return format (JSON with Markdown content) and adds an important constraint that date_range must be an object, not an integer. However, it doesn't mention whether the operation is read-only, potential side effects, authentication requirements, or error conditions. These gaps leave behavioral expectations partially unclear.
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 reasonably concise, with a clear top-level summary followed by a structured Args/Returns section. It front-loads the core purpose and includes necessary details without excessive verbosity. The Chinese formatting is compact, and the emphasis on the date_range object format is appropriately highlighted. It earns a 4 for being well-organized and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters) and presence of an output schema, the description covers the essential operational details: purpose, parameters, and return format. However, it lacks usage context (when to invoke this vs. alternatives) and does not mention any prerequisites or limitations. Consequently, an agent might call it incorrectly in scenarios where another tool would be better suited.
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%, so the description must compensate. It explicitly explains both parameters: report_type (daily/weekly) and date_range, providing format details, an example, and a prominent warning about the object type. This adds meaningful guidance beyond the raw schema, which only lists types without explanation. The only minor gap is not listing all possible report_type values beyond 'daily/weekly,' but that seems complete for the intended use.
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 action and resource: it generates a 'hot topic summary report' for daily/weekly periods. The verb 'generate' and resource 'summary report' are explicit, and the daily/weekly scope distinguishes it broadly from siblings like analyze_topic_trend or aggregate_news. However, it doesn't explicitly name alternatives or contrast with other report-type tools, so it falls short of 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?
The description provides no guidance on when to use this tool versus siblings such as search_news, analyze_data_insights, or compare_periods. It neither states typical use cases nor mentions alternatives that might be more appropriate for different scenarios. A user would have to infer from the tool name and description, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a good job: it reveals that it scans config.yaml and .env, supports a fixed set of 9 channels, and returns a JSON status report including each channel's configured state and source. It does not explicitly state that the operation is read-only or describe potential side effects, but the '检测' language strongly implies a non-mutating inspection, which is generally transparent for a getter.
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: a purpose statement, a detection detail line, a supported-channels list, a return-format section, and an example. It is front-loaded with the core purpose and each section adds value without redundancy. It is slightly verbose for such a simple tool, but the structure 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 tool's simplicity (no parameters, no nested objects, and an output schema exists), the description is sufficiently complete. It covers the source of configuration, the list of channels, the return format, and gives an example invocation. Minor omissions like error behavior or permissions are not critical for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (since properties is empty). The description's example call 'get_notification_channels()' confirms the no-argument signature, but the description adds no additional semantic meaning beyond what the empty schema already conveys, so the baseline of 3 is appropriate.
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 opens with a clear verb '获取' and a specific resource '通知渠道及其状态', and adds detail about configuration sources and the 9 supported channels. This makes the purpose distinct from siblings like send_notification or get_channel_format_guide, though it does not explicitly name any sibling to differentiate.
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 when this tool is relevant (checking notification channel configuration from config.yaml and .env) but gives no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. Usage is implied through the stated behavior, but no direct routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It implies a read-only operation ('查看...状态'), but does not explicitly state that it has no side effects, requires no special permissions, or makes network calls. It also doesn't mention how failures or empty states are represented, though the output schema likely covers the return structure.
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 purpose, but there is redundancy between the title ('获取存储配置和状态') and the first sentence ('查看当前存储后端配置...'). The Returns section is clear. It could be tightened, but overall it is well-structured and avoids unnecessary detail.
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 is complete given the tool's simplicity: no parameters, an output schema explains return fields, and the description adds that the status includes local/remote status and pull config. It lacks any mention of operational caveats or when it is safe to call, but for a status query these are minimal. The presence of the output schema reduces the need for the description to elaborate on return values.
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 has no properties, so the schema fully covers all parameter semantics. The baseline for 0 parameters is 4, and the description adds no parameter-specific details because none exist. No deduction is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('获取') and resource ('存储配置和状态'), and the expanded text details exactly what it returns: storage backend configuration, local/remote status, and pull config. This distinguishes it from sibling tools like get_system_status (system status) and get_rss_feeds_status (RSS feed status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_system_status or get_current_config. The description does not state any prerequisites, exclusions, or conditions that would select this over its siblings. An agent 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 behavioral burden. It does disclose the return shape (JSON), default values (min_frequency=3, top_n=20), and prominently warns that date_range must be an object and not an integer. However, it does not state whether the tool is read-only, whether it makes external/network calls, any rate/auth constraints, or expected cost/latency — notable gaps for a zero-annotation 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 uses a clear Args/Returns/Examples structure, front-loads the purpose, and every parameter earns its place given the complexity (5 params, 3 modes, conditional applicability). It is on the longer side, but the length is justified by the multi-mode surface; nothing is redundant. Minor trimming of the mode explanations could tighten it without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and zero annotations, the description is very nearly complete for correct invocation: modes, parameter semantics, defaults, format constraints, and runnable examples are all covered, and an output schema exists so the sketchy Returns line is acceptable. The main gap is the absence of guidance on how this relates to the many analysis siblings, which leaves a routing decision to the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate — and it does, thoroughly. It documents insight_type with three named options and their meanings, defines date_range's object format with example JSON and an explicit 'must not pass integer' warning, and explains the mode-scoped role of topic, min_frequency, and top_n including defaults. This is exemplary parameter documentation given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear unified purpose — a multi-mode data insight analysis tool — and enumerates three specific modes (platform_compare, platform_activity, keyword_cooccur) with one-line explanations for each. This gives a concrete verb+resource with meaningful subtypes. However, it never explicitly differentiates itself from the many analysis siblings (analyze_topic_trend, analyze_sentiment, compare_periods, aggregate_news), so an agent must infer how it differs from those.
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 internal usage guidance — which parameters apply to which mode (topic for platform_compare, min_frequency/top_n for keyword_cooccur) and three concrete examples of valid calls. This is step-by-step operating guidance. But it gives no guidance on when to choose this tool versus alternatives like analyze_topic_trend or analyze_sentiment, and with 26 siblings this relational routing is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses behavioral traits such as title de-duplication (limit param) and token-saving intent for include_url, but omits potential side effects, permissions, or rate limits. The coverage is partial but non-trivial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for Args, Returns, and Examples. It is concise yet informative, though slightly longer than minimal. Every sentence adds value, such as the suggestion to use resolve_date_range.
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 six optional parameters, no annotations, but an existing output schema (not shown), the description provides enough context for an agent to invoke correctly. It includes an example call and clarifies return contents. Some edge cases like empty topic are not addressed, but overall completeness is good.
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?
Even though schema description coverage is 0%, the description thoroughly explains all six parameters with meanings, defaults, and formats (e.g., date_range format, platform examples). It adds significant value beyond the schema's bare types.
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 a clear purpose: '分析新闻的情感倾向和热度趋势' (analyze sentiment and heat trends of news), with a specific verb and resource. It distinguishes this tool from sibling tools like search_news or get_news_by_date by its analysis focus, though it doesn't explicitly name alternatives.
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 conditional recommendation: when using natural language dates, call resolve_date_range first. This is useful guidance for a specific scenario, but it does not explain when to choose this tool over siblings like analyze_topic_trend or aggregate_news, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of behavioral disclosure. It adds useful context: include_url defaults to false to save tokens (a performance consideration), and the display suggestions indicate that the tool returns raw data that should not be summarized unless requested. However, it does not mention side effects (e.g., read-only), authentication requirements, or rate limits, which are typical behavioral aspects for an API 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 core description is compact: two sentences stating purpose, then a well-structured Args and Returns section. The additional 'data display suggestions' add length but serve a practical purpose for the agent. The structure is clear with headers, but the display suggestions could be seen as slightly redundant with general agent behavior. Overall, it is efficient and front-loaded with the main intent.
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 single output schema (indicated by 'has output schema: true'), so the description does not need to detail the return structure beyond mentioning it is a JSON news list. The parameter documentation is complete, and the display guidance helps the agent use the results appropriately. For a read-only news retrieval tool, this is fairly complete; the only missing piece is explicit disclosure of safety or side effects, which is minor given the tool's nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description thoroughly explains each parameter beyond the schema: platforms provides an example list and the default behavior (all platforms), limit specifies default and maximum (50 and 1000), and include_url states the default and rationale (token saving). This adds significant meaning over the bare schema, which has no descriptions and a 0% coverage signal.
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 function: retrieving the latest batch of crawled news to quickly understand current hot topics. It specifies a concrete action ('get') and resource ('latest news'), making the purpose obvious. However, it does not explicitly differentiate this from sibling tools like get_latest_rss or get_trending_topics, so it lacks sibling distinction.
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 implicit context: it is for 'latest' news, which implies it should be used when fresh data is needed. It also includes display suggestions that guide how to present results (e.g., show all unless user asks to summarize), but it does not explicitly state when to use this tool over alternatives or when not to use it. There is no reference to other tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains key behaviors like defaulting to all feeds when none specified, days max of 30, limit max of 500, and include_summary defaulting to False. It also states the return format. However, it omits any error behavior, authentication requirements, or rate limits, leaving some 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 well-structured: a brief purpose statement, an Args section with bullet points, a Returns line, and examples. It is front-loaded with the main purpose and avoids unnecessary fluff. It could be slightly more concise, but the organization aids comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 optional parameters and a simple retrieval purpose, the description covers all parameter semantics, provides examples, and states the output format. It does not mention error conditions or edge cases, but the presence of an output schema and the simplicity of the operation mean the essential context is present for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description goes well beyond the bare schema, which has no parameter descriptions. The Args section clearly explains each parameter: feeds (list of IDs, all if not set), days (default 1, max 30), limit (default 50, max 500), and include_summary (default False, token saving). This strongly compensates for the 0% schema coverage and adds critical semantic meaning.
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 fetches the latest RSS subscription data and supports multi-day queries. It differentiates RSS from hot-list news by noting they are stored separately, which helps distinguish it from sibling tools like get_latest_news and get_trending_topics, though it does not name them explicitly.
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 when to use this tool: for retrieving RSS content from specific sources, as opposed to hot-list news. It provides examples of different call patterns, but does not explicitly name alternative tools or state conditions under which to prefer this one over a sibling. The guidance is implicit rather than directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It describes merging and deduplication as an analytical/query operation and states that it returns JSON results, implying it is read-only. However, it does not explicitly state that no data is modified, nor does it mention rate limits, authentication, or any side effects. It adds useful context about coverage statistics but lacks explicit non-destructive guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a title, explanation, Args, Returns, and Examples. It front-loads the core purpose and then details parameters. For five optional parameters, the length is reasonable and informative, without excessive verbosity. The examples are helpful for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (deduplication, cross-platform merging, multiple optional filters) and the existence of an output schema, the description covers the essential invocation aspects. It explains the return contents (dedup statistics, list, platform coverage) and provides example calls. It does not describe pagination or how similarity threshold maps to strictness beyond the stated range, but these are minor in light of the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions (coverage 0%), so the description fully compensates by explaining every parameter with defaults and examples. It clarifies date_range, platforms (with example list), similarity_threshold (with range and default), limit, and include_url. Minor gaps: valid platform IDs are not enumerated, and the exact format of date_range (object vs string) is vague, but overall it adds substantial 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 states a specific verb and resource: '跨平台新闻聚合 - 对相似新闻进行去重合并' (cross-platform news aggregation - deduplicate and merge similar news). It clearly distinguishes this from sibling tools like get_latest_news or search_news by emphasizing cross-platform merging of the same event into a single aggregated news item with coverage and popularity metrics.
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 purpose implies usage context (when you need cross-platform aggregated news), and examples show typical calls, but there is no explicit statement about when to use this tool versus alternatives, nor any exclusions. It does not mention how it differs from search_news or find_related_news, leaving the agent to infer selection criteria.
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 of behavioral disclosure. It states that the tool returns configuration in JSON format and lists valid parameter values. However, it does not explicitly mention that it is a read-only operation, has no side effects, or how it handles invalid section values. For a simple getter, the description is adequate but not comprehensive; it stops short of explicitly stating safety and error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a one-line purpose statement followed by structured argument and return sections. The parameter list is formatted as clear bullets. It is efficiently written without unnecessary fluff, though it slightly under-elaborates on return details. Still, it earns high marks for front-loading the purpose and organizing details logically.
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 is simple (one optional parameter), and an output schema exists, so per rubric the description need not explain return values in depth. The description fully documents the parameter's allowed values and default, and states the output format. There are no prerequisites, authentication notes, or complex behaviors to disclose. For this complexity level, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'section' as a string with no description or enum values, and schema coverage is 0%. The description compensates fully by enumerating all accepted values ('all', 'crawler', 'push', 'keywords', 'weights') and explaining the default ('all'). This is critical semantic information that the schema entirely lacks, making the description indispensable for correct invocation.
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 title 'get_current_config' along with the description '获取当前系统配置' (Get current system configuration) clearly states a specific verb and resource. It distinguishes itself from sibling tools like 'get_system_status' or 'get_storage_status' by focusing on configuration, and the description provides a list of configurable sections (all, crawler, push, keywords, weights), making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or situations where another tool (e.g., get_system_status for status) would be more appropriate. The agent is left to infer usage based solely on the name and parameter list.
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 structure (available_dates, total_dates, today_feeds, generated_at) and provides an example, adding value beyond the empty schema. The term 'view' implies a read-only operation, but it does not explicitly state whether it has side effects or requires permissions. However, for a status tool, the main behavioral aspects are covered well.
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: a one-line purpose (in Chinese), followed by a 'Returns' section listing fields, and an example. It is concise and front-loads the primary function. The use of both Chinese and English is slightly unconventional but does not harm clarity, and every sentence adds relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-argument status tool, the description is complete: it explains what it does, what data it returns (including all fields), and gives an example. It does not mention error conditions or behavior when no feeds are configured, but these are likely unnecessary for a read-only status endpoint. The presence of an output schema in the description covers the return format, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain beyond confirming that no arguments are needed. The example 'get_rss_feeds_status()' reinforces this. Given the baseline for 0 parameters is 4, the description appropriately handles parameter semantics without unnecessary 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 the tool gets RSS feed status information, elaborating that it shows currently configured RSS sources and their data statistics. This distinguishes it from siblings like get_latest_rss (which returns content) or get_system_status (which is about system-level status), so an agent can readily understand the specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. It does not mention when to prefer it over get_latest_rss or get_system_status, and the provided example ('get_rss_feeds_status()') only demonstrates a call without giving scenarios or exclusions. The usage context is entirely implicit from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format (JSON with date lists and comparison) and the 'both' option that compares local and remote. However, it does not explicitly state read-only behavior or any side effects, which is a notable gap for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Examples sections. It is concise without unnecessary fluff, though the examples and formatting make it slightly longer than strictly needed. Front-loading the purpose in the first line is effective.
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 a simple tool with one optional parameter and an output schema (as indicated by context), the description provides enough information for correct invocation: it explains the parameter, default behavior, and result format. It lacks detailed return field descriptions but the output schema presumably covers that.
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 no descriptions for the 'source' parameter (0% coverage), but the description fully explains the three allowed values ('local', 'remote', 'both') and the default. This adds significant meaning beyond the bare schema, so the high score is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: lists available date ranges from local and remote sources. It specifies the resource (date availability), the action (list), and contrasts with siblings like get_news_by_date or resolve_date_range by focusing on availability rather than content or resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the source parameter and provides examples, but it does not explicitly state when to use this tool versus alternatives like resolve_date_range or get_news_by_date. It implies usage for checking date availability, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有任何注释，描述承担了行为透明度的全部责任。描述揭示了返回值结构（标题、平台、排名）、参数默认值（limit=50，include_url=false）和date_range的多种输入格式，但未说明任何副作用、权限要求或错误处理。此外，未明确声明是只读操作（尽管明显）。在无注释的情况下，提供的信息较充分但仍有缺口。
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?
描述开头一句话给出核心用途，随后用结构化列表逐项说明参数，末尾说明返回格式。信息密度高，无冗余。虽略长但每句话都有价值，且前部加载了关键信息。
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?
工具涉及4个参数，有输出schema，描述本身包含了返回字段（标题、平台、排名），基本覆盖了调用所需的信息。但没有提供示例调用或错误场景，对于较为复杂的date_range格式虽强制说明了类型未给具体示例，但已足够。
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描述覆盖率为0%，描述完美补充了所有4个参数的具体语义：date_range的多种格式、platforms的用途、limit的默认和最大值、include_url的目的。全部参数都获得清晰说明，远超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?
描述明确说明“获取指定日期的新闻数据，用于历史数据分析和对比”，精确地指特定时间范围的新闻检索，与兄弟工具如get_latest_news、get_trending_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?
描述暗示了历史分析的场景，但未明确说明与其他搜索/报告工具（如search_news、aggregate_news）的边界，也未提及何时不使用该工具。虽然用途清晰有余，但缺乏排除性指导，未达到4分。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It does reveal that it reads from 'config/frequency_words.txt' for the 'keywords' mode and can automatically extract high-frequency terms from news titles, implying read-only statistical computation. However, it does not explicitly state that the operation is side-effect-free, whether it triggers network calls, or if there are any latency or resource implications. This leaves some ambiguity for a tool with zero annotation 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 is structured with clear sections (Args, Returns, Examples) and is relatively compact. The purpose is front-loaded, and parameter explanations are concise but complete. It could be slightly shortened by removing some redundancy (e.g., repeating defaults), but overall it is efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (three optional parameters, no required fields), the description covers all essential aspects: parameter semantics, return format (JSON list of topic frequencies), and practical examples. It does not mention any side effects, rate limits, or data freshness, but the provided details are sufficient for a basic read-only statistics tool. The presence of an output schema (not shown here but indicated) means return details are partly covered externally, so the description is adequately 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 provides only names and defaults, with no descriptions (0% coverage). The description compensates fully: it explains each parameter's meaning, lists and defines acceptable values (e.g., 'daily' and 'current' for mode, 'keywords' and 'auto_extract' for extract_mode), and clarifies the purpose of top_n. This is far more than the schema offers, making it easy for an agent to invoke correctly.
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, specific phrase '获取热点话题统计' (get trending topic statistics), which names the verb and resource precisely. It distinguishes this tool from siblings like 'analyze_topic_trend' by focusing on frequency statistics rather than trend analysis, so an agent can tell it apart without deeper inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples of usage and explains parameter modes (e.g., 'daily' vs 'current', 'keywords' vs 'auto_extract'), which implicitly convey when to use different options. However, it gives no explicit guidance on when to select this tool over related siblings like 'analyze_topic_trend' or 'search_news', nor does it state any exclusions or prerequisites. The examples show usage but not contextual selection criteria.
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 uses Jina AI Reader, transforms pages to clean Markdown, and has rate limits (100 RPM) with a 5-second built-in delay. It also notes limitations with paywalled/content-gated pages. This is good transparency, though it does not mention error handling or authentication requirements, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive but well-structured with clear sections (purpose, usage flow, args, returns, examples, notes). It front-loads the core purpose, then provides actionable guidance. While lengthy, every section adds value (usage flow, parameter details, rate limits, example), so it is appropriate for the tool's complexity without being bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no annotations, external service dependency), the description covers essential operational context: the Jina AI dependency, rate limits, usage workflow, and an example. An output schema exists, so return format details are not needed. Missing only explicit disambiguation from the batch sibling, but otherwise complete for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fully describes both parameters: url requires http:// or https:// and is mandatory; timeout is in seconds with default 30 and maximum 60. This goes beyond the schema by explaining URL format and timeout constraints, making parameter usage unambiguous.
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 reads article content from a specified URL and returns LLM-friendly Markdown. It specifies the verb (read), resource (article content), and output format. It distinguishes itself from sibling tools by emphasizing single-URL operation and providing a typical workflow that pairs with search_news, but it does not explicitly mention the batch variant (read_articles_batch) or contrast with it, so differentiation is slightly implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear 'typical usage flow' (search → read → analyze), and states suitable use cases ('reading news, getting article details, analyzing content'). It gives practical context on when to use the tool, including the dependency on search_news for obtaining URLs. However, it does not explicitly state when not to use it or mention alternative tools like read_articles_batch for multiple URLs, so exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions 'optionally persistent' and 'save to local', but does not explain potential side effects like long-running network operations, effects on system state, or authentication requirements. The return format is given, but broader behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with Args, Returns, and Examples sections. It is front-loaded with the purpose, and while not extremely concise, it avoids redundancy and uses a clear format that aids comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (indicated by context signals), the description covers the main aspects: parameters, return type, and examples. It lacks error handling or edge-case details, but these are not critical for a tool with no required parameters.
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 0% coverage, but the description explains each parameter in detail: platforms list, include_url, save_to_local, and provides usage examples. This fully compensates for the schema gap and adds semantic meaning beyond the property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'manually trigger a crawl task' with specific parameters and return type. It is distinct from sibling tools like search_rss or get_latest_news which are about retrieval, and no other tool handles crawling triggers.
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 implicitly defines the use case as manually initiating a crawl. Since there are no sibling tools for crawling, explicit 'when-not-to-use' guidance is unnecessary, but the description could be more direct about when this is appropriate (e.g., when fresh data is needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It explains the effect of each analysis_type mode, documents default values, and specifies the return format ('JSON格式的趋势分析结果'). It also warns about date handling. It could disclose more about side effects or data sourcing, but it adds significant behavioral context beyond the bare-bones schema.
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 suggestion header, a parameter list, return type, and examples. It is slightly long, but that is necessary to explain 8 parameters in the absence of schema descriptions. Each section adds value and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and 4 distinct modes, the description is notably complete. It covers all parameters, their defaults, mode-specific usage, and provides two concrete examples. It even flags the date-range helper. The output schema exists, so return details are not required, but the description still mentions JSON format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does comprehensively. It explains each parameter's meaning, format (e.g., date_range as {'start': 'YYYY-MM-DD', 'end': ...}), and mode-specific applicability (e.g., spike_threshold for viral mode, lookahead_hours for predict). 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 clearly states the tool's purpose: '统一话题趋势分析工具' (unified topic trend analysis tool) and lists four specific modes (trend, lifecycle, viral, predict). It identifies the resource (topic) and action (analyze), and the modes distinguish its scope from any sibling analysis tools.
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 concrete prerequisite: 'use resolve_date_range for natural language dates' before calling this tool. It also differentiates internal modes (e.g., viral, predict) with clear parameter triggers. However, it does not explicitly state when to use this tool versus alternatives (e.g., analyze_sentiment, analyze_data_insights), nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that it checks both components, compares local vs remote, returns JSON with comparison, and optionally uses a proxy for GitHub access. It does not explicitly state that it is read-only, mention error handling, rate limits, or network dependencies beyond the proxy. For a simple version-check tool, this is adequate but not comprehensive. The proxy mention acknowledges network access, but it could be more explicit about side effects or failure modes.
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 sections for purpose, args, returns, and examples. It is front-loaded with the primary purpose in the first line. Every sentence contributes value: the argument description, return type, and two examples. There is no fluff or redundancy. The formatting is clear and easy to parse, making it efficient for an agent to read and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and an existing output schema, the description is complete. It covers the purpose, the argument semantics, the return format (JSON with version comparison and update-needed flag), and provides examples. The output schema (which exists) would document the return structure in detail, so the description need not. No critical information is missing for an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so well for the only parameter, proxy_url: '可选的代理URL，用于访问 GitHub（如 http://127.0.0.1:7890）' (optional proxy URL for accessing GitHub), with an example. This adds meaning beyond the bare schema, which only defines the type and default. The description clearly explains the parameter's purpose and provides a concrete example, making it easy for an agent to use it correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '检查版本更新（同时检查 TrendRadar 和 MCP Server）' (check version updates for both TrendRadar and MCP Server) and explains it compares local versions against GitHub remote. This specific verb-resource pairing (check version) distinguishes it from all sibling tools, which are news/RSS/crawling utilities. An agent can immediately understand what this tool does and why it exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need to check for updates of the two components. It does not explicitly name alternatives or exclusions, but given the unique purpose among siblings, the usage context is unambiguous. The examples ('check_version()' and with proxy) demonstrate typical invocations. It falls short of explicitly stating when NOT to use it, but no competing tool exists, so 4 is appropriate.
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 transparently discloses the 5-second interval between requests to respect rate limits, the maximum of 5 articles with excess skipped, failure isolation (single article failure does not affect others), the default timeout, and the return format. This is a solid transparency level, though it omits potential details like authentication or handling of redirects, which are not critical for a read 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 a summary, typical usage flow, args, returns, example, and notes. It is front-loaded with the core summary. However, it repeats constraints (max 5, interval) in multiple sections, which adds slight redundancy. Overall it is organized but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch tool, the description is complete. It covers the use case, a recommended workflow, all parameters, the return format (JSON with content and status), timing expectations (~25-30 seconds for 5 articles), failure behavior, and an example. An output schema exists, but the description provides sufficient detail on results, so nothing critical is missing for an agent to call 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?
Schema description coverage is 0%, and the description fully compensates. It explains urls as a required list of article links with a maximum of 5, and timeout as the per-request timeout in seconds with a default of 30. It also provides an example usage. All meaningful parameter semantics are covered, exceeding the baseline expectation.
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 purpose: batch read multiple article contents (up to 5, with 5-second intervals). The batch aspect distinguishes it from the sibling read_article, though it does not explicitly name the single-article alternative. The name and description make the distinction evident, so a 4 is appropriate for being clear but not fully explicit about sibling 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 a typical usage flow: first use search_news to get links, then call read_articles_batch with urls, and finally analyze the results. This gives clear context for when to use the tool. However, it does not explicitly state when not to use it (e.g., for a single article, use read_article) or mention alternative tools, so it is not a 5.
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 thoroughly explains the return content (per-channel format features, limitations, and prompt suggestions) and implies this is a read-only operation. It does not mention potential error cases or authentication requirements, but for a non-mutating query that's a minor gap. The description is far more transparent than typical tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured: a clear intro stating its purpose and timing, a bulleted list of channel-specific features, then formal Args/Returns/Examples sections. The front-loaded purpose and examples make it easy to parse. While it could trim some redundancy in the channel list, the structure earns its length by covering all necessary detail without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description doesn't need to detail the JSON structure, but it explains the conceptual content (supported features, restrictions, formatting prompts). It covers the primary use case, parameter behavior, and gives examples. Missing edge-case handling (e.g., invalid channel values) is not critical for a query tool like this, so the description is sufficiently complete for an agent to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'channel' as a string or null with no description or enum. The description fully compensates by documenting that the parameter is optional, enumerating the exact valid channel IDs (feishu, dingtalk, wework, telegram, email, ntfy, bark, slack, generic_webhook), and providing usage examples. This is exemplary coverage for a parameter with zero schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: retrieves formatting strategy guides for notification channels, with a detailed breakdown of supported Markdown features per channel. It clearly distinguishes itself from siblings like send_notification and get_notification_channels by focusing on formatting 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 Guidelines4/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 the target channel's formatting requirements. It also explains that the channel parameter is optional and that omitting it returns all strategies. While it doesn't list alternatives or negative usage scenarios, the context is clear enough for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注解未提供，因此描述承担了行为透明度的全部责任。描述详细说明了搜索模式的差异、threshold仅在fuzzy模式生效、是否包含RSS和URL、返回JSON结果等行为。尽管未明确声明为只读操作，但搜索性质暗示了无副作用，也缺少数额限制或认证需求，但整体行为透明且有具体细节。相比完全没有说明的工具，这个已足够。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述虽长，但结构化良好：先概述，再给建议，然后列出参数、返回值、示例，层次分明。每个句子都承载必要信息，没有冗余。对于10个参数且模式覆盖率0%的场景，这种详细程度是合理的。不过开头部分已足够简洁，可视为高信息密度。
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?
工具复杂度高，参数多，但描述覆盖了所有参数的含义、默认值、可选范围，说明了返回JSON内容，并推荐了辅助工具resolve_date_range，提供了示例。尽管未细化返回的具体字段结构，但系统提示存在输出模式，因此描述无需完全重复返回值细节。整体上足以指导智能体正确调用。
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?
输入模式对参数的描述覆盖率为0%，描述中通过Args部分详细解释了每个参数的含义、可选值及默认值（如search_mode的三种模式、date_range的格式示例、limit默认50等）。还给出了示例用法，完全弥补了模式的不足。对于10个参数，描述提供了充分的语义，甚至有额外的指引（如threshold仅用于fuzzy）。
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?
明确说明这是一个统一搜索接口，支持关键词、模糊、实体搜索模式，并可同时搜索热榜和RSS。清晰区分了与search_rss等兄弟工具，因为它明确涵盖了两者，而其他工具可能专一于某一部分。动词'搜索'和资源'新闻'明确，且提供了多种模式说明，具有很强的区分度。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
明确建议在自然语言日期时先调用resolve_date_range获取精确日期范围，提供了具体的场景用法。但未强调何时使用其他兄弟工具（如get_latest_news、get_trending_topics），缺少了当使用替代工具的明确指引。虽然未说'不用这个时用哪个'，但给出了一个前置条件的建议，属于清晰上下文，但无排他性指引。
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 behavioral disclosure. It clearly states the return format (JSON list of matching entries) and explains default behaviors for all parameters (feeds default to all, days=7, limit=50, include_summary=False). It does not mention errors, rate limits, or side effects, but for a read-only search tool, this level of transparency is sufficient. The description is honest about what the tool does and does not overclaim.
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-sentence summary, a clear Args block, a Returns line, and two concise examples. There is no redundant text; every sentence adds value. The front-loaded purpose makes it easy for an agent to quickly grasp the tool's purpose.
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 (5 parameters, one required), the description is complete: it explains all parameters, defaults, return type, and provides examples. Even though an output schema is said to exist, the description still describes the return shape, which is helpful. An agent has everything needed to invoke the tool correctly without ambiguity.
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 explain each parameter. It does so comprehensively: keyword is required, feeds accepts a list of feed IDs (with examples), days has a default and max, limit sets result count, and include_summary controls summary inclusion. Every parameter is given clear semantics with defaults and examples, more than compensating for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear statement of purpose: 'Search RSS data for articles containing the specified keyword.' It specifies the resource (RSS data) and the action (search), which distinguishes it from siblings like search_news (likely searching non-RSS sources). The phrasing is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples showing typical usage, which implies context (e.g., searching with a keyword, optionally restricting feeds, setting time windows). However, it does not explicitly state when to use this tool versus alternatives like search_news or get_latest_rss, nor does it mention exclusions. 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?
With no annotations provided, the description carries full disclosure burden — and it meets it well. It reveals the side-effecting nature (sends to all configured channels by default), the auto-adaptation of markdown per channel with exact format mappings (e.g., Telegram HTML conversion, Slack mrkdwn), default title, and JSON return shape. The per-channel format table is substantial behavioral context an agent would otherwise not know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place for a nine-channel tool: the channel-specific format table is non-obvious and essential, args/returns/examples follow in a clean, scannable structure. It's front-loaded with the core purpose before diving into channel details. Slightly verbose in the per-channel breakdown but justified by 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?
Coverage is strong for a multi-channel notification tool: purpose, per-channel format behavior, all parameters with enums, default behaviors, and return result shape are all present. An output schema exists so deep return-field documentation is unnecessary. Minor gaps remain — per-channel failure handling and rate-limit behavior — but these are not blocking 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 must fully compensate — and it does. The Args section defines all three parameters with meaning: message is markdown content, title has a stated default, and channels lists every valid value (feishu, dingtalk, wework, telegram, email, ntfy, bark, slack, generic_webhook) which the schema itself lacks as an enum. This is exemplary compensation for a schema with zero descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('向已配置的通知渠道发送消息' — send messages to configured notification channels), and the rest of the content enumerates per-channel behavior. This clearly distinguishes it from the data-fetching siblings (search_rss, get_latest_news, analyze_topic_trend) which are read-oriented, while this is the only send-action tool in the set.
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 tip explicitly directs the agent to call get_channel_format_guide before sending to produce optimal formatting — concrete guidance on tool orchestration. It's clear this tool is for sending (not for configuring channels, which get_notification_channels covers), though it doesn't state explicit when-not-to-use conditions for edge cases like unconfigured channels.
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 pulls data from remote storage, skips dates that already exist locally (implying non-destructive behavior), and returns a structured sync result with success/failure details. It also documents configuration requirements. This is substantial context, though it does not explicitly state that it writes to local storage or that it is a read-only operation on the remote side.
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 into sections (Args, Returns, Examples, Note). It is longer than necessary for a single-parameter tool, but every section adds value: the note about configuration is critical for successful invocation. The information is front-loaded with the purpose. Some redundancy exists (default days repeated in Args and examples), but overall it is structured and not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential aspects: purpose, usage scenario, parameter semantics, return format, examples, and configuration prerequisites. The output schema is present, but the description also details the return fields, which is helpful. There is nothing an agent needs to call this tool correctly that is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the 'days' parameter, but the description fully compensates by explaining its meaning ('拉取最近 N 天的数据'), default value (7), allowed values (0, 7, 30), and behavior for each. It even provides examples of usage with different values. This is detailed and precise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: '从远程存储拉取数据到本地' (pull data from remote storage to local). It also explains the use case (crawler stores to cloud storage, MCP server pulls for analysis). This clearly distinguishes it from all sibling tools, which focus on news search, analysis, and configuration, none of which are about synchronization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is for syncing data from remote storage to local before analysis. It explains the scenario and parameter usage, but does not explicitly mention alternatives or when not to use it. However, since none of the sibling tools are similar, the purpose itself is sufficient guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It clearly states that the tool performs a comparison and returns a JSON result with specific fields (periods, compare_type, and result object based on type). It also describes the parameter effects (e.g., compare_type changes the output shape). While it does not explicitly state that it is read-only or non-destructive, the nature of a comparison analysis tool implicitly conveys this. It omits potential performance or error considerations, but the behavior is well described for typical usage.
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 dense. It opens with a one-line summary, then usage scenarios, followed by a clear Args block with per-parameter explanations, a Returns section, and examples. Each sentence adds value—no filler. The format is front-loaded with the purpose and usage, and the parameter details are organized in a readable list. This is efficient and easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, no enum constraints, no schema descriptions) and the presence of an output schema (though not shown, the description details the return structure), the description is complete. It covers all parameter formats, defaults, and the output JSON structure, and provides three illustrative examples that cover the main comparison types. An agent can call this tool correctly without external documentation.
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 (0%), so the description must fully elaborate on parameter semantics, and it does. It explains period1 and period2 with two formats (object with start/end dates and preset strings like 'today'/'last_week'), lists valid compare_type values with meanings, describes topic as an optional filter, platforms as a list, and top_n with default. It also includes examples that demonstrate parameter combinations. This surpasses the schema's bare type definitions and provides complete guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: comparing two periods of news data ('时期对比分析 - 比较两个时间段的新闻数据'). It specifies the resource (news data) and the action (comparison), and enumerates comparison dimensions (hot topics, platform activity, news volume). This clearly distinguishes it from sibling tools like analyze_topic_trend (single-period trend) and search_news (search), making the purpose 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?
The description provides explicit usage scenarios (comparing week-over-week hotspot changes, analyzing topic popularity differences across periods, viewing periodic platform activity changes) and three concrete examples that illustrate typical calls. However, it does not explicitly state when NOT to use this tool or name alternative tools for different tasks (e.g., using analyze_topic_trend for a single-period trend). Despite this, the scenarios are clear enough for an agent to decide when this tool is appropriate.
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 of behavioral disclosure. It explains that the tool supports current and historical data, returns JSON sorted by similarity, and mentions '节省token' (saving tokens) regarding include_url. It does not explicitly mention whether it is read-only or has side effects, but the verb 'find' implies a read operation. The description adds useful context about optional parameters and defaults, but lacks explicit statements about safety or side effects, which could be a gap without annotations.
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: purpose, args, returns, and examples. It is front-loaded with the main purpose and then organizes details logically. Every sentence provides valuable information without redundancy. The structure makes it easy to scan and understand.
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 (5 params, no output schema in view), the description covers all necessary aspects: parameter meanings, default behavior, return format, and examples. It mentions sorting by similarity and optional URL inclusion. The description is sufficient for an agent to invoke the tool correctly without additional 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 description provides detailed explanations for all five parameters, including meanings, formats, defaults, and ranges. It explains date_range options (preset and custom), threshold with its range and default, limit, include_url (saving tokens), and reference_title. Since schema description coverage is 0%, the description fully compensates by providing essential semantic information for every parameter.
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: '查找与指定新闻标题相关的其他新闻' (find other news related to a specified news title). It specifies a specific verb (find) and resource (related news), and distinguishes it from siblings like search_news by emphasizing the 'related' aspect. This provides clear 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 examples and explains parameter behaviors, strongly implying when to use the tool (e.g., to find related news). However, it does not explicitly mention alternatives or provide exclusions (e.g., 'use search_news for keyword searches'). It gives sufficient context through examples but lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden — and it does so well. It discloses server-side computation with the precise current time, the consistency guarantee, a complete return structure (success, expression, date_range, current_date, description), and the supported expression categories. The only gap is undefined behavior for unsupported/ambiguous expressions, which prevents a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear headers (为什么/推荐使用流程/Args/Returns/Examples) and the priority call front-loaded. The three worked examples are somewhat repetitive and could be trimmed, and the overall length is generous for a single-parameter tool — but structure ensures scannability and every section 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?
For a single-parameter tool this is complete: the expression contract, return format, and cross-tool integration are all documented. Since an output schema exists, the return values need no additional explanation. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the schema only declares 'expression' as a string. The description fully compensates by enumerating supported formats across four categories (单日, 周, 月, 最近N天, 动态) with concrete examples in both Chinese and English. It also explains the downstream contract: the return value feeds the date_range parameter of other tools.
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 concrete verb+resource statement — '将自然语言日期表达式解析为标准日期范围' (parse natural-language date expressions into standard date ranges). It distinguishes itself from every sibling by uniquely addressing date parsing, and reinforces its distinct value with the '为什么需要这个工具' section (server-side consistency across models). No sibling overlaps this function.
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 marks it as '推荐优先调用' (recommended priority call) and provides a step-by-step recommended flow: user gives natural language → call resolve_date_range → feed the returned date_range into analyze_sentiment or search_news. Worked examples tie it to sibling tools concretely. This is explicit when-to-use guidance with no ambiguity.
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/AY08siliang/TrendRadar/badges/card.svg)](https://glama.ai/mcp/servers/AY08siliang/TrendRadar)

Score Badge

Copy to your README.md:

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

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