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. It does add useful behavioral context by saying the tool records immediately and does not wait for a quiet period. However, it does not disclose effects on existing state, prerequisites, or any failure/side-effect behavior beyond that.

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 a single, purposeful sentence with no filler. It front-loads the core behavior and then adds the key timing nuance, making it 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.

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

Given the low parameter count, full schema coverage, and presence of an output schema, the description is mostly sufficient. However, the many sibling tools (tc_init, tc_save, tc_show, etc.) create a need for more workflow context, and the description does not explain how capture fits in or what happens after capture.

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%, with the single parameter 'root' already described as '工作区根目录' (workspace root directory). The description adds no additional meaning to the parameter, but the baseline of 3 applies because the schema already fully documents it.

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 action and resource: '立即记录当前文件变化' (immediately record current file changes). It also distinguishes the tool's behavior with '不等静默期' (not waiting for quiet period), but it does not explicitly differentiate it from the sibling tools like tc_save or tc_init.

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 phrase '不等静默期' implies this tool should be used when an immediate capture is needed rather than waiting for a quiet period. However, there is no explicit guidance on when to prefer this tool over alternatives such as tc_save, nor any exclusions or 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?

With no annotations provided, the description carries the full burden and does well: it discloses destructive behavior (deleting layers), irreversibility (cannot restore), and a safety guarantee (step baseline unaffected). This is strong for a delete operation, though it could further mention any locking or concurrent effects.

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 front-load the core purpose, then add key consequences. No filler or redundancy — every clause earns its 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?

For a destructive tool with 4 parameters, the description covers purpose, effect, and non-target impact; the schema handles parameters and output schema exists for return details. It does not explain the default values or parameter interactions, but those are already in the schema, so the overall context 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 parameters are already well documented. The description adds minimal parameter-specific value beyond the schema, only aligning 'retention period' with keep_seconds. Baseline 3 is appropriate.

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 'reclaim archive space' and 'delete change layers older than retention period' — a specific verb and resource. It also differentiates from the sibling tc_restore by explicitly noting that recycled layers cannot be restored, making it clear this is the pruning counterpart.

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 context (when you need to reclaim archive space) and mentions the retention period, but does not explicitly state when to use this tool vs alternatives such as tc_save or tc_clean. It names restore only as a consequence, not as a decision point.

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 does add a meaningful behavioral constraint: '敏感文件内容不会导出' (sensitive file contents will not be exported), and it implies the destination must already exist. However, it does not disclose overwrite behavior, failure modes, or what happens if the directory does not exist.

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 two short sentences with no wasted words. The primary action is stated first, and the sensitive-content caveat is a valuable second sentence that earns its 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?

The tool has an output schema, so return values need not be described. However, for an export operation with no annotations, the description omits important context such as whether files are overwritten, whether the directory must be empty, and how this relates to sibling tools like tc_compress. It is adequate but not 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 100%, so the schema already documents both parameters. The description adds no new parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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 verb '导出' (export), the resource '交接包' (handover package), and the destination '已存在的目录' (existing directory). It is specific enough to understand the tool's core function, but it does not explicitly differentiate itself from siblings like tc_save or tc_capture.

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 guidance is given about when to use this tool versus alternatives such as tc_capture, tc_save, or tc_compress. The description only states what the tool does, not under what circumstances it should be chosen.

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, the description must carry the behavioral burden. It discloses a key side effect: existing active tasks are suspended rather than closed. This adds value beyond the name. However, it does not cover other traits like idempotency, failure modes, or whether the operation is destructive beyond the suspension note. The disclosure is partial but meaningful.

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, front-loaded with the core purpose and immediately followed by the key behavioral caveat. No wasted words or redundant details.

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 that the schema fully documents parameters and an output schema exists, the description covers the essential behavioral context (creation and suspension of active tasks). It does not explain relationships to sibling tools, but that is not strictly required for invocation. The description is sufficiently complete for a create operation.

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 every parameter already has a description in the input schema. The tool description does not add any parameter-specific meaning. Per the baseline rule for high coverage, a 3 is appropriate.

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 '创建任务' (create task), a specific verb and resource, and the additional sentence about suspending active tasks distinguishes it from sibling tools like tc_capture, tc_switch, etc. which imply other operations. The purpose is unambiguous and clearly differentiated.

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 that this tool is for creating a task and discloses a relevant condition (active tasks will be suspended). However, it does not explicitly name alternatives or state when not to use it, so it stops short of full guidance. The behavioral note gives useful context for invocation.

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, the description carries the behavioral burden. It usefully discloses the preview mode ('apply=false 只预览') and implies apply=true writes the workspace. However, it does not describe what gets modified, overwritten, or whether the action is reversible, which is notable for a restore/mutation tool.

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 states the core action first, then the two most important usage constraints. Every piece of information earns its place with zero 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?

