Server Quality Checklist

Tool Scores

• aida_highlightB
  3.1/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. While '记录' implies persistence, the description does not clarify side effects, visibility of the recorded highlights, authentication requirements, or what happens upon successful execution.

  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 sentence with no redundant words. Information is front-loaded with the verb and resource, followed by illustrative examples that earn their place by clarifying scope.

  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 simple single-parameter tool with full schema coverage and no output schema, the description adequately covers the core use case. However, given the mutation-like nature (recording/creating entries) and lack of annotations, it omits important behavioral context that would help an agent understand the full impact of invocation.

  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 baseline is 3. The description provides examples of highlight content (performance improvements, architecture optimizations) which gives semantic context for the 'content' parameter, though this does not significantly exceed what the schema already documents.

  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 records (记录) highlights/highlights (亮点) and provides concrete examples (performance improvements, architecture optimizations) that distinguish it from sibling bug-tracking and logging tools. However, it lacks explicit differentiation text comparing it to alternatives like aida_log_review.

  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 explains what the tool does but provides no guidance on when to use it versus siblings (e.g., when to use aida_highlight vs aida_task_done or aida_log_review). There are no exclusions or prerequisites mentioned.

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

• aida_log_reviewB
  3.1/5.0
  Behavior2/5

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

  无任何annotations提供，描述需承担全部行为披露责任。但仅说明是'记录审查结果'，未说明是否幂等、是否影响任务状态、有无副作用或返回确认信息。对于写操作类工具，缺乏关键行为特征披露。

  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?

  两句话结构紧凑，首句说明触发时机，次句说明功能，无冗余信息。但鉴于兄弟工具众多且缺乏annotations，信息量略显不足，故未给满分。

  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?

  虽有100% schema覆盖率，但无output schema和annotations，且面对9个兄弟工具（其中4个同为log前缀工具），两句话的描述不足以支撑AI智能体在复杂工具生态中做出准确选择，缺乏对其在审计链路中定位的完整说明。

  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描述覆盖率达100%，参数含义已由schema充分定义（如issues'逗号分隔'等）。描述中的'审查结果'为参数提供了上下文语境，但未额外补充schema未涵盖的语法细节或示例，符合高schema覆盖率下的基准分。

  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?

  描述明确使用动词'记录'和资源'审查结果'，并限定触发场景为'完成一轮代码审查后'。但面对多个同类logging兄弟工具（log_bug, log_deviation等）时，未明确说明与它们的甄别标准（如是记录整体评审结论而非具体缺陷）。

  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?

  明确指触发时机'当你完成一轮代码审查后调用'，但未提供何时不应使用（如不应替代log_bug记录单个缺陷），也未说明与task_done或log_bug等工具的协作或互斥关系。

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

• aida_log_bugB
  3.2/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. Only states '记录' (records) without disclosing persistence mechanism, visibility, notifications generated, or return value. Missing behavioral traits like idempotency or confirmation.

  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?

  Two concise sentences, front-loaded with trigger condition. No redundant words. Could potentially combine into one sentence but structure is efficient and scannable.

  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?

  With no output schema and no annotations, a logging tool should ideally disclose what happens after invocation (e.g., ticket creation, notifications). Description covers minimal 'when' and 'what' but omits 'what happens next' and sibling relationships expected for a 3-param tool with side effects.

  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% with complete Chinese documentation for each parameter. Description provides only generic '记录 bug 信息' without adding syntax guidance, validation rules, or usage tips beyond what schema already specifies. Baseline 3 appropriate.

  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?

  States specific trigger ('在开发或测试中发现 bug 时') and action ('记录 bug 信息'). Clear verb+resource. Loses one point because it doesn't differentiate from sibling 'aida_bug_fix' (logging vs fixing) or distinguish from other 'aida_log_*' tools.

  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?

  Provides implied usage context ('当...发现 bug 时调用') covering when to use. However, lacks explicit guidance on when NOT to use (e.g., vs aida_log_deviation) or workflow relationship to aida_bug_fix.

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

