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

Annotations already mark destructiveHint=true, so the description is not burdened with that. It adds the safety-critical behavior that explicit confirmation is required, and clarifies the operation is a 'hide' rather than a per-task delete. 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 short sentences, each earning its place: the first states the action and scope, the second states the confirmation requirement. No filler, front-loaded with the primary behavior.

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 two-parameter, destructive tool with full schema coverage and annotations, the description provides the essential action and confirmation requirement. It could mention reversibility or side effects of 'hide', but an agent has enough information to invoke the tool 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 coverage is 100% with detailed descriptions for both confirm and task_list_id, so the description need not elaborate. The phrase 'Requires explicit confirmation' mostly mirrors the schema's confirm description and adds no extra parameter-level meaning. 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?

Description uses a specific verb and resource: 'Hide all completed tasks in a list.' It clarifies the tool name's 'clear' as 'hide' and clearly distinguishes this from single-task siblings like complete_task and delete_task. The scope and action are 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?

Provides a clear context: use when you want to hide completed tasks in a list, and notes the confirmation prerequisite. It does not explicitly name alternatives or exclusions, but the purpose is specific enough for an agent to select it over single-task 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?

Annotations already indicate this is a mutating but idempotent, non-destructive operation. The description adds that the task's status changes to completed, but discloses no further behavioral context such as side effects on task ordering or visibility. This is acceptable given the annotation coverage but not 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 efficient sentence with no filler or redundancy. It is appropriately sized for a simple status-change operation, though it is very close to restating the tool name.

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 with a complete input schema and no output schema, the description is mostly sufficient. The main missing piece is any explicit statement about behavior when the task is already completed, but the idempotentHint annotation partially covers that.

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

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

The input schema has 100% description coverage, clearly explaining that task_id comes from list_tasks and task_list_id comes from list_task_lists. The description adds no parameter-level meaning, so the schema carries the full burden and the baseline score 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 states a specific action and resource: 'Mark a task completed.' This is clear and unambiguous as a verb-plus-resource statement. It does not explicitly differentiate from sibling tools like update_task or reopen_task, but the completion semantics are distinct enough to infer.

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 about when to use this tool versus alternatives such as update_task or reopen_task. The usage is only implied by the description and tool name, and no conditions, prerequisites, or exclusions 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?

Annotations already indicate this is a write operation (readOnlyHint=false). The description adds context about subtask and sibling semantics, which goes beyond the schema, but it does not disclose return value, side effects, or potential constraints (e.g., parent_task_id must belong to the same list). This is modest additional transparency.

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

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

The description is a single sentence that is front-loaded with the core action and then adds the optional placement behavior. It contains zero filler and is efficiently structured.

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 description is minimal: it covers placement but omits return value (no output schema present) and does not mention relationships between parent_task_id/previous_task_id and task_list_id. While the schema covers required fields, an agent might need more guidance on expected behavior or error cases. For a relatively simple create operation, the description is adequate but not rich.

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 schema description coverage at only 33%, the description compensates for the two most ambiguous parameters: parent_task_id is explained as creating a subtask, and previous_task_id as placing after a sibling. Other parameters are either self-explanatory or documented in the schema (due, task_list_id). This adds meaningful clarity.

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

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

The description clearly states the action ('create') and resource ('a task'), and adds placement options ('as a subtask or after a sibling') that distinguish it from other create/update tools in the sibling list. There is no ambiguity about what this tool does.

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

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

The description implies usage for creating tasks and mentions optional subtask/sibling placement, but does not explicitly contrast with alternatives like create_task_list or update_task. An agent can infer when to use it, but the description provides no explicit when-not or alternative routing.

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

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

The description discloses only that it creates a task list, which matches the readOnlyHint=false annotation, but adds no behavioral context beyond that. It does not mention permission requirements, side effects (despite openWorldHint=true), or what happens on success. The burden of disclosure falls entirely on the description since annotations are minimal, and it fails to provide any additional transparency.

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

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

