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. '创建新分类' implies a mutation but does not mention side effects, reversibility, permissions, or failure behavior. This is a minimal disclosure for a write operation.

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 short phrase, which is concise and front-loaded. However, it is under-specified, providing no structure or elaboration beyond the bare action, so it does not fully earn its place as a useful guide.

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 is incomplete. It lacks information about expected behavior, error conditions, or any operational context that would help an agent decide when to invoke 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?

The input schema has 100% description coverage for both parameters (name and description), so the description does not need to add parameter details. It adds no additional meaning beyond the schema, hence 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?

The description '创建新分类' (Create new category) clearly states the action (create) and resource (category). It is not a tautology and is distinct from sibling tools like category_delete and category_list by nature, though it does not explicitly name alternatives.

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 other CRUD tools like category_update or category_list. There is no mention of context, prerequisites, or 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?

There are no annotations, so the description carries the full burden for behavioral disclosure. It explicitly states the cascading behavior ('级联删除其下所有项目'), which is a critical side effect that an agent must know before invoking. It also correctly clarifies that tasks are not deleted, preventing potential confusion. This is good transparency for a destructive operation.

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 concise and front-loaded with the core action ('删除指定分类'), immediately followed by the most important side effect. Every word earns its place, with no filler. It avoids reiterating the parameter details that are already in the schema.

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 this is a destructive action with only one parameter and no output schema, the description is quite complete: it states the action, the cascading behavior, and an exclusion (tasks not deleted). An agent likely has enough to decide whether to call it and what to expect. The only minor gap is not specifying if the operation is reversible, but that is not always essential.

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 schema provides 100% description coverage for the only parameter 'id', so the description does not need to add much. It could have added context about where to find the ID, but given the schema already documents '分类ID', the description adds no additional meaning beyond what's in the schema. Baseline 3 is appropriate here.

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 action (delete a category) and the resource (category), distinguishing it from siblings like category_list and category_create. It also adds a critical side-effect note about cascading deletion of items but not tasks, which helps clarify the scope of the action.

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 this tool (when you need to delete a category) but does not provide explicit guidance on when not to use it or alternatives. For example, it doesn't mention that tags use tag_delete, but since only one category deletion tool exists, the usage context is fairly clear from the name alone.

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 must carry behavioral context. '获取' and '列表' signal a read-only retrieve operation bb, and the description states the returned content includes nested project lists. However, it does not explicitly address side effects, ordering, pagination, or permission/error behavior; for a simple zero-argument list endpoint this is a minor but present gap.

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 with no redundant phrases. The main purpose comes first, and the nested-project detail is useful.

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-parameter read-only list tool, the description is nearly sufficient: it names the resource and clarifies the response includes nested project lists. It lacks explicit mention of pagination/ordering or authentication, but those are not required for basic invocation of this simple tool.

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 with 100% schema coverage, so the baseline is 4. The description adds no parameter detail (none exists) but does clarify the response contains each category's project list.

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 object (所有分类列表), and adds a meaningful detail: each category includes its project list. It clearly distinguishes itself from mutation siblings like category_create/category_delete)Skip but it doesn't explicitly contrast with tag_list or project_list.

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 intended use is implied by the name and description—call to retrieve all categories. However, it does not explicitly state when to choose this over project_list or tag_list, nor does it mention any exclusions or prerequisites.

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 only states that a project is created and that category_id is required, but does not explain what happens on success (e.g., returns the project ID?), error conditions, or side effects. Since it is a create operation, the description should reveal expected behavior more explicitly.

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 concise sentence, front-loading the core action and the key requirement. It is efficient with no redundant words, but could slightly expand on parameter details 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?

Given the tool's low complexity (3 simple params, no output schema), the description is minimally adequate. It covers the core purpose and the critical requirement of category_id, but lacks any guidance on return value or error handling. For a simple create tool, this is acceptable but not exhaustive.

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 schema description coverage is 100%, so the input schema already explains 'name', 'category_id', and 'description'. The description adds a small hint that category_id is important (required), but doesn't add meaning about 'name' or 'description' beyond the schema. Baseline 3 is appropriate as the description does not contradict or add significant value.

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 '创建新项目，需要指定所属分类ID' clearly states the action (create a new project) and a key requirement (must specify category_id). It differentiates from siblings like project_list and project_delete by indicating creation. However, it does not mention the 'name' parameter being required, and it is a bit sparse.

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 creating a new project, and the requirement for category_id gives context. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites like checking if the category exists. No when-not-to-use guidance is provided.

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?

