Server Quality Checklist

Tool Scores

• generate_summary_reportB
  3.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden for behavioral disclosure. It only states it generates a report and returns JSON with Markdown content, but does not disclose whether it performs read-only operations, any side effects, permissions needed, or limitations. This is insufficient for a tool that generates reports.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized with Args and Returns sections, making it easy to scan. The formatting for date_range is slightly elaborate but serves a purpose. No fluff or redundant content is present.

  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 purpose, parameters, and return format, and an output schema exists so return details are not required. However, it lacks usage context and behavioral transparency, making it only minimally complete for a tool with no annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides zero description coverage (0%), so the description fully compensates by explaining report_type values ('daily/weekly') and date_range format with a concrete example and a warning against passing integers. This adds significant meaning beyond the bare 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 clearly states the tool generates daily/weekly hotspot summary reports, providing a clear verb ('generate') and resource ('summary report'). It distinguishes itself from sibling tools by focusing on report generation rather than analysis, though it doesn't explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives is provided. The mention of 'daily/weekly' implies scheduling context, but there is no statement of appropriate conditions or exclusions, leaving the agent to infer usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_system_statusB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full burden. It implies a read-only operation via '获取' but does not explicitly state safety, side effects, permissions, or the nature of the health check. No disclosure of possible performance impact or data freshness.

  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 primary purpose. The 'Returns:' line is somewhat redundant with the preceding sentence, but the overall length is appropriate for a parameterless tool.

  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?

  An output schema exists, so return format is covered. However, the description lacks any behavioral context, usage scenarios, or caveats. For a simple status tool this is adequate but leaves gaps about when to prefer it over sibling tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description adds value by detailing the return types (system version, data stats, cache status), though 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 clearly states it retrieves system running status and health check information, listing specific return contents (system version, data statistics, cache status). This distinguishes it from siblings like get_storage_status or get_current_config.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives such as get_storage_status or get_current_config. The description only states what it does, not the appropriate context or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_current_configA
  3.5/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Without annotations, the description carries full burden for disclosing behavioral traits. It implies a read operation through the verb '获取' and states the return format, but it does not explicitly confirm that the tool is read-only, safe, or free of side effects. It also omits any mention of authentication, permissions, or potential sensitivity of the configuration data. This is a minor gap for a getter but still a gap given no annotations exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized with Args and Returns sections, and it front-loads the purpose. It could be slightly more concise by omitting the explicit 'Returns' line, but the structure is clear and every element adds value. The section list is necessary for parameter semantics, and the overall length is appropriate for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple configuration getter with an output schema, the description covers the core information: what it does, the parameter options, and the return type. However, it lacks usage guidance and explicit behavioral safety confirmation, which are moderately important for an agent to invoke it correctly without assumptions. It is adequate but has clear gaps, so it meets the minimum viable standard but does not excel.

  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?

  While the input schema only defines 'section' as a string with default 'all', the description enriches this substantially by listing all valid enum values ('all', 'crawler', 'push', 'keywords', 'weights') and explaining their meaning. This goes far beyond the schema's bare type/default and fully compensates for the 0% schema description coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  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 current system configuration), which is a specific verb+resource pair. It enumerates distinct config sections (crawler, push, keywords, weights) and the default 'all', making its scope unambiguous and differentiating it from sibling tools like get_system_status or get_storage_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?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where one might prefer get_system_status or other configuration-related tools, nor does it state any exclusions or prerequisites. The section list implies use cases but does not explicitly say 'use this when you need to view current config values'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_latest_newsA
  4/5.0
  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 key behavioral traits: the default of platforms falls back to config.yaml, limit may return fewer items than requested, and include_url defaults to false to save tokens. It also notes that the data is crawled, which is useful context. No side effects or contradictions are present.

  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 starts with a concise purpose sentence, then clearly separates Args, Returns, and an 'Important' section. It is somewhat lengthy due to display suggestions, but the structure is logical and front-loaded. Every section serves a purpose, though the display advice could be condensed.

  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 parameter handling, return type, and provides practical usage advice. Given that an output schema exists, it need not detail every field of the returned news items. It lacks explicit error handling or rate limit information, but for a read-only 'get' tool, it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description thoroughly explains each parameter: platforms (list of IDs, default to config, includes Chinese names), limit (default 50, max 1000, may return fewer), and include_url (default false, token saving). With 0% schema coverage, this fully compensates and adds significant meaning beyond the input 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 clearly states the tool's function: '获取最新一批爬取的新闻数据' (get the latest batch of crawled news data). It specifies the resource (latest news) and the action (get), but it does not explicitly distinguish from sibling tools like get_news_by_date or search_news, though the 'latest' qualifier implies a difference.

  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 quickly understanding current hot topics ('快速了解当前热点'), which suggests when to use it. However, it does not explicitly contrast with alternatives such as get_news_by_date or search_news, nor does it provide when-not-to-use guidance. The guidance provided is more about data display than tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_related_news_historyA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It transparently explains the relevance threshold formula (70% keyword overlap + 30% text similarity), the fact that actual results may be fewer than the limit, the token-saving effect of include_url, and the return format (JSON with relevance scores and time distribution). It also describes the important data display strategy (show all by default, summarize only when explicitly requested). This is substantial behavioral context beyond a simple search 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 clear Args and Returns sections, and a bolded '重要' block for the display strategy. Every sentence adds meaningful information: parameter details, return format, and behavioral notes. The length is justified given the number of parameters and the need to explain the mixed-similarity calculation and display rules. No fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (5 parameters, custom threshold calculation, display strategy) and rich input schema, the description is remarkably complete. It covers the tool's purpose, all parameter semantics, output format, and a non-obvious display behavior. Even though an output schema exists, the description still describes the return content (relevance score and time distribution) which adds value. No significant aspects are missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 0% description coverage, meaning no per-parameter descriptions are provided in the schema. The tool description fully compensates by explaining every parameter in detail: reference_text, time_preset with all options and meanings, threshold with its calculation formula and effect on results, limit with its maximum and note that fewer may be returned, and include_url with its purpose. This is exemplary parameter documentation.

  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: searching historical news based on a seed news text ('基于种子新闻，在历史数据中搜索相关新闻'). This is a specific verb+resource combination that accurately conveys the tool's purpose. However, it does not explicitly differentiate from sibling tools like search_news or find_similar_news, so it loses a point for lacking sibling distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It explains parameter usage and the default display strategy, but does not mention when one would choose this over search_news, find_similar_news, or other siblings. There is no explicit when-to-use or exclusions, so it falls short of even 'clear context, no exclusions'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_news_by_dateA
  4.1/5.0
  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 notable behaviors: returns JSON with title/platform/ranking, may return fewer than the requested limit due to date-specific availability, and defaults that conserve tokens. It also adds a detailed display policy advising agents not to summarize data unless the user explicitly asks, which is useful contextual 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 organized with clear Args/Returns/important sections, making it easy to scan. The core parameter documentation is efficient, but the long '数据展示建议' section about user-facing display is somewhat tangential and adds length. Still, most sentences earn their place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only retrieval tool with zero required parameters, the description covers input formats, defaults, output structure, and behavioral expectations, including the caveat that returned count may be less than requested. It is complete enough to select and invoke the tool correctly without needing the output schema details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, but the description fully compensates by documenting date_query formats (natural language and standard dates), platforms source from config and name fields, limit constraints with default and max, and include_url purpose with defaults. This is far beyond what the schema provides and makes parameter selection unambiguous.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with '获取指定日期的新闻数据，用于历史数据分析和对比', clearly stating the tool retrieves news for a specified date for historical analysis. This distinguishes it from siblings like get_latest_news by its date-scoped purpose, though it does not explicitly name alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states the tool is '用于历史数据分析和对比', implying its intended use case of date-specific historical retrieval. However, it provides no explicit guidance on when to use this tool versus siblings like get_latest_news, search_news, or resolve_date_range, and no exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• analyze_topic_trendA
  4.4/5.0
  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 discloses key behaviors: the need to call resolve_date_range for natural language dates, the default date range of 7 days, the constraint that granularity only supports 'day' due to data aggregation, and mode-specific defaults. It does not explicitly state that the tool is read-only, but this is implied by the analysis context. Overall, it adds significant behavioral 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 well-structured with clear headings, lists, and examples. It is somewhat long but every section serves a purpose: the 'Important' notice for date range, the detailed Args list, Returns, and Examples. The examples repeat some information but demonstrate the two-step workflow, which is valuable for an 8-parameter tool with multiple modes.

  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 (8 parameters, 4 modes, prerequisite tool call), the description is quite complete. It covers all parameter semantics, defaults, modes, and provides a workflow example. It does not discuss error handling or edge cases (e.g., missing data), but an output schema exists to define return values, reducing the need for that in the description. Overall, it provides sufficient context for correct tool selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must fully compensate. It explains every parameter, its purpose, allowed values, defaults, and which analysis modes it applies to. For example, analysis_type enum values are defined, date_range format and acquisition method are provided, and mode-specific parameters like threshold and lookahead_hours are clarified. This is exemplary parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it is a unified topic trend analysis tool with multiple analysis modes (trend, lifecycle, viral, predict). It is specific about the resource ('topic trend') and the action ('analyze'), and the modes distinguish it from sibling tools like analyze_sentiment or analyze_data_insights.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context, including when to call resolve_date_range first and which parameters apply to which mode. It includes two examples showing a recommended calling flow. However, it does not explicitly mention when not to use this tool or name alternative tools for other analysis types, 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.

