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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds the crucial nuance that the operation only hides tasks and is reversible via list_tasks with include_completed=true. It also discloses the user-confirmation requirement, which is behavioral context not present in 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?

Two short sentences with zero waste. The core action is front-loaded, followed immediately by the non-destructive clarification and retrieval path.

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 tool has an output schema, so return values need not be explained. The description covers reversibility, the user-confirmation prerequisite, and how to retrieve hidden tasks afterward, which is complete for a two-parameter, idempotent hide operation.

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%. The task_list_id parameter is well documented in the schema, but the confirm boolean has no schema description. The description alludes to confirmation ('after user confirmation') without explaining that it maps to the confirm flag or that it defaults to false, so it only partially compensates for the schema 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?

States a specific verb and resource: 'Hide completed tasks.' The follow-up sentence distinguishes the operation from permanent deletion, which is exactly the confusion an agent could have among siblings like delete_task and 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?

The description gives a clear prerequisite ('after user confirmation') and a retrieval alternative ('list_tasks with include_completed=true'). It does not explicitly say when not to use this tool versus deleting individual tasks or deleting a whole list, but the context is strong enough to route correctly.

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 goes beyond simple status change by detailing *how* the modification occurs: it avoids overwriting the title, notes, or due date. This is a valuable behavioral constraint for a write operation, adding specific context that even the annotations do not cover.

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?

It is a single, tightly written sentence where every word is necessary. It immediately communicates the exact function and its limitations.

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 definition is highly complete for its scope. The agent knows precisely which entities it is affecting and what the consequences of the call will be (status change without data loss).

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?

Since schema coverage is 100%, the description adds minimal semantic value. However, it provides crucial context that the IDs must be 'Google IDs,' which helps the agent understand the required input format.

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 purpose: marking a task complete. It distinguishes itself from a general update operation by specifying the constrained action of completion rather than a full modification.

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?

While the action itself implies usage, the description doesn't explicitly advise when to choose this tool over a general update tool. It is clear what the tool does, but not necessarily the full decision criteria for using it.

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 (idempotentHint=false, destructiveHint=false), the description adds real behavioral context: the Google write-permission requirement and an explicit non-idempotency warning with a recovery heuristic. It does not describe what is returned, but an output schema exists to cover that.

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, front-loaded sentences with no filler; the core verb and scope come first. Slightly fragmented by the line breaks, but every sentence carries useful information.

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

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

Given an existing output schema and annotations covering safety/idempotency, the remaining burden is prerequisites and placement semantics, both of which are addressed. A minor gap is the absence of cross-references to sibling tools for follow-up actions.

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 low (17%), so the description must compensate. It does: "optionally as a subtask or after a sibling" explains the otherwise opaque parent_id/previous_id semantics, and "due is a calendar date, never a time" reinforces the date format constraint. Notes and title remain undocumented but are self-evident.

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 opens with a specific verb+resource ("Create a task") and immediately clarifies the two placement variants (subtask via parent, ordering after a sibling), which are non-obvious behaviors of this tool. It does not name siblings, but create vs update/move is 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?

It gives one concrete conditional rule — check the list before repeating a call when the outcome is unknown — and notes the write-permission prerequisite. However, it offers no explicit alternatives (e.g., use update_task to modify or move_task to reposition), so guidance is partial rather than complete.

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?

"Not idempotent" merely restates idempotentHint=false, so it earns no credit, while "duplicate names are permitted by Google" does add real value by clarifying that duplicates will not raise an error. It says nothing about required permissions, which account/workspace the list lands in, or failure modes, so it goes beyond annotations only modestly.

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 front-loaded and no filler. The idempotency clause is slightly redundant with the annotation, keeping it from a 5.

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 tool with an output schema, the description is mostly adequate, but it omits where the list is created (which account/workspace, relevant given openWorldHint=true) and any prerequisite ordering relative to create_task. Return shape is rightly left to the output 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?

With a single parameter at 0% schema description coverage, the description carries the burden of explaining 'title' but provides only an indirect clue via the duplicate-names remark (uniqueness not enforced). Length constraints and any naming conventions are left entirely to the schema.

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

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

