grr

Overview Schema Source Related Servers Discussions Admin

tasks.tasks.move

Moves a task within its current list or to another task list, optionally changing its parent or sibling position.

Instructions

Moves the specified task to another position in the destination task list. If the destination list is not specified, the task is moved within its current list. This can include putting it as a child task under a new parent and/or move it to a different position among its sibling tasks. A user can have up to 2,000 subtasks per task [HTTP POST] — creates or triggers a change; refused under --readonly safety profiles. Returns the API's response resource as JSON — request bodies are built from the typed parameters (typed flags win over the params map), or read whole from body_file Siblings over the same resource: clear, delete, get, insert, list, patch, update.

Input Schema

Name	Required	Description
`task`	Yes	[URL path segment] Task identifier.
`query`	No	Extra KEY=VALUE query pairs for endpoints whose parameters Discovery does not describe.
`params`	No	Parameter map merged into the request; typed parameters win.
`parent`	No	[query parameter] Optional. New parent task identifier. If the task is moved to the top level, this parameter is omitted. The task set as parent must exist in the task list and c
`dry_run`	No	Return the request that would be sent, without sending it.
`previous`	No	[query parameter] Optional. New previous sibling task identifier. If the task is moved to the first position among its siblings, this parameter is omitted. The task set as previo
`tasklist`	Yes	[URL path segment] Task list identifier.
`body_file`	No	Read the request body from this file ('-' for stdin) instead of building one from the parameters.
`destinationTasklist`	No	[query parameter] Optional. Destination task list identifier. If set, the task is moved from tasklist to the destinationTasklist list. Otherwise the task is moved within its curr

Output Schema

Name	Required	Description	Default
`id`	No
`due`	No
`etag`	No
`kind`	No
`links`	No
`notes`	No
`title`	No
`hidden`	No
`parent`	No
`status`	No
`deleted`	No
`updated`	No
`position`	No
`selfLink`	No
`completed`	No
`webViewLink`	No
`assignmentInfo`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 26, 2026

changedInput schema / properties / destinationTasklist / description

Previous value: -"Optional. Destination task list identifier. If set, the task is moved from tasklist to the destinationTasklist list. Otherwise the task is moved within its curr"New value: +"[query parameter] Optional. Destination task list identifier. If set, the task is moved from tasklist to the destinationTasklist list. Otherwise the task is moved within its curr"

changedInput schema / properties / parent / description

Previous value: -"Optional. New parent task identifier. If the task is moved to the top level, this parameter is omitted. The task set as parent must exist in the task list and c"New value: +"[query parameter] Optional. New parent task identifier. If the task is moved to the top level, this parameter is omitted. The task set as parent must exist in the task list and c"

changedInput schema / properties / previous / description

Previous value: -"Optional. New previous sibling task identifier. If the task is moved to the first position among its siblings, this parameter is omitted. The task set as previo"New value: +"[query parameter] Optional. New previous sibling task identifier. If the task is moved to the first position among its siblings, this parameter is omitted. The task set as previo"

changedInput schema / properties / task / description

Previous value: -"Task identifier."New value: +"[URL path segment] Task identifier."

changedInput schema / properties / tasklist / description

Previous value: -"Task list identifier."New value: +"[URL path segment] Task list identifier."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "assignmentInfo": {
+      "properties": {
+        "driveResourceInfo": {
+          "properties": {
+            "driveFileId": {
+              "type": "string"
+            },
+            "resourceKey": {
+              "type": "string"
+            }
+          },
+          "type": "object"
+        },
+        "linkToTask": {
+          "type": "string"
+        },
+        "spaceInfo": {
+          "properties": {
+            "space": {
+              "type": "string"
+            }
+          },
+          "type": "object"
+        },
+        "surfaceType": {
+          "enum": [
+            "CONTEXT_TYPE_UNSPECIFIED",
+            "GMAIL",
+            "DOCUMENT",
+            "SPACE"
+          ],
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "completed": {
+      "type": "string"
+    },
+    "deleted": {
+      "type": "boolean"
+    },
+    "due": {
+      "type": "string"
+    },
+    "etag": {
+      "type": "string"
+    },
+    "hidden": {
+      "type": "boolean"
+    },
+    "id": {
+      "type": "string"
+    },
+    "kind": {
+      "type": "string"
+    },
+    "links": {
+      "items": {
+        "properties": {
+          "description": {
+            "type": "string"
+          },
+          "link": {
+            "type": "string"
+          },
+          "type": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "notes": {
+      "type": "string"
+    },
+    "parent": {
+      "type": "string"
+    },
+    "position": {
+      "type": "string"
+    },
+    "selfLink": {
+      "type": "string"
+    },
+    "status": {
+      "type": "string"
+    },
+    "title": {
+      "type": "string"
+    },
+    "updated": {
+      "type": "string"
+    },
+    "webViewLink": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedOct 26, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool is an HTTP POST that 'creates or triggers a change', is 'refused under --readonly safety profiles', enforces a 2,000-subtask-per-task limit, and returns the API response resource as JSON. It does not mention permission or auth requirements, so it is not fully comprehensive.

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 core purpose and destination-list behavior are front-loaded and easy to scan. The trailing request-body construction details and sibling list are somewhat meta and do not all earn their place, but the description remains reasonably efficient.

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

Completeness4/5

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

For a nine-parameter mutation tool with no annotations, the description provides meaningful context: mutation behavior, readonly refusal, a quota limit, return format, and request-body construction. It is complete enough to invoke safely, though it omits authorization requirements and some failure conditions already covered by the schema.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all nine parameters. The description adds some meaning by explaining destination-list omission and parent/sibling positioning, but most parameter-level semantics are already present in the schema descriptions.

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: 'Moves the specified task to another position in the destination task list.' It explains the within-list case and the parent/sibling repositioning cases. It does not meaningfully differentiate from siblings such as patch or update beyond listing their names, so it falls 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.

Usage Guidelines4/5

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

It clearly states when a destination list is omitted and what that means ('moved within its current list'), and it mentions moving under a new parent or among siblings. However, it does not explicitly say when to choose move over patch/update or other siblings, leaving that comparison to inference.

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

Deploy Server