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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds only that the item is a checklist sub-step, but does not disclose whether the parent task is auto-created, whether it requires a resolvable task, or any other behavioral trait.

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 phrase with no filler and the core action front-loaded. It is efficient, though borderline sparse rather than genuinely well-structured prose.

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 4-parameter mutation tool with no output schema, the schema and annotations carry most of the load, but the description omits any mention of how the target task is identified or how this relates to the step/task siblings, leaving real gaps.

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 documented in the schema itself, including the taskId-over-title precedence. The description adds no parameter meaning beyond the schema, so the baseline 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 (add) and resource (sub-step/checklist on a task), which is clear enough to distinguish it from add_task (adds a task) and list_steps/update_step. However, it does not explicitly name or differentiate from those siblings, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use add_step versus add_task or update_step, nor any prerequisites such as needing an existing task identified by taskId or title. The agent must infer the usage context entirely.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so safety basics are covered. The description contributes nothing beyond them: no mention that title is required, that missing fields default, or that the task is persisted to a task list.

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 phrase is front-loaded with zero padding, which is structurally clean. But it is terse to the point of under-specification for a six-parameter write tool, so it cannot score highly on structure alone.

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 mutating, open-world tool with six parameters and no output schema, the description omits required fields, default behavior, side effects and return expectations. The rich schema compensates for parameter detail but not for tool-level behavior or sibling routing.

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%, including formats for due/reminder and the default list, so the schema carries the semantics. The description adds no syntax or behavioral detail about any of the six parameters, so 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?

States a specific verb and resource (新建 + 任务), so the agent knows this creates a task. However it gives no differentiation from the near-identical sibling add_today_task, nor from add_step or create_list, leaving the agent to guess which creation tool applies.

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?

There is no when-to-use guidance at all. The description never explains when to pick add_task over add_today_task (which presumably also creates a task, scoped to today) or when to add a step instead.

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 declare write (readOnly=false), openWorld, non-destructive. The description adds genuinely useful behavior beyond that: due date is forced to today, tasks land in '计划内' and surface as '我的一天' suggestions, and it discloses the Graph API limitation that prevents direct '我的一天' insertion.

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 compact clauses plus one parenthetical caveat, front-loaded with the core effect. No redundant or filler sentences; every clause carries 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 mutation tool with full annotation coverage and complete schema descriptions, the description covers the key behavioral twist (why it exists rather than relying on Graph API). No output schema exists, so return values need not be explained; only finer points like the default list behavior are left to the 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 description coverage is 100%, so all four parameters are already documented in the schema and the description adds no further syntax or format detail. Baseline 3 applies; '可一次添加多个' merely restates the titles array contract.

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 precisely scopes it as due today, appearing in '计划内' and suggested for '我的一天'. This clearly distinguishes it from the sibling add_task, which has no 'today' semantics.

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 for when to use it (fast-adding tasks meant for today, batch-capable), but never explicitly names add_task as the alternative for non-today tasks or states exclusions. Context is clear, routing is left implicit.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the agent knows this is a safe, side-effect-free read against an external service. The description adds that the result concerns login state and the current account, which is useful since no output schema exists, but it says nothing about failure modes (e.g. what happens when not logged in) or what the account identifier looks like.

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 that front-loads the resource ('Microsoft To Do') and the two things returned. No filler, no redundancy with the title or 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?

For a zero-parameter read tool with full annotation coverage and no output schema, the description is nearly sufficient: it tells the agent both the auth state and the current account are returned. It could go slightly further by naming the tool to use when the status shows unauthenticated, but nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly implies no input is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource and what is checked: the login/auth status and the currently signed-in account for Microsoft To Do. That is far more specific than a tautology and an agent can tell it is a status-query tool. It does not, however, explicitly contrast itself with the sibling 'login', which an agent might otherwise consider when auth is not working.

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?

There is no statement of when to call this versus alternatives such as 'login' (which presumably initiates authentication) or any prerequisite/precondition. Usage can only be inferred from the tool name and purpose; no exclusions or routing guidance are 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?

注解已说明它不是只读也不会破坏数据，但描述没有添加任何关于认证需求、任务匹配模糊时如何处理，或是否依赖于某个列表或标题/ ID 解析顺序的信息。

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?

对于包含 3 个可选参数且没有输出架构的变更工具而言，描述过于单薄；解释了任务匹配方式或如何在同级工具之间选择等基本调用细节都缺失。

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?

架构描述覆盖率为 100%，因此所有参数及其语义（列表、标题、taskId 且 taskId 优先）都已在架构中说明。描述没有提供额外细节；当架构承担主要说明时，基准分为 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?

明确的动词+资源（把任务标记为已完成），并且与存在的同级工具 uncomplete_task 形成清晰区分。

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

