Skip to main content
Glama

tasks list tasks

tasks_list_tasks
Read-onlyIdempotent

Fetch tasks from a Google Tasks list, optionally including completed tasks from other Google apps. Use tasklist_id '@default' to target the default list.

Instructions

List tasks in a task list. Use tasklist_id '@default' for the default list.

show_completed=true also returns tasks completed in Google's apps.

Input Schema

NameRequiredDescriptionDefault
page_tokenNo
max_resultsNo
tasklist_idNo@default
show_completedNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare this as a read-only, idempotent, non-destructive operation, so the description does not need to repeat safety details. It usefully explains the show_completed behavior and the '@default' convention, but omits pagination behavior and what max_results controls.

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

Conciseness4/5

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

The description is short, front-loaded with the main action, and avoids repetition. The second sentence earns its place by clarifying a non-obvious parameter behavior.

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

Completeness3/5

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

An output schema exists, so return formatting need not be described. Still, for a list operation with four parameters and no schema descriptions, the definition should cover pagination and result-limit behavior to be fully complete.

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

Parameters2/5

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

Schema description coverage is 0%, so the description carries the full burden for four parameters. It adds meaning for tasklist_id and show_completed, but leaves page_token and max_results completely undocumented in both schema and description.

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

Purpose4/5

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

The description states a specific verb and resource: 'List tasks in a task list.' It is distinguishable from tasks_get_task and tasks_list_tasklists by name, but it does not explicitly contrast itself with those siblings.

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

Usage Guidelines3/5

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

It gives a concrete usage hint for the tasklist_id '@default' value and explains when show_completed=true matters. However, it does not say when to use this tool instead of siblings like tasks_get_task or tasks_list_tasklists.

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