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

Annotations already declare the important behavioral traits: not read-only, open-world, idempotent, and not destructive. The description adds only the core action, without extra context such as whether completion is reversible or what happens if the task is already 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?

The description is two short sentences, front-loads the action, and uses a concrete example without unnecessary wording.

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 three-parameter operation with full schema coverage and clear annotations, the description is adequate. It does not mention return behavior, but no output schema exists and the main action is clear.

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

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

Schema description coverage is 100%, so task_id, list_id, and response_format are already documented in the schema. The description does not add meaning beyond the schema, which is acceptable at the baseline for fully covered parameters.

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

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

States a specific verb and resource: "Mark a task as completed." This clearly distinguishes completion from sibling operations like update_task or delete_task, though it does not explicitly name those 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 example "mark the bank call as done" implies the intended use case, but it does not explain when to use this instead of gtasks_update_task or when not to use it. Guidance is present only by example.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is supplied. The description adds one genuinely non-obvious behavior beyond that: Google Tasks cannot store a time or a reminder. It does not mention that repeating the call duplicates tasks (relevant given idempotentHint=false) or what the call returns.

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 paragraphs plus a single arrow-style example, with the core action front-loaded and the date constraint immediately after. No sentence is redundant; the example is the only elaboration and it carries real 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 6-parameter create tool with no output schema and full schema coverage, the description fills the highest-risk gap (day-only due dates, no reminders) and shows a realistic invocation. It is nearly sufficient, with the only real omission being the absence of any note about duplicate creation on retry.

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 100% schema description coverage the baseline is 3, and the example earns a step up because it demonstrates how to decompose a natural-language request: the action becomes title="Call the bank" and the date becomes due="2026-11-10", while the word "remind" is correctly dropped. That mapping guidance is meaningfully beyond the field descriptions, though other parameters (notes, parent, list_id, response_format) get no mention.

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 concrete verb and resource ("Create a task in a list") that an agent can distinguish from gtasks_create_task_list, gtasks_update_task, and gtasks_get_task without opening the schema. It stops short of naming any sibling explicitly, so differentiation is inferred from the verb 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?

Usage is only implied: the name and the worked example make clear this is for creating new tasks, and the example shows how to map a user utterance into title/due. There is no explicit when-to-use or when-not-to-use guidance, e.g. no pointer to gtasks_update_task for modifying an existing task or a warning that a re-run creates a duplicate.

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, idempotentHint=false, openWorldHint=true, and destructiveHint=false, so the mutation and safety profile are covered. The description adds no behavioral context beyond that — nothing about duplicate-name handling, the 1024-character title limit, whether the list is created in the authenticated user's account, or what happens on failure.

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

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

Two short sentences, front-loaded with the action, with zero filler. The example is brief and reinforces the required parameter, though it occupies space without adding much the schema does not already say.

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 create tool with full schema coverage and annotations, the description is minimally sufficient. It omits what the tool returns (no output schema exists) and any note about duplicate or conflicting list names, which an agent would benefit from knowing before invoking a non-idempotent create.

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%, including constraints (minLength 1, maxLength 1024) and the response_format enum, so the schema does the heavy lifting. The example clarifies that 'title' is a human-readable list name, which is a small but real addition. 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 names a specific verb and resource ("Create a new Google Tasks list"), which is clearly distinguishable from siblings such as gtasks_list_task_lists and gtasks_delete_task_list. It does not explicitly name those siblings, but the create-vs-list-vs-delete contrast is unambiguous from the verb alone.

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 example phrase "create a list called Groceries" implicitly signals when to use it, but there is no statement about when not to use it, no mention of checking for existing lists first, and no reference to alternatives. Usage is inferable 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=true, so the safety profile is covered. The description adds genuinely new behavior: deletion cascades to subtasks and user confirmation is expected before invoking — both beyond what the annotations convey.

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

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

Three short sentences, front-loaded with the action and its cascade effect, followed by the alternative and the confirmation requirement. No wasted wording.

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 two-parameter tool with full schema coverage and rich annotations, the description covers the key risks (subtask cascade, irreversibility implied by the alternative suggestion) and the confirmation step. No output schema exists, but a delete operation's return value is not critical to explain.

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

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

Schema description coverage is 100%, with both list_id and task_id documented in the schema including their source tools and the '@default' meaning. The description adds no parameter-level detail, 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 and resource ('Delete a task') and adds the crucial scope detail that subtasks are deleted too. It is clearly distinguishable from gtasks_complete_task, which it names 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?

Gives an explicit alternative for the 'keep a record' case (gtasks_complete_task) and a prerequisite ('Confirm with the user first'). It does not spell out when deletion is inappropriate beyond that, but the routing guidance is clear.

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

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

Annotations already flag destructiveHint=true, but the description adds information annotations cannot convey: the deletion cascades to all contained tasks, it is irreversible, and the default list is protected. The confirmation requirement also signals a human-in-the-loop expectation, which is meaningful behavioral context beyond the hints.

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 destructive outcome and cascade, followed by the irreversibility warning, the exclusion, and the confirmation requirement. No filler or repetition of the tool name.

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

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

For a one-parameter delete operation with no output schema, everything an agent needs is present: what is destroyed, that it is permanent, what cannot be targeted, and that user confirmation is required. 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 the single parameter already documents its provenance ('from gtasks_list_task_lists'), so the description need not re-explain list_id. Baseline 3 applies because the description adds no additional semantics about the identifier.

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 ('Permanently delete a task list') plus the cascade scope ('AND all the tasks in it'), which clearly separates it from the sibling gtasks_delete_task that removes a single task. An agent can pick correctly without opening either schema.

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

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

