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 does (converts natural language to SLS queries), what it returns (generated SLS query, project name, log store name), and important contextual behaviors like response time conversion from nanoseconds to milliseconds and handling of trace-specific queries. The main gap is lack of information about error conditions or rate limits.

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

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

The description is well-structured with clear sections (功能概述, 使用场景, 查询处理, 查询上下文, 查询示例, Args, Returns), but it's quite verbose at approximately 400 Chinese characters. Some sections like the detailed query context could be more concise while maintaining clarity.

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

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

For a tool with 4 parameters, 100% schema coverage, but no annotations or output schema, the description provides substantial contextual information. It explains the transformation process, return format, query considerations, and includes examples. The main gap is the lack of output schema documentation, but the Returns section partially compensates for this.

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

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 four parameters. The description's Args section restates the parameter names but doesn't add significant semantic value beyond what's in the schema. However, it does provide useful context about how 'question' parameters should be formulated with natural language queries.

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

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 '将自然语言描述转换为ARMS调用链查询语句' (converting natural language descriptions to ARMS trace query statements), which is a specific verb+resource combination. It clearly distinguishes this from sibling tools like 'sls_translate_natural_language_to_query' by focusing specifically on ARMS application trace queries rather than general SLS queries.

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

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

The '使用场景' section provides four explicit scenarios for when to use this tool, including querying trace information, analyzing performance problems, tracking specific request execution paths, and analyzing service call relationships. This gives clear guidance on appropriate usage contexts without needing to reference specific alternatives.

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

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

With no annotations provided, the description carries full behavioral disclosure burden. It effectively describes the search functionality, pagination behavior (page_size range 1-100, defaults), and return data structure. It could improve by mentioning authentication requirements or rate limits, but covers core behavioral aspects well.

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

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

The description is well-structured with clear sections (功能概述, 使用场景, etc.), but contains some redundancy. The Args/Returns section repeats information already covered in the 返回数据结构 section, and the 查询示例 section adds minimal practical value, making the description longer than necessary.

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

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

For a search tool with 4 parameters and no output schema, the description provides comprehensive context including purpose, usage scenarios, search constraints, pagination behavior, and detailed return data structure. The main gap is lack of authentication/rate limit information, but otherwise covers most essential aspects.

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

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

Schema description coverage is 100%, providing solid parameter documentation. The description adds some value by explaining app_name_query must be part of app name (not natural language) and providing region_id format examples ('cn-hangzhou'), but doesn't significantly enhance understanding beyond what the schema already documents.

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

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

The description clearly states the tool searches for ARMS applications by name and returns basic information including app name, PID, user ID, and type. It uses specific verbs ('搜索ARMS应用', '根据应用名称搜索') and distinguishes itself from sibling tools by focusing on ARMS applications rather than SLS operations or trace queries.

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

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

The description explicitly provides three usage scenarios: when needing to find apps by specific name, when needing PIDs for other ARMS operations, and when checking user-owned app lists. It also includes search condition guidance (app_name_query must be part of app name, not natural language) and pagination instructions.

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

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 effectively discloses behavioral traits: it describes the return data structure in detail ('返回数据结构' section), including keys like alias, sensitive, type, and json_keys. It also specifies that parameters '必须精确匹配' (must exact match) and provides query examples. However, it doesn't mention potential errors, rate limits, or authentication needs, which are gaps 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.

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

The description is structured with sections (功能概述, 使用场景, 返回数据结构, 查询示例, Args, Returns), which aids readability. However, it includes redundant elements: the Args and Returns sections largely repeat information from the schema and return structure description, and the query examples are somewhat verbose. While not overly long, it could be more front-loaded and efficient, with some sentences not earning their place fully.

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

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

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is fairly complete. It covers purpose, usage scenarios, return data structure, and parameter basics. The lack of output schema is mitigated by the detailed return structure explanation. However, it misses some contextual details like error handling or dependencies, which would enhance completeness 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.

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 with descriptions (e.g., 'must exact match, not fuzzy search'). The description adds minimal value beyond the schema: it repeats the exact match requirement in Chinese and lists parameters in the Args section without additional semantics. This meets the baseline of 3, as the schema does the heavy lifting, but the description doesn't compensate with extra insights like format examples or constraints.

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

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

