list_tasks

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

With no annotations provided, the description carries the behavioral disclosure burden and largely succeeds. It documents defaults for max_results, show_completed, show_deleted, show_hidden, and show_assigned, and it surfaces the nuanced constraint that show_hidden must be true to include completed tasks from first-party clients. The read-only nature is implied by 'list' and the return description, though not explicitly stated.

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 one-sentence summary is front-loaded and the rest is a scannable Args/Returns layout. For a 13-parameter tool, every line earns its place by adding semantics that the schema does not provide.

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?

All 13 parameters are meaningfully described, defaults are explicit, pagination is covered, and the return type is specified. Since an output schema exists, detailed return-field documentation is unnecessary, and the tool is fully callable based on the description alone.

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 provides only names, types, and defaults, so its description coverage is effectively zero. The description compensates fully by explaining every parameter, including required user_google_email, max_results bounds, pagination via page_token, RFC 3339 date filters, and the behavioral meaning of each show_* flag.

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 starts with a specific verb and resource: 'List all tasks in a specific task list.' It clearly distinguishes this from siblings like list_task_lists, which lists task lists, and get_task, which fetches a single task. The required task_list_id parameter reinforces the intended scope.

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

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

The description implies the tool is for enumerating tasks within a known task list, and the required user_google_email and task_list_id make the basic usage context clear. However, it does not explicitly explain when to choose this over alternatives, such as get_task, manage_task, or list_task_lists.

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