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 declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the safety and repeat-call profile is covered. The description adds nothing beyond that — it does not mention reversibility, that reopen_task can undo it, or auth requirements.

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

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

A single front-loaded sentence with zero waste. It is efficient, though arguably terse enough to leave gaps the other dimensions penalize.

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 mutation tool with annotations covering the safety profile and no output schema, the minimum is met. Still, no usage routing, no return behavior, and no mention of interactions with reopen_task/delete_task leaves the definition thin.

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 two fully described parameters, so the schema carries the meaning. The description adds no format or sourcing detail beyond the schema's own notes.

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 (mark completed) and resource (task), so the operation is unambiguous. It does not distinguish itself from siblings like update_task, delete_task, or reopen_task, which occupy nearby semantic space.

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

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

There is no statement of when to use this tool versus update_task (which can also alter status) or reopen_task, and no prerequisites called out beyond what the schema already says. Usage is only implied by the verb.

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 declare destructiveHint=true, idempotentHint=false, openWorldHint=true, readOnlyHint=false, so safety is covered. The description adds the useful scope of three move modes, but does not disclose what a move destroys (e.g., whether previous_task_id ordering is lost on list change), nor any permission or rate-limit 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?

One short sentence that front-loads the three capabilities. No padding, no repetition.

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-param destructive mutation tool with no output schema and 60% of params undocumented, the description is too thin. It should explain how the optional params combine (parent vs previous vs destination) to produce the three advertised behaviors.

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 40%. The three optional params (parent_task_id, previous_task_id, destination_task_list_id) have no schema descriptions, and the description does not explain their semantics or interactions - e.g., that previous_task_id controls ordering and destination_task_list_id triggers cross-list moves. The description's three verbs loosely map to these params but add no real clarification.

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 (move) and resource (task) and enumerates the three actions it performs: reorder, reparent, move lists. It distinguishes itself from sibling update_task by framing the operation as a move rather than a general field update, though it doesn't explicitly name that alternative.

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

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

No when-to-use guidance, no mention of alternatives like update_task, and no exclusions. The agent must infer that reparenting/reordering belongs here rather than in update_task.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the description doesn't need to repeat those. It adds the specific state change (completed → needing action), which is useful, but doesn't disclose side effects like whether subtasks or completion dates are affected.

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 that conveys the core action without any redundant 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 simplicity of the operation, the description combined with annotations and schema is nearly complete. It could mention whether reopening resets any completion metadata, but for a basic status toggle it is sufficient.

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

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

Schema coverage is 100%, so the schema fully documents both parameters (task_id and task_list_id). The description adds no additional 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?

States a specific verb ('Mark') and the exact state transition ('completed task as needing action again'), clearly distinguishing it from siblings like complete_task and update_task. An agent can immediately understand 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?

The description implies the task must already be completed ('a completed task'), providing clear context, but does not explicitly state exclusions or alternatives (e.g., use update_task for other changes).

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is partly carried by structured fields. The description adds one behavioral detail (null clears notes or due), which is useful, but does not mention destructive effects, required permissions, or partial-update semantics beyond what the annotations imply.

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, zero waste, front-loaded with the action and the affected fields. Every sentence 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?

With no output schema and half the parameters undocumented in the schema, the description should do more to cover update semantics, status enum behavior, and when to prefer dedicated tools like complete_task or reopen_task. It is adequate but leaves clear gaps for a mutation tool with sibling overlap.

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

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

Schema description coverage is 50%, with due and the two ID fields documented in the schema but title, notes, and status lacking descriptions. The description adds meaning by stating which fields can be patched and that null clears notes/due, which compensates somewhat for the uncovered parameters, but it does not clarify status values or title 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 (Patch) and resource (task) and enumerates the mutable fields (title, notes, due date, status). It is clear what the tool does, though it does not differentiate itself from siblings like complete_task or reopen_task, which also touch status.

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

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

No when-to-use or when-not-to-use guidance is given, and no alternatives are named. With siblings such as complete_task, reopen_task, and move_task, an agent could plausibly reach for update_task in cases where a dedicated tool is intended; the description leaves that ambiguity unresolved.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description does add one useful nuance: the tool only renames (overwrites the title) rather than performing a general field update, which clarifies the scope implied by the 'update_task_list' name.

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, appropriately sized for a two-parameter mutation. It is arguably too terse to be maximally helpful, but nothing is wasted.

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

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

For a simple two-parameter tool with no output schema, the description is minimally adequate. It omits the source of the task_list_id (partially covered by the schema), confirmation of return behavior, and any note that the change is idempotent.

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

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

Schema description coverage is 50%: task_list_id is documented in the schema, while title is only named. The description's 'rename' wording implies title replaces the existing name, which adds marginal meaning, but no format or length guidance beyond the schema's min/maxLength.

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 ('rename') and resource ('Google task list'), so an agent can distinguish it from update_task, update_task_list's task-level siblings. It does not, however, explicitly differentiate itself from other list-level tools like create_task_list or delete_task_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 prerequisites (e.g., needing an existing list ID), and no mention of what happens to the current title. The agent must infer all usage context.

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