The description clearly states the tool's purpose: '获取SLS日志库的结构信息' (Get SLS log store structure information) and elaborates with '获取指定SLS项目中日志库的索引信息和结构定义' (Get index information and structure definition of a specified SLS project's log store). It specifies the verb '获取' (get) and resource 'SLS日志库的结构信息' (SLS log store structure information). However, it doesn't explicitly differentiate from sibling tools like 'sls_list_logstores' or 'sls_execute_query', which reduces clarity slightly.

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

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

The description provides clear usage scenarios in a '使用场景' (Usage scenarios) section, listing four specific cases (e.g., '当需要了解日志库的字段结构时' - When needing to understand the field structure of a log store). It implicitly distinguishes from siblings by focusing on structure retrieval rather than listing or querying. However, it lacks explicit when-not-to-use guidance or named alternatives, such as contrasting with 'sls_execute_query' for actual data queries.

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

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 describes the tool's function (diagnosing failed queries) and output (diagnostic results with correctness, performance analysis, optimization suggestions), which is adequate for a read-only diagnostic tool. However, it lacks details about authentication requirements, rate limits, error handling, or response format specifics, leaving gaps in behavioral understanding.

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

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

The description is well-structured with clear sections (功能概述, 使用场景, 查询示例, Args), making it easy to scan. However, the query examples are somewhat redundant ('帮我诊断下 XXX 的日志查询语句' and '帮我分析下 XXX 的日志查询语句' are very similar), and the Args section could be more integrated with the functional explanation. Overall, it's appropriately sized but has minor inefficiencies.

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

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

For a diagnostic tool with 5 required parameters and no output schema, the description adequately covers purpose and usage but lacks details on output format, error cases, or dependencies. Without annotations, it should provide more behavioral context (e.g., what the diagnostic results look like, whether it modifies data). The absence of an output schema increases the need for description completeness, which is only partially met.

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

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

Schema description coverage is 100%, providing basic descriptions for all 5 parameters. The description lists parameters in an Args section but only repeats their names without adding meaningful semantics beyond the schema. It implies that 'error_message' is used for diagnosis and 'query' is the SLS statement to analyze, but this is already evident from parameter names and schema descriptions. The baseline score of 3 reflects adequate but minimal added value.

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

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

The description clearly states the tool's purpose: '诊断SLS查询语句' (diagnose SLS query statements) when they fail, generating diagnostic results including correctness, performance analysis, and optimization suggestions. It specifies the verb ('诊断' - diagnose) and resource ('SLS查询语句' - SLS query statements), distinguishing it from siblings like sls_execute_query (executes queries) and sls_translate_natural_language_to_query (translates natural language to queries).

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

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

The description explicitly states when to use this tool: '当 SLS 查询语句执行失败时' (when SLS query statements fail to execute) and provides specific usage scenarios like diagnosing query correctness or finding causes of SQL execution errors. It implicitly distinguishes from siblings by focusing on failure diagnosis rather than execution, translation, or listing operations.

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

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

With no annotations provided, the description carries full burden. It discloses that queries must use SLS syntax (not natural language), specifies required time range parameters, mentions error handling scenarios, and indicates results are returned as a list of log records. However, it doesn't cover important behavioral aspects like authentication requirements, rate limits, pagination behavior, or what happens with malformed queries beyond the specific error example.

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

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

The description is excessively long with redundant sections. The 'Args' and 'Returns' sections duplicate information that should be in the schema. The query examples are in natural language despite explicitly stating queries must use SLS syntax, creating confusion. The error handling section is overly specific to one sibling tool interaction. Much of this content could be streamlined or moved to structured documentation.

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

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

