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

Annotations provide readOnlyHint=false and destructiveHint=false, so the write nature is clear. The description adds the semantic detail that a bucket is a column, but it doesn't disclose additional behavioral traits such as duplicate name handling or side effects beyond what annotations already signal.

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 that contains no fluff. It succinctly conveys the core action and target.

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 create tool with two clearly documented parameters, the description is adequate. It clarifies the domain-specific term 'bucket' as a column. No output schema exists, but the description doesn't need to detail returns for such a straightforward operation. Minor gap: no mention of return value or potential errors, but not critical.

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% (both plan_id and name have descriptions). The description itself doesn't add parameter-level detail 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 uses a specific verb and resource: 'Create a new bucket (column) in a plan.' It clearly states what the tool does and distinguishes it from sibling tools like planner_create_task by explicitly referencing 'bucket' and clarifying it as a column within a plan.

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 when you need to add a bucket to a plan, but it doesn't explicitly contrast with alternatives or state when not to use it. The sibling list shows other creation tools (e.g., planner_create_task), but no explicit differentiation 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds no behavioral detail beyond 'Create', such as whether it returns the created task, requires permissions, or what happens with duplicate titles. It provides minimal incremental value over the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with action and scope, lists optional fields efficiently. 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?

Given the 7-parameter schema with full descriptions and annotations that mark it as a non-destructive write, the one-sentence description is adequate for basic invocation. However, it lacks context about prerequisite plan existence or return value, but the schema covers the required parameters, so it's largely complete.

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

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

Schema description coverage is 100%, and the description merely paraphrases the schema's parameter list without adding new semantics (e.g., it says 'assignees' rather than adding the need to use planner_find_user, which is already in 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?

Description clearly states 'Create a Planner task in a plan' – specific verb (create), resource (Planner task), and scope (in a plan). It distinguishes from siblings like planner_create_bucket and planner_update_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?

Provides clear context for when to use (adding a new task to a plan) but doesn't explicitly name alternatives or exclusions. Sibling tools like planner_update_task are not mentioned, so it stops short of explicit guidance.

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

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

The annotations already declare destructiveHint=true and readOnlyHint=false, covering the safety profile. The description adds the explicit 'cannot be undone' warning, which goes beyond just 'destructive' and indicates irreversibility, providing useful behavioral context for the agent.

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, well-structured sentence that front-loads the action ('Permanently delete') and provides essential warning ('cannot be undone') without wasted words. It is appropriately concise for a simple delete 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 delete operation with one parameter, the description adequately conveys the core behavior and the permanent consequence. No output schema exists, so no return value explanation is required. While it could mention idempotency or error handling, the description is complete enough 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 input schema fully describes the only parameter, task_id, with a description 'Task ID', achieving 100% schema coverage. The tool description adds no additional parameter-specific meaning, so it relies on the schema's documentation, warranting the baseline score of 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?

The description explicitly states 'Permanently delete a Planner task', providing a clear verb (delete) and resource (Planner task). The warning 'This cannot be undone' reinforces its destructive nature, distinguishing it from sibling tools that update or retrieve 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 description clarifies that this tool is for permanent deletion, implying it should be used only when the task should be removed permanently. However, it does not explicitly mention alternatives or when NOT to use it, such as using update_task for modifications, so it has clear context but no exclusions or alternative naming.

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 and idempotentHint=true, covering safety. The description adds that the search is by display name or UPN/email and that the result provides a user ID for assignments. However, it does not describe behavior like multiple matches or pagination limits, though the schema covers 'top'. The added context is useful but not especially rich.

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 starts with the action ('Find a user'), states the search method, and explains the purpose. 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 lookup tool with strong annotations and a fully described schema, the description explains the purpose and search criteria. It could mention that multiple matches may be returned or clarify the response shape, but since it says 'to get the user ID' it implies the return value, making it fairly 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% and all parameters have descriptive text, so the schema already explains 'query', 'top', and 'response_format'. The description adds no extra semantic value beyond restating the query criteria. Baseline 3 applies because the schema carries the parameter documentation.

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 'Find' with a clear resource ('user') and states the explicit purpose: to get the user ID needed for task assignments and planner_list_user_tasks. This distinguishes it from sibling tools that operate on plans, tasks, or buckets rather than users.

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 the tool: when you need a user ID for task assignments or for planner_list_user_tasks. It does not explicitly name alternatives or say when not to use it, but there is no sibling tool with an overlapping purpose, so the context is clear enough.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral context by stating that bucket IDs are required for task operations and that the tool returns both plan and buckets, which is useful given the lack of an output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the primary purpose, and the second sentence adds relevant context without fluff. Every word contributes meaning.

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 tool with only two parameters and no output schema, the description sufficiently covers what the tool returns (plan and buckets) and why it matters (bucket IDs for task operations). The schema covers parameter details, so no critical information 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?