The description is a single, short sentence that is front-loaded and free of fluff. It efficiently states the tool's purpose, though it under-specifies other needed details; this is more a completeness issue than a conciseness one.

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 creation tool with no output schema, the description should at least indicate the expected output (e.g., the created list's ID) or any unique behavior. It does neither, leaving the agent without essential information about the outcome of the call.

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 0%, meaning the description must compensate for the lack of parameter documentation, but it does not explain the 'title' parameter at all. The parameter is self-explanatory from its name, but the description does not add any meaning beyond the schema's min/max constraints.

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

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

The description clearly states the action ('Create') and the resource ('Google task list'), which unambiguously differentiates it from sibling tools like list_task_lists, get_task_list, update_task_list, and delete_task_list. The verb and object are specific enough that an agent would not confuse it with create_task (a task, not a list).

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

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

There is no guidance on when to use this tool versus alternatives—no mention of distinguishing from create_task or any preconditions. The description only states what it does, not the context in which it should be chosen over siblings.

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

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

Annotations already indicate destructive=true, and the description adds that deletion is permanent and requires explicit confirmation. This provides useful safety context about irreversibility and user consent. No contradiction with annotations; readOnlyHint=false is consistent with the write operation.

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

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

The description is two short sentences with no filler. The core action is front-loaded, and the confirmation requirement is the only additional essential 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 delete operation, the schema and annotations together cover the required IDs, the confirmation mechanism, and destructiveness. The description adds permanence and consent. There is no output schema, so omitting return-value details is acceptable. Minor gaps like behavior on nonexistent tasks are 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?

Input schema coverage is 100%, and each parameter is already well documented: task_id and task_list_id explain where to obtain them, and confirm explains the const=true requirement. The description adds no new parameter details beyond reinforcing the confirmation requirement, matching the baseline for high schema coverage.

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

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

The description states a specific verb ('delete') and resource ('a task'), with 'Permanently' adding important scope. It is clearly distinguishable from sibling tools like complete_task, delete_task_list, and clear_completed_tasks, so an agent can select it correctly without opening schemas.

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 a clear precondition: explicit confirmation is required before calling. However, it does not explicitly contrast with sibling operations (e.g., using complete_task instead of deletion, or delete_task_list for removing an entire list), so usage guidance is only implied rather than fully spelled out.

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 mark the tool as destructive, non-read-only, and non-idempotent. The description adds context beyond the annotations by emphasizing that deletion is permanent and that explicit confirmation is a requirement. This is valuable extra behavioral disclosure.

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 the core action first and the safety prerequisite second. There is no redundancy or filler; every word contributes to the tool's usability.

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 destructive tool with two well-documented parameters and strong annotations, the description is nearly complete. It covers permanence and confirmation. The main gap is that it does not clarify whether deleting a task list also deletes its contained tasks, which is relevant given the sibling task 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?

The input schema already provides complete descriptions for both parameters, including the source of task_list_id and the role of confirm. The description's confirmation requirement mirrors the schema but adds no new parameter-specific meaning, 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 clearly identifies the action (permanently delete) and the resource (Google task list). This distinguishes it from siblings like delete_task, which targets a different resource, and makes the tool's purpose immediately obvious.

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 states a clear prerequisite: explicit user confirmation is required. However, it does not explicitly explain when to use this tool versus alternatives such as update_task_list or delete_task, leaving the distinction to be inferred from the resource 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, idempotentHint=true, and destructiveHint=false. The description adds a small behavioral constraint ('one task' as opposed to a list), which is consistent with the annotations and provides marginal value beyond them, but it does not disclose error behavior, return format, or prerequisites.

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 filler. It conveys the operation, resource, and required identifiers in a directly usable format.

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

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

For a simple single-task retrieval with fully documented parameters and safety annotations, the description is sufficient to invoke correctly. Return shape and error handling are not described, but the absence of an output schema and the low tool complexity make this 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%, with each parameter already documented as to how to obtain it. The description restates the parameter names but adds no extra semantic detail beyond what the schema provides, 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 ('Get'), a specific resource ('one task'), and the required identifiers ('task-list ID and task ID'). This clearly distinguishes it from list_tasks (returns multiple tasks) and get_task_list (returns a task list), even without naming alternatives.

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

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

The description implies usage when a single task is needed and both IDs are available, but it does not explicitly state when not to use this tool or name alternatives. The schema parameter descriptions partially compensate by directing the agent to list_tasks and list_task_lists for ID provenance.

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, fully covering the safety profile. The description adds the scoping constraint "one ... by ID" but discloses no additional behavioral traits such as not-found behavior, rate limits, or response shape. 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?

The description is one short sentence with the verb front-loaded and zero filler. Every word contributes to the meaning. This is appropriately concise for a simple single-parameter retrieval tool.

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 read-only tool with full schema coverage and safety annotations, the description plus schema is sufficient for an agent to invoke it correctly. The only minor gap is the lack of an explicit return-value statement, but "Get" strongly implies the task list object is returned. No output schema exists, so this is a small but acceptable omission.

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 parameter description already explains that task_list_id is the Google task list ID and where to obtain it. The description only says "by ID", which slightly reinforces the parameter's role but does not add meaning beyond what the schema already provides. 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 "Get one Google task list by ID" has a specific verb (Get), a specific resource (Google task list), and the qualifier "one ... by ID" clearly distinguishes it from list_task_lists (which lists all) and task-level tools like get_task. The purpose is unambiguous even without referencing sibling names.

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 itself gives no explicit when-to-use guidance or alternatives. However, the parameter description in the schema — "obtain it from list_task_lists" — implies a workflow of first listing task lists to get an ID, then calling this tool. This provides implied usage context but no explicit exclusions or alternative routing.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint). The description adds useful context by specifying the operation is scoped to the authenticated user, but it does not disclose pagination behavior, return format, or default/limit semantics.

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 that is front-loaded and contains no filler. It communicates the tool's purpose clearly and efficiently.

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

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