For a 7-parameter query execution tool with no annotations and no output schema, the description provides adequate functional coverage but lacks important operational context. It explains what the tool does and when to use it, but doesn't sufficiently cover error patterns beyond one example, performance characteristics, or result format details. The description compensates somewhat for the lack of structured metadata but leaves gaps in behavioral transparency.

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

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 7 parameters thoroughly. The description adds minimal value beyond the schema - it mentions time range requirements and provides an example limit value, but doesn't explain parameter interactions, constraints beyond what's in the schema, or the significance of region_id selection. The 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.

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

The description clearly states the tool 'executes SLS log queries' with specific resources (SLS project and log store) and mentions returning query results. It distinguishes from siblings like sls_describe_logstore and sls_translate_natural_language_to_query by focusing on query execution rather than metadata or translation. However, it doesn't explicitly contrast with sls_diagnose_query which might have overlapping functionality.

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

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

The '使用场景' section provides clear context for when to use this tool (querying logs with specific conditions, time ranges, events, or aggregations). It explicitly references sibling tools sls_describe_logstore and sls_translate_natural_language_to_query for prerequisite steps. However, it doesn't explicitly state when NOT to use this tool or provide clear alternatives among siblings like sls_diagnose_query.

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

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

With no annotations provided, the description carries full burden and does well by disclosing the return format (dictionary with current_time and current_timestamp fields), data formats (YYYY-MM-DD HH:MM:SS string and Unix timestamp in seconds), and context about SLS query usage. It doesn't mention performance characteristics or error conditions, but provides substantial 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.

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

The description is well-structured with clear sections (功能概述, 使用场景, 返回数据格式) and efficiently communicates essential information. While slightly verbose due to the section headers, every sentence adds value and the information is appropriately front-loaded with the core purpose first.

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

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

For a zero-parameter tool with no annotations and no output schema, the description provides complete context: clear purpose, specific usage scenarios, detailed return format with field descriptions and data types. This gives the agent everything needed to understand when and how to use this tool effectively.

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

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. The description correctly notes 'Args: ctx: MCP上下文' which acknowledges the context parameter, though this is standard for MCP tools. It adds no additional parameter semantics beyond what's implied by having no parameters.

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

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

The description clearly states the tool's purpose: '获取当前时间信息' (get current time information). It specifies the exact resource (timestamp and formatted time string) and distinguishes it from sibling tools like sls_execute_query or sls_describe_logstore by focusing solely on time retrieval rather than query execution or metadata inspection.

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

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

The '使用场景' (usage scenarios) section explicitly lists three specific situations when to use this tool: setting query end times, performing timestamp calculations, and using current time as a reference point for query time ranges. This provides clear guidance on when this tool is appropriate versus alternatives.

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

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: the tool lists log stores with fuzzy search capabilities, defaults to log store type if unspecified, supports pagination via limit (range 1-100), and distinguishes between log and metric stores. It doesn't mention rate limits, authentication needs, or error handling, but covers core operational traits well.

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

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

The description is well-structured with clear sections (功能概述, 使用场景, etc.), but it includes redundant information. The Args and Returns sections repeat what's in the schema, and the query examples add little practical value. While not overly verbose, some content doesn't earn its place, reducing efficiency.

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

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

For a tool with 6 parameters, no annotations, and no output schema, the description does a good job. It explains the tool's purpose, usage, and key behaviors, and the schema covers parameter details. The main gap is the lack of output format explanation beyond '日志库名称的字符串列表' (list of log store names), but given the tool's simplicity, this is sufficient.

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

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 minimal value beyond the schema: it mentions fuzzy search for log_store and clarifies is_metric_store usage in a dedicated section. However, it doesn't provide additional context like examples for region_id format or interactions between parameters. Baseline 3 is appropriate given the schema does most of the work.

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

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

The description clearly states the tool's purpose: '列出SLS项目中的日志库' (list log stores in SLS projects). It specifies the exact action (list) and resource (log stores), and distinguishes it from siblings like sls_describe_logstore (which describes a single log store) and sls_list_projects (which lists projects). The functional overview reinforces this with details about fuzzy search and default behavior.

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

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