"Create a task list" states a specific verb and resource, clearly separating it from siblings like rename_task_list, delete_task_list, or list_task_lists. It is clear but does not explicitly name alternatives the way a 5 would.

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 explicit when-to-use or when-not-to-use guidance versus siblings is given. The note that duplicates are permitted implicitly suggests checking list_task_lists first if uniqueness matters, but this must be 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=true and idempotentHint=false, but the description adds real value on top: the confirmation requirement, the expected-title guard against acting on a stale ID, and the disclosure that Google does not expose recurrence metadata so the tool cannot be scoped to a single instance. That recurrence limitation is exactly the kind of caveat an agent cannot infer from structured fields.

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 tight paragraphs with the destructive action and its preconditions front-loaded. The recurrence paragraph is longer than strictly necessary and its 'do not promise that...' phrasing is agent-directed rather than tool-directed, but the information is not 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 destructive, open-world mutation with an output schema present, the description covers the safety prerequisites and a Google-side limitation. What remains unstated is the failure mode when expected_title does not match the stored title, and the pointer to get_task for retrieving the exact title.

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 compensates by documenting the two undescribed parameters: expected_title ('its exact current title') and confirm ('confirm=true'). It does not explain why the title must match (staleness protection) or how the caller should obtain the current title, so it falls just short of full compensation.

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 with a scope qualifier: 'Permanently delete a task'. The 'permanently' and 'after user confirmation' framing immediately separates it from reversible siblings such as complete_task or update_task.

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

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

Explicitly names the alternative path — 'prefer completion when appropriate' — and states the precondition of obtaining user confirmation plus the exact current title. The qualifier 'when appropriate' is left slightly vague rather than spelling out the condition, which keeps it short of a 5.

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 'destructiveHint' annotation, the description adds significant behavioral context: it requires the 'exact current title' as a precondition, and it clarifies that the task check includes 'hidden and completed tasks,' which is a crucial operational detail.

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?

Despite the high complexity of the operation, the description is highly efficient. Every sentence is focused on establishing a precondition, a constraint, or a specific behavioral outcome, resulting in zero waste.

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?

Considering this is a high-risk, low-coverage, destructive tool with complex prerequisites (ID matching, title matching, content checks), the description is entirely comprehensive, preventing ambiguous execution paths.

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?

Given the low schema description coverage (25%), the description adds massive value by clarifying the roles of the required parameters (ID vs. title) and detailing the complex logic governing the 'allow_nonempty' flag and user approval flow.

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 purpose is stated clearly: 'Permanently delete a task list.' It is specific and distinguished from sibling tools by specifying the complex content checking behavior required during the deletion process.

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

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

It provides crucial usage guidelines by defining the content constraints. It explicitly states that deletion is refused unless 'allow_nonempty=true' is set, providing a clear operational boundary for the 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 goes significantly beyond the hints by detailing *how* it behaves operationally—namely, it operates locally and does not initiate network requests to external services ('without... contacting Google'). This is a crucial behavioral constraint missing from standard 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 definition is perfectly sized (a single sentence). Every part of the sentence contributes equally by defining the output, the scope, and the operational limitations.

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 that the function is read-only and stateless (0 parameters), the description is complete. It provides all necessary context regarding what the agent will receive and how the operation is bounded.

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?

Since the tool takes zero parameters, the description must act entirely as context. It effectively defines the scope of the information retrieved (config and permissions), making the definition robust despite the empty schema.

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

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

The description uses a specific verb ('Show') and clearly defines the resource and data being exposed ('local configuration and stored permission status'). It is highly distinguishable from the task-management siblings.

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?

While it doesn't compare itself to a specific alternative, it provides critical usage constraints by defining the operational boundary. The explicit mention of not exposing secrets or contacting Google guides the agent on appropriate use cases (i.e., safe, local inspection).

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds that the full notes are included in the result, which is meaningful behavioral context about payload depth 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?

A single sentence with zero waste; the scoping constraint and payload note are front-loaded.

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

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

With an output schema, full parameter descriptions, and rich annotations, the short description is sufficient for an agent to call this correctly; nothing material is missing.

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

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