• find_similar_newsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It discloses behavioral traits such as threshold strictness ('阈值越高匹配越严格，返回结果越少'), limit caveats ('实际返回数量取决于相似度匹配结果，可能少于请求值'), and a display strategy instructing to show all results unless the user explicitly asks to summarize. This adds valuable context beyond the schema and annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with purpose, Args, Returns, and a bolded '重要：数据展示策略' section. It is front-loaded with the core purpose, and each section is concise. The display strategy is extra but earns its place by guiding agent behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (4 params, 1 required) and the description covers purpose, all parameters with behavioral notes, return format, and display behavior. With no annotations or output schema details, this description is complete enough for an agent to invoke the tool correctly and format the response appropriately.

  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. The Args section explains each parameter: reference_title (full or partial), threshold (range and strictness), limit (default/max and caveat), and include_url (default and token-saving rationale). This provides rich semantic meaning that the schema lacks.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: '查找与指定新闻标题相似的其他新闻' (Find other news similar to a specified news title). This specifies a distinct verb+resource+method, making it distinguishable from siblings like search_news or get_latest_news, even though it doesn't explicitly contrast them.

  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 (find similar news) but does not provide explicit when-to-use or alternative guidance. It lacks comparison to sibling tools like search_news or get_news_by_date. The display strategy is about result presentation, not tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_trending_topicsA
  4.4/5.0
  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 reveals that the tool depends on a configurable config/frequency_words.txt file, implies a read-only operation by returning a JSON list, and explains the behavioral difference between the two modes. This adds significant context beyond the tool's name, though it stops short of explicitly stating side-effect-free or handling of missing config files.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized with a clear purpose statement, an important clarifying note, and a structured Args/Returns section. While not as terse as possible, every sentence adds value and the layout is easy to scan for an agent. It is appropriately sized for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has only 2 parameters and no annotations, the description is largely complete. It covers the config dependency, mode semantics, and return type, which is sufficient for basic use. It could mention edge cases like an empty config file, but the existence of an output schema mitigates the need to detail the exact return structure. Overall, it provides enough context for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate, and it does comprehensively. The Args section explains top_n as '返回TOP N关注词' with default 10, and mode with two options (daily/current) and their meanings. This fully clarifies parameter semantics that the schema alone does not provide.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: obtaining news occurrence frequency statistics for personal watched words based on config/frequency_words.txt. It explicitly differentiates itself from automatic news hotspot extraction, which distinguishes it from sibling tools. The verb '获取' and resource '个人关注词的新闻出现频率统计' 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: it is for statistics on user-defined watched words, not automatic hotspot extraction, which indirectly guides against misuse. It also explains the two modes (daily/current) for selection. However, it does not explicitly name alternative tools, so it stops short of full usage/alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• resolve_date_rangeA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses server-side time calculation, supported expression formats, and the exact JSON return structure. It does not mention error handling or timezone behavior, which prevents a perfect score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with headers and code blocks but is very long and repetitious. The recommended flow example appears twice (once in the flow and once in Examples), and the 'why' section adds length. While informative, it could be more concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with a single parameter and a clear output schema, the description is exceptionally complete. It covers purpose, usage, parameter details, return format, and even integration steps with other tools. No significant missing context for an agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema only defines 'expression' as a string with no description. The description compensates fully by listing all supported natural language patterns (today, this week, last 7 days, dynamic numbers) and providing usage examples, adding substantial meaning beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with '将自然语言日期表达式解析为标准日期范围' which clearly specifies the verb (parse) and resource (natural language date expressions to target date range). It differentiates from sibling tools by focusing on resolving expressions rather than fetching news or data 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 includes a '推荐使用流程' that explicitly instructs when to call the tool (before other tools like analyze_sentiment and search_news) and why (ensures consistent date calculations). However, it does not state explicit exclusions such as 'if user already provides exact dates, use directly'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_available_datesA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden and reveals substantial behavior: it details how source values affect output, includes the 'configured' flag for remote, and explains the comparison logic. It does not explicitly state that the operation is read-only or cover error cases, but the nature of listing makes it implicit.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections (purpose, Args, Returns, Examples) and front-loaded with the main purpose. It is somewhat verbose but every section adds value, especially the return structure and examples, making it efficient despite its length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one optional parameter and an output schema, the description provides complete context: it covers purpose, parameter semantics, return format in detail, and usage examples. It also mentions the remote configuration state, which is helpful for the agent to interpret results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has zero description coverage, but the description fully compensates by explaining each allowed value of 'source' with its meaning and default, and provides examples showing different invocations. This is more than enough for the agent to understand and use the parameter correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with a clear verb phrase '列出本地/远程可用的日期范围' (list available local/remote date ranges), specifying the action and resource. It further explains the tool's role in understanding data coverage and sync status, which distinguishes it from sibling tools like get_news_by_date 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?

  The description provides clear context on when to use the tool (to understand data coverage and sync status) and explains the source parameter options. However, it does not explicitly mention when not to use it or name alternative tools, 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.

