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

Beyond the destructiveHint annotation, the description discloses essential behavioral safeguards: the agent must verify the candidate digest against the approval note, automatic rework calls are prohibited, and the host must implement real approval controls. These are non-obvious operational constraints that materially affect correct use.

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 three short, purposeful sentences with no filler. The most critical constraint—explicit human approval—is front-loaded, followed by verification requirements and the host-level enforcement note.

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 presence of an output schema and annotations, the description covers the main behavioral and safety requirements needed to invoke the tool correctly. It is slightly thin on what the approval actually changes in the system's state, but this is largely inferable and covered by schema structure.

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 compensate. It adds meaning by tying the expectedDigest to the approvalNote and requiring verification between them, but it leaves candidateId and optional taskId semantically unexplained and relies on schema names and formats for the rest.

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 uses a specific verb ('approve') and resource ('visual baseline') and adds an unmistakable precondition: approval is only valid after explicit human review and authorization. This clearly differentiates it from sibling tools like prepare_visual_baseline, verify_task, and rework_task.

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 the tool may be invoked (after user review and authorization) and when it may not be invoked (automatic rework), and it requires the host to enforce actual approval control. It does not name a specific sibling alternative, but the prohibition provides strong routing guidance.

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?

Beyond the destructiveHint annotation, the description details exact mechanisms (CLI process-tree termination, GUI button-click with bounded timeout, explicit indication if stop is unconfirmed) and state-dependent outcomes. This adds significant value beyond the annotation.

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?

A single well-structured sentence front-loads the core action, then details state-dependent behavior. No wasted words; all sentences earn their place.

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 output schema exists (so return values are covered), the description adequately explains the tool's behavior for all task states. It could mention the reason parameter's purpose, but that's minor given the simple tool and existing output schema.

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 coverage, the description must compensate for parameters. It never mentions taskId (obviously the target) or reason (optional). The description focuses on behavior but provides no direct guidance on parameter usage or 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 cancels running tasks, and differentiates behavior for CLI vs GUI agents, plus queued and terminal states. It uses a specific verb ('取消'/cancel) and resource ('任务'/task), making it distinct from siblings like continue_task or run_task.

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?

It explains behavior across task states (running, queued, terminal), implying when to use it (for running/queued) and when it does nothing (terminal). It doesn't explicitly name alternatives, but the purpose is unambiguous and no misleading guidance is present.

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?

The description goes well beyond the sparse annotations, explaining exactly what happens to the message parameter in different scenarios, including cases where no message is sent at all. It also discloses side effects like reconnecting to observe GUI and rechecking the environment, which is valuable 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 compact and front-loads the core purpose, then branches by runtime mode with semicolon-separated cases. Every clause adds behavioral information, with no filler or repetition.

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, the description covers the major user-facing states and runtime modes with specific message behavior for each. The output schema exists, so return-value documentation is not required here. The main workflow conditions needed to invoke the tool correctly are all present.

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 compensate. It does clarify the nuanced behavior of the message parameter across zcode and codex states, which is the critical semantic ambiguity. taskId is less explicitly described, but its meaning is reasonably inferable from the tool's purpose.

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?

States a specific verb and resource: resumes tasks in the needs_user state. It further distinguishes behavior across zcode and codex modes and specific sub-states, making it clearly distinct from siblings like run_task or cancel_task.

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 clearly scopes usage to tasks in needs_user state and provides situational branches for when each behavior applies. It does not explicitly name alternatives or exclusions, but the context is specific enough that an agent can infer when to call this tool versus run_task.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, setting the safety profile. The description adds value by revealing that results may include placeholder prompts for uninstalled/research items, giving the agent insight into the content of the output. It does not contradict 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?

A single, tightly worded sentence that front-loads the purpose and immediately communicates the scope. No filler or unnecessary detail. Every word contributes to understanding the tool.

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 simplicity of the tool (no parameters, read-only, output schema exists), the description is fully sufficient. It clearly states what the tool does and what kind of results to expect. No additional details are needed for correct invocation.

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 zero parameters and an empty schema. Per the baseline rule for 0 parameters, the score is 4. The description adds no parameter information, which is appropriate since no parameters exist.

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 a specific verb ('查看/view') and resource ('当前 agent 适配与可执行探测结果' - current agent adaptation and executable probing results), and also notes placeholder hints. It distinguishes itself from siblings, which are all task-related (run_task, query_task, etc.), by focusing on profiling results rather than task execution.

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 implies usage: if you want to view agent adaptation and probing results, call this tool. However, it provides no explicit when/when-not guidance or mention of alternative tools. Since siblings are fundamentally different, no exclusion is needed, but the lack of explicit context leaves this at an implied level.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only profile is covered by structured data. The description adds useful context beyond that: the report is fetched from report.md and round defaults to the latest. It does not describe pagination, error behavior, or report length, but for a simple read tool this is adequate.

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?

