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. 'Mark as completed' conveys the effect but does not mention idempotency, permissions, what happens if the task is already completed, or the response shape. This is a significant gap 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 front-loaded sentence with zero fluff. It is appropriately concise for a simple action, though it omits behavioral context that could have been included without much length.

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

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

Given the low schema/annotation richness and absence of an output schema, the description leaves out important context: no mention of return values, side effects, required permissions, or behavior on already-completed tasks. The tool is simple, but the description is too sparse to be fully self-sufficient.

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

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

Schema description coverage is 0%, and the description does not explain the parameters at all. While listId and taskId are reasonably self-explanatory, the description fails to compensate for the absent schema documentation, providing no meaning beyond the bare parameter names.

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

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

The description states a specific verb ('mark as completed') and resource ('Microsoft To Do task'), which clearly identifies the operation. It distinguishes itself from siblings like update_task (general updates) and create_task (new task creation) via the explicit completion 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 the usage scenario: when you want to set a task to completed. However, it provides no explicit guidance on when not to use it, such as 'use update_task for modifying other task fields', leaving alternative selection to inference.

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 only says 'create a task' and does not explain side effects, whether an existing list is required, how invalid IDs are handled, default behaviors, or what the response format is. This is a notable gap for a mutating 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 concise, front-loaded sentence with no wasted words. It earns its place by stating the core action and resource, though brevity comes at the cost of missing supporting detail covered elsewhere in the scoring.

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 7 parameters, no output schema, no annotations, and only partial schema descriptions, a one-sentence description is not enough for an agent to confidently invoke the tool. Important context such as required listId sourcing, timezone defaults, and parameter semantics is absent.

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

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

Schema description coverage is only 43%, with 4 of 7 parameters lacking any schema explanation, but the description adds no parameter-level semantics whatsoever. It does not help an agent understand title, body, importance, timeZone, or any other field beyond 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 clearly states a specific action ('create') and resource ('task in Microsoft To Do'), making it unambiguous. The verb 'create' also distinguishes this tool from sibling tools like list_task_lists, update_task, and complete_task, so an agent can immediately identify its purpose.

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

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

The description implies the tool is used when a new task needs to be created in Microsoft To Do, which is a clear enough context. However, it does not explicitly say when not to use it, mention alternatives, or note prerequisites such as needing a valid listId from list_task_lists before calling this tool.

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

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

With no annotations, the description carries the full transparency burden. It does disclose this is a read/list operation on the current Microsoft To Do context, which implies no side effects. However, it does not mention return format, ordering, or whether all lists are returned, leaving some behavioral ambiguity.

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, focused sentence that is front-loaded with the action and object. There is no wasted wording or extraneous 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 simple, parameterless list operation, the description is mostly complete. It could slightly improve by stating that it returns all task lists, but the verb '列出' already conveys the core behavior, and there is no output schema to rely on.

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

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

The tool has zero parameters, so the description has no parameter semantics to add. The baseline of 4 applies because there is no parameter documentation gap to compensate for.

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 ('列出' / list) and resource ('任务列表' / task lists), clearly distinguishing this tool from sibling list_tasks. Even without reading the sibling names, an agent understands exactly what object this tool operates on.

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

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

Usage is implied: call this when you need the user's task lists. However, the description gives no explicit guidance on when to prefer this over siblings, nor does it mention that list_tasks would be the alternative for individual tasks. It is minimally viable but leaves the routing to inference.

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 only says 'list tasks' and does not mention pagination, sorting, whether completed tasks are returned, or any read-only implications. The includeCompleted schema default hints at behavior, but the description adds nothing.

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 one concise, purposeful sentence in Chinese with no filler or repeated information. It is appropriately sized for a simple read operation.

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 two-parameter tool, the description plus schema is minimally sufficient to select and invoke the tool: listId is required and the behavior is to list tasks. However, lacking output details, filter semantics for includeCompleted, and any usage context leaves clear 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 50%, with listId documented but includeCompleted left undefined. The description does not compensate by clarifying either parameter; it only mirrors the general purpose of the listId parameter. With low schema coverage, this is a notable gap.

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

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

The description states a specific verb and resource: list tasks in a To Do list. It is semantically distinct from the sibling tool list_task_lists, which lists lists rather than tasks. It does not explicitly name siblings, so it falls just short of a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives such as create_task or list_task_lists. The intended use is somewhat inferable, but the description itself never states when-not-to-use or which sibling to prefer.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states that fields can be modified. It does not explain whether this is a partial update (only provided fields change) or a full overwrite, what happens to unspecified fields, whether timezone affects date/time values, or what response the agent can expect.

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 no redundant wording, and the main verb and resource appear immediately. It earns its place by listing the mutable fields, though it could have used the space more effectively by adding behavioral context.

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 eight parameters, no annotations, and no output schema, this description is under-specified. It fails to convey partial-update semantics, required identifiers, timezone handling, or what happens on success or failure, leaving the agent to infer critical calling conventions.

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

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

Schema description coverage is 0%, so the description must compensate. It maps five parameters (title, body, importance, dueDateTime, reminderDateTime) to recognizable field names, but it omits the required listId and taskId, and does not clarify timeZone or date-time format expectations. This is partial compensation for a low-coverage 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 uses a specific verb ('修改' = modify) and clearly names the resource (Microsoft To Do task) plus the exact fields it changes: title, body, importance, due date, or reminder. It implicitly differentiates from siblings like create_task and complete_task by focusing on updating existing task fields, though it does not explicitly name the 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?

No guidance is provided about when to use this tool versus list_tasks, create_task, or complete_task. There is no mention of prerequisites, such as needing an existing task ID, nor any exclusion like 'use complete_task to mark a task done instead.'

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