Schema description coverage is 100% and both parameters already document 'Exact Google ID from a previous tool result; names are not IDs.' The description only echoes the 'exact' requirement, adding little beyond the schema, 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 (Read) and resource (one task), scoped by exact list and task IDs, and notes that full notes are returned. It clearly contrasts with bulk siblings like list_tasks/search_tasks by saying 'one task', though it does not name those siblings explicitly.

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 phrase 'by exact list ID and task ID' implies you must already hold IDs from a prior result, which is useful guidance, but there is no explicit when-to-use versus search_tasks/list_tasks or any stated prerequisite or failure mode.

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 readOnly/idempotent/non-destructive, so the description rightly spends its space on what annotations cannot express: truncation semantics (truncated vs scan_truncated), per-group caps with full counts, and timezone resolution order (parameter > GTASKS_TIMEZONE > UTC). Only gap is silence on the max_lists/max_tasks scan bounds' effect on results.

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 core action is front-loaded in the first sentence, and each following sentence adds distinct semantics (timezone, window definition, caps, truncation flags) with no filler. Slightly fragmented across line breaks but still tight.

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 an output schema present, the description needn't enumerate return fields, and it instead explains the two subtle response flags that a schema alone would not clarify. It leaves the scan-bound parameters (max_lists, max_tasks) undocumented, which is the main completeness gap for a 6-parameter 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?

Schema description coverage is 0%, so the description must carry the load. It does well for timezone (IANA format, default resolution) and days ('tomorrow through today plus days, inclusive') and limit_per_group, but max_lists, max_tasks, and task_list_id are never mentioned, leaving half the parameters unexplained anywhere.

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: grouping open tasks into overdue / due today / upcoming / undated buckets. That is clearly distinct from sibling read tools like list_tasks or search_tasks, though the description never names those siblings to make the contrast explicit.

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

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

Usage is only implied by the word 'digest' and by the grouping behavior; there is no statement of when to prefer this over list_tasks or search_tasks, and no note on prerequisites such as needing a task_list_id scope. The reader can infer intent but gets no explicit routing guidance.

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

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

Annotations already cover readOnly, idempotent, openWorld, and non-destructive, so the description's job is to add context — and it adds essentially none: no behavior on an unknown/expired ID, no note that only list metadata (not its tasks) comes back, no auth notes. 'Exact' only echoes the constraint already stated in the schema.

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

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

One short sentence, front-loaded with verb and scope, with zero redundant or filler content.

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?

Rich annotations plus an output schema plus a fully documented single parameter mean little prose is required, and the description covers the essentials of a simple getter. A one-clause contrast with the list/search siblings would have closed the remaining gap.

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 the single parameter is fully documented there, including the 'names are not IDs' caveat, so the baseline is 3. The description reinforces the exact-ID semantics but contributes no new syntax or format detail.

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 with scope ('Read one task list'), so an agent can distinguish it from list_task_lists or delete_task_list by the singular 'one'. It never names a sibling or explicitly rules out alternatives, so it stops short of a 5.

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

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

Usage is only implied: 'by its exact Google ID' suggests a lookup of an ID obtained elsewhere, but the description never says when to prefer this over list_task_lists or get_task, nor what to do when only a name is known (that hint lives in the schema, not the description).

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 confirms the paged nature of the call ('one page') and the use of tokens for iteration, which are behavioral traits not fully captured by the structured hints alone. The presence of `readOnlyHint: true` suggests safety, and the description focuses on retrieval mechanics.

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 highly concise, fitting two points of information into two short, direct sentences that focus entirely on functional constraints and pagination 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?

While it explains pagination, the description is incomplete for a 2-parameter tool. It doesn't clarify the expected format of the page token or what the returned data structure contains beyond IDs and names. A minimal 'how-to-use' guide 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?

With 0% schema coverage, the description is the primary source of semantic meaning. It mentions 'one page' and 'exact IDs', which hints at how `page_size` and the results are delivered. However, it doesn't explain the format of the 'exact IDs' or how the token is provided/returned.

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 lists 'task lists' and provides two specific, actionable data points: 'exact IDs' and 'one page'. Although the title is null, the description functions well to define the core action.

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

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

