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

With no annotations, the description carries the full behavioral burden and does well: it discloses that archiving is a non-destructive mark, nothing is deleted, it is reversible via restore_archived, and that a background sweep normally handles it. It does not state permission requirements or how archived items surface elsewhere, so it is not fully exhaustive.

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?

Four compact clauses, front-loaded with what archiving does and its non-destructive guarantee, then the auto-behavior, then the parameter override. 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?

For a one-optional-parameter tool with no output schema and no annotations, the description covers what it does, its safety profile, its normal automatic trigger, the override, and the recovery path — everything an agent needs to call it 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 coverage is 100%, so baseline is 3, but the description adds value beyond the schema by naming the config key board.archive_done_after_days, its default of 3 days, and framing the parameter as a temporary per-call override rather than the normal path.

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 (归档/archive) on a specific resource (「完成已久」的已完成任务) and immediately disambiguates it from deletion ('打标记，一条都不删'), naming the counterpart tool restore_archived. An agent can distinguish this from delete_task or list_tasks without opening the schema.

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?

Explicitly says manual invocation is usually unnecessary because board_snapshot auto-archives per config, and then states the one condition under which to call it: to temporarily override the retention period via older_than_days. It also routes recovery to restore_archived.

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 full burden. It states '读取' (read) and lists the configuration contents, which implies a safe read with no mutation, but it does not explicitly confirm side-effect-free behavior, permissions, or freshness guarantees. Basic behavior is inferable but not fully disclosed.

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 sentences, front-loaded with the purpose and followed by a precise usage cue. Every clause earns its place; no redundancy or 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?

There is no output schema, so the description should indicate what is returned; it does so by listing columns, legal transitions, custom fields, database path, and web port. This is largely sufficient for a zero-parameter read tool, though it could note the response format or whether config is live.

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 takes zero parameters, and the input schema is an empty object with 100% description coverage. With no parameters to explain, the baseline of 4 applies; the description appropriately focuses on return contents instead.

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: '读取当前生效的看板配置' (read the currently effective board configuration), and enumerates the contents (columns, legal transitions, custom fields, DB path, web port). It does not explicitly differentiate from siblings like board_snapshot or list_columns, so a 4 rather than 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?

Gives clear context for use: '在决定「能移到哪一列」「有哪些自定义字段」之前先看它' (look at it before deciding which column to move to or what custom fields exist). This tells the agent when to invoke it, but no alternatives are named and no exclusions are given.

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 full behavioral burden. It does disclose the single most important trait — that this is destructive and gated behind confirm=true — but says nothing about irreversibility, whether columns/archived items survive, permission requirements, or recovery. That is a meaningful but partial 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?

Two short sentences, zero filler, with the destructive warning and the confirm precondition front-loaded. Nothing needs trimming and nothing is buried.

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, zero-required-param tool with no annotations and no output schema, the definition covers the safety gate but omits the blast radius (are columns, archived tasks, or events affected?), reversibility, and the actor parameter. Adequate for a cautious caller, incomplete for a confident one.

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 50%, so the description must compensate. It instead restates the confirm semantics already documented in the schema and says nothing at all about the undocumented 'actor' parameter, leaving half the inputs 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?

States a specific verb and resource ('清空看板上的全部任务') with an explicit scope qualifier ('全部'), which cleanly separates it from single-item siblings like delete_task and from archive_done. An agent can identify this as a board-wide bulk reset without opening any schema.

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 destructive framing implies caution, and the confirm=true gate implies a deliberate two-step invocation, but no alternative is ever named (e.g. use delete_task for one task, archive_done to preserve history). Usage is inferable rather than stated.

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 full burden, and it does disclose the return payload composition plus the key volume trade-off (compact=true returns only id/title to shrink responses when there are many tasks). It does not mention permissions or pagination, but for a read-only snapshot tool the behavioral disclosure is solid.

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 sentences, front-loaded with what the tool returns, then when to use it, then the compact caveat. No filler; 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?

