cls_describe_alarms

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

With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: it's a read operation (implied by '查询'), supports pagination (offset/limit with defaults and max limit), filtering options (name, topic_id, region), and default region behavior. It also hints at authentication context ('当前账号下') and mentions the response format. However, it doesn't cover rate limits, error conditions, or exact permission requirements.

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 a clear purpose statement followed by organized sections for parameters and return information. Every sentence adds value: the opening defines scope, parameter details are essential for understanding, and return info clarifies output. It could be slightly more front-loaded by moving key behavioral notes (e.g., pagination defaults) earlier, but overall it's efficient and informative.

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 (5 parameters, filtering, pagination), no annotations, but with an output schema (implied by '返回信息'), the description is quite complete. It covers purpose, usage context, parameter semantics, and output structure. The output schema existence means the description doesn't need to detail return values exhaustively. Minor gaps include lack of error handling or authentication specifics, but it's sufficient for effective use.

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 0%, so the description must fully compensate. It does this excellently by providing detailed parameter semantics in the '参数说明' section: explaining each parameter's purpose (e.g., offset for pagination, limit with max value, name for fuzzy matching), optionality, defaults, and practical usage notes (e.g., using cls_describe_topics if topic_id is unknown). This adds significant value beyond the bare schema.

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 as '查询告警策略列表' (query alarm policy list) and specifies it retrieves alarm policy information for the current account. It distinguishes from siblings like cls_describe_alarm_detail (detail view) and cls_describe_alarm_records (records) by focusing on listing policies with filtering capabilities. However, it doesn't explicitly contrast with all similar tools like cls_get_alarm_detail.

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 context for when to use this tool: to list alarm policies with pagination and filtering. It offers guidance on alternatives for related tasks, such as using cls_describe_topics to search by name if topic_id is uncertain, and cls_describe_regions to query available regions. However, it doesn't explicitly state when NOT to use it (e.g., vs. cls_describe_alarm_detail for detailed info).

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