• aida_bug_fixB
  3.3/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. States the marking action but fails to disclose mutation side effects, reversibility, state transitions, or whether this triggers notifications. For a state-change tool, behavioral details are insufficient.

  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?

  Two sentences with zero waste. Front-loaded with the trigger condition ('当你修复了一个 bug 后调用'), followed immediately by the effect. Appropriate length for the tool's scope.

  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?

  Adequate for a simple 2-parameter state-update tool with no output schema. Covers the essential trigger and action, though omitting operational details (e.g., whether this archives the bug, updates timestamps, or interacts with aida_status).

  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%, establishing baseline 3. The phrase 'after you have fixed a bug' adds context that the 'fix' parameter should describe the completed solution, but no additional semantic guidance (format constraints, example values) is provided beyond the schema.

  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 (标记/mark as fixed) and resource (bug), and specifies the trigger condition ('after you have fixed a bug'). It implicitly distinguishes from sibling aida_log_bug through the post-fix timing versus logging, though it could explicitly contrast with bug creation tools.

  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?

  Provides clear timing guidance ('when you have fixed a bug'), indicating the workflow state for invocation. However, lacks explicit guidance on when NOT to use (e.g., vs. aida_task_done for tasks) or alternatives for unverified fixes.

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

• aida_log_deviationB
  3.4/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 disclosure burden. It mentions the persistence aspect ('记录') and a specific behavioral side effect ('应询问用户是否沉淀为规则'), which adds context. However, it omits other behavioral traits like return values, idempotency, or failure modes that agents need for mutation/logging tools.

  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 three-sentence structure is efficient and front-loaded: trigger condition first, purpose second, and conditional workflow third. Each sentence earns its place. The Chinese phrasing is professional and compact, though a slightly more structured format (e.g., bullet points for the conditional logic) could improve scanning.

  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 this is a logging tool with no output schema, the description adequately covers the logging intent, categorization parameters, and the specific rule-missing workflow. However, it lacks information about return confirmation, error handling, or how logged deviations are subsequently accessed (e.g., via aida_log_review or similar), which would complete the usage 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?

  With 100% schema description coverage, the baseline is 3. The description adds valuable semantic context for 'rootCause' by explaining the specific workflow when this value is 'rule-missing', helping agents understand how to populate this enum. It does not add significant details for 'title' or 'category' beyond the schema.

  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 trigger condition ('当 AI 产出与用户预期不符时调用'), the action ('记录偏差'), and the purpose ('用于后续分析'). It partially distinguishes from siblings by specifying the deviation scenario and referencing the rule precipitation workflow (connecting to aida_log_rule), though it could explicitly contrast with aida_log_bug.

  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?

  It provides specific guidance for the 'rootCause' enum value ('当 rootCause 为 rule-missing 时...') and a follow-up workflow, but lacks explicit 'when-not-to-use' guidance or clear distinction from sibling logging tools like aida_log_bug. The alternative action (asking about rule creation) is described rather than alternative tool selection.

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

• aida_statusA
  3.7/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 implies read-only behavior through '查看' (view) and lists retrieved data categories, but does not explicitly disclose side effects, idempotency, caching behavior, or return format structure that would help an agent understand the full behavioral contract.

  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 consists of two highly efficient sentences. The first sentence front-loads the action and scope, while the second provides usage context. There is no redundant or filler text; every word earns its place.

  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 simplicity (no input parameters) and the lack of an output schema, the description appropriately lists the key data components (tasks, bugs, progress) that constitute 'status'. It could be improved by hinting at the return structure or format, but it adequately covers the essential information needed for tool selection.

  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 zero parameters, which per evaluation rules establishes a baseline of 4. The description does not need to compensate for schema gaps since there are no parameters to document.

  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 uses the specific verb '查看' (view/check) and clearly identifies the resource as 'development operation status'. It enumerates specific data components returned (task list, bug count, progress), which implicitly maps to the sibling tools (task_*, bug_*) and clarifies this is a reporting tool rather than an action tool.

  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 an explicit when-to-use condition: '在需要了解当前进度时调用' (call when needing to understand current progress). However, it lacks guidance on when NOT to use this (e.g., when to use specific query tools instead) and does not mention alternatives among the siblings.

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

• aida_task_doneA
  4/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 disclosure. It successfully communicates one key behavioral trait—the automatic calculation of time consumed ('自动计算耗时')—but omits other critical mutation details such as reversibility (can a task be un-marked?), side effects, error conditions, or the nature of the return value.

  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 consists of two highly efficient sentences: the first establishes the trigger condition, and the second lists the dual effects (marking completion and time calculation). There is zero redundancy or filler, with critical information front-loaded.

  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 simplicity (single string parameter, no nested objects, 100% schema coverage) and the absence of an output schema, the description adequately covers the essential invocation context and primary effect. It lacks safety annotations (destructive/reversible hints) which would be expected for a state-transition mutation, but remains sufficient for agent selection given the clear lifecycle positioning.

  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 coverage, the input schema fully documents the taskId parameter including examples and cross-references to aida_status. The main description does not add parameter-specific semantics beyond what the schema already provides, warranting the baseline score of 3.

  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 action (mark task completed) and trigger condition (after finishing a task), with a distinct behavioral detail (automatic time calculation). It implicitly contrasts with sibling aida_task_start through the temporal marker '完成后' (after completion), clearly positioning it in the task lifecycle.

  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 explicit temporal guidance on when to invoke ('当你完成一个任务后调用' / call after completing a task). However, it does not explicitly reference sibling alternatives like aida_task_start for initiation or caution against using this for starting tasks, nor does it mention the aida_status reference found in the parameter schema.

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

