Server Quality Checklist

Tool Scores

• android_clear_proxyC
  2.9/5.0
  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. It states the action ('clear proxy settings') but doesn't explain what this entails (e.g., whether it resets to default, requires device permissions, affects network connectivity, or has side effects). For a mutation tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part contributing essential information.

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

  Completeness2/5

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

  Given the tool's complexity (a mutation operation), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like effects, permissions, or return values, leaving critical gaps for an agent to understand the tool fully.

  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 input schema has 100% description coverage, with the 'serial' parameter documented as '设备序列号' (device serial number). The description doesn't add any parameter details beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.

  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 action ('清除' meaning 'clear') and the resource ('Android 设备上的代理设置' meaning 'proxy settings on Android devices'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'android_setup_proxy' or 'proxy_status', which prevents a perfect score.

  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 doesn't mention prerequisites (e.g., device connectivity), when-not-to-use scenarios, or how it differs from related tools like 'android_setup_proxy' or 'traffic_clear', leaving the agent without contextual usage cues.

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

• traffic_searchC
  2.9/5.0
  Behavior2/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 states that the tool returns matching fragments, which is useful context. However, it doesn't cover critical aspects like whether this is a read-only operation, potential performance impacts, error conditions, or authentication requirements. For a search tool with no annotations, this leaves significant gaps in understanding its 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 concise and front-loaded, stating the core functionality in the first sentence. The second sentence adds important details about search scope and return format. Both sentences earn their place by providing essential information without redundancy. It could be slightly improved by structuring with bullet points for clarity, but it's efficiently written.

  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?

  Given the tool's complexity (6 parameters, search functionality) and lack of annotations and output schema, the description is moderately complete. It covers the purpose and return format but misses behavioral context and usage guidelines. For a search tool, it adequately explains what it does but doesn't fully address how or when to use it effectively, leaving room for improvement in contextual understanding.

  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?

  Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. It mentions searchable components (e.g., URL, headers) which align with the 'search_in' parameter, but doesn't provide extra context like format examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 purpose: '搜索流量内容' (search traffic content). It specifies the searchable components (URL, headers, bodies) and the return format (matching fragments rather than full content). However, it doesn't explicitly differentiate this search tool from sibling tools like 'traffic_list' or 'traffic_get_detail', which likely serve different purposes in traffic 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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'traffic_list' (likely listing traffic) and 'traffic_get_detail' (likely getting detailed traffic records), there's no indication of how this search function differs or when it's preferred. The description mentions what it does but not the context for its use.

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

• traffic_clearB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether this operation is destructive (likely yes, but unstated), requires specific permissions, has side effects, or provides any confirmation/response. The description is minimal and lacks critical behavioral context for a clear 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 a single, efficient sentence in Chinese that directly states the tool's purpose with no wasted words. It's appropriately sized for a simple, parameterless operation and is front-loaded with the core action.

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

  Completeness2/5

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

  For a destructive operation with no annotations and no output schema, the description is incomplete. It doesn't explain what 'captured traffic' refers to, whether the clearance is permanent, what happens to related data (e.g., traffic details), or what the tool returns (success/failure status). Given the complexity of traffic management and sibling tools, more context is needed.

  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 no parameter documentation is needed. The description appropriately doesn't discuss parameters, aligning with the empty input schema. Baseline is 4 for zero-parameter tools when schema coverage is complete.

  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 '清空所有捕获的流量' (Clear all captured traffic) clearly states the action (clear) and target resource (captured traffic). It distinguishes from siblings like traffic_list (list) and traffic_get_detail (get detail), but doesn't explicitly contrast with android_clear_proxy which clears proxy settings rather than traffic.

  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. It doesn't mention prerequisites (e.g., whether traffic must be actively captured), consequences (e.g., irreversible deletion), or when to choose other traffic-related tools like traffic_search or traffic_read_body.

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

• android_get_device_infoB
  3.2/5.0
  Behavior2/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 what data is retrieved but doesn't disclose behavioral traits like permissions required, rate limits, error handling, or whether this is a read-only operation. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.

  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 a single, efficient sentence in Chinese that front-loads the key action and details. It wastes no words but could be slightly more structured (e.g., separating purpose from data types). Overall, it's appropriately sized and 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?

  Given the tool's low complexity (1 parameter, no nested objects) and no output schema, the description adequately covers the purpose and data retrieved. However, with no annotations and missing behavioral details, it's not fully complete for an agent to use confidently. It meets minimum viability but has clear gaps in transparency.

  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 parameter 'serial' fully documented in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., no extra context on serial format or validation). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.

  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 ('获取' meaning 'get') and resource ('Android 设备的详细信息'), specifying what information is retrieved (model, version, root status). It distinguishes from siblings like android_list_devices (which lists devices) but doesn't explicitly contrast with all tools. The purpose is specific and actionable, though not fully differentiated from all 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?

  The description implies usage when detailed device info is needed, and the input schema hints at using serial numbers from android_list_devices. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., traffic tools for network data) or any exclusions. The context is clear but not comprehensive.

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

