Todoist AI MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

reorder-objects

Idempotent

Reorder Todoist projects and sections by position, and move personal projects to a new parent or root. Sets sibling order and hierarchy changes in one call.

Instructions

Reorder projects or sections, and optionally move personal projects to a new parent. Personal projects: order places a project among its siblings; parentId moves it ("root" for top level). Workspace projects: order places a project within its folder, in the shared default ordering every member sees; needs permission to reorder the workspace. Sections: order places a section within its project.

Input Schema

Name	Required	Description	Default
`type`	Yes	"project": personal projects among the siblings under their parent, or workspace projects within their folder. "section": sections within their project.
`items`	Yes	Each item needs order and/or parentId. Moves happen first, so order is a position under the new parent.

Output Schema

Name	Required	Description
`type`	Yes	The type of entity that was reordered/moved.
`success`	Yes	Whether every entity was moved and reordered as asked.
`failures`	Yes	Entities that could not be moved or reordered, with the reason for each.
`movedCount`	Yes	The number of entities moved to a new parent.
`affectedIds`	Yes	The IDs of the entities moved or reordered.
`reorderedCount`	Yes	The number of entities reordered.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv13.8.4Nov 2, 2026

changedInput schema / properties / items / description

Previous value: -"The items to reorder or move. Each item must have at least order or parentId. Items with parentId will be moved first, then items with order will be reordered. All items being reordered should be siblings for predictable results."New value: +"Each item needs order and/or parentId. Moves happen first, so order is a position under the new parent."

changedInput schema / properties / items / items / properties / order / description

Previous value: -"The new position/order value for the entity. Lower values appear first."New value: +"0-based position among its siblings after the reorder: 0 is first, past the end is last. Unlisted siblings keep their relative order."

changedInput schema / properties / items / items / properties / parentId / description

Previous value: -"Move a project to be a sub-project of this parent project ID, or use \"root\" to move to the top level. Only valid when type is \"project\"."New value: +"Move a personal project under this parent project ID, or \"root\" for the top level. Personal projects only."

changedInput schema / properties / type / description

Previous value: -"The type of entity to reorder. \"project\" reorders sibling projects within the same parent (and can move projects to a new parent). \"section\" reorders sections within the same project."New value: +"\"project\": personal projects among the siblings under their parent, or workspace projects within their folder. \"section\": sections within their project."

changedOutput schema / properties / affectedIds / description

Previous value: -"The IDs of all affected entities."New value: +"The IDs of the entities moved or reordered."

addedOutput schema / properties / failures

Added value: +{
+  "description": "Entities that could not be moved or reordered, with the reason for each.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "code": {
+        "type": "string"
+      },
+      "error": {
+        "type": "string"
+      },
+      "item": {
+        "description": "Usually the ID of the item that failed.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "item",
+      "error"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / properties / success / description

Previous value: -"Whether the operation was successful."New value: +"Whether every entity was moved and reordered as asked."

changedOutput schema / required

Previous value: -[
-  "type",
-  "movedCount",
-  "reorderedCount",
-  "affectedIds",
-  "success"
-]New value: +[
+  "type",
+  "movedCount",
+  "reorderedCount",
+  "affectedIds",
+  "failures",
+  "success"
+]

Changed2 schema fields changedv13.0.0Aug 20, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv10.4.2Jul 9, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare it non-read-only, idempotent, non-destructive, and closed-world. The description adds genuinely non-obvious context beyond that: workspace ordering is a shared default every member sees, reordering a workspace requires permission, and moves are applied before order positions so order is evaluated under the new parent.

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?

Front-loaded lead sentence states the full scope, followed by one sentence per entity type, which is an easy-to-scan structure. It is efficient overall, though the per-type sentences restate schema wording closely, so some content is duplicated rather than additive.

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?

An output schema exists, so return values need no explanation, and the permissions and ordering semantics are covered. It does not address partial-failure or atomicity behavior across the `items` array, which would matter for a batched mutation, leaving a small completeness gap.

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

Parameters4/5

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 real meaning: `order` is sibling-relative per entity type, workspace ordering is shared across members, and `parentId` accepts "root" and is personal-projects-only. It is largely a mirror of the schema text, which keeps it out of 5 territory.

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?

States a specific verb and resource ("Reorder projects or sections") and immediately disambiguates the three modes it covers: personal projects, workspace projects, and sections. It gives no differentiation from the sibling `project-move` tool, which appears to overlap with the parentId move behavior, 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 Guidelines3/5

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

Usage is implied rather than stated: the reader can infer that `order` reorders within siblings and `parentId` relocates a personal project, and it notes the workspace permission prerequisite. There is no explicit when-not-to-use guidance and no routing to alternatives such as `project-move` or `update-projects`.

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