无注解，描述承担全部行为披露责任。它明确指出了关键副作用（任务不删除但失去关联），这是重要信息。但未提及权限要求、可逆性、返回结果等，对删除操作而言，信息仍不完整。

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?

工具简单（1个参数），无输出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已提供id参数的描述（项目ID），覆盖率100%，描述未添加额外参数语义，符合基线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?

描述明确指定动词'删除'和资源'项目'，并说明了对任务的副作用，与project_create、project_list等兄弟工具清晰区分，不存在歧义。

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?

描述未明确说明何时使用此工具或排除其他工具，但删除操作本身意图清晰，且无替代工具需要区分。缺乏对前提条件（如项目是否存在）的说明。

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 discloses the default behavior of returning all projects when no filters are passed, which is useful. However, it does not mention pagination, result ordering, or read-only nature beyond the verb '获取', leaving some behavioral context unspecified.

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, compact sentence that front-loads the core purpose ('获取项目列表') and then covers filter options and default behavior without 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 simple list tool with two optional parameters, the description covers the core invocation details: what it does, the available filters, and fallback behavior when filters are omitted. It could additionally explain response format or pagination, but the tool is simple enough that the current description is largely 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 coverage is 100%, with both 'keyword' and 'category_id' already documented in the input schema. The description adds no new parameter details beyond what the schema already states, so the baseline 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?