Schema description coverage is 100%, as both parameters have descriptions: 'Plan ID' and 'Output format...'. The description does not add additional parameter semantics beyond what the schema provides, 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?

The description uses a specific verb 'Get' and identifies the resource as 'a Planner plan and its buckets,' which clearly states the tool's function. It also differentiates from sibling tools like planner_create_bucket and planner_list_plans by specifying that buckets are part of the returned data.

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 a clear use context: 'Bucket IDs are needed to create or move tasks,' indicating when this tool is necessary. It does not explicitly exclude alternatives, but the context is specific enough to guide selection.

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 read-only and non-destructive behavior. The description adds that it returns description, checklist, and etags, which is additional behavioral context. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two succinct sentences, front-loaded with purpose and a helpful note about etags. 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 get with two parameters and rich annotations, the description adequately conveys what is returned (description, checklist, etags). It doesn't need to explain return format because the schema covers response_format, and output schema is absent but not critical 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 covers 100% of parameters with descriptions for task_id and response_format, including default and enum. The description adds no further parameter semantics, 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?

The description clearly states 'Get a Planner task including its description and checklist,' using a specific verb and resource. It also mentions the return of etags needed by update tools, which distinguishes it from sibling list/get 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 provides useful context that etags are needed by update tools and that updates fetch them automatically, implying when to use this tool. However, it does not explicitly mention alternatives or exclusion conditions, so it lacks a direct comparison.

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, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds behavioral context beyond annotations by specifying the exact resource scope (plans owned by a specific group) and that it lists all such plans. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states the core purpose, the second gives a practical prerequisite. It is front-loaded, concise, and contains no filler or redundant information.

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

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

For a simple list tool with strong annotations and a clear schema, the description provides the essential context: what is listed, how to get the required ID, and the read-only nature. No output schema exists, so return value details are not required.

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

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

Schema description coverage is 100%, with both parameters (group_id and response_format) already documented in the schema. The description does not add new parameter semantics beyond what the schema provides, 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 uses a specific verb ('List') and resource ('Planner plans') with a clear scope ('owned by a Microsoft 365 group'). It distinguishes from sibling tools like planner_list_tasks (tasks) and planner_get_plan (single plan).

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 clearly indicates when to use this tool (to list plans for a group) and includes a direct pointer to the prerequisite sibling tool (planner_search_groups) for obtaining the group ID. It does not explicitly exclude alternatives, but the context is clear.

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, idempotentHint=true, and destructiveHint=false, covering safety. The description adds no new behavioral traits beyond what annotations and schema descriptions provide, such as default exclusions of completed tasks or pagination limits. It is accurate but minimal.

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 concise sentences that front-load the core purpose and then mention optional filters. 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?

While annotations and schema cover most behavior, the description doesn't clarify the relationship between plan_id and bucket_id (whether both are needed, which takes precedence) or how this tool differs from planner_list_user_tasks. For a list-only tool with good schema coverage, this is adequate but leaves some usage 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 the baseline is 3. The description summarizes filters ('assignee user ID or open/completed state') which map to assigned_to and include_completed, but adds no extra detail beyond the schema's own parameter descriptions.

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

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

The description clearly states the tool's function: 'List Planner tasks in a plan (or a single bucket)' with a specific verb, resource, and scope. It distinguishes itself from siblings like planner_get_task (single task) and planner_list_plans (list plans) by focusing on tasks within a plan/bucket.

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 the tool (when you need tasks in a plan/bucket) but does not explicitly state alternatives or exclusions. It could differentiate from planner_list_user_tasks, but no such 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?

Annotations already declare the tool safe and read-only. The description adds useful behavioral context about the cross-plan scope and the dependency on planner_find_user to obtain the user ID, without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loads the core purpose, and adds a practical prerequisite. 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 list tool with strong annotations and fully documented parameters, the description is sufficient. It clarifies the exact scope and prerequisite, which covers essential context. It omits no critical behavior needed for invocation.

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

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

