TrendRadar MCP Server
Server Quality Checklist
Latest release: v6.10.0
- Disambiguation4/5
Most tools have clearly distinct purposes: news retrieval, RSS, analysis, reporting, and notification tools are separated. A few analysis tools (analyze_sentiment, analyze_topic_trend, analyze_data_insights) could be confused at first glance, but their descriptions clearly define different analysis modes and parameters.
Naming Consistency5/5All tool names follow a consistent snake_case verb_noun pattern (e.g., get_latest_news, search_rss, analyze_sentiment, send_notification). The naming is uniform and descriptive, with no mixed conventions or vague verbs.
Tool Count2/5The server exposes 27 tools, which exceeds the 25-tool threshold for being too many. While the broad scope of news monitoring, analysis, notifications, and storage sync justifies a larger surface, this server would benefit from consolidation (e.g., merging some analysis tools).
Completeness5/5The tool set covers the full lifecycle of news monitoring: crawling, retrieval, search, aggregation, analysis (sentiment, trends, insights, comparison), reporting, article reading, and notification. It also includes configuration, status, and sync tools, leaving no obvious dead ends for common workflows.
Average 4.3/5 across 27 of 27 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.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?
With no annotations, the description carries the behavioral transparency burden. The verb '获取' and the stated return values imply a read-only operation, but the description does not explicitly disclose absence of side effects, authentication requirements, or performance characteristics. It provides minimal but non-misleading behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the 'Returns: JSON格式的系统状态信息' line partially duplicates the earlier sentence '返回系统版本、数据统计、缓存状态等信息'. Still, it remains concise and scannable.
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?
For a zero-parameter tool with an output schema, the description covers the basics. However, given sibling tools such as get_storage_status, check_version, and get_current_config, the description does not clarify how this aggregate status tool relates to them, leaving some selection ambiguity.
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 is empty, so the schema provides full coverage trivially. The baseline of 4 applies because there is no parameter semantics burden, and the description appropriately focuses on return content.
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 gets system running status and health check information, and enumerates example contents (system version, data statistics, cache status). It does not explicitly differentiate from sibling tools like get_storage_status or check_version, but the scope is clearly broader.
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 usage guidance is provided. The description does not explain when to choose this tool over siblings such as get_storage_status, get_current_config, or check_version, and it lacks any exclusion or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds the critical constraint that date_range must be an object (not an integer) and states the return format (JSON with Markdown). However, it does not disclose other traits like data source, read-only behavior, or edge-case handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args/Returns and is reasonably concise, but uses Markdown formatting and spacing that adds some length. It is not overly verbose and every part adds value.
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 tool has a simple interface (two optional params) and an output schema exists. The description covers the purpose, input formats, and return format. It lacks deeper context about content specifics or failure modes, but is otherwise sufficient.
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, and the description fully compensates. It explains report_type values (daily/weekly), provides a concrete date_range format and example, and warns about the object-type requirement. This is far beyond the raw 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 the tool generates daily/weekly hotspot summary reports, using a specific verb and resource. It distinguishes itself from siblings via the 'daily/weekly summary' and 'hotspot' focus, but does not explicitly contrast with overlapping tools like aggregate_news or compare_periods.
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 alternatives. It does not mention use cases, exclusions, or situations where sibling tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not explicitly state that this is a read-only, non-mutating analysis operation, nor does it mention any side effects, rate limits, or dependencies on underlying data. The description focuses on parameters and return format, leaving the safety and side-effect profile largely undisclosed.
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 'Args', 'Returns', and 'Examples' sections, making it easy to scan. Each parameter entry is informative and relevant, and the examples illustrate real usage. No filler; the length is justified by the tool's multi-modal nature.
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 five parameters, their meanings, and provides examples for all three insight types, which is strong for a multi-mode tool. However, it leaves some ambiguities, such as whether date_range is required for platform_activity, and doesn't mention any prerequisites or data dependencies. Overall, it is sufficiently complete given the output schema exists.
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 zero descriptions; the description fully compensates by documenting every parameter, its possible values (insight_type enum), applicable modes, defaults, and the required object format for date_range. It even provides an explicit warning that date_range must not be an integer, adding critical semantic detail beyond the 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 clearly states it is a unified data insight analysis tool integrating multiple analysis modes and enumerates three specific modes (platform_compare, platform_activity, keyword_cooccur), each with a brief explanation. This distinguishes it from sibling tools like analyze_topic_trend or analyze_sentiment by covering these specific comparative/co-occurrence analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples and clarifies which parameters apply to which insight mode (e.g., 'topic' for platform_compare; 'min_frequency' and 'top_n' for keyword_cooccur), giving implicit usage context. However, it does not explicitly state when to choose this tool over siblings such as analyze_topic_trend or analyze_sentiment, nor does it provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It states that it returns JSON and documents mode-specific parameters, but it does not explicitly state whether the tool is read-only, whether it has side effects, requires authentication, or how it handles invalid or missing data. The term 'analysis' implies non-mutating, but that remains implicit rather than explicit.
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: a brief summary, a practical usage tip, a clear Args list with inline explanations, and two illustrative examples. Although somewhat long, every section earns its place, and the main 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 an 8-parameter tool with no annotations and a minimal schema, the description covers all parameters, mode semantics, and even provides a cross-tool dependency hint. It does not discuss data sources, performance, or rate limits, but the presence of an output schema and the detailed parameter guidance make the tool sufficiently usable.
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, providing only types and defaults. The description fully compensates by explaining every parameter, including the valid values for analysis_type, the expected format for date_range, and the mode-specific meanings of spike_threshold, time_window, lookahead_hours, and confidence_threshold. This is exemplary parameter documentation.
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 integrating multiple analysis modes (trend, lifecycle, viral, predict), which distinguishes it from sibling tools like analyze_sentiment or get_trending_topics. It lacks an explicit imperative verb like 'analyzes', but the name and detailed mode list make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises calling resolve_date_range when using natural-language dates, which is a clear cross-tool usage guideline. It also documents each analysis_type mode with defaults, helping the agent choose the appropriate mode. However, it does not explicitly say when to prefer this over sibling tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It explains that results are sorted by similarity, that `include_url` saves tokens, and how the date range works. It does not mention potential limitations like data freshness or rate limits, but the 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, Args section, Returns, and Examples. It is somewhat lengthy due to date_range details, but every part earns its place and the structure aids comprehension.
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 5 parameters and an output schema, the description covers functional semantics, parameter details, output format, and examples. It lacks edge cases or error handling, but it is sufficiently complete for an agent to use the tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It fully explains every parameter: `reference_title` (full/partial), `date_range` (with preset and custom formats), `threshold` (meaning and default), `limit`, and `include_url` (purpose and token-saving). This is exemplary parameter documentation.
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 finds news related to a specified title and supports current/historical data. It uses specific verbs and resources, but does not explicitly distinguish itself from siblings like `search_news` or `get_latest_news`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed parameter usage, date range formats, and examples, making it clear how to invoke the tool. However, it does not explicitly state when to use this tool instead of alternatives such as `search_news`, nor does it list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full burden. It uses '查看' (view) and '获取' (get), implying a read-only operation with no side effects, and it discloses the return format (JSON with local/remote status and pull configuration). However, it does not explicitly state safety, permissions, or any rate limits.
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?
Description is three short sentences, front-loaded with the primary action, and includes a returns note without 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 zero-parameter status tool with an output schema, the description sufficiently conveys scope and result content. It lacks contextual guidance on when to prefer it over siblings, but that is covered under usage guidelines; overall it's adequate for its low complexity.
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 0 parameters, so the description cannot add parameter detail; the schema is trivially 100% covered. The description's mention of return content partially clarifies what the user can expect, but no parameter semantics are 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 storage configuration and status ('获取存储配置和状态'), specifying storage backend, local/remote storage status, and pull configuration. This distinguishes it from siblings like get_system_status or get_rss_feeds_status by focusing on storage resources.
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?
No explicit when/when-not guidance is provided. The use case is implied by the description: call when needing storage status information, but no alternatives or exclusions are mentioned relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses parameter behaviors, defaults, and return format, and notes that threshold only applies to fuzzy mode and include_rss toggles RSS results. However, it omits potential edge cases, pagination behavior, or error conditions, leaving some behavioral aspects implicit for a complex tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately structured: a one-line summary, a cross-tool suggestion, a detailed Args list, Returns, and Examples. Each section serves a clear purpose, and the length is justified by the need to document 10 parameters when the schema provides no descriptions. It is front-loaded with the core purpose and does not waste words.
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 the complexity (10 parameters, no schema descriptions), the description is quite complete. It covers all parameters, provides practical examples, and mentions the return structure as JSON with hot list and optional RSS. The presence of an output schema reduces the need to detail return fields, and the guidance to use resolve_date_range addresses a common usage pitfall. Minor gaps remain regarding advanced behaviors, but overall it is sufficient for effective use.
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, so the description must compensate. It provides thorough explanations for all 10 parameters, including the meaning of search_mode values, the expected date_range format, platform list usage, and defaults for limit, threshold, and include_rss. The examples illustrate realistic parameter combinations, adding substantial semantic value beyond the bare 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 clearly states this is a unified search interface that supports multiple search modes and can simultaneously search hot lists and RSS feeds. The verb 'search' and resource 'news' are specific, and it distinguishes itself from siblings like search_rss and get_latest_news by combining both sources and offering multiple modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one concrete usage guideline: suggesting a call to resolve_date_range for natural language dates. It implies this is the primary unified search tool, but it does not explicitly state when to prefer it over alternatives like search_rss or get_latest_news, nor does it mention exclusions or fallback scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the exact return structure, including available_dates, total_dates, today_feeds with per-feed name and item_count, and generated_at. However, it does not explicitly state that the tool is read-only or describe any caching or performance implications, though the nature of a status getter implies safety.
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 and well-structured, with a title, description, returns section, and example. It front-loads the purpose and provides a clear example of usage, earning a high score.
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 the tool has no parameters and the description provides a detailed return format, it is contextually complete. The example invocation clarifies usage, and the output schema (per context) would supplement type information. The description covers all necessary aspects 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 tool has zero parameters, so the description correctly omits parameter details. Per the rubric, zero params yields a baseline of 4, and the description adds no unnecessary parameter information.
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's function: '获取 RSS 源状态信息' (get RSS feed status information) and elaborates that it shows configured RSS sources and their data statistics. This distinguishes it from sibling tools like get_latest_rss or get_system_status, which focus on content or overall system status rather than feed-specific statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking RSS source status and statistics but does not explicitly state when to use it over alternatives. For example, no mention of using it when you need feed health metrics vs. using get_system_status for overall system health. This is 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 of behavioral disclosure. It reveals a key behavior: automatic format adaptation per channel, with detailed per-channel transformations. It also states the return type (JSON with per-channel status). However, it omits important behavioral aspects like error handling for invalid channels, rate limits, or whether sending is asynchronous. This is a moderate disclosure but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear intro, a bulleted per-channel format list, a tip, and examples. The bullet list is detailed but directly relevant—it helps the agent generate appropriate content. It is longer than necessary but not bloated; every section serves a purpose.
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 no annotations and moderate complexity (3 parameters, multiple channels), the description covers essential aspects: purpose, parameter semantics, return format, and examples. It also points to a sibling tool for deeper formatting details. Missing error handling and failure semantics, but the provided information is sufficient for typical use.
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 is the sole source of parameter meaning. It explains each parameter: message (markdown content, required), title (default 'TrendRadar 通知'), and channels (list of valid channel names, default null sends to all). This goes beyond the schema by adding usage context and default behavior. It could be slightly richer (e.g., length limits), but it is solid.
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 starts with a clear verb+resource: '向已配置的通知渠道发送消息' (send messages to configured notification channels). It distinguishes itself from siblings like get_channel_format_guide and get_notification_channels by explicitly focusing on the sending action. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a direct tip: '发送前可调用 get_channel_format_guide 获取目标渠道的详细格式化策略' which tells the agent when to use an alternative tool. It also clarifies the default behavior when channels is not specified ('不指定则发送到所有已配置渠道'). However, it does not explicitly state when not to use this tool (e.g., for listing channels), but the sibling distinction is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions the return format (JSON) and lists configurable sections, but it does not explicitly confirm that the operation is read-only, nor does it mention any side effects, authorization requirements, or rate limits. The name 'get' implies a safe read, but the description does not elaborate beyond that.
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 and well-organized: a clear header, an Args section detailing the parameter and its options, and a Returns section. Every line serves a purpose, and it is appropriately sized for a tool with one optional parameter.
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 simple single-parameter tool with an output schema, the description covers all essential aspects: what the tool does, what parameter it accepts (with valid values), and what it returns (JSON). It is complete enough for an agent to invoke the tool correctly, and the presence of an output schema means detailed return fields are not required in the description.
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 defines 'section' with a string type and default 'all', with no description or enums. The description fully compensates by listing all accepted values ('all', 'crawler', 'push', 'keywords', 'weights') and their meanings, along with the default behavior. This adds substantial semantic value that the schema lacks.
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 function: retrieving the current system configuration. It lists specific configuration sections (crawler, push, keywords, weights), which distinguishes it from sibling tools like get_system_status or get_rss_feeds_status. The verb '获取' (get) and resource '系统配置' (system configuration) are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when configuration is needed, but it does not explicitly state when to prefer this tool over alternatives or mention any exclusions. It provides clear context about what sections are available, but no explicit guidance on when not to use it or which sibling tools to use instead.
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 details several behaviors: default date range is today, limit defaults to 50 with a maximum of 100, titles are deduplicated, sort_by_weight defaults to true, include_url defaults to false to save tokens, and the return format is JSON with sentiment distribution, heat trends, and related news. This goes beyond a simple operation description, though it lacks explicit read-only or error behavior details.
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: a one-sentence purpose, a useful usage tip, a clear Args list, Returns overview, and an Example. Each section is concise and earns its place, with no unnecessary repetition or verbose explanations.
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 inputs with defaults, provides a relevant usage tip, and summarizes the output structure. It does not address error scenarios or what happens with empty results, but given the presence of an output schema and the tool's moderate complexity, the description is sufficiently complete for correct invocation in typical use cases.
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, but the tool description provides thorough explanations for all six parameters in the Args section. It specifies formats (e.g., date_range as {'start': 'YYYY-MM-DD', 'end': 'YYYY-MM-DD'}), defaults, and semantic notes (e.g., deduplication, token saving). This fully compensates for the schema's silence and adds significant meaning beyond the raw property 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 the tool's purpose: '分析新闻的情感倾向和热度趋势' (analyze sentiment and popularity trends of news). It uses a specific verb+resource structure. However, it does not explicitly distinguish itself from sibling tools like analyze_topic_trend or analyze_data_insights, which could overlap in scope.
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 an explicit usage guideline: when using natural language dates, first call resolve_date_range to obtain a precise date range. This gives clear contextual guidance for a common scenario. It does not explicitly state when to use this tool over sibling analysis tools, but the parameter descriptions and defaults also aid usage.
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 burden. It explains that the tool compares local and remote versions and returns a JSON result, which is useful. However, it does not disclose that this is a network operation that may fail or be slow, nor does it mention any dependencies like internet access or GitHub availability. These are meaningful behavioral traits beyond the schema that could affect invocation.
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 first line stating the core purpose, followed by Args, Returns, and Examples. It is concise, with no wasted sentences, and the examples are helpful. It earns its place.
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?
This is a simple tool with one optional parameter and an output schema. The description covers the return value adequately. It does not mention error behavior or network prerequisites, but for this straightforward version-check tool, the description is sufficiently complete. The output schema further reduces the need to describe return fields.
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, but the description's 'Args' section fully explains proxy_url as an optional proxy for accessing GitHub, with an example URL. This adds significant meaning beyond the bare schema type (string/null), compensating perfectly for the gap.
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 verb 'check' and the resource 'version updates', and specifies it checks both TrendRadar and MCP Server components. It also explains the action: compare local vs GitHub remote version. This is specific and distinguishes it from sibling tools (no other tool deals with version checking).
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 implies when to use it: when you need to determine if an update is required. It provides context about checking two components and comparing against GitHub, but does not explicitly state exclusions or alternatives. Since there are no closely related sibling tools, a clear implicit usage context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses default values, token-saving behavior via include_url, and notes the return format (JSON list). However, it does not explicitly state that this is a read-only operation or mention potential errors/rate limits. The get-verb implies safety, but not fully explicit.
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 an intro sentence, an Args section listing parameters with concise explanations, and a Returns note. Every sentence adds value and there is no unnecessary repetition or filler. The length is appropriate for 4 parameters.
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, return format, and usage context. It also notes the output contains title, platform, ranking, etc. With an output schema present, return details need not be exhaustive. Minor gaps include not listing valid platform IDs explicitly (though examples are given) and not describing sorting order, but overall it is sufficiently complete for a retrieval tool.
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 provides only basic types (anyOf object/string/null, integer, boolean) with no additional details. The description compensates fully by explaining each parameter: date_range formats (range object, natural language, single day, default), platforms example with default behavior, limit default/max, and include_url default with rationale. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves news data for a specified date, with the purpose of historical analysis and comparison. This distinguishes it from sibling tools like get_latest_news (current news) and search_news (search by query). The verb '获取' plus resource '新闻数据' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use ('用于历史数据分析和对比'), implying it is for historical queries. However, it does not explicitly mention alternative tools or exclusions, though the intent is evident from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral information. It does disclose that it reads configuration from specific files and returns a JSON with configuration source, which is useful. However, it does not explicitly state that the operation is read-only or mention error conditions, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with sections for summary, supported channels, return format, and an example. It is front-loaded with the main purpose and contains no unnecessary filler.
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 tool is simple (0 params) and has an output schema; the description still explains the return format and the sources it checks. It also lists the 9 supported channels, making it complete for its complexity.
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 description coverage is trivially 100%. According to the rubric, the baseline is 4; the description adds no parameter details, but none are 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 uses the specific verb '获取' (get) and resource '已配置的通知渠道及其状态' (configured notification channels and their status), making the purpose explicit. It distinguishes from sibling tools like send_notification and get_channel_format_guide by focusing on retrieval of channel status.
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 clearly implies the tool is for checking which notification channels are configured by detecting config.yaml and .env, giving context for use. However, it does not explicitly name alternatives or exclusionary conditions, so it stops short of a full 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. It explains the core behavior (merging similar news from different platforms, showing coverage and heat) and describes the return format (JSON with dedup stats, aggregated list, platform coverage), which gives a clear picture of the tool's operation. It does not explicitly state whether it is read-only or mention potential side effects, but the aggregation nature and examples imply a safe query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise one-line summary, a brief overview paragraph, and clearly labeled Args, Returns, and Examples sections. It is slightly verbose with the Chinese text but every section earns its place, and the front-loaded summary aids quick understanding.
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, describes return content, and provides two usage examples. It does not specify the exact format for date_range (schema allows string or object), nor does it list valid platform IDs, which could leave an agent unsure about valid inputs. However, given an output schema exists and the core behavior is described, it is fairly complete for an aggregation tool.
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?
Since schema description coverage is 0%, the description fully compensates by explaining each parameter beyond the schema. It provides meaning, defaults, constraints (e.g., similarity_threshold 0.3–1.0, higher = stricter), and platform list examples. This adds substantial value over the bare 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 clear, specific purpose: '跨平台新闻聚合 - 对相似新闻进行去重合并' (cross-platform news aggregation with deduplication and merging). It further explains that the tool merges reports of the same event from different platforms and displays cross-platform coverage and aggregated heat, which clearly distinguishes it from sibling tools like get_latest_news, search_news, and get_news_by_date.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for when you need deduplicated, cross-platform aggregation of the same event, and provides parameter defaults like 'not specified uses all platforms' and 'similarity threshold controls strictness.' However, it does not explicitly name alternative tools or state when not to use it, so it lacks explicit exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does mention the tool returns JSON and supports multi-day queries, but it does not explicitly state that it is a read-only operation or disclose any constraints like rate limits or error behavior. This 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: a summary sentence, a context sentence, then Args, Returns, and Examples. It is concise yet complete, with every sentence earning its place. The examples are useful for immediate understanding.
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 that the tool has an output schema (so return values are defined elsewhere) and the description covers usage context, parameter semantics, return format, and examples, it is effectively complete. No critical information is missing for a read-oriented tool.
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 Args section provides comprehensive semantics for all 4 parameters, including defaults, ranges, and examples. For instance, 'days: 获取最近 N 天的数据，默认 1（仅今天），最大 30 天' adds meaning beyond the schema. With 0% schema description coverage, this fully compensates.
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 the tool's purpose clearly: '获取最新的 RSS 订阅数据' (Get the latest RSS subscription data). It also differentiates RSS data from hot news by saying 'RSS 数据与热榜新闻分开存储' (RSS data is stored separately from hot news), which distinguishes it from sibling tools like get_latest_news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: '适合获取特定来源的最新内容' (suitable for getting latest content from specific sources), which gives clear context. However, it does not explicitly name alternatives or state when not to use this tool, 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, the description carries the full burden. It explains the source parameter's behavior, returns a JSON with comparison results, and provides examples, implying a read-only listing operation. It lacks explicit notes on network behavior or edge cases, but this is sufficient for a simple read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for summary, args, returns, and examples. It is concise and front-loaded, though the first two sentences are somewhat redundant. Overall, it is appropriately sized and organized.
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 single-parameter tool with an output schema, the description covers the purpose, parameter semantics, return format, and examples. It does not mention error conditions or performance, but these are less critical for a listing tool. It is reasonably 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?
The schema provides only a 'source' field with a default, but the description fully documents the three allowed values ('local', 'remote', 'both'), their meanings, and default behavior. This completely compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists available date ranges from local/remote storage, with a specific verb ('list') and resource ('date ranges'). It also explains the purpose of checking which dates have data, distinguishing it from sibling tools like resolve_date_range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/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 (checking data availability across local/remote) and illustrates usage with examples for the default and specific source. However, it does not explicitly mention alternatives or when not to use it, so it falls 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 behavioral disclosure burden. It reveals that include_url defaults to false to save tokens, sets a maximum limit of 1000, and advises the agent to show all data by default. These details go beyond the schema, though it does not mention side effects or rate limits.
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 front-loaded with the core purpose, followed by a clean Args/Returns structure and a concise bulleted list of display suggestions. Every section adds value without unnecessary verbosity.
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 tool is simple with 3 parameters and an output schema, and the description covers purpose, parameters, return type, and usage tips. It lacks explicit ordering guarantees or empty-result behavior, but it is adequate for a straightforward fetch tool.
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 thoroughly explains all three parameters: platforms with an example list, limit with default and max, and include_url with its token-saving rationale. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '获取最新一批爬取的新闻数据' (get the latest batch of crawled news data), clearly stating the verb, resource, and temporal scope. It distinguishes itself from siblings like get_latest_rss by specifying news data, and it conveys the purpose of quickly understanding current hotspots.
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 by focusing on the latest crawled news, and it includes explicit display guidance on showing all data unless the user asks for a summary. However, it does not explicitly list alternative tools or when-not-to-use scenarios.
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 full burden. It discloses that the tool uses server-side current time for consistency, and details the return structure with start/end dates, current_date, and description, plus examples. It does not mention error cases or side effects, but for a non-destructive parsing tool this is sufficient.
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 lengthy but well-structured with headers, bullet points, and examples. Every section adds value, but some repetition (e.g., multiple examples of the same workflow) could be trimmed. Still, it is organized enough for quick scanning.
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 one-parameter tool, the description covers all necessary aspects: valid input options, return format, and end-to-end usage examples. The presence of an output schema (noted in context) further reduces the need to explain return values, making this description 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%, so the description is essential. It compensates by listing supported expression formats (e.g., '今天', '本周', '最近7天') and providing concrete examples that map to accepted values. This gives the agent clear guidance on how to fill the 'expression' parameter.
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 identifies the tool's function: parsing natural language date expressions into a standard date range. It explicitly states the verb and resource ('将自然语言日期表达式解析为标准日期范围') and positions it as a recommended precursor to other tools, distinguishing it from siblings like get_news_by_date.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow instructions showing when to call resolve_date_range before analyze_sentiment or search_news, and explains why it should be used (to ensure consistent dates across AI models). However, it does not explicitly mention when not to use the tool or list alternative date-handling approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It thoroughly explains the operation (comparison), how parameters affect output (e.g., compare_type changes result structure), and the return format. It lacks explicit caveats about data availability or rate limits, but overall provides substantial behavioral context beyond a simple one-line summary.
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 for usage scenarios, arguments, return values, and examples. Although moderately long, every section conveys necessary information for a tool with 6 parameters, and the structure front-loads the core purpose.
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 the tool's complexity (6 parameters, no annotations, output schema exists), the description is comprehensive: it covers purpose, usage scenarios, parameter semantics, return structure, and examples. It enables an agent to select and invoke the tool correctly without needing external context.
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 the description fully compensates by explaining each parameter's type, allowed values, and format, with examples for period1 (object or preset strings), compare_type (enum values), and top_n (default 10). This is essential for correct invocation.
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 '时期对比分析 - 比较两个时间段的新闻数据' and lists concrete comparison dimensions (hot topics, platform activity, news quantity). It differentiates from sibling tools by focusing on two-period comparison with specific use cases like '对比本周和上周的热点变化'.
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 dedicated '使用场景' section with concrete examples such as comparing this week vs last week and analyzing topic shifts. However, it does not explicitly name alternative tools or state when not to use this tool, 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?
With no annotations, the description carries the full burden for behavioral transparency. It discloses the difference between daily and current modes, the dependency on a config file for keywords mode, the automatic title extraction for auto_extract mode, and the JSON return format. It does not mention any side effects or read-only status, but no such behavior is implied, so it is reasonably 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 clear sections (Args, Returns, Examples) and uses bullet points for enums. Every sentence contributes value, and the examples are concise yet illustrative. No redundant or filler content.
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 the complexity of three parameters with distinct options and an output schema, the description fully explains all inputs, outputs, and provides examples. It also covers default values and the intent of each mode, making it complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides parameter names and defaults but no descriptions (coverage 0%). The description compensates fully by explaining each parameter in detail: top_n (number of topics), mode (daily vs current with definitions), and extract_mode (keywords based on config file vs auto_extract from news titles). This is a complete semantic mapping.
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 obtains trending topic statistics (获取热点话题统计) and specifies the modes and extraction options, distinguishing it from sibling tools like analyze_topic_trend which focus on trend analysis. It is specific about the resource (hot topics) and the verb (get statistics).
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 each mode (daily vs current) and extraction method (keywords vs auto_extract), with practical examples. However, it does not explicitly mention alternatives or when not to use this tool versus other sibling tools, so it stops 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. It discloses default values (days=7, limit=50, include_summary=False), the max limit for days (30), and the behavior when feeds are not specified (search all RSS sources). It also describes the return format as JSON. This is solid coverage for a search tool, though it does not mention error handling or rate limits.
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 for Args, Returns, and Examples. Each sentence adds value, and the examples illustrate common usage patterns without unnecessary 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?
The description is complete for a search tool with 5 parameters. It covers parameter semantics, defaults, return format, and provides concrete examples. Although there is an output schema, the description also clarifies the purpose of each parameter and the overall behavior, making it fully self-contained.
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, making the description the only source of parameter meaning. It explains each parameter: keyword (required), feeds (with example and behavior when null), days (default and max), limit (default), and include_summary (default). This goes beyond the schema and provides essential usage details.
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 '搜索 RSS 数据' (search RSS data) and further explains it searches articles containing specified keywords within RSS subscription data. This clearly identifies the action and resource, distinguishing it from sibling tools like search_news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/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: searching RSS data by keyword. It also gives examples with optional feeds and days, showing the tool's flexibility. However, it does not explicitly mention when not to use it or compare with alternatives like search_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 full burden. It discloses side effects (optional local saving), token-saving behavior of include_url, and return structure (success/failed platform lists plus news data). It doesn't clarify whether the crawl is synchronous or asynchronous, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with a one-line summary, Args section, Returns section, and examples. Every sentence provides value and is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 optional parameters and an output schema, the description covers purpose, all parameter semantics, return format, and usage examples. It is self-contained and sufficient for an AI agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only lists types and defaults with no descriptions. The description compensates fully by explaining each parameter: platforms (list of platform IDs, defaults to all), save_to_local (whether to save to output dir), and include_url (whether to include URLs to save tokens). Examples further demonstrate usage.
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 '手动触发一次爬取任务' which clearly states the verb (trigger) and resource (crawl task), and adds optional persistence. It distinguishes itself from siblings that are read/query tools by being an action-oriented tool.
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?
It establishes clear context: a manual, on-demand crawl trigger with optional persistence. It doesn't explicitly state when not to use it or name alternatives, but the purpose is unmistakable given the sibling list is dominated by read/query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the return format (JSON with features, limitations, prompts), the optional parameter behavior (returns all channels if not specified), and provides channel-specific formatting details. It could additionally state that it is read-only with no side effects, but the '获取' (get) verb and return description imply this.
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 an intro, channel overview list, Args, Returns, and Examples. Each section provides essential information without fluff; the detailed channel list serves as both documentation and reference, earning its length.
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 simple tool with one optional parameter and an output schema, the description is complete. It covers purpose, usage, parameter semantics, return structure, and includes multiple examples. The output schema exists, so detailed return value documentation is not required, but the description still gives a useful overview.
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%, so the description must compensate. It thoroughly documents the 'channel' parameter, including optionality, default behavior (returns all), and enumerates all valid values (feishu, dingtalk, etc.) that the schema lacks. This adds significant meaning beyond the bare input 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 clearly states the tool's purpose: to retrieve formatting strategy guides for notification channels, listing supported Markdown features, limitations, and best-practice prompts. It distinguishes itself from sibling tools like get_notification_channels and send_notification by focusing on format guidance.
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?
Explicitly instructs to use this tool before calling send_notification to understand the target channel's format requirements, providing clear contextual usage. This names the relevant sibling tool and gives a clear when-to-use scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses external service dependency (Jina AI Reader), rate limits (100 RPM), built-in rate control (5s interval), and limitations with paywalls. This is rich behavioral context beyond what schema or annotations would provide.
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 sections for usage, args, returns, example, and notes. Each section adds value, and there is no unnecessary fluff. It is appropriately sized for a tool with no annotations, covering all essential aspects without being overly verbose.
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 simple read tool with an output schema, the description covers purpose, usage flow, parameter constraints, return format, limitations, and rate limits. It is complete enough for an agent to select and invoke the tool correctly without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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. It adds meaning to both parameters: url is required and must start with http/https; timeout has default 30 and max 60. It also provides an example, making parameter usage very clear.
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's purpose: reads article content from a specified URL and returns LLM-friendly Markdown. It distinguishes from siblings by specifically targeting single-article reading, and contrasts with read_articles_batch for batch operations.
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?
Provides explicit use cases and a typical workflow: search_news first, then read_article. This gives clear context for when to use it. However, it does not explicitly mention alternatives or when NOT to use it (e.g., for batch reading), so it falls short of full exclusion guidance.
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 fully carries the transparency burden. It discloses key behaviors: automatic 5-second delay for rate limiting, max 5 articles, failure isolation (single failure doesn't affect others), and expected time duration. It also mentions the return format, making the tool's behavior predictable.
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 sections (overview, typical flow, args, returns, example, notes), front-loads the critical constraints (max 5, interval), and every sentence provides useful information without redundancy. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters and no annotations, the description is complete: it covers the usage workflow, parameter meanings, return format, a concrete example, and operational notes. The presence of an output schema reduces the need for detailed return explanation, and the description still covers it sufficiently.
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 descriptions for parameters, but the description explains urls (required, max 5) and timeout (default 30, per-request timeout). This adds crucial semantics beyond the schema, enabling correct parameter usage.
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 it reads multiple articles in batch, with a max of 5 and a 5-second interval. It uses a specific verb and resource ('batch read articles'), distinguishing it from the sibling tool read_article which handles single articles.
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?
It provides a typical usage flow (search_news first, then batch read, then analysis) which gives clear context for when to use this tool. However, it doesn't explicitly state when not to use it (e.g., for a single article, read_article might be preferable), so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the transparency burden. It discloses the sync behavior including skipped local-existing dates, failed dates with errors, and the JSON return structure. It also lists required configuration (config.yaml or environment variables) and environment variable names, providing rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for Purpose, Args, Returns, Examples, and Note. Every part adds value—parameter semantics, return format, usage examples, and configuration—without redundancy. Length is appropriate given the need to explain the tool's role and requirements.
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 tool has one parameter, no output schema in structured data, yet the description thoroughly explains the return fields, parameter options, configuration setup, and usage context. This is complete and exceeds what is typical for tools of similar complexity.
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 only 'days' with default 7 and no description (0% coverage). The description compensates by explaining valid values (0, 7, 30), their meanings, and provides examples. This fully clarifies the parameter's 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 clearly states the action ('从远程存储拉取数据到本地') with a specific verb (pull) and resource (remote storage to local). It also provides context (MCP Server scenario) and differentiates from siblings by detailing its purpose in the data pipeline.
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?
It explicitly describes when to use the tool ('用于 MCP Server 等场景：爬虫存到远程云存储...拉取到本地进行分析查询') and specifies configuration prerequisites in the Note section. It does not explicitly mention when not to use it or compare to sibling tools, so a 4 is appropriate.
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/rui497/my-trendradar'
If you have feedback or need assistance with the MCP directory API, please join our Discord server