Gives a required precondition ('Confirm with the user first') and a hard exclusion ('The default list cannot be deleted'), which prevents the most likely misuse. It does not name sibling alternatives (e.g., gtasks_delete_task for single tasks), but for a delete tool the exclusions are the practically important part.

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, so the safety profile is fully covered elsewhere. The description adds that notes and due date are part of the payload, which is useful return-shape context given there is no output schema, but it does not mention failure behavior for a missing or invalid task_id.

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

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

One short sentence with the key identifier constraint front-loaded and no filler. It is efficient, though the brevity leaves it close to under-specified rather than genuinely 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?

For a simple, fully annotated read tool with complete schema coverage, the description covers the core fetch and hints at returned fields. It omits what happens on a not-found task and does not note that list_id scopes the lookup, both of which an agent would want when calling it.

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 task_id, list_id (including the '@default' meaning) and the response_format enum all documented in the schema itself. The description only echoes the ID-based lookup and adds no format or scoping detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Get one task by ID') and names the two fields the caller receives, so an agent can distinguish a single-record fetch from the sibling gtasks_list_tasks. It stops short of explicitly naming that sibling as the 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?

The phrase 'by ID' implies a lookup when the identifier is already known, but there is no explicit statement of when to use this versus gtasks_list_tasks, nor any prerequisite that the ID must come from gtasks_list_tasks (that detail lives only in the schema).

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 safety profile needs no restating. The description adds the useful fact that results carry id and title and that the id is the join key for siblings, but it says nothing about pagination or result caps despite exposing a page_token and a 100-item limit.

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

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

Two sentences plus a short example, with the core action front-loaded and every element earning its place. Nothing is repeated from the schema or annotations.

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 zero-required-parameter list tool with a fully documented schema and no output schema, the description covers purpose, return fields, and the cross-tool linkage. Only pagination behavior is unaddressed, a minor omission given page_token's own schema description.

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 limit, page_token, and response_format are each documented in the schema itself and the baseline is 3. The description adds no additional meaning about when to raise the limit or how to page, so it neither compensates nor detracts.

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?

"List the user's Google Tasks lists" gives a specific verb and resource, and "(id and title)" discloses what comes back, which cleanly separates it from gtasks_list_tasks and gtasks_get_task. It stops short of naming a sibling explicitly, but the resource distinction 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?

The description supplies a concrete trigger example ("what lists do I have?") and explains the downstream usage of the returned id as list_id in the other tools, which is strong chaining guidance. It offers no when-not conditions or note on when to re-fetch versus cache, so it falls 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description wisely spends its budget on behavior instead: the pending-only default, inclusive date semantics, and the non-obvious rule that undated tasks vanish once a due_from/due_to filter is set. It omits any mention of pagination or result-size behavior, which is the remaining behavioral gap.

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?

Front-loaded with the one-sentence purpose, followed by default behavior and then three intent-to-parameter examples that each carry routing value. Slightly repetitive between the prose default and the example lines, 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?

With nine optional parameters and no output schema, the description adequately covers default filtering, date format, and the undated-task edge case. It leaves pagination (page_token, next_page_token) unaddressed, so an agent has no description-level cue that results may be truncated.

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

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

Schema coverage is 100%, so parameters are already documented; the description nevertheless adds real meaning beyond the schema by clarifying that due ranges are inclusive and by demonstrating how date filters and include_completed combine in practice. The interaction between include_completed and the completed_from/completed_to range is only shown by example rather than stated as a rule.

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 plus the scoping constraint ('in one list'), which distinguishes it from gtasks_get_task (single task) and gtasks_list_task_lists (lists themselves). It stops short of naming those siblings explicitly, so an agent infers the boundary rather than being told it.

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

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

Gives a clear default (pending only) and maps concrete user intents to parameter combinations ('what is due today or overdue?' -> due_to=<today>), which is strong when-to-use guidance. It does not state when to prefer a different tool or what to do when the list_id is unknown beyond the schema note pointing at gtasks_list_task_lists.

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 non-read-only, idempotent, non-destructive, open-world behavior, but they say nothing about partial-update semantics. The description adds the key trait that unspecified fields are left untouched, plus that due=null and notes=null actively clear data and that status='needsAction' reopens. It does not mention response shape or what happens on an invalid task_id, which keeps it off a 5.

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 core mutation semantics, then the null-clearing edge cases, then the sibling redirect. No filler and no restatement of the title.

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 7-parameter mutation tool with full schema coverage and no output schema, the description covers partial updates, clearing, reopening, and the sibling alternative. It leaves the return value and error behavior unstated, which is the only real 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%, so the baseline is 3, but the description adds a distinction the schema does not encode: omitting a field leaves it unchanged versus passing null clears it. The reopen behavior of status='needsAction' is repeated from the schema and adds no new meaning.

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 ('Change a task's title, notes, due date or status') and immediately narrows scope with 'Only the fields you pass are changed.' The explicit pointer to gtasks_complete_task separates it from the nearest sibling without opening any schema.

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

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

Names an alternative tool (gtasks_complete_task) and the exact condition that should route the agent there instead ('to simply finish a task'). It also gives the when-to-use rule for the null arguments, so both the tool choice and the invocation mode are covered.

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