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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutation behavior is disclosed. However, the description adds no extra behavioral context—it does not mention side effects like appending to an existing task, what happens if the list or task is missing, or any error conditions. With annotations present, the bar is lower, but the description still fails to enrich the behavioral profile.

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

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

The description is a single, concise sentence with the core verb and resource front-loaded. There is zero fluff, and every word contributes to the purpose statement.

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?

This is a mutation tool with four parameters and no output schema. The description does not mention prerequisites, expected parameter values, or the relationship between the parameters (e.g., that the step's text is required, that checked defaults to false). An agent would need to inspect the schema for the two documented parameters and guess on the others, which is insufficient for reliable 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 50% (list and task_id have descriptions; text and checked do not). The description does not clarify any parameter, including the purpose of 'text' or the meaning of 'checked'. It adds no value beyond the schema's partial coverage and does not compensate for the undocumented parameters.

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

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

The description clearly states the verb 'add' and resource 'step (subtask)' and ties it to a task, making the primary purpose obvious. However, it does not explicitly distinguish itself from sibling tools like create_task or update_step, relying on the word 'subtask' to imply the difference. This is clear but not fully differentiated.

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 update_step. It does not mention prerequisites (e.g., the task must exist) or conditions that would make this the right choice. No exclusions or alternative recommendations are given, leaving the agent to infer usage from the name alone.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a write operation that is not destructive. The description adds no behavioral context beyond 'create', such as whether the list is created empty, whether duplicate names are allowed, or any side effects. With annotations covering the basic safety profile, a 3 is appropriate.

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 zero waste. The action and resource are front-loaded, and there is no redundant information. It earns its place entirely.

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 one required parameter and no output schema, the description is nearly complete. The annotations cover the safety profile (not read-only, not destructive). The only minor gap is that it doesn't state what the response is or whether creation can fail, but for a simple tool this is acceptable.

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

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

Schema description coverage is 100%: the only parameter 'name' is described as 'Name of the new list'. The description adds no additional meaning beyond the schema, so the baseline 3 applies. The description's phrase 'new To Do list' aligns with the parameter but doesn't add syntax or format details.

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

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

The description 'Create a new To Do list' clearly states the verb (create) and resource (To Do list), which is sufficient to distinguish it from siblings like rename_list, delete_list, and list_lists. It doesn't explicitly name a sibling, but the action is specific enough that an agent can tell it apart.

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 it: when a new list needs to be created. It doesn't explicitly state when not to use it or mention alternatives, but the context of sibling tools (rename_list, delete_list, list_lists) makes the usage fairly clear. No explicit exclusions or alternative routing, so it's adequate but not exceptional.

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 indicate readOnlyHint=false, so a write operation is already expected, and the description adds no further behavioral context. It does not mention side effects, required fields, how the task is associated to the list, or what response is returned. There is no contradiction with the annotations, but the description carries little behavioral weight.

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

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

The description is a single concise sentence with the primary action front-loaded. It contains no filler, though the brevity means some useful context is sacrificed.

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 seven parameters, two required, and no output schema, the description is too sparse to fully support correct invocation. It fails to mention required parameters, the important flag, prerequisites, or return behavior, leaving the agent to infer critical information from 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 description mentions four optional parameters (note, due_date, reminder, steps), but adds no meaning beyond what the schema already provides. It omits 'important', a parameter lacking a schema description, and does not clarify the required list and title parameters, leaving a real semantic 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 uses the specific verb 'Create' with the resource 'task' and lists the key optional fields (note, due date, reminder, steps), making the operation clear. It does not explicitly differentiate from sibling tools like create_list, but the 'task' resource makes the target unambiguous.

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

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

No guidance is given on when to use this tool versus alternatives such as update_task or add_step. There are no stated prerequisites, such as the requirement that list and title are mandatory or that the target list must already 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?

It discloses destructive consequences beyond the annotations: cascading deletion of every task, no recycle bin or recovery path, and the requirement to confirm with the user. This goes well beyond the destructiveHint and openWorldHint annotations and does not contradict them.

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 front-load the critical consequences ('permanently delete', 'no recycle bin') before the user-confirmation note. Every clause earns its place without 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?

With a one-parameter schema fully described, no output schema, and annotations covering the safety profile, the description supplies all needed operational context: what is destroyed, irreversibility, and the confirmation step. Nothing necessary for calling it correctly 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 coverage is 100% and fully documents the single required 'list' parameter, so the description is not responsible for explaining parameters. It adds no param-specific meaning, earning the baseline 3 for fully-covered schemas.

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 ('delete'), resource ('To Do list'), and scope ('every task in it'), making it clearly distinct from sibling tools like delete_task. The permanence qualifier removes any ambiguity about the operation.

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

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

It clearly establishes when to use the tool: to permanently delete a list after user confirmation. It doesn't explicitly name alternatives or when-not-to-use conditions, but the sibling list and task tools make the distinction straightforward.

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 disclose destructiveHint=true and readOnlyHint=false, so the description does not need to restate that this is destructive. It adds minimal context ('from a task') but does not describe consequences such as permanence or effects on the task's step 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?

The description is a single concise sentence that front-loads the action and contains no filler or redundant restatement. 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?

For a simple delete operation, the required parameters are fully documented in the schema and the safety profile is covered by annotations. The description is mostly sufficient, though it does not mention return behavior or permanence beyond what the annotations imply.

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 required parameters are already documented. The description adds no additional parameter-level meaning beyond the general statement that a step is deleted from a task.

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 ('Delete') and names the resource ('a step') and its container ('a task'), making the operation unambiguous. It is clearly distinct from sibling tools like delete_task or update_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?

The description implies the tool should be used when a step needs to be removed, but it provides no explicit when-to-use guidance, no exclusions, and no mention of alternatives. Usage context is adequate but left 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?

Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds the crucial irreversibility detail: 'no recycle bin.' This goes beyond the annotation by clarifying that deletion is permanent and not recoverable, which is valuable behavioral context.

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

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

Two sentences with no fluff. The most important fact (permanent deletion, no recycle bin) is front-loaded, and the alternative is given immediately after in a single clear directive.

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 delete operation, the description is complete: it explains the destructive nature, provides the key routing to update_task, and the schema covers all parameters. No output schema exists, so no return-value explanation is 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%, so the schema fully documents both list and task_id. The description adds no parameter-specific meaning beyond the schema, which aligns with 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 clearly states the tool's action: permanently delete a task, with the critical qualifier that there is no recycle bin. It distinguishes itself from update_task by explicitly noting that completing a task should use update_task(completed=true) instead.

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 an explicit alternative and the condition under which it should be used: to finish a task, use update_task(completed=true). This directly helps an agent choose between delete_task and update_task, the most likely sibling-tool conflict.

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 the description's 'Get' aligns with that, so there is no contradiction. The description adds only a list of returned fields, not additional behavioral traits such as error behavior, permissions, or side effects, which annotations do not require for a safe read 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?

Single sentence with no filler; key scope ('one task in full') is front-loaded and the field list is compact and useful.

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

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

For a simple read tool with full schema parameter documentation and annotations covering safety, the description is complete: it enumerates the return payload fields despite no output schema. An agent can select and call it correctly.

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

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

Schema covers both parameters at 100%, including list's case-insensitive display name or id and task_id's provenance from list_tasks. The description adds no parameter-level meaning beyond this, so baseline 3 applies.

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

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

States a specific operation ('Get one task in full') and distinguishes from list_tasks by promising full task detail. Enumerates return contents, making the resource and scope unambiguous.

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

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

Implied usage: retrieving a single task by ID, with no explicit when-to-use versus list_tasks or alternatives. There is no exclusion guidance or selection condition, though 'one task in full' offers some 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 readOnlyHint=true and openWorldHint=true, covering safety and non-exhaustiveness. The description adds scope details about including default lists and flagged emails, which is helpful, but it does not disclose return format, ordering, or whether results include IDs needed for later mutations.

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

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

One sentence with no filler. It leads with the core action ('List all To Do lists') and adds the important default-list detail in a parenthetical, making it front-loaded and 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 no-argument read-only tool, the description is nearly complete. It states what is listed and even enumerates the default entries; the only minor gap is that without an output schema it does not say what fields each list object includes, but that is not necessary just to invoke the tool.

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

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

The tool has zero parameters and the schema is trivially complete. With no parameters to document, the description has little semantic burden, so the baseline 4 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: 'List all To Do lists', and it clarifies the scope by calling out the default 'Tasks' list and 'Flagged Emails'. This clearly distinguishes it from sibling tools like create_list, rename_list, delete_list, and list_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 tool's purpose is obvious and the 'all' wording implies it is the enumerating read operation for To Do lists, but it does not explicitly state when to prefer it over siblings such as list_tasks or when it should be used before rename/delete operations. Usage context is implied rather than explicit.

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

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

Beyond readOnlyHint/openWorldHint, the description discloses non-obvious behaviors: default hiding of finished tasks, newest-first ordering, and 200-character note truncation with an escalation path. 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?

Three short sentences, each carrying a distinct fact: operation/order, status filtering, and truncation behavior with a pointer to get_task. No filler and the most important usage caveats come first.

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?

Covers the main caveats an agent needs: ordering, default status filtering, and truncation. There is no output schema, but the return shape is inferable; pagination is not described but is covered by the limit parameter in 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 the schema already documents all five parameters. The description adds behavioral context around status and limit ('newest first') but does not add parameter-level meaning beyond that, so baseline 3 applies.

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

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

States a specific verb and resource ('List tasks in a list'), adds an ordering guarantee ('newest first'), and explicitly points to get_task for full task details, distinguishing it from the single-task sibling.

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

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

Gives concrete guidance to use get_task when notes are truncated, and clarifies that completed tasks are hidden unless status is completed/all. It does not explicitly mention list_lists, but the verb/resource makes the distinction 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 indicate destructive and read-only behavior, but the description adds no additional behavioral context beyond the literal rename action. It does not mention whether the list id stays stable, whether tasks are affected, or whether the rename is reversible, so the description carries little weight beyond 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 a single, concise sentence with no filler or repetition. It delivers the core instruction upfront without wasting tokens.

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 mutation, the description plus schema is reasonably sufficient to attempt a call. However, the missing usage guidance and lack of new_name semantics create noticeable gaps, even though no output schema is present to explain return values.

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

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

Schema description coverage is only 50%, and the description does not compensate. The 'list' parameter is documented in the schema, but 'new_name' has no description, and the tool description adds no constraints like uniqueness, length limits, or formatting expectations.

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 ('Rename') and resource ('a To Do list'), making the operation immediately clear. It is also distinct from the sibling tools like create_list, delete_list, and list_lists, so an agent can tell them apart without opening the schema.

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

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

The description gives no guidance about when to use this tool instead of alternatives, nor any prerequisites such as the list needing to already exist. There is no mention of when renaming is appropriate or what happens if the new name conflicts with an existing list.

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 as a non-read-only, destructive, idempotent mutation. The description adds no behavioral details beyond that, such as what happens when text or checked is null, or what side effects occur. It is consistent with annotations, so there is no contradiction.

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

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

One short sentence with no filler; the operations are front-loaded. It is concise and skimmable, though it could include more guidance without becoming verbose.

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

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

For a simple two-operation update tool, the description plus schema/annotations covers the basics. Gaps remain: it does not state that text and checked may be null/no-op, and it gives no guidance on choosing between update_step and the sibling update/add/delete tools.

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 60%; list, step_id, and task_id are described in the schema. The description adds meaning to the two undocumented params by mapping 'Rename' to text and 'tick/untick' to checked, but it does not clarify null defaults or the effect of omitting both optional fields.

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 ('a step') and two precise actions: 'Rename' and 'tick/untick'. This clearly distinguishes update_step from add_step/delete_step and from update_task, even without explicitly naming sibling 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?

The intended use is implied: call this when a step's text or checked state needs to change. However, there are no explicit when-to-use or when-not-to-use statements, no exclusions, and no named alternative tools.

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 the annotations, the description reveals valuable behavior: only passed fields are changed, and fields are removed via `clear` rather than by passing null. This clarifies partial-update semantics and the destructive removal mechanism, which the raw annotations do not convey.

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-load the core purpose and immediately explain the most important behavioral nuance. Every word earns its place, with no redundancy or filler.

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

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

The schema covers parameter formats and required fields, while the description supplies the crucial partial-update and clearing semantics. The definition is sufficient for correct invocation, though it omits return-value expectations and does not explicitly distinguish this tool from siblings.

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 78%, so the schema already documents most parameters. The description adds nuance around the `clear` parameter, but it does not compensate for the undocumented `title` and `important` parameters, leaving those meanings to inference.

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

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

The description clearly states the verb and resource—'Change a task'—and adds the key semantic that it is a partial update. However, it does not differentiate update_task from its siblings beyond the tool name, and it doesn't enumerate which task fields can be updated.

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 offers no guidance about when to use update_task versus alternatives like create_task, delete_task, or rename_list. The mention of `clear` is operational parameter guidance, not selection criteria, so there is no explicit when-to-use/when-not-to-use context.

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