Description states a specific verb and resource: '获取项目列表' (get project list), with optional filters by category ID and name keyword. This clearly distinguishes it from project_create and project_delete, and from sibling list tools like task_list and category_list.

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: the tool lists projects and optionally filters them, with no filter returning all projects. However, it does not explicitly mention when to prefer this tool over alternatives or when not to use it, so usage guidance 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 bears the full burden. It discloses that name is required, color is optional with a default value (#6366f1), which adds some behavioral context beyond the schema. However, it does not mention potential side effects, idempotency, uniqueness constraints (though schema notes it), or error behavior, leaving gaps 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 a single, succinct sentence that front-loads the action and immediately lists parameter requirements. There is zero extraneous information, and it is efficient for an agent to parse.

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 creation tool with two parameters, the description covers the required and optional fields, including the default. The schema fills in uniqueness and format details. No output schema exists, so return-value documentation is not required. The description is adequate but could mention uniqueness or failure conditions to be 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 100%, so the schema already documents both parameters. The description adds value by specifying the default color value (#6366f1), which is not present in the schema, and clarifies that color is optional. This exceeds the baseline for full schema 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 action and resource: '创建新标签' (Create a new tag), with the verb and object clearly distinguishing it from sibling tools like tag_list and tag_delete. It is unambiguous and immediately identifiable as a creation operation.

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 does not explicitly compare this tool to alternatives or state when not to use it. It implies usage for creating a new tag, but offers no context on how it differs from category_create or when to prefer it over other tag operations. This leaves the agent to infer usage from the name and siblings.

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 disclosure burden. It usefully reveals that deleting a tag does not delete associated tasks, which is a meaningful side-effect guarantee. However, it does not address irreversibility, required permissions, or what happens to task-tag relationships after deletion.

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 compact sentence with a parenthetical clarifier that adds important behavioral nuance without unnecessary verbosity. It is front-loaded with the core action and immediately clarifies scope.

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 single-parameter delete tool with full schema coverage, the description covers the essential action and the main cascade risk. It lacks explicit usage guidance and deeper behavioral disclosure, but it is largely complete given the tool's simplicity.

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%, and the single 'id' parameter is already described as '标签ID'. The tool description adds no further parameter detail beyond saying the tag is 'specified', 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 specific verb ('删除') and resource ('指定标签'), and adds the important qualifier that associated tasks are not deleted. This clearly distinguishes tag_delete from sibling tools like tag_list, tag_create, and category_delete.

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 does not explain when to use tag_delete versus alternatives, nor does it mention any exclusions, prerequisites, or conditions. The parenthetical clarifier implies a safe non-cascade use case, but no explicit guidance is provided.

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 indicates a read operation via '获取' but does not mention authentication needs, pagination, sorting, rate limits, or what the response contains. For an unannotated tool, this is minimal transparency.

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 short sentence with no filler or redundancy. It is front-loaded with the core action and resource, making it easy for an agent to parse quickly.

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 low complexity, zero parameters, and lack of an output schema, the description adequately explains what the tool does. An agent can invoke it correctly without additional context, though return-format details are not specified.

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 input schema has zero parameters, so the baseline is 4. There are no parameter semantics to explain, and the description does not need to compensate for any schema gaps.

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 action (get/list) and resource (all tags), distinguishing it from sibling tools like category_list, tag_create, and tag_delete. The scope '所有' (all) adds precision, making the purpose 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?

The description provides no guidance on when to use this tool versus alternatives in the sibling set. It does not mention exclusions, prerequisites, or scenarios where tag_create or tag_delete would be more appropriate. Usage context is only weakly implied by the word 'get'.

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 responsibility for disclosing behavior. It only says that a new task is created and title is required, without revealing the effect beyond that (e.g., return value, default status behavior, reference validation, whether duplicates are allowed). For a mutating action, this is a notable transparency gap.

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 only three short sentences and front-loads the core action. Each sentence serves a clear purpose: purpose, required vs. optional fields, and how tag_ids relates to tags. No redundancy or unnecessary detail.

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 7-parameter creation tool with no output schema and no annotations, the description covers the essential basics but leaves gaps: it does not explain what an agent should expect back from the call, whether referenced tags/projects need to exist, or any preconditions. It is adequate for a simple call 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?

The input schema already covers all 7 parameters with descriptions, so the 100% schema coverage establishes a baseline of 3. The description adds the useful summary that title is required and other fields are optional, and explains tag_ids as linking tags, but it largely paraphrases what the schema already provides.

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 opens with "添加一个新任务" ('add a new task'), which clearly identifies the action and resource. It is unambiguous relative to siblings like task_update, task_list, and task_delete, though it does not explicitly call out those distinctions.

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 only implied: an agent will call this when it needs to create a new task, especially to be used before subsequent updates/reviews. There is no explicit mention of when to prefer it over task_update or how to prepare IDs such as project_id or tag_ids, so the guidance is minimal.

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 for disclosing behavioral traits. It does not mention whether the change is immediate, if there are any side effects (e.g., moving task to archive), or if there are restrictions on transitions. The description simply states the action, leaving the agent unaware of potential consequences beyond the status change.

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 concise, consisting of one sentence that defines the tool's purpose and lists the statuses. It is appropriately front-loaded with the verb and resource. However, it could be slightly more structured with bullet points for the enum list, but overall it is efficient and to the point.

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 status change tool with 2 parameters and an enum, the description is minimal. It meets the basic need of informing the agent of allowed statuses, but it does not explain the context of task status transitions, any prerequisites (e.g., task must exist), or what happens on success/failure. Given the lack of an output schema, the description should fill more gaps but does not.

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%, with both parameters described in the schema ('任务ID' and '目标状态'). The description adds Chinese labels for the status enum values, but since the schema already includes English enum values and brief descriptions, the description adds marginal value. It does not provide additional meaning beyond what the schema offers.

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 specific verb '变更' (change) and resource '任务状态' (task status), and lists the allowed enum values with Chinese labels. However, it does not differentiate from sibling tools like 'task_update', which likely also changes task attributes. The description is clear about what it does but could be more explicit about its unique role among similar siblings.

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 does not explicitly state when to use this tool versus alternatives. It lists allowed statuses but does not mention any conditions for transitioning between statuses (e.g., cannot go from 'completed' to 'not_started') or when to use 'task_update' instead. Usage is implied but not clearly guided.

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 discloses the irrecoverable nature of the deletion (不可恢复), which is a key behavioral trait. However, without annotations, it does not mention permissions, cascading effects, or any other side effects, leaving some 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?

The description is a single concise sentence, front-loading the action and the irrecoverability caveat. It is efficient with no wasted words.

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 single-parameter delete tool without an output schema, the description is adequate. It communicates the action and the key risk (irrecoverable), which is sufficient for an agent to call it correctly. No additional context seems necessary given the tool's simplicity.

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 schema fully describes the 'id' parameter as '任务ID' (task ID) with 100% coverage. The description adds no additional meaning beyond the schema, so it does not enhance parameter understanding.

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 'delete' and the resource 'task' (删除指定任务), and adds the critical caveat 'irrecoverable' (不可恢复). This distinguishes it from update or change-status siblings.

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 explicit guidance on when to use this tool versus alternatives like task_update or task_change_status. It only states the action itself, leaving the agent to infer when deletion is appropriate.

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 discloses that the tool returns detailed task info including tags and projects, which is useful. However, it doesn't disclose whether this is a read-only operation (though '获取' implies it), whether it requires any special permissions, or what happens if the task doesn't exist (error behavior). For a simple read tool, this is a moderate gap.

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 that front-loads the main purpose and adds the key detail about included information. No wasted words.

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 single-parameter read tool, the description is mostly adequate. It tells the agent what it does and what it returns. However, with no annotations and no output schema, it could be more explicit about the return format or error behavior. The sibling list shows this is one of many task tools, and the description does enough to differentiate it from task_list.

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% – the only parameter 'id' is described as '任务ID' (task ID). The description adds that the tool returns details including tags and projects, which gives context for why the id is needed. Baseline 3 is appropriate since the schema already fully documents the parameter.

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 ('获取' = retrieve) and resource ('指定任务' = specified task), and mentions it includes tag and project information. This clearly distinguishes it from task_list (which lists tasks) and task_add/task_update/task_delete (which mutate tasks). However, it doesn't explicitly name a sibling alternative, so it loses one point.

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: call this when you need detailed information about a specific task, including its tags and projects. It doesn't explicitly state when not to use it or name alternatives like task_list for listing multiple tasks. The context is clear but no exclusions or alternatives 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?

No annotations are provided, so the description carries the burden. It discloses that the tool returns a task list and that no parameters yield all tasks, which is helpful. However, it does not mention pagination, ordering, whether archived tasks are included by default, or any rate limits/scoping—gaps typical for a list operation.

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 with no fluff. The main purpose is front-loaded, followed by filter options and default behavior. Every sentence adds value.

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 optional-parameter list tool, the description covers purpose, filters, and default behavior. However, with no output schema and no annotations, it omits return-value structure, pagination, and sort order, which an agent may need to fully interpret the result.

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 fully documents all parameters. The description only restates the filterable fields (status, project ID, tag ID, keyword) without adding deeper semantics or examples. 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?

The description states a specific verb and resource: '获取任务列表' (get task list). It clearly distinguishes itself from siblings like task_get (single task retrieval) and project_list/tag_list (other resources). The filtering details further clarify scope.

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 clear context: it supports filtering by status, project ID, tag ID, or keyword, and explicitly says that omitting all parameters returns all tasks. It does not name alternatives or exclusions, so it stops short of a 5, but the usage context is well conveyed.

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 bears the behavioral burden. It discloses the partial-update behavior and the important destructive-ish nuance that tag_ids replaces the original tag list entirely ('覆盖原有标签'). It does not mention response format or auth, but the core side effects are clearly stated.

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 short sentences, each earning its place: the operation, the update semantics, and the tag-overwrite caveat. It is front-loaded with the core purpose and contains no filler or redundant schema 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?

For a moderate 7-parameter tool with one required id and fully commented schema, the description plus schema supplies enough to invoke correctly: required id, updatable fields, partial-update semantics, and the tag overwrite behavior. It could be more complete with a note about return values or how status updates should route to task_change_status, but the core invocation contract is 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 coverage is 100%, so the schema already documents every parameter, giving the baseline 3. The description adds the general partial-update rule but largely restates what the schema already says for tag_ids ('覆盖'), without adding new syntax, formatting, or edge-case detail.

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 opens with '更新任务信息', naming the resource and the update operation, and immediately clarifies the partial-update semantic with '只需传入要修改的字段'. The tag_ids overwrite caveat further differentiates this from task_add, task_delete, and even task_change_status by describing the field-level behavior.

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 gives clear invocation guidance ('只需传入要修改的字段'), telling the agent to send only changed fields, which implies skipped fields remain unchanged. However, it never explicitly says when to prefer task_update over sibling tools like task_change_status, and it provides no exclusions or alternative-routing hints.

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