A single, dense sentence that front-loads the core action (fetch full report) and then the parameter default. Zero wasted words, and the most important behavioral nuance (round default) is placed second, right after the verb.

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 simple read-only tool with an output schema and readOnlyHint annotations, the description covers the essentials: what is fetched, which file, and the round default. No missing critical information prevents correct invocation; taskId's role is inferable from context.

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 carry parameter meaning. It does clarify that round is optional and defaults to the latest round, and that the result is the full text of report.md. However, taskId's semantics are only implied by the tool name and are not explicitly described, so compensation is partial.

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?

Description states a specific verb (取/get), a specific resource (验收报告全文/report.md), and the round-scoping behavior. This clearly distinguishes it from sibling tools like query_task or list_tasks, which are about task state rather than report file content.

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 gives a clear usage rule: round defaults to the latest round when omitted. However, it does not explicitly state when to use this tool instead of siblings such as query_task or verify_task, nor does it mention any exclusion conditions.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about the 'historical' scope and the default limit of 50, but does not describe return format or pagination behavior. This is comparable to the calibration example where a filtered-list tool with read-only annotations earned a 3.

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?

One concise sentence delivers the verb, resource, scope, filter options, and default limit. Every element earns its place and the key action is front-loaded.

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 simple read-only listing tool with three optional parameters and an output schema, the description covers all functional essentials: what the tool lists, how to filter, and the default limit. Annotations cover safety and the output schema covers return values, so nothing an agent needs to call it correctly is missing.

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 carries the burden of explaining parameters. It does name projectPath and status as filter dimensions and adds the default limit of 50, which the schema does not specify. However, it does not clarify valid status values, projectPath format, or the limit maximum, so the compensation is partial.

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 states a clear verb and resource: '列出历史任务' (list historical tasks). It also mentions the key filtering dimensions, making the core purpose unambiguous. It does not explicitly differentiate from sibling tools such as query_task, so it stops short of a 5.

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 implies when to use the tool (to list historical tasks with optional filters) but provides no explicit guidance on when not to use it or which sibling tool might be a better alternative. The usage context is clear but there are no exclusions.

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 annotations readOnlyHint=false and destructiveHint=false, the safety profile is partially conveyed Equipment. The description adds useful behavioral context: it requires user authorization, returns a summary and preview, and does not commit to a formal baseline. This exceeds what annotations provide.

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?

Two short sentences with no filler. The primary action and the most important outcome (summary/preview) are front-loaded. It relies on the reader already knowing the tool's context, but the length is appropriate.

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?

The output schema presumably covers the return structure, but the input schema has no descriptions and the description doesn't explain the parameters. No usage scenarios, exclusions, or ordering with sibling tools are provided. For a 4-parameter tool with meaningful semantics, this is incomplete.

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%, and the description mentions no parameter names or roles. projectPath, caseIds, imports, and viewportIds are completely undocumented in both schema and description, so an agent has no guidance on what values to provide.

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 states a specific verb ('prepare') and a specific resource ('visual baseline candidate'), and clarifies it returns a summary and preview. The phrase 'does not adopt a formal baseline' distinguishes it from formal approval tools like approve_visual_baseline without naming them.

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?

No explicit when-to-use or when-not-to-use guidance is given. The statement that it does not adopt a formal baseline implies it is a preparatory step before approval, but the description never says to use it before approve_visual_baseline or before other editing tools. Sibling differentiation is left entirely to the agent.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile, and the description is consistent with those (a query operation). It adds value beyond annotations by specifying the default log tail behavior (last 40 lines) and the two-part return shape (meta + log snippet). No contradiction with the 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?

A single, front-loaded sentence conveys purpose, default behavior, and return content with zero filler. Every clause earns its place, and the most important information (status/progress/log tail) appears 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?

The presence of an output schema covers the return values, so the description needn't detail them. For a moderate 2-parameter read tool, it covers purpose, default behavior, and return content adequately. The only gap is the lack of explicit guidance on when to choose this over get_task_report/verify_task, which is minor given the clarity of the read-only purpose.

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 bears the compensation burden. It explains tailLines behavior implicitly via the 'default last 40 lines' note, which clarifies the default when tailLines is omitted. taskId is not described but is self-evident from its name. The description partially compensates for the coverage gap but doesn't fully document parameter syntax 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 a specific verb ('查询'/query), the resource (task), and the precise scope: status, progress, and recent log tail with a stated default of the last 40 lines of agent.log. It also names the return content (task meta and log snippet), which distinguishes it from siblings like run_task (execution), cancel_task (cancellation), and list_tasks (listing). It doesn't explicitly name a sibling alternative, but the purpose is 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?