没有说明何时使用此工具而非其他工具、没有任何前置条件，或如何传入任务标识符。

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is carried by structured data. The description adds nothing behavioral beyond that - no mention of duplicate-name handling, return value, or side effects - so it contributes no extra 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 single short sentence is waste-free and front-loaded, but at this length it is under-specified rather than deliberately concise. It uses its small footprint without earning much.

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 creation tool with annotations present and no output schema, the description is minimally sufficient to call the tool. It omits any note about authentication or duplicate handling, leaving modest gaps for a simple 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?

With a single parameter and 100% schema description coverage ("列表名称"), the schema fully documents the input. The description adds no syntax, format, or constraint details, 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?

"新建一个 To Do 列表" states a clear verb (新建) and resource (To Do 列表), so the basic action is unambiguous. However, it is essentially a translation of the tool name create_list, adding no differentiation from the many sibling list/task tools, so it sits at minimum-viable rather than distinguishing.

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?

There is no guidance on when to use this tool versus alternatives such as add_task or list_lists, nor any noted prerequisites (e.g. that auth may be required given the login/auth_status siblings). The agent must infer all usage 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds that the deletion is irreversible (不可恢复) and that it is gated on an explicit user request — information the annotations do not encode. It still says nothing about behavior when the step is not found or about partial-match collisions.

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 zero padding, front-loading the action and immediately following with the safety constraint. Nothing could be removed without losing 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 destructive tool with no output schema and full schema coverage, the description covers the essential facts: what is destroyed and when it is permitted. It omits failure/ambiguity behavior, which given the schema's partial-match step resolution would be worth a sentence for a delete 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 all four parameters (list, step, title, taskId) including the required 'step' are already documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 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 names a specific verb and resource (delete a task's sub-step) and scopes it to the step level, which distinguishes it from the sibling delete_task. It stops short of explicitly naming the alternative tool the way the highest-scoring examples do.

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 an explicit gating condition — only invoke when the user has explicitly asked for deletion — which is real routing guidance for a destructive operation. It does not name delete_task/update_step as alternatives or state when to prefer them, so it sits below a full 5.

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 annotations already declare destructiveHint=true and readOnlyHint=false, so the bar is lower. The description still adds value by stating the effect is irreversible (不可恢复) and by imposing a user-consent requirement, which is meaningful context beyond the structured hints.

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 zero waste; the destructive/permanent nature is front-loaded, followed immediately by the usage condition.

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 three parameters, full schema coverage, and no output schema, the description supplies everything needed: what it does, that it is irreversible, and when to call it. It could be marginally richer by noting behavior when multiple tasks match title, but that is a minor 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 description coverage is 100%, so the schema already explains list, title, and taskId, including the precedence of taskId over title. The description adds no additional parameter guidance, so the 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 states a specific verb and resource (永久删除任务) with the added modifier that the deletion is permanent. It does not explicitly distinguish itself from the sibling delete_step, but the resource (task) is unambiguous alongside the other task-level tools.

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 an explicit precondition: only invoke when the user explicitly requests deletion. This is a clear when-to-use gate that an agent can act on directly, and it prevents accidental destructive calls.

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

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

Beyond readOnlyHint/destructiveHint, the description discloses real behavioral traits: data is read from the local cache, Graph API cannot supply it, and tasks flagged 未同步 exist only locally and cannot be modified by other tools. That caveat is exactly the kind of non-obvious state an agent needs. It does not cover pagination, empty-result behavior, or the fact that the cached view may be stale.

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 compact sentences, front-loaded with what is read and from where, then the unsynced caveat. No filler, no repetition of 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?

For a single-parameter read tool with no output schema, the description covers source, read-only nature, and the key limitation about unsynced tasks. Minor gaps remain: no indication of the return shape/ordering or what happens when My Day is empty.

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 optional parameter (date, YYYY-MM-DD, default today) and schema description coverage is 100%, so the schema fully documents it. The description adds no extra date semantics (e.g., whether a future date is valid, or timezone behavior), so the baseline 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?

States a specific verb (读取/read) and a specific resource ("我的一天"/My Day tasks) and even names the backing data source (本机缓存, not Graph API). It never names or distinguishes itself from the very similar sibling get_today_tasks, so an agent must infer which of the two to pick.

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 parenthetical "Graph API 不提供此数据" implies this is the only route to My Day data, which is useful implied guidance. However, there is no explicit when-to-use/when-not statement and no routing to alternatives such as get_today_tasks or get_today_tasks vs list_tasks, so the agent is left to infer.

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

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