It explicitly addresses navigation through the entire dataset by stating that names might not be unique and instructs the user to use the `next_page_token` for subsequent calls. This provides excellent guidance on repetitive execution.

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 read-only/idempotent annotations, the description discloses several important behaviors: completed tasks are excluded by default, date bounds are inclusive calendar dates, filtered pages can be empty while still having next_page_token, include_completed also requests hidden tasks completed in Google apps, notes are omitted by default, and Docs/Chat-assigned tasks are omitted from default listings. These are substantive operational details an agent could not infer from annotations alone.

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 front-loaded with the core operation, then adds dense, useful behavioral details in short sentences. Every sentence earns its place by clarifying defaults, date semantics, pagination edge cases, or omissions.

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 an output schema and strong annotations, the description is nearly complete for a read-only listing tool: it covers default exclusions, date bounds, pagination edge cases, and optional fields. It is only slightly short of complete because page_size behavior and explicit alternative-tool routing are not addressed.

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 very low (14%), so the description must carry parameter meaning. It does this well for several parameters: task_list_id must be an exact ID, due bounds are inclusive YYYY-MM-DD dates, include_completed has a special hidden-task meaning, include_notes defaults off, and page_token can coexist with an empty filtered page. It still leaves page_size and page_token input semantics largely to the schema, preventing a 5.

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

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

The description states a specific verb and resource: 'Read one page of tasks from an exact list ID.' The scope constraint ('exact list ID') helps distinguish it from broader search tools, but it does not explicitly name or contrast with sibling tools such as search_tasks or get_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 usage by saying it requires an exact list ID and excludes completed tasks by default, but it never explicitly says when to use this tool versus search_tasks or get_task. The default behaviors provide useful context, but alternative routing is 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?

Goes beyond the annotations (readOnly=false, destructive=false, idempotent=false) by disclosing the native-API move, omission semantics for parent_id/previous_id, the cross-list restriction on repeating tasks, and that returned IDs should be reused. It does not mention permissions, error modes, or rate limits, so it is strong but not exhaustive.

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?

Four short sentences with the purpose front-loaded and no filler; each sentence carries real information (move, omission semantics, constraint, ID reuse). The closing "Use IDs returned by this call" is somewhat redundant given the output schema, but the overall structure is tight.

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?

Output schema and annotations already cover return values and safety, so the description needn't repeat them. For a 5-parameter mutation with low schema coverage, it leaves gaps: it does not explicitly distinguish source list from destination list, nor describe what happens when parent_id/previous_id are supplied together with a destination list. Adequate but incomplete.

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%, so the description must compensate; it explains omission behavior for parent_id and previous_id and gestures at destination_list_id via "optionally to another list." However, it never clarifies that task_list_id is the source list, nor the interaction between destination_list_id and parent_id/previous_id, leaving key semantics undocumented.

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 ("Move ... optionally to another list") and adds the implementation directive "Never copy then delete," which implicitly steers the agent away from using delete_task/create_task. It does not explicitly name or contrast with a sibling tool such as update_task, so sibling differentiation is implied rather than stated.

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

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

Provides clear context: omitting parent_id moves to the top level, omitting previous_id places the task first, and repeating tasks cannot move between lists (an explicit when-not constraint). It does not spell out alternatives by name or describe prerequisites/permissions, leaving some inference to the 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 annotations already declare non-destructive and idempotent behavior, and 'preserving its tasks' reinforces the non-destructive nature but adds limited extra disclosure. It does not describe permissions, error cases, or whether a title collision is allowed, so a 3 is appropriate given the annotation coverage.

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 with zero waste, and the key scoping constraint ('by exact ID') is front-loaded. Every part of the sentence contributes to understanding the operation.

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

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

An output schema exists, so the description need not explain return values; annotations cover safety and idempotency; and the schema documents the critical ID parameter. For a simple two-parameter rename tool this is largely sufficient, though it could mention title uniqueness or validation behavior.

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 with an exact-ID warning, and the description's 'by exact ID' echoes that; the title parameter is self-evident from its name and schema constraints. With 50% schema description coverage, the description does not add constraints or syntax beyond what the schema provides, so this meets the baseline 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 names the specific verb 'Rename' and resource 'task list', with additional scope from 'by exact ID' and 'preserving its tasks'. This makes it clearly distinguishable from delete_task_list and from create/get/list siblings without needing to name 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?