• aida_log_filesA
  4.4/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 successfully explains the automatic git diff scanning mechanism and zero-parameter design, but lacks details on data persistence, output format, or whether the recording operation has side effects on the repository.

  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?

  Three sentences with zero waste: first states purpose, second explains mechanism and parameters, third specifies invocation timing. Information is front-loaded and appropriately sized for the tool's simplicity.

  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 zero-parameter tool without output schema, the description adequately covers purpose, invocation context, and data source. It omits output format details, but this is acceptable given the lack of output schema and the tool's straightforward logging nature.

  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?

  With zero parameters, the baseline score is 4. The description appropriately confirms no arguments are required ('无需传参') and does not need to compensate for missing schema documentation.

  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 uses a specific verb ('记录'/record) with a clear resource ('文件变更'/file changes) and distinguishes itself from siblings by specifying the unique mechanism ('自动扫描 git diff'/automatically scans git diff) rather than logging bugs, reviews, or rules like the other aida_log_* 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?

  Provides explicit temporal guidance on when to invoke: '在完成一轮代码修改后调用' (Call after completing a round of code modifications). It also clarifies the zero-parameter requirement ('无需传参'), eliminating confusion about whether arguments are needed.

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

• aida_log_ruleA
  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 behavioral burden. It discloses the user-consent requirement and clearly defines scope boundaries (allowed categories vs prohibited business logic). It implies this is a persistent write operation but omits failure modes or idempotency details.

  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?

  Single complex sentence that efficiently packs purpose, condition, scope, and restrictions without redundancy. Information is front-loaded with the action (沉淀项目规则). Minor improvement possible by breaking into two sentences for readability.

  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?

  Appropriate for a 3-parameter logging tool with no output schema. The description sufficiently covers domain-specific logic (technical vs business rules) and prerequisites (user consent). Could mention whether rule deposition is idempotent or what confirms success.

  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?

  Schema coverage is 100% (baseline 3). The description adds semantic value by mapping the category enum values to concrete examples (公共组件使用规范→component, API调用规范→api, 代码风格/架构规范→style/architecture) and contextualizing sourceDeviation as linking to specific deviation IDs.

  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 uses a specific verb (沉淀/deposit) with a specific resource (项目规则/project rules). It clearly distinguishes from sibling tools like aida_log_bug and aida_log_deviation by specifying this is specifically for rule-missing root causes and technical specifications.

  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?

  Provides explicit triggering conditions (当偏差的 rootCause 为 rule-missing), scope restrictions (项目级技术规范 vs 业务逻辑), and clear prohibitions (禁止沉淀业务逻辑). It also notes the consent requirement (询问用户同意后), establishing a critical workflow constraint.

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

• aida_task_startA
  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. It successfully discloses the workflow context ('数据采集流程' - data collection process) and lifecycle implications, but lacks explicit detail about return values, idempotency, or specific side effects (e.g., whether it creates a persistent record).

  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?

  Four sentences with zero waste: (1) purpose definition, (2) timing context, (3) workflow sequence, (4) subtask rule. Logical front-loaded structure moves from general use to specific sequencing constraints.

  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 workflow complexity and sibling tool ecosystem, the description successfully explains the complete task lifecycle, integration with logging tools, and subtask protocols. No output schema exists, and none is required given the schema coverage.

  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 coverage is 100% with both 'title' and 'stage' fully documented in the schema including examples. The description adds no parameter details, which is acceptable when the schema is self-documenting, warranting the baseline score of 3.

  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 '开始一个新任务' (starts a new task) with specific verb+resource, and distinguishes from siblings by positioning it as step 1 of a 5-step workflow (contrasting with aida_task_done at step 5 and the aida_log_* middle steps).

  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?

  Provides explicit temporal guidance ('在接到用户需求、开始编码前调用' - call after requirements, before coding), sequences the full workflow with numbered steps, and specifies subtask handling rules ('多个子任务必须每个都单独 start/done'), clearly delineating when to use vs. alternatives.

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