The description provides explicit usage scenarios: finding if a specific log store exists, getting all available log stores, or searching by partial name. It also includes a dedicated section '是否指标库' (Is it a metric store) that explicitly guides when to set is_metric_store to True versus False, offering clear alternatives for different data types.

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

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

With no annotations provided, the description carries full burden. It discloses key behavioral traits: it's a read-only listing operation (implied by '列出'), supports fuzzy search ('模糊搜索'), has a default limit of 10 with range 1-100, and requires region_id. However, it doesn't mention rate limits, authentication needs, or pagination behavior, leaving some gaps 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.

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

The description is structured with clear sections (功能概述, 使用场景, etc.), but it's verbose with redundant information. For example, the '返回数据结构' section repeats what's in the Returns docstring, and the '查询示例' adds little operational value. Some sentences don't earn their place, making it less concise than ideal.

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

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 does a good job covering the tool's purpose, usage, parameters, and return format. It explains what the tool does, when to use it, and what data it returns. However, it lacks details on error handling, authentication, or rate limits, which would be helpful for a cloud service tool with no structured metadata.

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

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 well. The description adds minimal value beyond the schema: it reiterates that project_name_query supports fuzzy search and that region_id is required, but doesn't provide additional context like format examples beyond 'xx-xxx' or practical usage tips. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the specific verb ('列出' - list) and resource ('阿里云日志服务中的所有项目' - all projects in Alibaba Cloud Log Service). It distinguishes from siblings like sls_list_logstores (which lists logstores within projects) by focusing on projects rather than logstores, making the scope unambiguous.

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

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

The '使用场景' section explicitly provides three scenarios for when to use this tool: checking if a specific project exists, getting all SLS projects in a region, and searching by partial project name. It also mentions '如果不提供项目名称，则返回该区域的所有项目' (if no project name is provided, returns all projects in the region), clarifying the default behavior.

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

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

With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits. It explains: '生成的是查询语句，而非查询结果' (generates query statements, not query results), '需要对应的 log_store 已经设定了索引信息' (requires log_store to have index settings), '可能会导致查询失败' (may cause query failure), and '首次生成的查询可能不完全符合要求' (first generated query may not fully meet requirements). This covers limitations, prerequisites, and expected behavior beyond basic functionality.

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

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

The description is well-structured with clear sections (功能概述, 使用场景, 使用限制, 最佳实践, 查询示例, Args, Returns) and appropriately sized. While comprehensive, some sections like the detailed usage restrictions could be slightly more concise. Every sentence earns its place by providing valuable guidance, but there's minor room for tightening.

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

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

Given the tool's complexity (natural language to query translation with multiple parameters and behavioral constraints) and the absence of both annotations and output schema, the description provides complete context. It covers purpose, usage scenarios, limitations, best practices, examples, parameters, and return values. The description fully compensates for the lack of structured metadata.

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

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

Schema description coverage is 100%, so the baseline is 3 even though the description doesn't add parameter details beyond what's in the schema. The Args section in the description merely lists parameters (text, project, log_store, region_id) without providing additional semantic context beyond what the schema already documents with its descriptions. The description adds value through usage context but not parameter semantics.

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

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

The description clearly states the tool's purpose: '将自然语言转换为SLS查询语句' (translate natural language to SLS query statements). It specifies both the verb (convert/translate) and resource (natural language to SLS queries), and distinguishes it from sibling tools like sls_execute_query (which executes queries) and arms_generate_trace_query (for ARMS applications).

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

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 vs alternatives. It states: '当用户不熟悉SLS查询语法时' (when users are unfamiliar with SLS query syntax), '需要配合sls_execute_query工具使用' (needs to be used with sls_execute_query tool), and '如果查询涉及ARMS应用，应优先使用arms_generate_trace_query工具' (if the query involves ARMS applications, prioritize using arms_generate_trace_query tool). This clearly defines usage context and exclusions.

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