Schema coverage is 100%, with each parameter already described. The description adds minimal semantic value beyond the schema, only reinforcing that user_id is central to the 'assigned to a user' scope. 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 the verb 'List' and specifies the resource: 'all Planner tasks assigned to a user across every plan they participate in'. This clearly distinguishes it from sibling tools like planner_list_tasks by emphasizing the user-centric, cross-plan 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 provides clear context and a workflow hint ('Get the user ID from planner_find_user'), but it does not explicitly mention alternatives or when not to use this tool. This falls short of a 5 because no exclusions are stated.

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

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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, so the safety profile is covered. The description adds context about the use case (finding group ID) but does not describe pagination, result format, or potential multiple matches. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main purpose and immediately followed by actionable workflow guidance. No redundant or filler content; every word earns its place.

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

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

Given the tool's simple search functionality, annotations covering read-only safety, and full schema parameter descriptions, the description provides sufficient context. It clearly states the primary use case and output dependency (group ID), making it complete for an agent to decide when to use it. A minor gap is the lack of explicit mention of return structure, but output structure is not required 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%, with all parameters fully described. The description adds no new parameter-specific details beyond referencing display name, which is already in the schema. Baseline of 3 is appropriate since the schema carries the semantic load.

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 explicitly states the tool searches Microsoft 365 groups by display name, with a clear verb+resource+scope. It also distinguishes itself from siblings by noting it provides the group ID required by planner_list_plans, aligning with sibling tool names like planner_list_plans.

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?

Provides clear context: 'Use this first to find the group ID required by planner_list_plans.' This implies when to use it in a workflow, though it does not explicitly state when not to use it or mention alternatives beyond the implied sibling relationship.

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 adds behavioral insight by stating 'Fetches the current etag automatically,' which tells the agent it does not need to provide an etag. This complements the annotations (readOnlyHint=false, idempotentHint=true) and does not contradict them. However, it does not disclose partial-update semantics or error 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?

The description is two concise sentences: the first lists updateable fields, the second explains etag handling. No wasted words, and key information is front-loaded.

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 tool with 8 parameters, full schema coverage, and no output schema, the description is largely sufficient. It covers the main updateable aspects and the etag behavior. It could be improved by noting that only provided fields are updated (partial update), but this is not critical given 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?

The input schema already provides detailed descriptions for all 8 parameters (100% coverage), so the description adds minimal extra value. It mentions 'bucket (move)' and groups assignees, but these ideas are already present in the schema (e.g., 'Move to this bucket ID'). 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 clearly states it updates a Planner task and enumerates specific fields (title, bucket, due date, priority, progress, assignees). This differentiates from generic update tools, but it does not explicitly distinguish itself from the sibling planner_update_task_details.

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 advice on when to use this tool versus alternatives like planner_update_task_details. It neither states exclusions nor recommends other tools for different update scenarios, despite the presence of a similarly named sibling.

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 indicate this is not read-only, not destructive, and idempotent. The description adds that item IDs come from planner_get_task, which is helpful. However, it does not disclose behavioral details beyond the annotations, such as whether the description is replaced entirely (though the schema notes 'replaces the existing one') or how invalid item IDs are handled.

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, clear sentence that front-loads the main purpose and then specifies the distinct operations. It avoids redundancy and is appropriately sized for the tool's complexity.

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

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

While the description covers the primary operations, it lacks details about return values, error behavior, or edge cases (e.g., what happens if an item ID is invalid). With no output schema and five parameters, the description could provide more context on expected outcomes or prerequisites, though it does mention the source of item IDs.

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 parameters are well-documented. The description adds value by explicitly linking check/uncheck operations to item IDs obtained from planner_get_task and by grouping parameters into logical actions (description update, add items, check/uncheck). This enhances understanding beyond the raw 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 clearly identifies the tool's function: updating a task's description and managing checklist items. It distinguishes itself from sibling tools like planner_update_task by specifying the exact operations (description, add/check/uncheck checklist), making it highly specific.

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 useful contextual guidance by noting that item IDs come from planner_get_task, indirectly indicating a prerequisite step. However, it does not explicitly state when to use this tool over alternatives like planner_update_task, nor does it mention limitations or opposing conditions.

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