Server Quality Checklist

Tool Scores

• get_hardware_infoA
  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 effectively describes what the tool returns (CPU, memory, disk, network info, with optional detailed mode for temperature, battery, GPU) and emphasizes the importance of real-time data for performance diagnosis. However, it lacks details on potential limitations like rate limits, error conditions, or data freshness, which would be helpful for a tool with no annotation coverage.

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

  Conciseness3/5

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

  The description is appropriately front-loaded with the core purpose, but it includes repetitive warnings (e.g., multiple ⚠️ symbols and emphatic statements) and a lengthy list of scenarios that could be more streamlined. While informative, some sentences could be condensed without losing clarity, making it slightly verbose for its content.

  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 (hardware diagnostics with real-time data) and lack of annotations or output schema, the description does a good job covering purpose, usage, and return values. It specifies what information is returned in both basic and detailed modes. However, it doesn't describe the output format (e.g., structured data vs. text) or potential errors, leaving some gaps for the agent to infer.

  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 100% description coverage for its single parameter 'detailed', so the baseline is 3. The description adds value by explaining what 'detailed mode' includes (CPU temperature, battery status, graphics card info), providing context beyond the schema's boolean description. This compensates meaningfully, though it doesn't cover edge cases or default behavior implications.

  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: '获取用户硬件配置和实时使用情况' (get user hardware configuration and real-time usage). It clearly distinguishes from siblings like get_location, get_system_info, and get_time by focusing specifically on hardware metrics (CPU, memory, disk, network) rather than location, general system info, or time.

  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, explicit guidance on when to use this tool, listing 7 specific scenarios (e.g., performance complaints, resource diagnosis, configuration inquiries). It also includes strong imperatives like '强制调用场景' (mandatory call scenarios) and '必须调用' (must call), clearly directing the agent to prioritize this tool over alternatives in relevant contexts.

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

• get_system_infoA
  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 effectively describes what the tool returns (OS type, version, architecture, kernel version, hostname, uptime) and emphasizes its importance for providing accurate technical advice. However, it doesn't mention potential limitations like rate limits, authentication requirements, or error conditions, which would be helpful for a tool with no annotation coverage.

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

  Conciseness3/5

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

  The description is appropriately front-loaded with the core purpose, but contains some redundancy in the usage scenarios list and uses multiple warning symbols (⚠️) that could be streamlined. While all content is relevant, the structure could be more efficient with better grouping of similar scenarios and less repetitive emphasis.

  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 (0 parameters, no output schema, no annotations), the description provides strong contextual completeness by clearly explaining what information the tool returns and when to use it. The main gap is the lack of output schema, which means the description must fully explain return values - it does this adequately by listing the specific data points returned, though a structured output schema would be more precise.

  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 with 100% schema description coverage, so the baseline would be 4 even with no parameter information in the description. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose and usage guidelines.

  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 as '获取用户操作系统的详细信息' (get detailed information about the user's operating system), which is a specific verb+resource combination. It distinguishes itself from sibling tools like get_hardware_info, get_location, and get_time by focusing specifically on operating system details rather than hardware, location, or time information.

  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 guidance on when to use this tool versus making assumptions, listing six specific scenarios including user inquiries about system info, before providing installation/configuration instructions, diagnosing system issues, discussing compatibility, when users mention installation/configuration/running/deployment, and before providing command-line instructions. It also includes a strong warning not to assume the user's OS and to call this tool for accurate information.

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

• get_timeA
  4.4/5.0
  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 effectively describes the tool's behavior by stating it returns real-time information (not cached or estimated), lists the specific data returned (local time, UTC, timezone, Unix timestamp, full date/time, weekday), and emphasizes the critical constraint that the agent must call it instead of using internal knowledge. It doesn't mention error handling or rate limits, but covers the core behavioral aspects well for a read-only tool.

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

  Conciseness4/5

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

  The description is appropriately sized and well-structured, with clear sections (purpose, warnings, usage scenarios, return information). Every sentence adds value, such as the critical warning about inaccurate training data and the list of mandatory call scenarios. It could be slightly more concise by reducing repetition of '必须调用' (must call), but overall it's efficient and front-loaded with the core purpose.

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

  Completeness5/5

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

  Given the tool's low complexity (one optional parameter) and lack of annotations/output schema, the description is highly complete. It thoroughly explains the tool's purpose, when to use it, behavioral constraints, and what information it returns. For a simple time-fetching tool, this provides all necessary context for an agent to invoke it correctly, compensating for the absence of structured metadata.

  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 description coverage is 100%, with the single parameter 'format' fully documented in the schema (including enum values and default). The description doesn't add any parameter-specific information beyond what's in the schema, but it implicitly reinforces the tool's purpose of returning time data in various formats. Since schema coverage is high, the baseline score of 3 is appropriate.

  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 as '获取用户环境的实时时间信息' (get real-time time information of the user's environment), which is a specific verb+resource combination. It clearly distinguishes from sibling tools like get_hardware_info, get_location, and get_system_info by focusing exclusively on time data rather than hardware, location, or broader system information.

  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 and detailed guidance on when to use this tool, listing multiple mandatory scenarios (e.g., when users mention time-related words, ask about time-sensitive events, or need to determine past/future dates). It also explicitly states when not to use alternatives by emphasizing '必须调用此工具' (must call this tool) and warning against relying on the agent's own knowledge or training data for time information.

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

• get_locationA
  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 of behavioral disclosure. It effectively describes key behaviors: it returns comprehensive location data (country, region, city, coordinates, timezone, ISP), emphasizes accuracy over assumptions, and mandates proactive calls in specific scenarios. However, it lacks details on rate limits, error handling, or authentication needs, which would be helpful for a tool with no annotation coverage.

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

  Conciseness4/5

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

  The description is well-structured and front-loaded with the core purpose, followed by important warnings and detailed usage scenarios. Every sentence adds value, such as clarifying return information and emphasizing proactive calls. It could be slightly more concise by reducing repetition in the mandatory scenarios, but overall it's efficient and easy to follow.

  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 (location lookup with no output schema and no annotations), the description is mostly complete. It covers purpose, usage guidelines, return data, and behavioral expectations. However, it lacks details on output format (e.g., JSON structure), error cases, or limitations (e.g., accuracy for VPNs), which would enhance completeness for an agent invoking this tool.

  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 100% description coverage, with the 'ip' parameter documented as optional (defaulting to the user's public IP if not provided). The description adds value by reinforcing this in the context of the tool's purpose ('IP地址（可选，不提供则自动获取用户当前公网IP）'), but it doesn't provide additional semantics beyond what the schema already covers, such as IP format validation or examples.

  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: '根据IP地址获取用户的真实地理位置信息' (get real geographic location information based on IP address). It specifies the exact resource (geographic location) and distinguishes it from sibling tools like get_hardware_info, get_system_info, and get_time by focusing on location rather than hardware, system, or time data.

  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 guidance on when to use this tool, listing five '强制调用场景' (mandatory call scenarios) such as when users ask about their location, need localized recommendations, discuss region-specific topics, provide installation instructions, or recommend content. It also emphasizes not to assume user location and to call this tool proactively for region-specific advice, offering clear alternatives (use this instead of assuming).

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