• android_list_devicesB
  3.2/5.0
  Behavior2/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 states the action ('列出所有连接的 Android 设备') but doesn't describe behavioral traits such as what 'connected' means (e.g., USB, network, emulator), whether it requires specific permissions or setup (e.g., ADB enabled), how it handles no devices, or the format of the output (e.g., list of device IDs, names). For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence in Chinese ('列出所有连接的 Android 设备') that directly states the tool's purpose with zero waste. It's appropriately sized for a simple listing tool and front-loaded with the core action, making it easy for an agent to parse quickly.

  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?

  Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally complete. It states what the tool does but lacks context on behavior, output format, or usage scenarios. Without annotations or an output schema, the agent won't know what to expect from the result (e.g., list structure, error handling). It's adequate for a basic tool but has clear gaps in providing a full operational picture.

  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 0 parameters with 100% coverage, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it meets the baseline of 4 for tools with no parameters. It correctly implies no inputs are required for listing devices.

  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 purpose as '列出所有连接的 Android 设备' (List all connected Android devices), which is a specific verb+resource combination. It distinguishes itself from siblings like android_get_device_info (which gets info for a specific device) and android_clear_proxy/android_setup_proxy (which manage proxy settings). However, it doesn't explicitly mention how it differs from traffic_list (which lists traffic records), so it's not a perfect 5.

  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 doesn't mention prerequisites (e.g., needing Android devices connected via ADB), when not to use it (e.g., if you need device-specific details), or direct alternatives like android_get_device_info for individual device info or traffic_list for traffic monitoring. The agent must infer usage from the name and context alone.

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

• traffic_read_bodyB
  3.2/5.0
  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. While it mentions the tool reads chunks of large content with pagination, it doesn't address important behavioral aspects like whether this operation is safe (read-only), what permissions might be required, error conditions, or what format the returned content will be in (raw bytes, decoded text, etc.).

  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 extremely concise with just two sentences that each earn their place. The first sentence states the core functionality, and the second sentence provides important context about when to use it. There's zero wasted language or redundancy.

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

  Completeness2/5

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

  For a tool that reads potentially sensitive traffic data with 4 parameters and no output schema, the description is insufficient. It doesn't explain what the tool returns (content format, structure, or metadata), doesn't address authentication or permission requirements, and provides minimal guidance on error handling or edge cases despite the tool's potential complexity.

  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?

  With 100% schema description coverage, the input schema already documents all 4 parameters thoroughly. The description adds minimal value beyond the schema - it mentions '分页读取' (pagination reading) which relates to offset/length parameters, but doesn't provide additional semantic context about parameter interactions or usage patterns.

  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 purpose with specific verbs ('分片读取' - chunked reading) and resources ('请求体或响应体' - request body or response body). It distinguishes from siblings like traffic_list (which likely lists traffic) and traffic_get_detail (which might get full details), but doesn't explicitly name these 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?

  The description provides implied usage context ('用于查看大内容，支持分页读取' - for viewing large content, supports paginated reading), suggesting this tool should be used when dealing with large bodies that need chunked access. However, it doesn't explicitly state when NOT to use it or name specific alternative tools for different scenarios.

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