There is no explicit when-to-use or when-not guidance. It does not name alternatives such as delete_task_list or create_task_list, and only implies that this operation is for renaming by ID rather than by 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 the safety profile (readOnly=false, destructive=false, idempotent=true), so the bar is lower. The description adds the concrete state change — clearing the completion timestamp — which tells the agent exactly what is mutated; it stops short of saying what happens if the task isn't currently completed.

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 ten-word sentence that front-loads the action and its effect 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 rich annotations, full schema coverage, and an output schema that carries return values, the description covers what an agent needs to invoke it correctly. The only minor gap is the absence of behavior on a non-completed task.

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 both task_id and task_list_id documented as exact Google IDs rather than names. The description adds no parameter-level meaning beyond that, so the 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 ('Reopen') and resource ('a completed task') and adds the state effect ('clear its completion timestamp'). It is clearly the inverse of the sibling complete_task, though it never names that sibling explicitly.

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 intent to undo a completion is implied by 'Reopen a completed task', but there is no explicit when-to-use guidance, no alternative named (e.g. update_task), and no statement about prerequisites such as the task already being completed.

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 read-only, idempotent, non-destructive and open-world, but the description still adds real value: substring vs fuzzy matching semantics, the truncation contract (truncated=true means results are incomplete), and the paging bounds max_tasks/max_lists. What it omits is the default exclusion of completed tasks, which matters for interpreting results.

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, front-loaded with the matching semantics, then scope, then paging. The closing clause about 'ambiguous name-based mutations' is slightly defensive but does usefully signal this is a read-only path, so little 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?

An output schema exists, so return values need not be explained, and truncation is covered. But for a 6-parameter search tool with 0% schema coverage, the description leaves the agent guessing about the completed-task default and the relation between limit and max_tasks, which is short of complete.

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

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

Schema coverage is 0%, so the description carries the full burden and only partly does so: it explains task_list_id (null = scan multiple lists) and the max_tasks/max_lists paging caps. It says nothing about query, limit, or include_completed, and the include_completed default of false is a genuinely surprising behavior an agent cannot anticipate from the schema alone.

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 first sentence gives a specific verb (search) plus the searched fields (titles and notes) and the matching semantics (case-insensitive substring), which is more precise than the sibling list_tasks. It never names that sibling or get_task explicitly, so the agent must infer the boundary between searching and listing.

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?

'Omit task_list_id to scan multiple lists' gives one concrete usage rule, which is the strongest guidance present. There is no statement of when to prefer this over list_tasks or get_task, and no prerequisite or exclusion guidance beyond that single line.

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 discloses the core partial-update contract, including preservation of omitted fields and precise clearing semantics for notes and due dates. It also warns not to pass due and clear_due together, which is a meaningful behavioral constraint not captured in the schema.

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

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

The description is four short sentences, front-loads the patch semantics, then gives the two field-clearing rules and the sibling-tool routing. Every sentence carries actionable information.

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

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

For a mutation tool with an output schema already available, the description covers what an agent needs: partial-update behavior, preservation rules, clearing rules, conflict avoidance, and when to use sibling tools instead. No significant behavioral gap remains 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 description coverage is only 33%, so the description usefully compensates by explaining the ambiguous parameters: notes clearing via empty string, due preservation vs. clear_due removal, and the conflict between due and clear_due. It does not explicitly discuss title, but the patch-only framing covers it adequately and the ID parameters are documented in the schema.

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

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

The description uses a specific verb ('Patch') and clearly states the partial-update behavior: supplied fields are changed while all other task data is preserved. It distinguishes the operation from status changes and hierarchy moves by naming the sibling tools to use 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?

It explicitly routes the agent away from this tool for status and hierarchy changes, naming complete_task, reopen_task, and move_task as alternatives. It also gives concrete guidance on when to omit fields versus when to clear them, including the clear_due conflict.

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