TrendRadar MCP Server

Server Quality Checklist

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

Latest release: v6.10.0
Disambiguation3/5
The tools have reasonably distinct purposes, but there is some overlap between search_news, search_rss, and get_news_by_date, as well as between get_latest_news and get_news_by_date. Also, analyze_topic_trend and analyze_data_insights both serve as umbrella analyzers, which could cause misselection despite distinct sub-modes.
Naming Consistency4/5
Most tool names follow a clear verb_noun pattern (get_, search_, analyze_, send_, etc.), with only minor deviations like resolve_date_range (verb_object) or check_version (verb_noun). The naming is generally consistent and intuitive.
Tool Count3/5
With 27 tools, the server covers a wide range of functionality (news retrieval, analysis, configuration, notifications, storage), which is somewhat heavy but justifiable given the broad scope. It is on the upper edge of the acceptable range, but not excessive.
Completeness4/5
The tool surface is quite comprehensive for a news monitoring and analysis server, covering retrieval, search, trend analysis, sentiment, aggregation, comparison, reporting, and notifications. Minor gaps include lack of direct article management or explicit data deletion, but these are not critical for the domain.
Average 4.2/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
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only mentions the return format and a parameter format constraint. It does not clarify whether this operation is read-only, triggers any computation or crawl, requires permissions, or has rate limits. Given siblings like trigger_crawl and sync_from_remote, such ambiguity is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args, Returns, and Examples headers, making it easy to scan. It is somewhat verbose due to formatting embellishments, but the parameter explanations and examples earn their place. The front-loaded title and purpose are clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers parameters, examples, and return type, but it does not clarify which modes date_range applies to, whether parameters interact, or how to choose this over sibling tools. Since an output schema exists, return value details are not required, but the usage context and behavioral constraints are incomplete for a 5-parameter multi-mode tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description fully documents all five parameters, including allowed values for insight_type, mode-specific applicability, defaults, and a detailed date_range format with a warning against integer input. The examples demonstrate valid parameter combinations, adding substantial meaning beyond the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a unified data insight analysis tool with three specific modes (platform comparison, platform activity, keyword co-occurrence), each clearly defined. It provides concrete examples, but does not differentiate from sibling tools like analyze_topic_trend or analyze_sentiment, which also perform analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what modes exist and when each mode is relevant, but gives no guidance on when to choose this tool over the many sibling analysis tools (e.g., analyze_topic_trend, analyze_sentiment, compare_periods). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注解覆盖行为特征，因此描述本身需传达行为信息。描述说明了返回 JSON 状态信息，但未说明是否需要特殊权限、是否只读、可能存在的副作用或错误行为。属于已知 schema 的只读型信息获取工具，缺失部分行为上下文。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述仅两句话，高度简洁，信息密度适中，无冗余内容、无重复列出 schema 中已有的信息。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
存在输出schema声明返回JSON格式并包含存储状态，对状态查询类工具足够完整。未说明权限、错误格式或故障条件等边界行为，缺少部分运维类工具的行为约束信息。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入参数为0，schema覆盖率为100%。无参工具的参数语义由schema完全承载，描述未增加额外参数说明。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确指出工具用于“获取存储配置和状态信息”，动词（获取）+资源（存储配置）+范围（本地/远程），语义清晰。但与同列工具 get_current_config、get_system_status 等存在边界模糊，未说明与这些工具的区别。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述未提供任何使用时机、前置条件或与同族工具（get_current_config/get_system_status）的取舍说明。仅有隐含的用途暗示，未达‘清晰上下文但无排除说明’的4分水平。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description bears the full burden of disclosing behavior. It explains the date_range behavior (defaults to today when not specified), the threshold semantics (higher = stricter), and the include_url flag (defaults to False to save tokens). This is good transparency about parameter-driven behavior. However, it doesn't disclose what happens if no related news is found, whether the tool makes external API calls, or any rate limits or performance considerations. It does note that `include_url` defaults to False to save tokens, which hints at token consumption.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear intro sentence, a list of parameters with explanations, a Returns section, and Examples. It's front-loaded with the purpose and uses bullet points for parameters. While it's somewhat long (9 bullet points for parameters), each point adds distinct information. The examples are concise and useful. It earns a 4 because the structure is organized and information is dense without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, an output schema, and no annotations, the description is fairly complete. It covers parameter semantics, return format (JSON list sorted by similarity), and provides examples. The output schema exists, so the description doesn't need to detail return fields, but it mentions sorting by similarity which is useful. It could add more about edge cases (empty results, error handling) or mention similarity computation method, but overall it's adequate for a complex tool with 5 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, meaning the description is the only source of parameter meaning. The description does explain all 5 parameters: reference_title (full or partial), date_range (options with format details), threshold (range 0-1, default 0.5), limit (default 50), include_url (default False). This is a thorough explanation that adds value beyond the raw schema (which only has types and defaults). However, it could provide more detail on the exact format of the date_range object (it says 'start' and 'end' but the schema just says 'additionalProperties' for the object, so the description clarifies). The threshold explanation is minimal but the default and range are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose clearly: '查找与指定新闻标题相关的其他新闻' (find other news related to a specified news title). It specifies what it does (find related news based on a reference title) and supports both current and historical data. This is a clear verb+resource combination. However, it doesn't explicitly distinguish from sibling tools like search_news or get_news_by_date, though the term 'related' implies semantic similarity rather than exact search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use it via the 'reference_title' parameter and provides examples that illustrate usage. It mentions date_range options, which gives context on when to use historical vs. today-only queries. However, it doesn't explicitly state when NOT to use this tool vs. alternatives (e.g., search_news for exact text matching). The examples are helpful but not exhaustive.
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?
缺少 annotations，描述本身承担了披露行为细节的责任。描述了返回值（JSON 包含 Markdown 格式内容）和参数约束（日期范围必须是对象），但没有说明这具备副作用（如是否触发抓取、发送通知）或是否会持久化数据。对非破坏性工具来说还算基本透明，但未达到充分披露。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述简明扼要，使用 Args/Returns 结构分块，各项信息包括参数类型、格式、示例和返回值均具价值，没有冗余或重复 schema 的废话。中文措辞紧凑，令人一目了然。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
对于这种既有输出 schema 的工具，描述只需重点补充参数语义，基本覆盖了实际使用要点。但工具名为 'generate_summary_report'，没有说明生成报告所依赖的数据来源（如是否使用已抓取新闻或缓存），也没有提及默认日期范围的行为，这在实际使用中可能产生模糊。整体上还是足够完成任务。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
尽管 schema 覆盖率为 0%，描述中对两个参数的含义、类型和格式都提供了有价值的补充。尤其对 date_range 给了明确的对象结构 {'start':..., 'end':...}、示例和强调提示，比 schema 的 anyOf 更清晰。report_type 也给出了可选值 daily/weekly，完全超出了 schema 的信息量。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确指出这是一个每日/每周摘要报告生成器，动作明确（生成），资源明确（报告），并说明了输入输出的大致内容。但与 'aggregate_news'、'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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述没有提供任何使用场景或与其他工具的对比说明。虽然提到了 'daily/weekly' 两种报告类型，以及可选的日期范围，但没有说明何时应使用该工具而不是兄弟工具（如 compare_periods、aggregate_news 等）。也没有提及默认行为（如未传日期范围时如何处理）。
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 key behavioral aspects: the two time modes, extraction modes, the dependency on config/frequency_words.txt, and the return format. However, it does not mention potential side effects, data source specifics, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line, Args block, Returns, and Examples. It is appropriately sized for three parameters, with no redundant fluff, though the formatting could be streamlined for machine readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately simple, and the description covers the essential usage, parameters, and examples. The mention of an output schema (though not shown) reduces the need to detail return structure. Missing context includes how 'daily' vs 'current' differ in time boundaries and whether any news source filtering applies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully by explaining each parameter's meaning and default values: top_n, mode ('daily' vs 'current'), and extract_mode ('keywords' vs 'auto_extract'). It also clarifies the config dependency, making the semantics richer than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as obtaining trending topic statistics, with verb-resource structure ('获取热点话题统计'). It distinguishes the tool by showing its focus on topic frequency statistics rather than raw news lists, though it does not explicitly compare to sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed mode options and examples, implying usage patterns, but does not explicitly state when to prefer this tool over alternative siblings like analyze_topic_trend or get_latest_news. There are no exclusion criteria 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?
No annotations are provided, so the description carries the full burden. It states the action (triggering a crawl) and optional persistence via save_to_local and include_url, which hints at resource consumption (saving to local, including URLs costs tokens). However, it doesn't disclose side effects like whether it creates data that other tools then read, how long the crawl takes, or if there are rate limits. It also doesn't mention that the operation might be blocking. It gives some behavioral detail (task status returned) but not comprehensive, so a 3 is fair.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but includes a clear summary, parameter explanations, return format, and examples in a structured format (Args/Returns/Examples). It's front-loaded with the purpose. It's not perfect because the parameter descriptions could be bulleted more cleanly, but it's efficient for a tool with 3 parameters. No wasted sentences, so a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a trigger action with 3 params, an output schema (mentioned), and no annotations. The description covers the core functionality, parameter semantics, return type, and provides examples. It doesn't explain prerequisites like whether the crawl needs prior configuration or if it conflicts with scheduled crawling, but given the tool's simplicity and the output schema, it's reasonably complete. A 5 would need explicit note about side effects or dependencies, but a 4 is solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does: 'platforms' is described as a list of IDs with an example, 'save_to_local' is explained as saving to the output directory, and 'include_url' is explained as including URLs to save tokens. The examples also clarify usage patterns. This adds significant meaning beyond the schema's defaults and types, so a 4 is justified. A 5 would require more detail like accepted platform names or validation rules, but it's already strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'trigger' and the resource 'crawl' (爬取任务), and mentions optional persistence. It distinguishes from siblings like get_latest_news, get_latest_rss, and search_rss by being the tool that actually initiates a crawl rather than fetching or reading. However, it doesn't explicitly explain how it differs from other tools that might trigger similar actions, like sync_from_remote, so it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use it (manual trigger), but doesn't explicitly state when NOT to use it or mention alternatives. It gives examples and default behaviors, which helps the agent understand typical usage scenarios. Since it's a manual action in a set of read-centric tools, the need for explicit exclusions is less critical, 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.
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 behavioral burden. It discloses that the tool returns JSON system status information including version, data stats, and cache status, which implies a read-only health-check operation. However, it does not disclose potential side effects, freshness guarantees, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the core purpose stated first. The 'Returns:' line adds useful format information, though the content is slightly redundant with the earlier list of returned fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is mostly complete: it states the tool's purpose and the general shape of its response. It could add a note about whether the status info is real-time or cached, but overall it is sufficient for a simple status endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so there is nothing to explain beyond what the schema already makes clear. The baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: '获取系统运行状态和健康检查信息' (get system running status and health check info), and lists concrete contents such as version, data statistics, and cache status. This distinguishes it from sibling tools like get_storage_status or get_current_config, which target narrower concerns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the description: an agent would use this when needing overall system health and status. However, there is no explicit guidance about when not to use it or how it compares to alternatives like get_storage_status, get_current_config, or check_version.
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?
无annotations提供，描述需承担全部责任。描述说明了返回JSON格式包含情感分布、热度趋势和相关新闻，但未提及任何副作用、权限需求或对数据的影响，行为透明度中等。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述结构清晰，包含功能、建议、参数说明、返回值和示例，各部分简明。没有冗余信息，但Args部分与schema重复命名，增加了可读性但略长，整体仍算简洁。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
有输出schema，描述不必详述返回格式，但提供了概要。6个参数全部详细说明，并给出示例，对于复杂分析工具来说完整度较高。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
schema描述覆盖率为0%，但描述中对每个参数（topic, platforms, date_range, limit, sort_by_weight, include_url）都给出了详细解释，包括默认值、作用以及注意事项（如去重、节省token），完全补偿了schema的不足。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明'分析新闻的情感倾向和热度趋势'，动词+资源清晰，但未与兄弟工具（如analyze_topic_trend、analyze_data_insights）进行区分，目的基本明确但缺乏独特性说明。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
提供了明确的建议：使用自然语言日期时先调用resolve_date_range，这是很好的指导。但未说明何时不使用此工具或替代方案，缺乏明确的排除条件。
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?
没有提供注解（如 readOnlyHint、destructiveHint），描述中没有明确说明授权需求/速率限制/副作用。描述补充了搜索结果内容（JSON结构），但安全与写操作等信息缺失。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
文本组织得较清晰：先说明用法，再述参数，后附代码示例。为全部参数作了内联列表，但整体篇幅较长，部分参数说明冗长。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
返回结果说明为JSON、包涵热榜和可选RSS feed；已提供输入schema、默认值和建议。存在相关兄弟工具和fetch场景，但未对返回结构做详细解释，且缺少annotation明文说明。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
schema的description字段本身序列覆盖率为0%，但文本描述对全部10个参数（query、search_mode、date_range、platformsaku、limit、sort_by、threshold、include_url、include_rss、rss_limit）都有解释，并附带默认值与示例，远优于贫乏的json schema。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述以明确动词开头（'统一搜索接口'），说明统一搜索热榜和RSS，且参数覆盖多种搜索模式。虽然与同类工具相比有明显区分，但没有明确点名替代性工具。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
提供了使用建议：在自然语言日期前先用 resolve_date_range 获得精确范围，并在 include_rss 等参数上有默认行为。但未明确说明与同类工具的选用边界。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the return format (JSON with version comparisons and update needs) and the optional proxy_url for network access. However, it does not detail permissions needed, network behavior, or potential side effects (e.g., whether it makes network calls), but the safe read-only nature is implied by 'check' and 'compare'. It meets basic transparency but lacks richer context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear summary, Args, Returns, and Examples sections. It's concise (under 10 lines) and front-loaded with the main purpose. The section headers help parseability. Minor redundancy exists (the first line and the detailed paragraph repeat the same purpose), but overall it's well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no required params, no output schema details beyond description), the description is quite complete. It covers purpose, parameters, return format, and examples. The main gap is lack of explicit behavioral notes (e.g., network prerequisites), but overall it's adequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter (proxy_url) with 0% description coverage, meaning the schema only shows the type. The description compensates by explaining 'proxy_url' is optional and provides an example of how to use it ('http://127.0.0.1:7890'). This adds meaning beyond the schema, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks version updates for both TrendRadar and MCP Server, comparing local versions with GitHub remote versions. It explicitly names the resources involved (TrendRadar, MCP Server, GitHub) and the action (check/compare), making it distinct from sibling tools that handle news, RSS, or system functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when checking for updates) and provides a clear example of using the optional proxy_url parameter. However, it does not explicitly state when NOT to use it or mention alternative tools, but given the unique purpose (version checking), the context is clear enough.
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 is the sole behavioral disclosure. It communicates a read operation through '获取' and documents the JSON return shape, but it does not state side-effect-free behavior, required permissions, or behavior on invalid section values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The tool uses a one-line purpose plus compact Args/Returns blocks. No redundant prose appears, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one optional parameter, the description covers the parameter domain and return format; an output schema exists, so return details need not be repeated. It lacks error/edge-case behavior but remains sufficient for selecting and invoking the tool successfully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only declares an optional string 'section' with a default and no enum or property description. The description fully compensates by listing the five allowed values and the default, giving the agent actionable selection criteria.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line '获取当前系统配置' identifies a specific getter for system configuration, and the section list names distinct config domains (crawler/push/keywords/weights). This clearly separates it from sibling health/status and news tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing config sections but contains no explicit when-to-use statement or alternatives. It does not distinguish from get_system_status or get_storage_status, leaving the agent to infer invocation contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the deduplication/merging behavior, cross-platform coverage display, and return format (JSON with dedup statistics and platform coverage). It does not mention potential side effects, but the aggregation semantics strongly imply a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, Args section, Returns section, and examples. Every sentence adds value, and the format is easy to scan. The examples are concise and illustrative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, all parameters, return structure, and examples, making it largely complete for an agent to invoke. It lacks explicit guidance on valid platform IDs and exact date_range syntax, but the output schema and examples mitigate this. Overall, it is a strong, self-contained description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by explaining all five parameters with defaults and meaningful semantics (e.g., similarity_threshold range and strictness, platforms example, include_url purpose). However, the date_range format is left ambiguous (string vs object), which is a minor gap in fully specifying invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: aggregating news across platforms and merging similar reports into one item. It explicitly distinguishes itself from siblings like get_latest_news and search_news by emphasizing cross-platform deduplication and comprehensive heat metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cross-platform news aggregation and deduplication, and provides parameter defaults and examples. However, it does not explicitly state when to prefer this tool over siblings such as get_news_by_date or find_related_news, nor does it mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses useful defaults like date_range defaulting to recent 7 days and granularity to 'day', plus mode-specific thresholds. However, it does not mention edge-case behavior, error conditions, data source assumptions, or whether some parameters are ignored in certain modes beyond what is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured with an overview, prerequisite suggestion, Args block, Returns line, and Examples. Each parameter description earns its place. It is longer than minimal, but the detail is necessary because the schema provides no property descriptions and the tool has 8 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and 0% schema coverage, the description is largely complete: it explains all parameter semantics, defaults, mode-specific use, example calls, and a cross-tool prerequisite. It could be more complete by enumerating valid granularity values or describing behavior when optional parameters are irrelevant, but overall it is sufficient for accurate invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate entirely for parameter meaning. It fully explains every parameter, provides valid values for analysis_type, gives a concrete date_range format, specifies defaults, and gives correct use examples. This is far more useful than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it is a unified topic trend analysis tool and lists concrete analysis modes: trend, lifecycle, viral, and predict. This clearly distinguishes it from sibling tools like get_trending_topics, analyze_sentiment, or 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit workflow guidance: when using natural language dates, first call resolve_date_range. It also defines mode-specific parameters, telling the agent when spike_threshold and time_window apply vs lookahead_hours and confidence_threshold. It lacks explicit when-not-to-use statements for other siblings.
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 implies read-only behavior ('get') and provides helpful context around the `include_url` parameter to save tokens, but does not explicitly state the operation is non-mutating, nor disclose potential rate limits, pagination, or error behavior. The display suggestions add behavioral context, but overall transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: first a clear purpose, then Args, Returns, and a final '数据展示建议' section. It is slightly verbose with the display suggestions, but those are valuable operational guidance. The core tool description (excluding suggestions) is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown) so return format need not be detailed. The description covers purpose, parameters, and usage guidelines. It lacks explicit mention of when not to use and alternatives, but for a straightforward retrieval tool with three optional params, it is sufficiently complete. The display suggestions add practical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no descriptions in the input schema), but the description compensates fully by explaining each parameter with examples ('platforms: 平台ID列表，如 [\'zhihu\', \'weibo\']', 'limit: 默认50，最大1000', 'include_url: 默认False（节省token）'). This adds significant meaning beyond the bare schema, making parameter usage clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the latest batch of crawled news data' and purpose 'quickly understand current hot topics'. This specific verb+resource combination distinguishes it from siblings like get_latest_rss or search_news, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a '数据展示建议' (data display suggestions) section that guides how to present results (show all by default, summarize only on user request, etc.), and explains default platform behavior. However, it does not explicitly mention when to prefer this over alternatives like get_trending_topics or get_news_by_date, or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the JSON return format containing features, limitations, and formatting prompts, and clarifies the optional channel parameter behavior (omitting returns all strategies). However, it doesn't detail the exact JSON structure or confirm the operation is read-only, leaving some ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than typical but every section earns its place: purpose, usage timing, per-channel format differences, Args, Returns, and Examples. The channel-specific feature list is essential content for this tool's value, not padding. It's front-loaded with purpose and flows logically, though slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter lookup tool, the description is thoroughly complete: it explains what to do with results (format message content before send_notification), documents all channel values with their format differences, provides a Returns section describing output, and includes two concrete examples. Comprehensive for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by documenting the channel parameter: meaning (channel ID), optionality, default behavior (returns all channels when omitted), and all nine valid enum values (feishu, dingtalk, wework, telegram, email, ntfy, bark, slack, generic_webhook). This exceeds schema-provided information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves channel-specific formatting strategies (Markdown features, limitations, and formatting prompts). It identifies a specific resource (notification channel format guides) with a precise verb, and effectively differentiates itself from sibling tools, none of which deal with formatting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use the tool before send_notification to understand target channel formatting requirements, establishing clear usage context. However, it doesn't explicitly state when NOT to use it, though the tool's unique purpose within the sibling set makes exclusions largely unnecessary.
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?
由于没有提供任何注释，描述承担了更多责任。描述详细解释了返回的数据结构，包括 available_dates、total_dates、today_feeds 和 generated_at，这些是行为方面的重要细节，比如它返回统计信息而非原始数据。虽然可以使用输出模式，但描述提供了每个字段的含义，增加了洞察力，没有矛盾，因此评分较高。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述非常简洁，使用了结构化的返回格式和示例。它没有浪费文字，直接说明了用途、返回内容，并提供了代码示例。全文包括头部信息在内仅约150个字符，但信息密度高，每个部分都有用。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
尽管没有参数，但描述提供了完整的返回结构和示例，足够让一个AI代理理解如何调用和解析结果。与同命名空间的其他工具相比，它独立，因此完整性很高。由于输出模式丰富，描述不需要过多展开，但已提供了所有必要信息。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
没有参数，所以参数语义负担较低。但描述明确说明了工具没有参数，并给出了示例调用 get_rss_feeds_status()，这澄清了调用方式。由于参数语义不存在，但描述仍然提供了清晰的调用信息，因此评分4分合理。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明了工具的功能：获取RSS源状态信息，包括可用日期、总日期数、今日统计和生成时间。这清晰地区分了它与其他工具（如 get_latest_rss、get_news_by_date）的不同，因为这些工具可能分别获取新闻或按日期查询，而此工具是查看RSS源的元数据状态。动词“获取”和资源“RSS源状态”非常具体，且示例详细展示了调用方式，使得目的十分清晰。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述说明了工具用于查看当前配置的RSS源状态，但没有明确说明何时使用此工具而非其他工具。它没有排除或指定特殊情况，例如何时应该使用 get_current_config 或 get_storage_status。也没有给出使用此工具的上下文，比如在需要监控RSS源健康时还是查看可用日期。隐含了使用场景，但不够明确，因此评分3分。
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 transparency burden. It identifies the data sources (config.yaml and .env), the supported channels, and the return value shape (JSON with configured status and source). It does not declare side effects or read-only behavior, but the inspection semantics are reasonably evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately compact and structured, covering purpose, sources, supported channels, return format, and an example. The example line is nearly redundant for a zero-parameter call, but it does not meaningfully detract from the precision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple zero-parameter inspection tool with an output schema present. The description fully explains what is checked, where the configuration comes from, what the response contains, and the scope of channels. Nothing essential is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so there is no parameter semantics to enrich. The zero-parameter case is given the baseline score of 4, and the description still clarifies the output format and scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: '获取所有已配置的通知渠道及其状态' (get all configured notification channels and their status). It further distinguishes itself by enumerating the 9 supported channels and the return type, which separates it from siblings like send_notification and get_channel_format_guide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context by explaining that it checks config.yaml and .env environment variables, so users understand when to call it. It does not explicitly name alternatives or state when not to use it, but the use case as a configuration-status inspection tool is clearly implied.
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 burden. It describes behavior fully: returns JSON list of matching items, supports filtering by feeds, days (default 7, max 30), limit (default 50), and include_summary flag. It does not mention error handling or side effects, but for a read-only search tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Examples sections. It is concise, covering all necessary information without redundancy. Every line adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (5 parameters) and a stated output format (JSON list), the description is complete. It doesn't deep-dive into edge cases, pagination, or error codes, but for a typical search tool with an output schema present, this is sufficient. It also lacks explicit mention of sorting or exact match behavior, but that's minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates completely. It explains every parameter: keyword (required), feeds (optional list, default all), days (default 7, max 30), limit (default 50), include_summary (boolean). Examples also illustrate usage, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: searching RSS data for articles containing a specific keyword. It uses a clear verb ('search') and resource ('RSS data'), and differentiates from siblings like get_latest_rss or search_news by focusing on keyword-based search across RSS feeds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (when searching RSS feeds by keyword) and notes that if feeds are not specified, it searches all sources. While it doesn't explicitly contrast with alternative tools or state when not to use it, the context is clear enough for typical search 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?
With no annotations, the description carries the burden and does a solid job: it states the sync behavior, result fields, skipped dates for existing local data, failed dates with errors, and configuration prerequisites. It does not fully explain overwrite semantics or partial failure behavior, but it is reasonably transparent for a sync utility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured with clear sections: purpose, Args, Returns, Examples, and Note. Every section is informative and relevant; there is no filler or redundant repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool, the description covers the essential workflow, return fields, examples, and configuration requirements. It is complete enough for an agent to know when and how to use it, though a deeper dive into conflict handling would be extra.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only shows 'days' as an integer with a default, but the description explains the meaning of 0, 7, and 30, provides default behavior, and includes examples for usage. This is valuable semantic detail beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '从远程存储拉取数据到本地' (pull data from remote storage to local), identifying a specific verb, resource, and direction. This clearly differentiates it from the sibling news/analysis tools focused on reading or analyzing local data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete usage scenario: a crawler stores data in remote cloud storage such as Cloudflare R2, and the MCP server pulls it locally for analysis. It does not explicitly name alternatives or when-not-to-use, but the context is clear enough given the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses key behaviors: default days, maximum limit, optional summary inclusion to save tokens, and behavior for unspecified feeds. It could add edge-case behavior like invalid feed IDs or ordering, but the core read behavior and defaults are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a purpose line, argument list, return type, and examples. It is compact and every section adds information, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-optional-parameter read tool with an output schema, the description covers invocation, parameter semantics, examples, and the RSS-vs-news distinction. Combined with the existing output schema, the agent has enough context to select and call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully documents all four parameters with defaults, max values, example values, and behavioral consequences (e.g., include_summary saves tokens). This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching the latest RSS subscription data for specified feeds, supports multi-day queries, and explicitly separates RSS from hot-list news, which distinguishes it from sibling get_latest_news. The verb-resource pair is specific and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use the tool: for latest content from specific RSS sources, with RSS data separate from hot news. It does not explicitly state exclusions such as 'use search_rss for keyword search', but the context and examples make appropriate use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavior disclosure. It explains default behavior for platforms, limit, include_url, and documents that include_url=false saves tokens. It also describes the return format. While it does not discuss permissions or safety, this is a read-only retrieval tool, and the provided behavioral details are sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence purpose, followed by a formatted Args section and a Returns section. Every line adds useful information, and the date_range examples are particularly valuable without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four optional parameters and no annotations, the description covers all parameter semantics, defaults, and return behavior. The output schema exists, so detailed return documentation is not required, but the description still usefully lists the news fields. This is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the bare schema: date_range formats are enumerated with examples including range objects, natural language strings, single dates, and defaults. platforms, limit, and include_url are all semantically explained, including default values and token-saving rationale.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: retrieve news data for a specified date, explicitly framed for historical data analysis and comparison. This distinguishes it from siblings like get_latest_news and search_news by scoping the tool to date-based historical retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating the tool is for historical data analysis and comparison, which implies it should be used when a specific date range is relevant rather than for current/latest news. It does not explicitly name alternatives or exclusions, but the intent is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does a strong job by explaining that the tool calculates on the server side using precise current time, enumerates supported expression types (including dynamic day ranges), and provides a full return format example. However, it doesn't discuss edge cases or failure behavior (e.g., invalid expressions, timezone handling), leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a bold recommendation, rationale, workflow, Args, Returns, and Examples sections. It is front-loaded with the purpose and key information. However, it is somewhat verbose with examples that could be trimmed, though the examples add significant practical value for an AI agent, so the length is largely justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (parsing diverse natural language expressions) and low schema coverage, the description covers everything needed: supported formats, concrete examples, return structure, and integration with downstream tools. The output schema exists and the description's Returns section aligns with it, making the tool fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only lists 'expression' as a string with no description, so the description is the only source of parameter explanation. It thoroughly enumerates supported expression formats (单日, 周, 月, 最近N天, dynamic) with examples in both Chinese and English, which fully compensates for the 0% schema coverage. The return format is also detailed, making the parameter semantics very clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves natural language date expressions into standardized date ranges. It distinguishes itself from sibling tools by being a date-resolution utility that other tools depend on for date_range parameters, and it explicitly positions it as the recommended first step in call flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive usage guidance: when to use it (whenever a user expresses dates in natural language), why it's needed (ensures consistent date calculations across AI models), and a recommended workflow with concrete steps and examples showing how to chain it with other tools like analyze_sentiment and search_news. It also shows what not to do implicitly by demonstrating the correct call sequence.
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 transparency burden. It discloses useful behavior such as auto-adapting Markdown per channel, defaulting to all configured channels when none are specified, and returning JSON with per-channel send status. It doesn't discuss irreversibility, retry, or failure behavior, but the key behavioral traits are explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: purpose first, then channel-specific formatting details, a usage tip, structured Args/Returns, and representative examples. The length is justified because the channel-by-channel formatting behavior is genuinely useful to an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema can handle return-type details, the description is complete enough for reliable tool selection and invocation. It covers the exact parameters, per-channel behavior, channel options, default behavior, and a companion helper tool, so an agent has enough context to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well: message must be Markdown, title has a default value, and channels lists all supported target channels plus the critical semantic that omitting it means 'all configured channels'. The example calls also clarify realistic usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: send a message to configured notification channels ('向已配置的通知渠道发送消息'), then explains the Markdown input and per-channel adaptation. This distinguishes it from sibling read/search/report tools such as get_latest_news and generate_summary_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete usage context: use this tool to send notifications, and before sending it suggests calling get_channel_format_guide for detailed formatting policy. It could more explicitly state when not to use it or name excluding conditions, but the send-vs-read distinction is effectively clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It uses 'Returns:' section to describe the output structure clearly, and each compare_type is explained (overview, topic_shift, platform_activity). However, it doesn't disclose edge cases like behavior when no data exists for a period, or whether dates are inclusive/exclusive. Slight deduction for not mentioning potential failure modes or data availability requirements, but overall it adds meaningful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections (usage scenarios, Args, Returns, Examples) and uses markdown formatting. It's front-loaded with the purpose, then progressively details parameters and return values. While comprehensive, it's a bit long (~200 words in Chinese), but every section serves a purpose - no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 params, 3 compare types, output schema present), the description covers all bases: parameter formats, compare types with explanations, output structure, and working examples. The output schema exists so return values don't need exhaustive explanation, but the description still outlines the return fields. It's sufficient for an agent to use this tool effectively without additional clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description completely compensates by explaining all 6 parameters in detail. For period1/period2 it specifies accepted formats (date objects or predefined strings like 'today', 'last_week'). It explains the topic parameter as optional keyword filtering, compare_type with three named values and their meanings, platforms as a filter list with examples, and top_n with default. Examples illustrate real usage of parameters in combination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares news data across two time periods, covering multiple dimensions like hot topics, platform activity, and news volume. It explicitly distinguishes itself from siblings like get_news_by_date (single date) and analyze_topic_trend (single topic trend) by focusing on two-period comparison. The verb '对比' (compare) and resource '时期' (periods) 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a dedicated '使用场景' (usage scenarios) section with concrete examples like comparing this week vs last week, and analyzing topic popularity differences across periods. It also includes multiple working examples showing typical call patterns. While it doesn't explicitly state when NOT to use it, the scenarios and examples clearly define appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the rate-limiting behavior (5-second interval), the max batch size (5), the timeout parameter, and the behavior on partial failures (single failure doesn't affect others). It also mentions the return format (JSON with content and status). This is comprehensive, though it could mention whether the tool is read-only (but that's implied by '读取').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (typical workflow, args, returns, examples, notes). It is front-loaded with the key information (batch read, max 5, interval 5s) and every sentence adds value. It's 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch operation, rate limiting, partial failures), the description is complete. It covers the workflow, parameters, return format, limitations, and error behavior. The output schema exists, so return values are not over-explained. The description is sufficient 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'urls' parameter (list of article links, required, max 5) and 'timeout' (per-request timeout in seconds, default 30). It also provides an example usage. This adds meaning beyond the schema, which only lists types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads multiple article contents in batch, with a specific verb ('批量读取') and resource ('多篇文章内容'). It distinguishes itself from siblings like read_article (single article) and search_news (searching) by explicitly mentioning the batch nature and the typical workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it outlines a typical workflow (search first, then batch read, then analyze), and implicitly distinguishes from read_article by focusing on batch processing. It also notes the limit of 5 articles and the time cost, which helps the agent decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 side effects. It explicitly states '列出' (list) and '查看' (view), indicating a read-only operation with no modifications. This fully discloses the non-destructive nature of the tool, exceeding the baseline for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a clear explanation followed by the parameter details and examples. It avoids unnecessary prose, and the structure (purpose, parameters, return, examples) is highly scannable and efficient. Every sentence contributes to the understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's behavior: it defines the parameter, explains the return format (JSON list of dates), and provides usage examples. Although there is a minimal output schema, the description is self-sufficient and leaves no significant gaps for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides detailed meaning for the 'source' parameter, listing all three valid values ('local', 'remote', 'both') and the default value. This adds significant value beyond the schema, which only has a default and no description. The coverage is complete and enriches the parameter's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '列出本地/远程可用的日期范围' (list available date ranges from local/remote). The verb 'list' and resource 'available dates' are specific, and it is distinct from sibling tools like 'resolve_date_range' or 'get_news_by_date'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: to view which dates have data available in local or remote storage. It does not explicitly contrast with alternatives, but the purpose is straightforward and the examples clarify typical invocations, making the usage clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full transparency burden. It discloses the underlying Jina AI Reader service, rate limits (100 RPM), built-in 5-second request delay, and paywall limitations. This is thorough and gives the agent realistic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Examples, Notes) and is front-loaded with the main purpose. Every sentence adds value, and the markdown formatting enhances readability without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool, the description is complete: it covers the typical workflow, parameter semantics, return format, an example, and operational constraints. The presence of an output schema is acknowledged by the description's mention of JSON return format, making it sufficient for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for parameters (0% coverage), so the description fully compensates. It explains url is required and must start with http/https, and timeout has a default of 30 and max of 60. This adds essential meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: reads article content from a specified URL and returns LLM-friendly Markdown. It also references a workflow with search_news, distinguishing it from sibling news tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly outlines a typical usage flow (search_news → read_article → analyze) and lists suitable use cases. However, it does not explicitly state when not to use the tool or mention batch alternatives like read_articles_batch, making it clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/17191004/TrendRadar'

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