With no output schema, the description must convey the return shape, and it does: column definitions, tasks per column, and aggregate statistics. Combined with the compact behavior note, an agent has everything needed to call and interpret it.

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 100%, so the baseline is 3, but the description adds genuine value beyond the schema by explaining the rationale for compact (significantly smaller payload when tasks are numerous). Minor mismatch: the description says compact returns '任务 id 与标题' while the schema also mentions column_id.

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+resource (读取看板完整快照) and enumerates exactly what the snapshot contains: 栏目定义、每列下的任务、统计。This aggregate scope distinguishes it from the granular siblings list_tasks, list_columns and get_task, which return narrower slices.

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?

Gives explicit trigger conditions ('想看当前进展、或要渲染看板时用它'), which is clear context for selection. It does not, however, name an alternative (e.g. list_tasks) for the case where a full snapshot is unnecessary, so the routing is one-sided.

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 full burden. It usefully discloses two behaviors beyond the schema: column_id defaults to the first column, and unknown keys in fields raise an error. It omits anything about required permissions, what an error response looks like, or whether task_id collisions are rejected.

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 tight sentences with the purpose front-loaded followed by the two conditional behaviors. Nothing is padded and every clause carries information an agent needs.

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 an eight-parameter mutation tool with no annotations and no output schema, the description should say what is returned (e.g., the generated task id) so an agent can chain calls. It covers defaults and validation well but leaves the return value and permission requirements unstated.

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 100%, setting the baseline at 3. The description goes beyond the schema by documenting the omitted-column_id default and the board.fields key constraint on the fields object, adding real semantics for two of the eight parameters.

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: creating a new task on a board. It is inherently distinguishable from update_task/delete_task/move_task by the creation action, though it never names a sibling to sharpen the boundary.

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 explains defaults and validation but gives no explicit guidance on when to reach for create_task versus list_tasks, update_task, or board_config. There is no when-to-use/when-not framing and no prerequisites or permissions mentioned.

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 full burden and does disclose the two most important behaviors: the data is unrecoverable and a delete event is logged as a side effect. It omits permission requirements and whether related records are affected, so it is strong but not complete.

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 the action front-loaded and the destructive consequence immediately following. Nothing is wasted.

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, non-annotated tool with no output schema, the description covers the critical risk (irreversibility) and the audit side effect. It leaves the 'actor' parameter and any authorization/related-data behavior unexplained, so it is adequate but not 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 coverage is only 50%: task_id is documented in the schema but 'actor' has no description anywhere. The description adds no meaning to either parameter, so it fails to compensate 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?

States a specific verb+resource combination ('删除一个任务') that is unambiguous. It does not explicitly name or contrast with the highly relevant sibling archive_done, though the irreversibility note implicitly distinguishes it from archiving.

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. Given siblings like archive_done and restore_archived, the description should say to prefer archiving when reversibility is desired, but it leaves that inference 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read via 读取, but says nothing about behavior when task_id does not exist, permissions, or whether the read has any side 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?

A single short sentence with no waste and the key scope (single task, complete fields) front-loaded. It is terse almost to a fault, but nothing redundant is present.

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 one-parameter getter with no output schema, the mention of 完整字段 partially signals the return payload, which is helpful. However, with no annotations and no output schema, it leaves the agent guessing about error behavior and permissions.

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?

There is a single parameter and schema description coverage is 100%, so the schema already documents task_id (任务 id，必填). The description adds nothing beyond restating that one task is targeted, which matches the baseline 3 for high coverage.

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 (读取/read) and resource (单个任务/single task) plus the scope of the read (完整字段/complete fields). It implicitly contrasts with list_tasks by emphasizing a single task, but it never names siblings explicitly.

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 contains no when-to-use guidance, no prerequisites, and no reference to alternatives such as list_tasks for bulk retrieval or update_task for mutation. Usage must be inferred entirely from the verb.

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 full behavioral burden. It discloses the returned fields (order, color, WIP limit), but does not explicitly state that this is a read-only operation, nor does it mention permissions or side effects. The implied read-only nature from '列出' is helpful but not explicit.

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 sentence that is front-loaded with the verb and resource. It contains no redundant or filler content, and every phrase (order, color, WIP limit) adds useful return information.

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 list tool with zero parameters and no output schema, the description adequately communicates the returned column attributes. However, it does not state that the operation is read-only or that no side effects occur, which would be more important given the absence 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?

The tool has zero parameters, so the rubric baseline is 4. There is no parameter semantics to add beyond the empty schema, and the description appropriately does not discuss 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?