For a simple, optional-parameter read operation backed by strong annotations, the description is largely sufficient. It could add a note about pagination or maximum result behavior, but the schema already disambiguates the optional parameters with defaults and constraints.

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 is expected to compensate for the two parameters. It does not mention page_token or max_results at all, leaving the agent to infer their meaning solely from schema titles and constraints.

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'), a clear resource ('Google task lists'), and a scope ('authenticated user's'). The plural 'task lists' distinguishes it from the sibling get_task_list, which targets a single list, and from list_tasks, which targets tasks inside a list.

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

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

The usage context is implied: use this tool when needing to enumerate the authenticated user's task lists. However, there is no explicit guidance about when to prefer this over siblings like list_tasks or get_task_list, and no exclusions or alternatives are named.

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=false, covering the safety profile. The description adds only a generic 'filters and pagination' note, which is largely a restatement of the schema properties. It does not disclose return shape, default behaviors like show_completed=true, or rate-limit/auth details, but it is consistent with 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, tight sentence that front-loads the core action and scoping. Every word contributes meaning, with no filler or 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 11 parameters, no output schema, and very low schema description coverage, the description is too thin. It does not explain what the returned task objects look like, how pagination should be used, or the semantics/interaction of the date filters. The read-only annotations reduce risk, but an agent still lacks enough context to call this tool confidently with non-trivial filters.

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 9%, with only task_list_id described. The description does not compensate by explaining the filter parameters (due_min, due_max, completed_min, completed_max, updated_min), date formats, or pagination mechanics. The parameter names are somewhat self-explanatory, but the description adds little semantic value beyond what the raw schema already shows.

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 ('tasks in a Google task list'), and adds 'filters and pagination' to distinguish it from simply retrieving a task list. It is clearly distinguishable from siblings like list_task_lists, which lists task lists, and get_task, which retrieves a single 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?

The description implies this tool is for browsing/filtering tasks within a specific task list, but it does not explicitly state when to use it instead of alternatives like get_task for a single task or list_task_lists for task lists. There is no exclusions or when-not-to-use guidance, so usage is mostly implied.

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 a non-read-only mutation (readOnlyHint=false), and the description adds behavioral scope by listing reorder, reparent, and cross-list move. But it does not disclose important behavioral details such as the role of task_list_id as the source list, the meaning of previous_task_id for ordering, or whether moving across lists requires destination_task_list_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?