Annotations already declare this is a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the safety profile is covered. The description adds the semantic scoping rule (incomplete + due today or overdue), which is genuinely useful, but says nothing about result ordering, grouping by list, or whether completed-but-overdue tasks are excluded.

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 sentence with no filler, and the most consequential qualifier (due today or overdue) is placed where it is read first. Nothing to trim.

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 no-argument, read-only aggregation tool with no output schema, the description supplies the one thing that matters: which tasks are returned. Minor gaps remain around result shape (flat list vs grouped by list) and ordering, but nothing blocks correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters and the schema is an empty object with full description coverage, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless tool.

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 (tasks) narrowed by three concrete scope qualifiers: all lists, incomplete, due today or overdue. This is far more precise than a bare 'list tasks', though it never names how it differs from siblings like get_my_day, list_tasks, or search_tasks.

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 filter definition implicitly signals when the tool applies (a 'what's on my plate today' view), but there is no explicit when-to-use, no exclusions, and no pointer to the alternative tools that could also return tasks. Usage must be inferred.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no pagination behavior, no result ordering, no mention of authentication requirements, so it contributes no behavioral context of its own.

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 that is front-loaded and free of filler. It is efficient, though its brevity borders on under-specification rather than genuine conciseness.

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 a simple parameterless read, but it sits among many similarly named list_* siblings, and the description gives no cue about scope, result shape, or selection criteria. With no output schema and an obviously crowded namespace, more context was warranted.

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, so per the baseline there is nothing for the description to disambiguate. Parameter semantics are not applicable 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?

States a verb (列出) and resource (To Do 列表) with an 'all' scope quantifier, but this largely restates the tool name list_lists. It offers no differentiation from siblings such as list_tasks or list_steps, leaving the agent to infer which list type is meant.

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?

There is no guidance on when to call this versus list_tasks, search_tasks, or get_today_tasks, and no stated prerequisites (e.g. auth). The agent must guess the appropriate context purely from the name.

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

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

Annotations already declare this a safe read (readOnlyHint=true, destructiveHint=false), so the safety profile is covered. The description adds that the result includes sub-step completion state, a small amount of return-context value, but does not mention ordering, pagination, or what happens when a task has no sub-steps.

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 zero filler, front-loading the action and the returned information. Nothing is wasted and nothing is left dangling.

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-parameter read tool whose safety and parameters are already fully covered by annotations and schema, the description adequately states output content. The only real gap is the absent usage guidance about locating the parent task, which is minor here.

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 three parameters (list, title, taskId) including the taskId-over-title precedence rule are already documented in the schema. The description adds no format or matching semantics beyond what the schema provides, 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 and resource: viewing all sub-steps of a task, plus what is displayed (checked state). An agent can distinguish it from list_tasks or add_step, but the description never explicitly contrasts itself with the step-related siblings (add_step, update_step, delete_step).

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 when-to-use guidance, no prerequisites, and no naming of alternatives such as list_tasks or search_tasks for finding the parent task first. The agent must infer the usage context entirely from the tool name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context of its own - no pagination/limit behavior, no indication of how many tasks come back, no auth or scope notes.

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 zero waste, but also nearly zero content - for a tool with two parameters and several overlapping siblings, this is terse to the point of being under-specified rather than optimally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

For a simple read-only list tool with no output schema and full schema coverage, the description is minimally viable. It omits return format, result limits, and how it relates to sibling listing/search tools, which an agent would want before choosing 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 description coverage is 100%, so both parameters (list and status, including the enum values) are fully documented in the schema. The description adds no extra meaning, which is the baseline 3 case when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a clear verb+resource (list tasks) and scopes it to a given list, so the agent knows exactly what operation this is. However, it does nothing to differentiate from siblings like search_tasks, get_today_tasks, or get_my_day, which also return tasks.

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?

There is no guidance on when to use this tool versus search_tasks (filtered search) or get_today_tasks/get_my_day (special views). The only implied usage comes from the schema default of the '任务' list, which the description never mentions.

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?

Goes well beyond the annotations by disclosing the interaction model: the tool returns a URL and a verification code, the agent must relay them verbatim to the user, and login is finished in the browser before other tools are usable. It does not mention code expiry, polling behaviour, or what happens if the user abandons the flow. Annotations (readOnly, openWorld) already frame the safety profile, so this added context is 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?

Purpose is front-loaded in the first clause and the operational instruction (relay the URL/code, then call other tools) follows in one tight sentence. No padding, and the ordering information is exactly what 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?

With no input parameters and no output schema, the description carries the burden of explaining return values, and it does (URL + verification code). It stops short of the practical lifecycle details an agent would want — code validity window, retry/failure behaviour, and whether auth_status should be consulted first.

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, so the baseline is 4; there is no parameter syntax the description could or should add. Nothing here misleads about 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 and resource ('用设备码方式登录 Microsoft 账号') and names the mechanism (device code flow), which no sibling tool covers. It implies its position as a prerequisite ('登录完成后再调用其他工具') but never names the auth-related sibling auth_status for 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?

Clear context for use: this is the entry step needed before other tools will work, and the agent is told to hand the URL/code to the user for out-of-band completion. It never says whether to check auth_status first to see if login is even required, which is the one obvious exclusion.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the search scope (all lists or one list); it says nothing about matching fields beyond title, result caps, or ordering.

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 compact sentence with the scope constraint front-loaded; nothing is redundant or padded.

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 search with no output schema, the essentials are present, but the description omits search-field scope (title only), result limits, and how results relate to list_tasks output, leaving an agent to infer them.

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 67%: query and status are documented in-schema while list is bare. The description loosely maps to those parameters ('关键字' -> query, '指定列表' -> list) but adds no format, syntax, or default details beyond the schema.

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 (搜索/search), resource (任务/tasks), and scope (所有列表或指定列表/all or a specified list), which distinguishes it from plain list_tasks. It stops short of naming list_tasks or get_today_tasks as the non-search 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 phrase '按关键字' implies the tool is for keyword-driven lookup, and '(或指定列表)' hints at narrowing. However, there is no explicit when-to-use vs list_tasks/get_today_tasks guidance and no exclusions.

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

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

Annotations already declare this is a non-read-only, non-destructive, open-world mutation, so the safety profile is covered. The description adds that the completion flag is cleared, but says nothing about side effects (e.g., subtasks, timestamps) or what happens if the task is not currently completed — reasonable but thin for a mutation.

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 the core action front-loaded and a clarifying parenthetical; no wasted words. It is arguably too terse to be maximally useful, but structurally clean.

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 3 parameters (0 required), no output schema, and multiple selection paths (list/title/taskId), the description omits behavior when nothing matches, when multiple tasks match by partial title, and the relationship to complete_task. It is under-specified for the tool's complexity.

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 list/title/taskId semantics (including partial-match and taskId precedence) are already documented in the schema. The description adds nothing beyond the schema, 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?

The description states a specific verb+resource: undoing a task's completed status ('取消任务的完成状态'). It is clearly the inverse of the sibling complete_task, so the agent can distinguish the two, though it never names that sibling directly.

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?

There is no statement of when to use this versus complete_task or update_task, nor any prerequisite such as the task needing to currently be completed. Usage is only implied by the name and the parenthetical '取消勾选'.

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

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

Annotations already declare this is a non-read-only, non-destructive, open-world write, so the safety profile is covered. The description adds almost nothing behavioral beyond that: it does not say what happens if the step cannot be located, whether new_text and checked can be applied together, or what is returned.

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?

Very short and front-loaded, with the core action in the first clause. Slight redundancy in restating the checked=true/false mapping after already saying 勾选/取消勾选, which is why it is not a 5.

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 6-parameter mutation tool with no output schema, the description is minimally adequate: the how-to-locate-the-step parameters (list, step, title, taskId) and their precedence are left entirely to the schema. Nothing in the description is wrong, but it omits edge-case behavior an agent would want.

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 every parameter including the checked boolean. The description only restates the checked=true/false mapping that the schema already provides, adding no new syntax or lookup semantics. Baseline 3 applies when the schema does the heavy lifting.

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 pair (勾选/取消勾选子步骤 or 修改步骤文字) so an agent immediately knows this mutates a step rather than a task. It does not, however, distinguish itself from siblings such as complete_task/uncomplete_task or update_task, which overlap conceptually.

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 two usage modes (toggle checked state, or replace step text), which is better than nothing, but it gives no when-to-use/when-not-to-use guidance and never names an alternative tool. The agent must infer the routing decision from the sibling list 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the mutation/open-world profile is covered. The description does add one useful behavioral detail beyond the annotations: that clear_due=true clears the due date rather than requiring an empty value. It still omits whether a task identifier is mandatory and what happens when no field is supplied.

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 compact sentences with the field list front-loaded and the clear_due exception following. It is appropriately sized for a 9-parameter update tool, with no filler, though the comma-separated field list is slightly terse.

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 100% schema coverage and annotations covering the safety profile, the description is largely adequate. The remaining gap is that zero parameters are required, so an agent could call with no taskId and no title; the description never states that one identifier is needed, which is a meaningful omission for a mutation 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?

Schema description coverage is 100%, so the baseline is 3; the schema already documents formats such as YYYY-MM-DD, 'today'/'tomorrow', partial title matching, and taskId priority over title. The description only restates the field list and the clear_due flag, adding no syntax beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (修改/modify) and resource (任务/task) and enumerates the modifiable fields (title, due date, importance, note, reminder), so an agent knows exactly what the tool does. It does not, however, explicitly distinguish itself from siblings like update_step or complete_task.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance: nothing tells the agent how this differs from update_step, complete_task, or delete_task, nor when to prefer it over creating a new task. The field enumeration implies scope but provides no selection criteria.

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