TrendRadar
Server Quality Checklist
Latest release: v6.10.0
- Disambiguation3/5
Several tools have blurred boundaries: get_latest_news, get_news_by_date, and search_news all fetch news with overlapping date semantics, and analyze_topic_trend, analyze_sentiment, and analyze_data_insights all offer trend-like analysis modes. Multiple status tools (get_system_status, get_storage_status, get_rss_feeds_status) and the read_article/read_articles_batch pair add further ambiguity, though the detailed descriptions help an agent most of the time.
Naming Consistency4/5The naming mostly follows a clean verb_noun snake_case pattern: get_latest_news, search_news, trigger_crawl, send_notification, resolve_date_range. Minor deviations exist, such as get_latest_news vs get_news_by_date and the compound names get_rss_feeds_status vs get_channel_format_guide, but no chaotic mixing of conventions.
Tool Count2/5At 27 tools, the set exceeds the 25-tool threshold where count becomes a burden. While the server does span crawling, storage, RSS, analysis, article reading, and notification, many tools could be consolidated, such as merging the batch/single article readers and folding status checks into fewer tools.
Completeness4/5The surface covers the full news-monitoring lifecycle well: ingest (trigger_crawl, sync_from_remote), retrieve (search_news, get_latest_rss, get_news_by_date), analyze (analyze_topic_trend, compare_periods, analyze_sentiment), read (read_articles_batch), and notify (send_notification). Minor gaps exist, such as no explicit tool for listing available platforms and no update/delete management for stored data, but agents can work around these.
Average 4.2/5 across 27 of 27 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 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.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the type of information returned (version, data stats, cache status) and states output is JSON, which is helpful. However, it does not mention potential latency, whether it requires any setup, or any side effects. Given it's a read-only status tool, the description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loads the primary purpose. It is bilingual (Chinese and English), which is slightly redundant but not harmful. The Returns section is briefly noted. No unnecessary fluff, though the Chinese-English duplication adds minor verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters) and the existence of an output schema, the description is reasonably complete. It identifies main fields and format. However, it could clarify what 'system status' encompasses (e.g., does it include storage or RSS feed health?) to avoid overlap with sibling tools. The output schema might cover return structure, but the description does not mention any prerequisites or caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter documentation to compensate for. The description explicitly mentions the return content (version, stats, cache) and format, which helps set expectations. Since there are no parameters to explain, a baseline of 4 is appropriate for adding value in describing the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool reports system status and health check info, including version, data stats, and cache state. This is a clear purpose, but it does not explicitly distinguish from siblings like get_storage_status or get_rss_feeds_status, which could also be status-related. The verb 'get' is specific to status, but differentiation is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get_storage_status or get_rss_feeds_status. The description simply says it returns system status, but doesn't clarify scope (e.g., overall system vs. specific subsystems) or when to prefer it. This leaves the agent to guess.
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 must disclose behavioral traits. It mentions the return format (JSON with Markdown content) and implies it is a read-only generation (no mention of writes or side effects). However, it does not state whether the tool triggers any external actions, whether it is idempotent, or whether it requires special permissions. The absence of such details leaves some gaps, but the return format disclosure is a positive addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, structured with Args and Returns sections, and front-loads the core purpose. It avoids redundancy by not repeating every schema detail, but it does include the necessary parameter specifics inline. Each section earns its place, and the length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the parameters and return format, and there is an output schema that likely specifies the exact fields. However, given the large set of sibling tools, it lacks context on when to use this tool vs. others, and it does not mention any prerequisites or side effects. The description is adequate for calling the tool but not for understanding its role in the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero property descriptions (coverage 0%), so the description carries the full burden of explaining parameters. It explicitly defines report_type as daily/weekly, and for date_range it provides a required object format with example, and warns that integers are not allowed. This adds meaningful constraints beyond the plain schema, enabling correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a daily/weekly hotspot summary report (自动生成热点摘要报告). It identifies the resource (summary report) and the action (generate), and specifies the report frequency. However, it does not explicitly differentiate from siblings like aggregate_news or analyze_topic_trend, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 the many sibling tools. It does not mention alternatives, conditions, or exclusions. The description simply states what the tool does without positioning it within the larger toolbox, so an agent would lack context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It explains that it returns JSON results and lists mode-specific parameters, but it doesn't disclose potential behaviors such as rate limits, required authentication, cost implications, or what happens when data is insufficient. For a complex tool with multiple modes, more behavioral transparency (e.g., error handling, data availability dependency) is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with a clear title and suggestion, then a concise Args list with defaults, a Returns note, and examples. It front-loads the tool's purpose and key usage hint. However, it's slightly long due to detailed parameter listings, but this is justified given the complexity of 8 parameters. The structure is logical and skimmable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which describes return values), the description provides a brief note that returns are JSON but doesn't detail response fields. For an 8-parameter tool with no enum constraints and no annotations, the description covers parameter semantics, mode-specific behavior, and examples, making it fairly complete. Minor gap: it doesn't clarify how analysis_type interacts with other parameters (e.g., whether date_range is required for 'predict'), but overall it is adequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does an excellent job by detailing each parameter's purpose and, for mode-specific parameters, indicating which analysis_type they apply to. It also provides examples. This goes beyond the schema by explaining the role of each parameter, such as spike_threshold being for 'viral' mode and lookahead_hours for 'predict' mode, which is essential for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a unified topic trend analysis tool, with a specific verb ('analyze') and resource ('topic trend'). It distinguishes multiple analysis modes, but doesn't explicitly differentiate from siblings like 'analyze_data_insights' or 'compare_periods'. The purpose is clear and specific enough for an agent to understand its primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a suggestion to use resolve_date_range for natural language dates, which gives some usage context. However, it doesn't explicitly state when to use this tool versus alternatives, nor does it provide exclusions or conditions for choosing other tools. The guidance is implied through the list of analysis types but lacks explicit when-to-use versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It explains that the tool triggers a crawl, optionally saves to local, and optionally includes URLs, which indicates it may perform write operations. However, it does not disclose the impact on system state, resource usage, or potential side effects. The behavior is partially transparent but could be more explicit about side effects (e.g., network requests, data storage).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a brief intro, parameter explanations, return description, and examples. It is front-loaded with the main purpose and efficiently covers each parameter. The structure is clear and each sentence adds value. Minor: the Args section repeats the parameter names already in the schema, but that's acceptable because it adds contextual meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 3 parameters, all optional, and an output schema exists (though not detailed here), the description covers the essential context: purpose, parameters, return type, and examples. It does not mention potential errors, rate limits, or specific platform IDs, but for a tool with no required parameters and an output schema, this is fairly complete. The examples clarify usage. It's slightly above average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description is the only source of parameter rationale. The description explains each parameter: platforms (list of platform IDs), save_to_local (whether to save to output), include_url (whether to include URLs to save tokens). This adds meaning beyond the schema, which only provides types and defaults. However, it does not elaborate on valid platform values or the format of the 'output' directory, but it does what is needed given the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (trigger a crawl), the resource (crawl task), and key options (platforms, persistence, URL inclusion). It distinguishes itself from siblings like get_latest_news (which retrieves data without triggering) and get_rss_feeds_status (which checks status). Being specific about the trigger action and optional persistence helps the agent understand its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes examples of usage (e.g., trigger_crawl(platforms=['zhihu'])) that demonstrate how to call it, but does not explicitly state when to use this tool versus alternatives or any exclusions. It implies this is for manual crawling, but lacks direct comparison to siblings that might be alternatives (e.g., if the user just wants latest news, they might use get_latest_news instead). The context is clear but not deeply elaborated.
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, placing the full burden on the description. The description does disclose the input sections and that the return is JSON, but it does not explicitly state side-effect-free behavior, authorization requirements, or other execution-relevant details. It is adequate for a simple getter but leaves room for greater transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with clear Args and Returns sections. Every sentence contributes information about usage or behavior, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity config getter with a single optional parameter and an existing output schema, the description covers the necessary invocation details. It could be more explicit about side-effect safety or how this tool relates to get_system_status, but overall it provides sufficient context for the defined scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only contains a string property 'section' with a default of 'all'. The description enriches this by documenting all accepted values (all, crawler, push, keywords, weights), which is essential for correct invocation. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the current system configuration and enumerates the available configuration sections (all, crawler, push, keywords, weights). This adds resource-level specificity beyond the tool name, though it does not explicitly distinguish itself from similar siblings like get_system_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implicitly clear: call this tool to get configuration data by section. However, there is no explicit guidance on when not to use it or how it differs from sibling tools such as get_system_status or get_storage_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden — and it does explain the return shape in useful detail (the four fields and their nesting). However, it never explicitly states this is a read-only, side-effect-free operation (a relevant concern when a sibling is trigger_crawl), nor does it describe any failure, staleness, or cost behavior. The Returns section is helpful context, but a single explicit 'read-only' statement would elevate it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and appropriately front-loaded with the core purpose, followed by a structured Returns section and a minimal example. Every section earns its place. Minor marks: the docstring-style headers are slightly more verbose than necessary, but nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, this is nearly complete: the output schema exists, the Returns section adds field-level semantics the schema may not carry, and the example shows valid usage. Nothing an agent needs to invoke this safely appears to be missing; only explicitly confirming non-destructiveness would round it out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4; the description has no parameter meanings to add. The included example call 'get_rss_feeds_status()' demonstrates correct no-argument invocation, which is the right compensation for an empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('获取 RSS 源状态信息' — get RSS feed status information) and immediately details what's included: available_dates, total_dates, today_feeds, and generated_at. The return semantics make the purpose unmistakable even before considering the docstring's detailed field breakdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a working example call and its comment ('查看所有 RSS 源状态') implying when to use it, but it never explicitly states when to prefer this tool over siblings like get_system_status or get_storage_status. Usage context is implied through the example rather than stated, and no exclusions or alternative conditions are given.
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?
Since no annotations are provided, the description carries the burden of behavioral disclosure. It supplies meaningful behavioral details: limit=100 deduplicates titles, sort_by_weight defaults to True, include_url defaults to False to save tokens, and date_range defaults to today. It does not explicitly state whether the operation is read-only or whether rate limits apply, but the analysis-oriented behavior is still well described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured: purpose, routing advice, args, return shape, and an example. There is some length, but the parameter details and examples justify it, and there is little wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters, a calling pattern, an example, and the general return shape. Because an output schema is present, the lack of detailed return-field documentation is acceptable. The main remaining gaps are the absence of a full list of valid platform IDs and an unclear handling of the string-type date_range variant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates. All six parameters are explained with intended meaning, default values, formats, and practical examples. For instance, date_range is given an explicit JSON structure and platforms is shown with concrete example values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly says 分析新闻的情感倾向和热度趋势, giving a specific verb and resource. It is clear about what the tool does, but it does not directly differentiate itself from close sibling tools like analyze_topic_trend or analyze_data_insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is a useful routing hint to call resolve_date_range first for natural-language dates, and the parameter list provides defaults and examples. However, there is no explicit guidance about when this tool should be used instead of analyze_topic_trend or analyze_data_insights, so usage is mostly implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does disclose key behaviors: returns JSON, defaults for platforms/limit/include_url, and token-saving rationale. However, it does not explain data freshness, sorting, pagination, or failure behavior, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for summary, args, returns, and display guidance. Each section serves a purpose, though the display-suggestion block adds length beyond a minimal tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only news retrieval tool with three optional parameters and an output schema, the description covers purpose, parameters, return format, and usage advice. It could more explicitly distinguish itself from sibling tools like get_news_by_date, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates: it explains platforms with an example, gives limit's default and maximum, and clarifies include_url's default plus its token-saving purpose. This is more than the schema provides and enables correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the latest batch of crawled news data for quick awareness of current hot topics. It is distinct from date-based tools like get_news_by_date and search_news, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '快速了解当前热点' gives clear context for when to use this tool: when the user wants the latest news quickly. It does not explicitly list when-not-to-use scenarios or alternative tools, but the usage context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注解可用，描述需承担完整行为披露责任。它说明了返回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/5Is the description appropriately sized, front-loaded, and free of redundancy?
描述较长但结构清晰，分为Args、Returns、Examples三部分，每个句子都承载必要信息。内容虽多但无冗余，为全面解释参数和示例所必需，组织良好，略超于“简洁”但合理。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
鉴于工具拥有10个参数且无schema描述，描述提供了完整的信息：每个参数的意义、默认值、格式，使用建议，以及三个典型示例。虽存在输出模式，描述仍概括了返回结构（JSON），没有遗漏关键调用信息，对于复杂工具而言非常全面。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema描述覆盖率为0%，描述完全弥补了这一点。Args部分详细解释了全部10个参数，包括枚举值（搜索模式）、默认值、格式示例（date_range）、条件用途（threshold仅fuzzy模式）、布尔标志含义等，远超出schema提供的类型和默认值，对智能代理正确调用至关重要。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
描述使用具体动词“搜索”和资源“热榜和RSS”，明确指出这是“统一搜索接口”，能区分于兄弟工具如search_rss（仅RSS）和get_latest_news（最新新闻）。但未明确命名这些兄弟工具或说明它们的差异，因此未达到5分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
描述明确建议在需要自然语言日期时先调用resolve_date_range，提供了具体的使用场景。但未明确说明何时不使用本工具（如仅搜索RSS时该用哪个），缺乏排除性指导，未达到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, the description carries the full behavioral burden. It discloses the read-only search nature, the 'all feeds if unspecified' behavior, defaults for days/limit/include_summary, and a JSON return format. It does not cover edge cases like empty results or errors, but for a search tool the core behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into Args, Returns, and Examples sections. Each sentence contributes meaningful information, and the most important facts (what it searches and what is required) come first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters, examples, and the return format, and an output schema exists so field details are not required. The main gap is that it never explains when to choose this over the very similar search_news sibling, leaving a small selection ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining every parameter: keyword is required and used for matching, feeds defaults to all sources when omitted, days defaults to 7 with a max of 30, limit defaults to 50, and include_summary defaults to False. This adds semantics far beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches RSS data for articles matching a keyword, giving a specific verb and resource. It does not explicitly contrast itself with the sibling search_news, so an agent must infer the distinction from the RSS focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives usage context, e.g., '不指定时：搜索所有 RSS 源' and explains default days/limit, which helps an agent decide how to fill parameters. However, it does not state when to prefer this tool over alternatives like search_news or get_latest_rss.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, which it handles well: it discloses that similar stories get merged, that similarity_threshold controls strictness (越高越严格), and that the result includes dedup statistics, the aggregated list, and platform coverage stats. It does not state its read-only nature explicitly, but all params are query filters, so that is safely inferable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well structured: one-line summary, prose explanation, then Args/Returns/Examples sections. The purpose is front-loaded. It is a bit long, but justified because it must carry all parameter documentation that the 0%-coverage schema omits. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all parameters, defaults, and return shape (even though an output schema exists, so returns were optional). The only real gap is the date_range value format — the schema allows object or string, and the description just says '日期范围' without specifying accepted formats (e.g., ISO dates, relative strings) — a minor ambiguity for a complex tool with zero schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully — and it does. The Args block documents all 5 parameters with semantics, valid ranges (0.3–1.0 for similarity_threshold), defaults (50, 0.7, False), and examples (['zhihu', 'weibo']). This is textbook compensation for an empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action (deduplicate and merge similar news across platforms into one aggregated item) with a distinct resource (cross-platform news). The first line '跨平台新闻聚合 - 对相似新闻进行去重合并' plus the fuller explanation of merging same-event stories and showing cross-platform coverage clearly separates it from siblings like get_latest_news, search_news, and find_related_news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case: seeing combined cross-platform coverage with heat and dedup stats rather than raw per-platform lists. However, it never explicitly names alternatives or states when not to use it. Given ~27 sibling news tools, explicit routing (e.g., 'use get_news_by_date for a single day's raw items') would materially help an agent.
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 takes on the burden of explaining behavior: it details what is computed in each mode, where keywords come from, and what the return value looks like. It does not mention potential side effects or whether the dataset is automatically refreshed, but a read-only behavior is strongly implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured using a docstring-style layout with Args, Returns, and Examples. Every sentence contributes useful information, and examples summarize the main use cases concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three optional parameters, no annotations, and an output schema, the description is sufficiently complete. It covers all parameters, return format, and example usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions, but the description fully compensates by explaining all three parameters, their defaults, allowed modes, and real usage examples. This leaves no ambiguity about how to set each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: generating counts and statistics on hot topics, which matches the name 'get_trending_topics'. It is distinct enough from generic news-fetching tools, though it does not explicitly distinguish itself from the overlapping sibling tool 'analyze_topic_trend'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong internal usage guidance, such as the 'daily' vs 'current' modes and 'keywords' vs 'auto_extract' modes, along with concrete examples. However, it does not mention when to choose this tool over related siblings like 'analyze_topic_trend' or 'get_latest_news'.
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. The description carries full Burden: It reveals the default behavior (reference date defaults to today), the meaning of threshold (higher = stricter match), include_url (to save tokens), and return format sorted by similarity. It covers the main behavioral expectations but does not detail edge cases like error conditions, pagination, or the event when no matches are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args, build returns, and rater examples. It is comprehensive but still readable. It includes only required details, defaults emphasized. It might be slightly nitrogen but not verbose. The content is front -loaded with the main purpose and parameter meaning, so Concise them. Score 4 for good structure without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 1 required, an output schema, the description is adequately complete: it provides defaults for every parameter, illustrates different styles date_range, states the return type (JSON sorted by similarity), and offers usage examples. It does not mention pagination, but that also lies in output schema and defaults. The level of detail matches the tool complexity and the schema information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The antecedent has 0% schema coverage; every parameter listed in the schema has no description property. The description provides a full Args block that explains each parameter meaning, its (date preset and custom JSON format), default values, and the effect of similarity threshold and include_url. Includes examples; this is exactly the compensation needed for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states: it finds other news related to a given news title ('查找与指定新闻标题相关的其他新闻'), and supports both current and historical data. This is a specific verb-resource pair that clearly distinguishes it from sibling tools like get_news_by_date (date–based) or search_news (generic search). An agent reading the first sentence knows exactly what tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage examples and explains parameter behavior (e.g., '不指定只查询今天的数据'), but it does not explicitly instruct when to use this tool over search_news, get_news_by_date, or other siblings. It covers the da:definitions of arguments, but leaves the selection criteria to inference. The 'If not specified' etc. shows usage context for the tool, but not when to pick it over its peers.
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?
无注解，描述承担了行为披露责任。它说明了数据存储分离、多日查询、返回格式，以及include_summary参数带来的'节省token'行为。但未明确说明只读性质、权限要求或速率限制。对于get类工具，行为基本可预期，评分4。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
所有参数被解释，返回类型有说明，示例提供了用法。但缺少对输出格式的详细描述或异常情况。尽管没有输出schema，但提供了返回描述。整体完整。评分4。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
描述为每个参数提供了明确语义：feed列表、默认天数、返回条数限制、摘要选项。参数含义清晰，并有示例用法。schema只有类型没有描述，描述补齐了这一点。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
描述以具体动词“获取”开头，明确资源为“RSS订阅数据”，并说明“与热榜分开存储”，足以与同类get_latest_news区分。标题虽缺失，但描述提供了完整目的信息。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
描述说明RSS数据与热榜数据分开存储，按时间流展示，适合获取特定来源的最新内容，这提供了使用上下文。但未明确说明何时不应使用（例如何时选择get_latest_news），也未提及替代工具，因此建议性指导有限。
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 behavioral disclosure burden. It reveals that the tool inspects config.yaml and .env, scans 9 specific channels, and returns JSON with per-channel configured status and source. It does not discuss side effects, auth, or failure modes, but for a read-only status tool this is adequate and non-misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary, supporting details about config sources and channel list, and a return-format section. It is concise and front-loaded; the example call is minor but not wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only status tool with an output schema, the description is sufficiently complete: it names the config sources, lists channels, and states the JSON response shape. It does not mention all potential edge cases, but none are critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is no parameter ambiguity. The baseline of 4 applies here; the description adds no parameter-specific meaning because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all configured notification channels and their status, with a specific verb, resource, and scope. It lists the supported channels and distinguishes itself from RSS/config sibling tools by focusing on notification 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when you need the configuration state of notification channels from config.yaml and .env. It does not explicitly name alternatives or exclusions, but the resource is scoped enough that an agent can select it appropriately.
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?
没有任何 annotations，因此描述需要承担行为披露职责。它明确说明这是只读的“列出/查看”操作，并交代了返回 JSON 列表和对比结果，没有暗示修改或破坏行为。虽然未提远程访问延迟或权限要求等细节，但对于一个 list 类工具，行为信息已经比较充分。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
描述由核心一句话、参数说明、返回说明和示例组成，结构清晰、信息密度高，最重要使用方式被放在靠前位置。不过首句“列出本地/远程可用的日期范围”和后续描述存在轻微语义重合，所以不是满分级别。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具本身只含一个可选参数，复杂度很低；描述已经覆盖了参数取值、默认行为、返回格式和典型调用方式，并给出了具体示例。上下文提示中存在 output schema，所以不需要展开逐字段返回值，整体对安全正确调用已经足够完整。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
input-schema 对 source 只给了字符串类型和默认值，没有描述参数含义，描述则完整补充了 local、remote、both 三个取值及各自语义，还明确默认情况下会同时列出并对比。额外给出了 list_available_dates(source="local") 的调用示例，充分弥补了 schema 参数描述缺失的问题。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
描述以“列出/查看”明确动词，资源限定为“本地/远程可用的日期范围”，并说明返回 JSON 格式的日期列表与对比结果。该用途与同组的新闻查询、趋势分析等兄弟工具清楚区分，agent 不会混淆其职责。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
描述给出了 source 参数的三种取值及默认行为，也提供了调用示例，能够让 agent 推断出“查看哪些日期有数据”时使用此工具。但没有明确指出何时不应使用，也没有和 resolve_date_range、get_news_by_date 等相近工具做选择性说明。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden reasonably well. It discloses prerequisites (config/env vars), the days parameter behavior including 0/7/30 meanings, and the expected return structure including skipped_dates for local-existing files. It could mention overwrite behavior or failure handling more explicitly, but it is far beyond a vague one-liner.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into Purpose, Args, Returns, Examples, and Note sections. It is moderately long but each section adds necessary information, and the purpose is front-loaded. Slightly verbose but justifiably so for a tool with configuration prerequisites.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description covers the operation, the parameter semantics, the return schema in detail, and the required environment/config setup. This is enough for an agent to invoke the tool correctly without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully explains the one parameter 'days': default value, meaning of 0, 7, and 30, and even provides examples. This more than compensates for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: pulling data from remote storage to local for analysis/query in MCP Server scenarios. It is unambiguous and easy to distinguish from siblings like get_storage_status, though it does not explicitly name any sibling as an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: when a crawler has stored data to remote cloud storage and the MCP Server needs to pull it locally for analysis. It does not explicitly state when not to use it or list alternatives, but the scenario is specific enough to guide 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 available, the description carries the burden of behavioral disclosure. It clearly indicates this is a check-only operation, compares against GitHub, affects two components, and returns JSON. The optional proxy_url also hints at network-dependent behavior. It does not describe failure modes, but core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Examples sections, and it is front-loaded with the core purpose. Every sentence adds value, and the examples are terse but sufficient. No redundant or bloated content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter and an output schema, the description covers invocation, parameter purpose, return format, and examples. It is complete enough for an agent to call the tool correctly. Minor gaps include explicit error scenarios or when a proxy is required, but these are not essential for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema's lack of parameter documentation. It does: proxy_url is described as an optional proxy URL for accessing GitHub, with a concrete example. This adds meaningful semantic value beyond the raw schema type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: '检查版本更新' (check version updates), comparing local versions against GitHub remote versions for both TrendRadar and MCP Server. This clearly differentiates it from all listed siblings, which are about news, data analysis, configuration, and notifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: check if an update is needed by comparing local and remote versions. It explains when the proxy_url parameter is relevant (for accessing GitHub) and gives usage examples. It does not explicitly discuss exclusions or alternative tools, but no sibling tool serves a similar version-check purpose.
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?
There are no annotations, so the description carries the full disclosure burden. It provides meaningful behavioral details: supported date_range formats, default behavior of 'today', platform defaulting to all, limit maximum of 1000, and include_url default false to save tokens. It also states the return shape. It stops short of describing pagination or error behavior, but for a read-only fetch tool the coverage is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured withArgs and Returns sections, each line earning its place. The purpose sentence is front-loaded, and parameter details are grouped clearly. Slightly verbose due to the format details, but that detail is essential given there are no schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter retrieval tool with an output schema and zero required parameters, the description is nearly complete: it covers defaults, constraints, example values, and return contents. It doesn't explicitly mention sort order or what happens on invalid input, but those are minor gaps given the output schema and the otherwise thorough parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully, and it does. Each parameter is explained beyond its type: date_range gets concrete examples and accepted formats, platforms gets an example list, limit gets default and max, and include_url gets a default plus the rationale '节省token'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: '获取指定日期的新闻数据' (get news data for a specified date), and frames it for historical analysis and comparison. This clearly differentiates it from siblings like get_latest_news, which targets current news, and search_news, which implies query-based retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: historical data analysis and comparison, which implies this is the tool to use when a specific date range is needed rather than the latest items. It doesn't explicitly list alternatives or exclusion criteria, but the date-centric framing and sibling names make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states the tool returns JSON-formatted storage status including local/remote status and pull configuration, which goes beyond the name. The verbs '获取' and '查看' imply a read-only, non-destructive operation. This adequately discloses the behavioral profile for a no-parameter status query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the purpose front-loaded in the first sentence and a clear 'Returns' section for output details. Every sentence earns its place, and there is no redundant or filler content. The structure is easy to parse for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter status query, the description is reasonably complete. It states the output format and core content, and there is an output schema available. It does not explicitly mention error handling or permissions, but those are less critical given the read-only nature. The description covers what an agent needs to know to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to add beyond the schema. The baseline for 0 parameters is 4, and the description appropriately focuses on the output rather than parameters. No additional parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' - get) and resource ('存储配置和状态' - storage configuration and status). It elaborates that it views current storage backend configuration and local/remote status, which precisely distinguishes it from sibling tools like get_system_status and get_current_config. The purpose is 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to retrieve storage configuration and status) but does not explicitly mention alternatives or exclusions. Sibling tools like get_current_config and get_system_status exist, yet no 'use this instead' guidance is given. However, the scoping to storage is evident, so the usage intent is implied strongly enough.
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 important behavioral traits: uses Jina AI Reader, strips ads/navigation noise, 100 RPM limit, built-in 5-second rate control, and possible paywall/login limitations. This is meaningful, though it could also mention error behavior or HTTP failure handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections, a typical workflow, examples, and notes. Every section provides useful operational information, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema present, the description covers the main call flow, parameters, output format, and operational constraints. It is complete enough for an agent to invoke the tool correctly, though it omits explicit error-handling expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well by explaining that url is required and must start with http:// or https://, and that timeout defaults to 30 with a maximum of 60 seconds. This adds practical meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('读取指定 URL 的文章内容') and clearly states the output format (LLM-friendly Markdown). It also distinguishes the tool's purpose from search-oriented siblings by framing it as the follow-up step after searching for news links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit typical workflow: search_news first, then read_article, then analysis. This is strong contextual guidance, though it does not explicitly mention when to use the sibling read_articles_batch instead, so it falls just short of 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 details the automatic formatting adaptations for each channel (e.g., DingTalk strips <font>, Telegram converts markdown to HTML), revealing internal behavior beyond a simple send. It also notes that results are returned per channel. It does not mention rate limits or auth requirements, but given the context, the formatting adaptations are the most critical behavior and are well covered. A 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured: an intro, channel-specific formatting list, a helpful hint, then Args, Returns, and Examples. Each section serves a purpose, and the channel list is necessary for clarity. It could be slightly condensed (e.g., grouping similar channels), but the organization is logical and front-loads the core purpose. A 4 is fair.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists (so return value details are not required), the description covers key usage aspects: parameter semantics, channel adaptations, and a pointer to the format guide. It does not mention error handling or prerequisites like authentication, but these may be covered by output schema or system context. For a sending tool with zero schema coverage, it is quite complete, though a brief note on partial failures could fill a small gap. Score 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. The 'Args' section explains each parameter: message is required, title has a default value, and channels has a clear list of allowed values. It even provides examples showing usage. This adds substantial meaning beyond the bare schema and effectively documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends messages to configured notification channels ('向已配置的通知渠道发送消息'). It lists the specific channel types and distinguishes itself from siblings like get_channel_format_guide (which retrieves format strategies) and get_notification_channels (which lists channels). The purpose is unambiguous and well-scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use get_channel_format_guide before sending to optimize formatting, which helps route the agent to the right sibling. It also clarifies that channels parameter is optional and defaults to all configured channels. However, it does not explicitly state when NOT to use this tool or mention alternative sending-related tools (e.g., get_notification_channels for listing channels), so it falls short of a perfect 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?
无注释，描述承担了行为披露责任。详细列出了各渠道支持的特性，并说明返回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/5Is the description appropriately sized, front-loaded, and free of redundancy?
描述较长但结构分明：前导介绍、渠道概览、参数说明、返回值、示例。每个部分都有价值，冗余少，但可以进一步精炼。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
有输出schema，描述也说明了返回格式。参数解释彻底，没有遗漏关键信息。对于该工具，描述已足够支持代理正确调用。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
schema覆盖率为0%，描述完全补偿了参数说明。channel参数的每个可选值都列出，并明确不指定时返回所有策略，语义清晰。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明工具获取通知渠道的格式化策略指南，动词+资源清晰，并且列出了各渠道的格式差异，与send_notification等sibling工具区分明显。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
明确说明在调用send_notification之前使用，提供了具体使用场景，但没有明确指定替代方案或什么时候不使用。不过该工具是唯一的指南类工具，与sibling区分已足够。
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 behavioral transparency burden. It supplies useful behavioral detail: modes are mutually exclusive, date_range must be an object rather than an integer, defaults are given, and the result is JSON. It does not explicitly state that the tool is read-only, but its analysis-only framing makes that risk minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into clearly titled sections, with each parameter explained in one line and concrete examples at the end. There is no fluff: every sentence conveys needed selection, invocation, or formatting information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a five-parameter tool with an empty schema and no annotations, the description is unusually complete. It covers all parameters, default values, mode-specific applicability, return format, and examples—an agent can call it correctly without further inference. The output schema is present elsewhere, so the terse return description suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and loose date_range typing, while the description fully compensates by defining meaningful semantics for all five parameters. It enumerates valid insight_type values, clarifies which modes topic belongs to, gives explicit object syntax for date_range, and documents defaults for min_frequency and top_n.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific unified tool for data insight analysis and clearly enumerates three distinct insight modes. Each mode is associated with a concrete purpose, which differentiates this tool from sibling news-fetching, crawling, and system-status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear mode-by-mode context with examples showing which parameters apply to each insight type. It does not explicitly state when to avoid this tool in favor of a specific sibling, but the scope is obvious enough that an agent can select it appropriately.
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 explains the return structure (JSON with periods, compare_type, and specific result keys) and the behavior of each compare_type, as well as defaults and optional filters. It does not explicitly state that the operation is read-only or describe error handling for invalid periods, but the read-only nature is implied by the analytical purpose and the detailed output spec.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage, arguments, return, examples) and is front-loaded with the primary purpose. Each sentence contributes value, and the examples illustrate realistic calls. Despite its length, it is efficient and avoids redundancy, making it 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no annotations, the description is comprehensive. It covers all parameters, explains the output schema, provides multiple examples, and clarifies the semantics of each compare_type. The output schema exists, reducing the need to detail return fields, but the description still summarizes the result keys. No essential information for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, making the description the sole source of parameter meaning. It thoroughly explains all six parameters: period1 and period2 with accepted formats (object or preset strings), topic, compare_type with enumerated values and descriptions, platforms as a filter list, and top_n with default. This goes well beyond the schema's type-only definitions and adds critical usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: '时期对比分析 - 比较两个时间段的新闻数据' and enumerates the dimensions compared (hot topics, platform activity, news count). It is specific about the resource (news data) and the action (compare two periods), distinguishing it from trend-analysis siblings like analyze_topic_trend, which focus on a single series rather than pairwise comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a '使用场景' section with three concrete examples (comparing this week vs last week, topic heat differences, platform activity changes), giving clear context for when to use the tool. However, it does not explicitly mention when not to use it or name alternative tools, though the sibling list includes related analytics tools. This is a minor gap.
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 disclosure burden, and it does well: it reveals that computation happens server-side using precise current time, and documents the full return shape including expression, date_range, current_date and description. The only gap is error behavior — what happens when the expression is unsupported is never stated, despite the example showing a 'success' field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence and the body is chunked with headers and numbered steps for scanability. It is verbose, however — the workflow section and the two worked examples partially duplicate each other — but given the 0% schema coverage, the extra length is justified compensation rather than bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema but no annotations, everything an agent needs is present: the parameter's accepted grammar, the exact return contract, the recommended invocation context, and a chaining example. The only theoretical gap (failure modes) is negligible for a pure computation utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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: it enumerates every supported expression form — single day, week, month, recent-N-days, and dynamic N — in both Chinese and English. An agent has everything needed to format the 'expression' argument correctly without opening any other documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening line states a specific verb+resource: '将自然语言日期表达式解析为标准日期范围' (parse natural language date expressions into a standard date range). It is plainly distinct from all siblings — none of the 26 news/sentiment/crawl tools does date parsing — so no ambiguity with alternatives. The examples reinforce the single clear job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly marks itself '【推荐优先调用】' (recommended as priority call), justifies why (AI models computing dates themselves causes inconsistency), and lays out a numbered 3-step workflow showing exactly when to invoke it and how to chain the result into analyze_sentiment and search_news. The when-not case is implicit but complete because no sibling shares its function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states that requests are made sequentially with automatic 5-second delays to respect rate limits, handles up to 5 articles, has a per-request timeout, and isolates failures so one failure doesn't affect others. It also mentions the expected time cost (25-30 seconds for 5 articles), making behavior highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary, explanation, typical usage flow, args, returns, and notes. It is front-loaded with the primary purpose and contains no redundant information. Every sentence adds value, such as the note about skipping extras and the total time, making it concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides comprehensive context: it explains the batch reading mechanism, the rate-limiting rationale, the usage flow with a preceding tool, parameter details, return format (JSON with contents and status), and important edge cases (max articles, timeout, failure isolation). This covers all necessary information for an agent to use the tool correctly without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions, but the description explains both parameters thoroughly: 'urls' is clarified as a required list of article links with a maximum of 5, and 'timeout' is described as per-request timeout in seconds with a default of 30. This adds essential meaning beyond the bare schema, fully covering the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool reads multiple article contents in batch, specifying a maximum of 5 articles and an interval of 5 seconds. It clearly distinguishes itself from the single-article 'read_article' tool by using the term '批量' (batch) and outlining the batch behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a typical usage flow, starting with search_news to obtain URLs and then using read_articles_batch, which gives practical context. However, it does not explicitly compare with the alternative 'read_article' for single articles, nor does it state when to prefer one over the other, so it falls slightly short of full explicitness.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/15642875149/TrendRadar'
If you have feedback or need assistance with the MCP directory API, please join our Discord server