The description adequately covers the internal logic of the tool (how to select a target and preview vs apply), and an output schema exists. However, it lacks guidance on tool selection among siblings and does not disclose the side effects of apply=true, leaving an agent to infer the restore behavior's full impact.

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. The description adds meaning beyond the schema by stating that index and drift_id are mutually exclusive and that apply=false means preview only—constraints and behavioral semantics not present in the individual parameter descriptions.

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 '恢复' (restore) and resource (task-layer/change-layer), and explains the two identifier modes (index vs drift_id). It is clear and unambiguous, though it does not explicitly differentiate from siblings like tc_resume or tc_switch.

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 guidance is given on when to use this tool versus sibling tools such as tc_resume, tc_switch, or tc_export. The description only provides internal usage constraints (choose index or drift_id, apply=false for preview), 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states '只读' (read-only), clearly indicating the tool has no mutating side effects. It also enumerates what is returned. It does not cover edge cases such as a missing active task, but for a read-only status query this is largely sufficient.

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 a single, front-loaded sentence with no redundancy. It leads with the read-only safety property and then lists the returned items compactly. Every word earns its 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?

The tool is simple and has an output schema alongside fully described parameters, so the description does not need to explain the return format. However, it omits when to use this tool and uses domain-specific terms like '未落档路径' without clarification, leaving some ambiguity for correct selection and 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?

Schema description coverage is 100%, so the schema already documents both root and task_id. The description adds no parameter-level detail beyond the schema; it only describes the overall operation, so the baseline score of 3 applies.

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 concrete action: read-only return of four specific state items (target, current step, un-archived path, next step). This is a specific verb-plus-resource statement, not a tautology. However, it does not differentiate from sibling tools such as tc_show, which may also return state.

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 no guidance on when to use tc_resume versus alternatives like tc_show or tc_capture, and no exclusions or prerequisites are mentioned. Correct usage must be inferred from the tool name and the listed fields, which is not explicit.

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 behavioral disclosure burden. It does disclose a meaningful behavioral trait: close=true closes the task and rejects further saves. However, for a save/mutation tool with zero annotations, it doesn't mention persistence semantics, error behavior, or what happens on overwrite, leaving significant gaps.

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, front-loaded sentences with zero filler. The primary action is stated first, followed by the important close behavior. Appropriately sized for the tool's role, though it could be slightly more informative without becoming verbose.

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?

With 10 parameters, 70% schema coverage, and an output schema present, the description is thin. It captures the core purpose and the close semantics but omits context around the step-save workflow (e.g., what constitutes a valid step, interaction with active task selection) that would help an agent invoke it correctly. The output schema reduces the return-format burden, but the overall guidance is minimal.

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 coverage is 70% with 10 parameters. The description adds value by clarifying the close parameter's behavioral effect (closes task, no further saves), which goes beyond the bare boolean schema type. However, it doesn't address the undocumented parameters (verified, open_questions, paths constraint) beyond what the schema's descriptions 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 action ('保存一个任务层步骤' – save a task-layer step) with a clear verb and resource. It is distinguishable from siblings like tc_capture, tc_init, and tc_switch, though it doesn't explicitly name any alternative. The close=true semantic adds useful context to the purpose.

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 no guidance on when to use this tool versus its siblings (tc_capture, tc_restore, tc_compress, etc.). The only behavioral note is the close=true behavior, which is a parameter effect rather than usage guidance. An agent gets no direction on choosing this tool over 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, the description must carry the burden of behavioral disclosure. It mentions the effect of include_drift and that index views a single step, but it doesn't describe return value structure, pagination behavior, or side effects (none expected). It covers some behavior but is incomplete given the absence of 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 two short sentences, front-loading the main purpose and then adding a key option. Every word contributes, with no wasted text.

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 has an output schema and 6 parameters, the description is moderately complete. It covers the main use and two key parameters, but because there are no annotations, it should also explain the output format (though output schema exists) and the effects of limit/cursor for pagination, which are 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 only 33%: only root and task_id have descriptions. The description adds meaning to index (precise viewing of a single step) and include_drift (lists change layer too), which helps. However, it doesn't explain limit and cursor parameters, but the description partially compensates for the coverage gap.

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 the primary purpose ('列出任务层步骤') and mentions the optional include_drift to also list the change layer, which distinguishes it from siblings that likely manage tasks rather than view them. However, it doesn't explicitly name sibling tools or contrast with them, so it's clear but lacks explicit differentiation.

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 for listing task steps and mentions when to use include_drift, but it does not explicitly say when to use this tool versus alternatives like tc_switch or tc_save. It provides some context but lacks clear exclusions or 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?

没有 annotations，描述承担了行为披露责任。它披露了 closed 任务会被拒绝这一重要行为，但没有说明切换时原活动任务是否被取消、是否持久化、失败时的返回形式等。仅有部分行为透明。

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?

对于只有两个参数的工具，描述提供了基本可用的信息，且存在 output schema 可补充返回结构。但缺少对“活动任务”概念的解释、切换的副作用以及 closed 状态如何判定，整体处于最低可用水平。

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 覆盖率为 100%，root 和 task_id 都已有说明，因此达到基线 3。描述本身没有为参数增加额外语义，例如 task_id 的格式或 root 的约束。

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?

描述明确说明了工具行为：切换活动任务，并补充了 closed 任务会被拒绝的限制。但与 tc_resume、tc_restore 等兄弟工具的差异没有明确说明，agent 仍需通过名称推断边界。

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?

描述没有说明何时使用本工具而非其他兄弟工具，也没有给出使用前提或替代方案。唯一的行为约束是 closed 任务会被拒绝，但这不足以指导 agent 在多个相似工具间做选择。

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