• analyze_data_insightsA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of disclosure. It thoroughly explains parameter behaviors, including the critical requirement that date_range must be an object (not an integer), and gives format examples. It also clearly states that results are returned as JSON. It lacks details on potential side effects or error conditions, but for an analysis tool, this is reasonable coverage.

  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) and is appropriately sized for the tool's complexity. Every sentence contributes meaning—parameter descriptions are terse yet informative, and the three examples are illustrative without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the presence of an output schema (so return values are covered) and the moderate complexity (5 parameters, 3 modes), the description is fully complete. It covers all parameter semantics, format constraints, defaults, and provides multiple usage examples, leaving no significant gaps for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate, and it does so comprehensively. Every parameter is semantically explained: insight_type values with meanings, topic applicability, date_range format and example, min_frequency and top_n defaults with their mode context. This adds substantial value beyond the bare type information in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this is a unified data insights analysis tool with three specific modes (platform_compare, platform_activity, keyword_cooccur), each with a concise explanation. It explicitly names the resource (data insights) and the action (analyze), distinguishing it from siblings that are more specialized.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use each insight_type (e.g., platform_compare for cross-platform topic attention, keyword_cooccur for keyword pattern analysis), and includes practical examples. However, it does not explicitly exclude alternatives or compare against sibling tools like analyze_topic_trend, so it earns a 4 rather than a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_newsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description fully carries the behavioral disclosure burden. It details default date behavior (today), fuzzy-mode threshold filtering, the fact that limit is not guaranteed, platform config sourcing, and include_url's token-saving purpose. It also explains the response structure and provides a nuanced display policy. This goes well beyond basic tool semantics.

  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?

  Although lengthy, the description is well-structured with bold headers, numbered steps, bullet points, and concrete examples. The critical prerequisite (resolve_date_range) is front-loaded, and each section adds value without unnecessary fluff. The length is justified by the tool's eight parameters and complex usage scenarios.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is highly complex (8 parameters, no annotations), yet the description covers prerequisites, parameter semantics, return types, display strategy, and illustrative examples. An output schema exists, but the description still adds value by explaining higher-level workflows and edge cases (e.g., fuzzy-mode filtering, default date behavior). It is fully complete for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the description documents every parameter with meaningful details: search_mode values, date_range format and acquisition, platforms source, sort_by options, threshold semantics, limit caveats, and include_url's purpose. It fully compensates for the schema's lack of descriptions, making parameter values actionable.

  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 '统一搜索接口' and describes searching news with multiple modes (keyword, fuzzy, entity), clearly identifying a search verb and resource. It does not explicitly distinguish itself from sibling tools like get_latest_news or search_related_news_history, but the '统一搜索接口' framing and mode details imply a broad search capability.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance: for natural-language date ranges like '本周' and '最近7天', it instructs the agent to first call resolve_date_range. It also gives examples and a display strategy (show all results unless summarization is requested). However, it does not explicitly state when to prefer this tool over siblings or mention exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sync_from_remoteA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the burden. It discloses behavior: pulls recent N days, skips dates already present locally, returns structured results, and requires specific configuration. It doesn't mention potential overwrites or side effects in detail, but covers the main behavior and prerequisites.

  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 (summary, use case, args, returns, examples, note). It is appropriately detailed without redundancy; every line adds useful information for invocation.

  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 is complete for a single-parameter tool: it explains purpose, parameter values, return structure, examples, and configuration requirements. It anticipates potential issues (missing config) and clarifies behavior (skip existing dates).

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, but the description fully compensates by explaining the 'days' parameter with default value, meaning of specific values (0, 7, 30), and providing examples. This gives the agent all necessary information to choose the right parameter value.

  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 (sync/pull) and resource (remote storage to local) with a specific use case (MCP Server pulling cloud-stored crawler data). It distinguishes from siblings like get_storage_status (status check) and trigger_crawl (initiate crawl) by focusing on data transfer.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool (when remote data is needed locally for analysis) and explains the typical scenario. It does not explicitly name alternatives or exclusions, but the context is sufficient to avoid confusion with sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• trigger_crawlA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full burden. It discloses return format, failed_platforms field, persistence option (save_to_local), and the effect of include_url. It does not mention potential side effects like network latency or rate limits, but for the tool's scope 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 a well-organized docstring with Args, Returns, and Examples sections. It is moderately sized but every sentence adds value, with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with zero annotations, a full input schema, and rich output expectations, the description covers all essential aspects: purpose, parameter semantics, return structure, and practical examples. The presence of an output schema also reduces the need to detail returns, but the description still includes a concise returns overview.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has no parameter descriptions, so the description compensates excellently. It explains each parameter's type, default behavior, meaning (e.g., platforms list with config fallback), and even notes why include_url saves tokens. This is more than sufficient for an AI to correctly select and invoke the tool.

  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 action ('trigger a crawl task') and its optional persistence feature. It is distinct from sibling read-only tools (get_current_config, get_system_status, etc.), making it the only tool that initiates a crawl.

  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 a manual crawl is needed. It provides concrete examples for common scenarios, but does not explicitly mention alternatives or when not to use it. Still, the context is clear and the examples are helpful.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• analyze_sentimentA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals deduplication behavior (“本工具会对新闻标题进行去重...实际返回数量可能少于请求的 limit 值”), default values (platforms from config.yaml, date_range defaults to today, include_url defaults to false to save tokens), and display strategy (“默认展示方式：展示完整的分析结果...仅在用户明确要求'总结'时才进行筛选”). These are concrete behavioral traits 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 long, but well-structured with bold headers, a clear flow from purpose to args to examples, and an important note section. The examples repeat some information but are useful for illustrating the intended sequence. It is appropriately sized for the tool's complexity and is front-loaded with the most critical guidance.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the essential aspects for correct invocation: parameter semantics, default behaviors, the dependence on resolve_date_range for natural-language dates, return format (complementing the output schema), deduplication caveat, and display strategy. No significant gaps remain for an AI agent to effectively use this 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%, but the description's Args section fully compensates by explaining every parameter with formats, defaults, and context. For example, platforms are described with fallback behavior and name mapping, and date_range includes both format and acquisition method. This adds significant meaning beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: “分析新闻的情感倾向和热度趋势” (analyze sentiment and heat trends of news). This clearly states what the tool does and distinguishes it from siblings like analyze_topic_trend by focusing on sentiment analysis. The scope (news, sentiment, trends) is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides strong usage guidance: it explicitly instructs the agent to call resolve_date_range first when the user uses natural language dates like “本周” or “最近7天”. It also includes recommended call flows with examples. However, it does not explicitly compare alternatives or state when not to use this tool, so a minor gap exists.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_storage_statusA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It clearly implies read-only behavior ('查看') and fully discloses the return structure, including nested fields for local and remote storage, making behavior 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections (summary, returns, example), no fluff, and the return format is presented in an easily scannable tree-like layout. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is complete for a zero-parameter tool: it covers purpose, full output schema details, and even a usage example. Nothing important is missing, and the presence of an output schema (or documented return) makes it 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 tool has 0 parameters, so baseline 4 applies. The schema is empty and no parameter semantics are needed; the description adds no parameter details because there are none.

  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 '获取存储配置和状态' (get storage config and status) and details local/remote storage status, making it distinct from siblings like get_system_status and get_current_config.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool (view storage status) and includes an example 'get_storage_status() # 查看所有存储状态'. It does not explicitly mention alternatives, but the purpose is unambiguous and distinct from sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.