States a specific verb '列出' (list) and resource '所有栏目（列）' plus the returned attributes order, color, and WIP limit. It clearly identifies what the tool does, but does not differentiate itself from siblings like board_config or board_snapshot, which may also expose column information.

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 when-to-use guidance, no alternatives, and no prerequisites. An agent must infer that this tool is for reading column metadata rather than for any configuration or mutation 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?

No annotations are provided, so the description carries the full burden. '读取' (read) and the described event payload make the read-only, non-destructive nature reasonably inferable, but nothing is said about auth requirements, ordering, retention, or rate limits for polling.

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 tight sentences: purpose first, then the two parameter-driven modes. No filler, nothing repeated from the schema, and the most important information leads.

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 read-only, zero-required-parameter list tool with no output schema, the description is nearly sufficient. It omits ordering of events and how limit interacts with since_seq across a long history, which are minor but real gaps for a polling use case.

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 100% so the baseline is 3, but the description adds intent beyond the raw field docs: since_seq is framed as an incremental-sync cursor and task_id as a per-task history filter. That tells an agent how to combine them, not just what they accept.

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 (read the change/event stream) and even spells out the returned content: who moved what from which column to which column, when. That distinguishes it from list_tasks or board_snapshot without naming them, though it stops short of explicit sibling 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?

Explains two concrete usage modes: incremental pulling via since_seq and full single-task history via task_id. This is clear operational context, but it never states when to prefer this tool over alternatives like board_snapshot or list_tasks.

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 full burden, and it delivers the key behavioral trait: the semantics is 'reporting interruption' rather than 'progress unchanged', plus the false-positive risk and the idle_sec return field. It omits auth/permission or pagination behavior, but the critical misinterpretation hazard is disclosed.

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?

Three sentences, front-loaded with the definition, then the semantic caveat, then the return field. The bolded warning is placed where it matters and no sentence is redundant.

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 zero-required-param read tool with no output schema, the description covers what the filter means and surfaces the one return field that matters (idle_sec). Nothing essential to calling it correctly is missing, though return shape beyond idle_sec is unspecified.

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 both parameters (now, threshold_sec) are already documented in the schema. The description reinforces the threshold concept and mentions idle_sec but adds no syntax or format detail beyond the schema, matching the baseline 3.

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+resource (列出疑似停滞的任务) and immediately operationalizes it: tasks still in non-terminal columns with no writes beyond the threshold. This is clearly distinguishable from sibling list_tasks, which has no such filter.

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?

Explains the triggering condition and warns that long tasks must periodically call update_progress or be mislabeled, which effectively names the corrective sibling action. It stops short of explicitly contrasting with list_tasks/list_events as alternatives, so it is strong context rather than full when/when-not routing.

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 full behavioral burden and does meaningful work: it discloses that archived tasks are excluded by default, that archiving is not deletion, and that data persists. It omits return format, ordering, and any pagination behavior, but the key hidden default is surfaced.

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?

Three tight sentences, front-loaded with the filtering scope, then the common case, then the archived caveat. Every sentence adds information with no padding.

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 3-param, no-required read tool with no output schema and no annotations, the description covers scope, the primary filter, and the archived default/restore path. It does not describe the shape or ordering of returned tasks, which is the main remaining gap.

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 100% and the schema already documents all three parameters including the default of include_archived. The description largely restates the default and adds a usage example for column_id, which is helpful but not materially beyond the structured fields, so the baseline 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?

States a specific verb+resource (list/filter tasks) and its scope (by column or tag). It doesn't explicitly differentiate itself from siblings like get_task or list_stalled, so an agent still has to infer which listing tool applies, but the purpose itself 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?

