Executes an explicit, already-approved list of changes against Todoist. ONLY call this with changes the user has explicitly approved ITEM BY ITEM in chat. Never infer, batch, or add a change the user did not individually confirm — if the user vetoed or didn't respond to an item, leave it out of the changes array entirely.

Each change is { taskId, action, params? } where action is one of:

• reschedule: params.dueDate (YYYY-MM-DD) OR params.dueString (Todoist natural language like "next monday"). Provide exactly one.

• set_priority: params.priority, an integer 1-4, sent RAW to the API — 4 is highest/urgent, 1 is normal (inverse of the UI's P1 label). Do not remap.

• move_to_project: params.projectName (a name, e.g. "Someday/Maybe"). The server finds the project by exact case-insensitive name, or creates it if missing, then moves the task there. This is the primary way to retire a task without deleting it.

• reword: params.content, the new task text.

• complete: no params. Marks the task done — the other way to retire a task.

• apply_label: params.label. Fetches the task, appends the label if not already present, and saves it.

There is NO delete action in this server — tasks are never destroyed, only completed or moved. split also does not exist in v1.

Input validation note: the changes array is validated as a whole against a strict schema before any writes happen. If ANY item is malformed (unknown action, missing required params, wrong type), the ENTIRE call is rejected and NOTHING is written — no partial execution of a batch that contained a bad item. This is deliberately the safer of two valid designs. Once validation passes, each item is executed independently and the result reports success/failure per item (so a live API failure on one item, e.g. a task that was deleted in Todoist meanwhile, does not stop the others).

Returns every currently-overdue Todoist task as weekly-review candidates: { id, content, projectId, projectName, priority, dueDate, daysOverdue, timesRescheduled? }.

This tool is READ-ONLY and writes nothing. After calling it, propose a fix for EACH task in chat (reschedule to a concrete date, change priority, or retire it via complete / move_to_project to a project like "Someday/Maybe") and get the user's explicit approval or veto PER ITEM before ever calling apply_changes. Never batch-apply changes the user hasn't individually confirmed.

Signal reading guide: higher daysOverdue and higher timesRescheduled together indicate a stronger candidate to RETIRE (complete or move to Someday/Maybe) rather than reschedule yet again — a task rescheduled 6 times is a task the user isn't going to do. A task that is merely a day or two overdue with 0 reschedules is a normal reschedule candidate. timesRescheduled is omitted entirely when Todoist didn't report it for that task.

IMPORTANT: priority is the raw Todoist API value (1-4) where 4 = highest/urgent and 1 = normal. This is the INVERSE of the Todoist UI's "P1" (P1 in the UI = API value 4). Do not remap it — read it as-is and account for the inversion when you describe it.

Returns every Todoist project as { id, name } (paginated to completion). Use this to see what projects already exist — in particular, to check whether a "Someday/Maybe" (or similarly named) retirement project already exists before proposing to move a task there. You do NOT need to create it yourself: apply_changes' move_to_project action finds-or-creates the target project by name automatically.