• traffic_listB
  3.3/5.0
  Behavior2/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 tool lists traffic with filtering, but doesn't disclose behavioral traits such as whether it's read-only (implied by '列出' but not explicit), potential rate limits, authentication needs, or what happens with large datasets (e.g., pagination). For a tool with no annotations, this leaves significant gaps in understanding its operation and constraints.

  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 appropriately sized and front-loaded: a single sentence that states the core purpose and key features (filtering). There's no wasted text, and it efficiently conveys essential information without redundancy or unnecessary elaboration.

  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?

  Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and filtering, but lacks details on behavioral aspects (e.g., read-only nature, performance) and doesn't explain return values (no output schema). It's complete enough for a simple list tool but has clear gaps in context.

  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?

  Schema description coverage is 100%, so the schema fully documents all 5 parameters (limit, filter_domain, filter_type, filter_status, filter_url). The description adds minimal value beyond the schema by mentioning filtering support but doesn't provide additional semantic context (e.g., how filters combine, default behaviors). Baseline 3 is appropriate as the schema does the heavy lifting.

  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 purpose: '列出捕获的 HTTP/HTTPS 流量' (list captured HTTP/HTTPS traffic). It specifies the resource (traffic) and verb (list), and distinguishes itself from siblings like traffic_clear (clear traffic) and traffic_get_detail (get detailed traffic). However, it doesn't explicitly differentiate from traffic_search (search traffic), which might have overlapping functionality, keeping it from a perfect score.

  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 mentioning filtering capabilities ('支持按域名、类型、状态码、URL 筛选'), suggesting it's for retrieving filtered traffic data. However, it lacks explicit guidance on when to use this tool versus alternatives like traffic_search (no mention of differences) or traffic_get_detail (no indication of detail vs. list). The context is clear but incomplete for sibling differentiation.

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