Gives a concrete when-to-use cue ('when you want to see what's in progress, filter with column_id') and explains the default archived exclusion with a remedy (include_archived=true). It stops short of naming sibling alternatives such as list_stalled or board_snapshot, so routing is implied rather than 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 full burden, and it does meaningful work: illegal transitions raise an error and enumerate the allowed target columns, and ordering is controlled by before_task_id (append to column tail if omitted). It still omits permission/auth requirements and reversibility, so not a 5.

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 tight sentences with no filler; the core action is front-loaded and the behavioral caveats (transition legality, ordering) follow in priority order.

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 mutation tool with no annotations and no output schema, the description covers the main surprise behaviors (validation failure mode, ordering control), which is what an agent most needs. Missing only auth/permission context and any note on side effects, so it stops short of fully self-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 all four parameters are already documented in the schema (including the append-vs-insert default for before_task_id). The description restates the before_task_id semantics without adding new syntax, format, or constraint detail, so baseline 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?

States a specific verb+resource ('把任务移到另一列') and adds the conceptual framing (状态流转) so the agent knows this is a status/column transition, not a generic edit. It does not explicitly distinguish itself from update_task, which a sibling-savvy agent might assume can also change columns, so it falls short of the top tier.

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 column-transition framing, and the description usefully notes the transition-legality gate (board.transitions), but it never states when to prefer this over update_task or any other sibling, nor any preconditions. Adequate but with clear routing gaps.

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 full behavioral burden. It states that tasks are restored to the main view and that omitting task_id restores all, but it omits important mutation details such as required permissions, reversibility, potential conflicts with existing tasks in the main view, or rate limits.

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 wasted words. The main action is front-loaded, and the conditional behavior is stated immediately after, making the description easy to scan.

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 restore tool with one fully documented parameter, the description covers the core action and the optional bulk mode. However, with no annotations and no output schema, it should do more to disclose behavioral context such as side effects or safety implications of restoring all tasks.

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 the single optional task_id parameter. The description restates the same meaning (provide task_id to restore one, omit to restore all) without adding syntax, format, or edge-case details beyond the schema, matching the baseline for high coverage.

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 and resource: restore archived tasks back to the main view. It distinguishes the tool's action from siblings like archive_done or delete_task, but does not explicitly name or contrast those alternatives, so it falls short of full sibling 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 explains parameter behavior (restore one task vs all tasks) but gives no guidance on when to use this tool versus alternatives such as delete_task or get_task. There is no explicit when-to-use or when-not-to-use context.

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 zero annotations, the description carries the full load and does so richly: monotonic-only semantics with explicit rejection of lower values plus the error returning the current value, idempotency via absolute values, and retry safety. These are exactly the non-obvious behaviors an agent needs.

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?

Front-loaded with purpose, then the critical monotonic constraint in bold, then idempotency, then the operational recommendation. Every sentence carries distinct information with no 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 an 8-param, no-annotation, no-output-schema mutation tool, the description covers the crucial behavioral contract (monotonicity, rejection, idempotency, stalling). It doesn't describe the return payload beyond the rejection case, but the schema fully documents the remaining parameters, so coverage is nearly 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 baseline is 3, but the description adds real meaning beyond the field docs by clarifying that current is absolute rather than a delta and drawing the idempotency consequence. That is a semantic contribution the schema does not spell out.

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+resource (推进进度字段) and scopes it to long-running tasks, with the parenthetical (长耗时任务用) routing the agent away from the general update_task sibling. An agent can identify the operation and its domain without opening the schema.

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?

Clearly states when to use it (long-running tasks) and adds an operational directive (report periodically) tied to a concrete consequence (being flagged by list_stalled). It stops short of explicitly naming update_task or get_task as alternatives, so it's clear context but not full when/when-not/alternative routing.

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 full behavioral burden. It usefully discloses partial-update semantics (只改传入的部分), but does not cover permissions, reversibility, side effects, or return behavior for a 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?

The description is two short sentences with no wasted wording and is front-loaded with the updatable fields followed by the partial-update behavior. It is tersely structured rather than verbose, though it may be too minimal for the tool's complexity.

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 seven parameters, a nested object, no annotations, no output schema, and low schema coverage, the description is not complete enough. It omits actor semantics, required task_id context, custom-field merge behavior, and any auth or output expectations.

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 29%, so the description must compensate. It names five of seven parameters (title, description, tags, custom fields, priority) but omits actor and task_id, and adds no format or merge details beyond the field names.

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+resource (更新任务) and lists the updatable fields: title, description, tags, custom fields, and priority. It does not distinguish itself from siblings such as update_progress or move_task, so it falls 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 gives no when-to-use guidance, no alternatives, and no prerequisites. It states that only passed parts are changed, but that is behavioral context rather than selection guidance.

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