A single, tightly written sentence that front-loads the core operations with no filler or irrelevant 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 5-parameter tool with no output schema, the description and sparse schema leave critical ambiguity: the distinction between task_list_id and destination_task_list_id, the meaning of previous_task_id, and constraints around parent changes are all unexplained. An agent would need to infer or probe API behavior, making the definition incomplete for 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?

Only task_id and task_list_id have schema descriptions, so coverage is 40% and the three optional parameters are left undocumented. The description maps high-level operations to parent_task_id, previous_task_id, and destination_task_list_id, but it does not explain their precise semantics, such as previous_task_id indicating the task after which the moved task should appear.

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 three concrete operations (reorder, change parent, move to another task list) on the specific resource 'task'. This clearly distinguishes it from sibling tools like complete_task, reopen_task, and delete_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?

The description implies when to use the tool: when you need to reorder, reparent, or relocate a task. However, it never explicitly contrasts this with update_task or states when not to use it, leaving the agent to infer the decision boundary.

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 directly explains the behavioral effect: transitioning a task from completed back to needing action. Annotations already cover non-read-only, idempotent, and non-destructive properties, and the description adds the key semantic detail without contradicting those 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, front-loaded sentence with no filler. Every word contributes meaning, and the core action is immediately clear.

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 mutating tool with fully documented parameters and annotations covering safety and idempotency, the description is complete. No output schema exists, but the operation is simple enough that return-value details are not essential for 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?

Schema coverage is 100% and both parameters are described with source hints ('obtain it from list_tasks'). The description adds one important piece of semantic context beyond the schema: the target task must be completed. This helps the agent understand which task_id is valid for this operation.

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 ('Mark') and resource ('a completed task') plus the intended outcome ('needing action again'). It clearly conveys the state transition and is easily distinguished from the sibling tool complete_task, which performs the reverse operation.

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

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

The description provides clear context: use this tool when a task is completed and should be brought back into an actionable state. It does not explicitly mention alternatives or exclusion cases, but the 'completed task' prerequisite is strong enough guidance for an agent.

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 a key behavioral detail beyond the annotations: 'Use null to clear notes or due.' This clarifies the semantics of null values, which is especially important for a patch operation. Annotations already indicate it is mutating, idempotent, and non-destructive, so the description does not need to repeat those.

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, information-dense sentences. The main action is front-loaded, and the null-handling detail is included without fluff. 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 patch operation with annotations already covering safety and idempotency, the description is mostly sufficient. It could be improved by stating what the tool returns (e.g., updated task object), since there is no output schema. The null semantics are covered, and required parameters are 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 coverage is only 50%, and the description helps compensate by explaining that null clears notes and due dates. It also enumerates the editable fields, mapping directly to the parameters. However, it does not add meaning for title or status beyond what the schema's constraints and enum convey, so the compensation is partial.

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?

Uses the specific verb 'Patch' and names the resource 'task' followed by an explicit list of updatable fields (title, notes, due date, status). This clearly distinguishes it from specialized siblings like complete_task or move_task, even without naming them.

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: use this tool when you need to update those four fields. However, it gives no explicit guidance about alternatives such as complete_task or reopen_task for status changes, or move_task for relocating tasks. The usage context is inferred rather than 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 destructiveHint=false and idempotentHint=true. The description adds that this is a rename operation, meaning it replaces the list title without deleting the list. It does not mention side effects on contained tasks or permissions, but annotations carry the core safety 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 five-word sentence with no filler. The operation is front-loaded and 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 two-parameter rename tool with annotations covering idempotency and non-destructiveness, the description plus schema provide enough to select and invoke it. The lack of an output schema and minimal depth about return values are minor gaps for this low-complexity 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 schema documents task_list_id well, including how to obtain it. The 'Rename' wording implies the title parameter is the new list name, adding some meaning, but title has no direct schema description and the tool description does not elaborate on it. With 50% schema coverage, this is adequate but not fully compensating.

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

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

Description states a specific verb ('Rename') and resource ('Google task list'), clearly distinguishing it from create_task_list, delete_task_list, and update_task. There is no ambiguity about what the tool does.

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 makes the intended use clear: use this tool to rename a task list. It does not explicitly name when not to use it or point to alternatives, but the operation is unique among siblings and the context is intuitive.

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