• android_setup_proxyA
  3.5/5.0
  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 of behavioral disclosure. It adds important context about limitations ('对部分应用可能无效' - may not work for some apps) and suggests manual configuration as an alternative. However, it doesn't describe what the tool actually does behaviorally (e.g., whether it requires device connection, what happens if proxy fails, or what the response looks like).

  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 extremely concise with just two sentences. The first sentence states the core purpose, and the second sentence adds important caveats and recommendations. Every word earns its place with no wasted text.

  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 tool with 3 parameters, no annotations, and no output schema, the description provides adequate but minimal context. It explains what the tool does and adds important limitations, but doesn't cover behavioral aspects like error conditions, success indicators, or integration with sibling tools. The completeness is sufficient for basic understanding but leaves gaps for practical implementation.

  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?

  Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting for 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 purpose: '在 Android 设备上设置 HTTP 代理' (Set up HTTP proxy on Android device). It specifies the verb ('设置' - set up) and resource ('HTTP 代理' - HTTP proxy) with platform context ('Android 设备' - Android device). However, it doesn't explicitly differentiate from its sibling 'android_clear_proxy' beyond the opposite action.

  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 some usage context: '此方式对部分应用可能无效，建议在 Wi-Fi 设置中手动配置' (This method may not work for some apps, it's recommended to configure manually in Wi-Fi settings). This implies limitations and suggests an alternative approach, but doesn't explicitly state when to use this tool versus the sibling 'android_clear_proxy' or other proxy-related tools like 'proxy_status'.

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

• proxy_statusA
  3.5/5.0
  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 a key behavioral trait: the tool requires the proxy to be started first via a specific command. However, it doesn't describe what the status output includes (e.g., running/stopped, ports, errors), rate limits, or authentication needs, leaving gaps in behavioral context.

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

  Conciseness4/5

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

  The description is two concise sentences: one stating the purpose and another with a prerequisite note. It's front-loaded with the main function and avoids unnecessary details, though the prerequisite could be slightly more integrated for optimal flow.

  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?

  Given no annotations and no output schema, the description is minimally complete for a zero-parameter tool. It covers the purpose and a key prerequisite, but lacks details on return values (e.g., status format) and doesn't fully address behavioral aspects like error handling or dependencies, leaving room for improvement.

  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, and schema description coverage is 100% (empty schema). The description doesn't need to add parameter semantics, so a baseline of 4 is appropriate—it efficiently states the tool's purpose without redundant parameter explanations.

  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 purpose as '获取代理服务器状态' (get proxy server status), which is a specific verb+resource combination. It doesn't explicitly distinguish from sibling tools like 'android_setup_proxy' or 'android_clear_proxy', but the core function 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 Guidelines3/5

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

  The description provides implied usage guidance through the prerequisite note: '需要先在终端运行 'uv run android-proxy-start' 启动代理' (requires running 'uv run android-proxy-start' in the terminal to start the proxy first). This indicates when the tool can be used (after proxy startup), but doesn't specify when to use it versus alternatives like checking device info or traffic tools.

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

• get_cert_infoA
  3.8/5.0
  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 that the tool provides information and a guide for installing a CA certificate, which is useful for HTTPS traffic capture. However, it lacks details on behavioral traits like whether this is a read-only operation, if it requires specific permissions, or what the output format is. The description adds some context but is incomplete for a tool with no 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 concise and well-structured in two sentences: the first states the purpose, and the second provides usage context. Every sentence earns its place by adding value, with no wasted words or redundancy.

  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?

  Given the tool has no parameters, no annotations, and no output schema, the description provides basic purpose and usage context. However, for a tool related to security (CA certificates), it lacks details on output format, potential errors, or prerequisites. It's minimally adequate but has clear gaps in completeness for this context.

  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, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately focuses on the tool's purpose and usage. Baseline is 4 for zero parameters, as it avoids unnecessary parameter details.

  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 purpose: '获取 CA 证书信息和安装指南' (Get CA certificate information and installation guide). It specifies the resource (CA certificate) and the action (get information and guide), though it doesn't explicitly differentiate from sibling tools like 'android_get_device_info' or 'proxy_status'.

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

  Usage Guidelines4/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 this tool: '抓取 HTTPS 流量需要在设备上安装此证书' (Capturing HTTPS traffic requires installing this certificate on the device). This implies usage for HTTPS traffic interception setup, but it doesn't explicitly state when not to use it or name alternatives among siblings.

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

• traffic_get_detailA
  4.2/5.0
  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 of behavioral disclosure. It clearly indicates this is a read operation (not destructive) and specifies what data is included/excluded (metadata only, no body content). However, it doesn't mention potential limitations like authentication requirements, rate limits, or error conditions that 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.

  Conciseness5/5

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

  The description is extremely concise (two sentences) with zero wasted words. The first sentence states the core purpose, and the second provides critical usage guidance about what's excluded and the alternative tool. Every sentence earns its place and is front-loaded with essential information.

  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 single-parameter read tool with no annotations and no output schema, the description does an excellent job of explaining what the tool returns (metadata) and what it doesn't (body content), plus providing clear sibling differentiation. The main gap is the lack of output format details, but given the tool's relative simplicity and the clear behavioral description, this is reasonably complete.

  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 input schema has 100% description coverage, with the single parameter 'request_id' well-documented in the schema itself. The description doesn't add any additional parameter information beyond what the schema provides, which is acceptable given the high schema coverage. The baseline of 3 is appropriate when the schema does the heavy lifting.

  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 specific verb ('获取' meaning 'get') and resource ('单个请求的元数据' meaning 'metadata of a single request'), and explicitly distinguishes it from its sibling tool 'traffic_read_body' by noting it excludes request/response body content. This provides precise differentiation from related tools.

  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 (for metadata only) and when to use an alternative ('使用 traffic_read_body 读取' meaning 'use traffic_read_body to read' for body content). It also implies prerequisites by referencing 'request_id' from 'traffic_list', creating clear usage context.

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