cls_describe_data_transform_tasks

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

With no annotations provided, the description carries full burden. It describes what the tool returns (task list with IDs, names, statuses, source/destination topics, processing statements, creation times) and mentions pagination behavior through offset/limit parameters. However, it doesn't disclose important behavioral traits like whether this is a read-only operation (implied but not stated), rate limits, authentication requirements, or error conditions. The description adds useful context about what 'data processing' means but lacks comprehensive behavioral disclosure.

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: purpose statement, parameter explanations, and return information. Each sentence earns its place by providing necessary information. The front-loaded purpose statement is clear, though the Chinese formatting with markdown headers might be slightly less accessible than plain text. It's appropriately sized for a tool with 5 parameters and detailed return expectations.

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 (5 parameters, no annotations, but has output schema), the description provides good coverage. It explains all parameters thoroughly, describes what the tool returns, and provides context about data processing. The existence of an output schema means the description doesn't need to exhaustively document return values. However, it could better address when to use this versus similar tools and provide more behavioral context given the lack of 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?

With 0% schema description coverage (titles only provide parameter names without meaning), the description fully compensates by explaining all 5 parameters in detail. It provides: 1) offset as pagination offset with default 0, 2) limit as items per page with default 20, 3) task_name as optional filter by task name, 4) topic_id as optional filter by source log topic ID with guidance on how to find IDs, 5) region as optional region parameter with examples and guidance on how to query available regions. 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: '查询数据加工任务列表' (query data processing task list) with specific context about what data processing entails ('数据加工用于对日志数据进行清洗、转换、分发等处理' - data processing is used for cleaning, transforming, and distributing log data). It distinguishes itself from siblings like cls_describe_topics by focusing specifically on data transform tasks rather than general topics or other resources.

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 certain parameters (e.g., '如不确定 ID，可先通过 cls_describe_topics 按名称搜索' - if unsure about ID, first search by name using cls_describe_topics; '可通过 cls_describe_regions 查询所有可用地域' - can query all available regions using cls_describe_regions). However, it doesn't explicitly state when to use this tool versus alternatives like cls_describe_scheduled_sql_tasks or other describe_* siblings, missing explicit comparison guidance.

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