Usage context is implied — an agent would infer this tool is for checking task state/progress/logs — but there is no explicit when-to-use vs. when-not guidance and no named alternatives or exclusions. The description leaves sibling differentiation (e.g., vs. get_task_report or verify_task) to the agent's inference rather than stating it.

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?

注释已提供 destructiveHint=true 和 readOnlyHint=false，描述未与之矛盾。描述补充了'同一 agent/项目与轮次记账'以及 feedback 的追加指示语义，这些是注释之外的有用信息。但未说明具体副作用（如是否会覆盖原有结果），对破坏性工具而言透明度中等。

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?

描述为单句，信息密度高，无冗余内容。虽然未使用分段或强调结构，但精炼且关键信息（状态限制、行为、反馈用途）均在前半句呈现，符合高效表达。

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?

工具简单（2个参数），且有输出 schema（未提供内容）。描述覆盖了核心操作和反馈语义，但未提及返回内容、可能的错误条件或前置条件（如是否需要先验收）。由于存在破坏性注释，缺少关于执行后影响的说明，完整性略逊。

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 描述覆盖率为 0%，描述需承担全部参数解释责任。描述明确解释了 feedback 作为'追加指示'并建议携带验收失败摘要，这对该参数提供了有用语义；但 taskId 仅从'终态任务'中隐含，未直接说明其标识作用，且未给出任何格式或示例。补偿不充分。

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?

描述以明确的动词'返修'指出了操作，并限定了资源（终态任务 failed/needs_attention）和行为（重新入队续跑），能够与兄弟工具如 run_task（启动新任务）和 continue_task（可能继续非终态任务）大致区分。但未显式提及与这些工具的差异，因此扣一分。

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?

描述隐含了使用条件（当任务处于 failed 或 needs_attention 终态时），但未明确说明何时不应使用此工具，也未提及替代方案（如 verify_task 或 cancel_task）。使用情境可从状态限制推断，但缺少显式的 when-not 指导。

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 readOnlyHint=false and openWorldHint=true already signaling a mutating external operation, the description adds valuable behavior: asynchronous execution returning taskId, automatic verify/rework capability, and pre-send validation of ZCode path references in task/context. No contradiction with annotations exists.

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 compact and front-loaded: the core function and async result appear first, followed by platform-specific parameter rules and a validation note. Every sentence adds information without redundancy.

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 13 parameters and 0% schema-level explanations, this description is not complete enough. The output schema helps with return values, but the agent still lacks semantic guidance on most parameters required to configure a task correctly.

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% and there are 13 parameters, but the description only clarifies model, mode, and path-reference validation in task/context. It does not explain agentId, planDoc, autoVerify, autoFixRounds, taskTimeoutMs, reasoningLevel, designSystem, projectPath, or allowCreateProject, leaving the agent to guess for the majority of inputs.

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 names a concrete action ('启动外部 AI-Agent 开发任务') and a distinctive outcome ('异步返回 taskId'), going well beyond the bare title. This clearly separates a launch/dispatch operation from sibling tools like continue_task, query_task, or rework_task.

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?

Usage is implied by the core phrasing '派活' and '启动外部 AI-Agent 开发任务', but the description does not explicitly state when to choose run_task over a sibling such as continue_task or rework_task. The platform-specific model/mode rules are useful configuration guidance but are not tool-selection guidance.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavior beyond that: it explicitly says source code is not modified, checks are run against a git baseline, and extraChecks are temporary. No contradiction with annotations is present.

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 compact and front-loaded: purpose first, non-mutation note second, method and custom-check capability after. Every clause adds information, and there is no filler.

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?

Together with the output schema and readOnly/destructive annotations, the description is mostly sufficient for an agent to invoke the tool correctly: it knows the target, the non-mutating scope, the git-baseline context, and the task/project selection rule. The missing checksMode explanation and lack of explicit sibling routing keep it from being fully complete.

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 carries the burden. It usefully explains that taskId/projectPath are a one-of requirement, that extraChecks are temporary additions, and that analysis is relative to a git baseline. The main gap is checksMode, whose append/replace semantics are left unexplained.

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 states a specific action ('executes acceptance/verification'), a specific target ('completed task or project path'), and a concrete method ('automatic command checks + code analysis relative to git baseline'). This clearly distinguishes verify_task from siblings like run_task, continue_task, or query_task, even without naming them.

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 gives a clear use context: verify completed tasks or project paths, and requires exactly one of task/project. It does not explicitly name alternative tools or state when not to use it, but the '已完成' constraint and the verification framing are enough for an agent to select it appropriately.

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