Skip to main content
Glama
andreasd083

amazing-marvin-complete-mcp

update_task

Idempotent

Update a task: title, day, time, reminders, size, subtasks. /doc/update (Full Access Token). Categories/projects: update_category_or_project; priority and frog: set_priority; completion: mark_done.

Instructions

Update a task: title, day, time, reminders, size, subtasks. /doc/update (Full Access Token). Categories/projects: update_category_or_project; priority and frog: set_priority; completion: mark_done. Changing the day does what the app does: reminderTime and the server entry T move to the new day, own reminders (M) stay and are listed in the response. New clock time: new T, own reminders (including 'X min before') keep their time. time='' removes the clock time in the app's form. If the day is removed (day='unassigned') the clock time and T are removed as in the app; own reminders stay. Subtasks are written with dotted keys. parent_id or subtasks on a recurring occurrence give a warning: the recurring task stays as it is, so future occurrences follow it — change it with update_recurring_task. Strategy-dependent fields are stored even when the strategy is off in the app. A sporadic 500 on /doc/update is transient (retried once); a permanent 500 = the document does not exist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dayNoSchedule on YYYY-MM-DD, 'today', or 'unassigned' to unschedule
noteNoNew note (replaces the existing one)
sizeNoSize XS/S/M/L/XL (taskSize 1-5), '' removes (false)
timeNoClock time HH:MM (requires a day). Writes the app's form: taskTime, title prefix 'HH:MM ', reminderTime and a server entry of type T — the app reminds at that time. '' removes the time (update_task)
orbitNoOrbit strategy: True = put in orbit (verified in the app 2026-08-29: shows in the Orbit view + orbit icon in Today). UNDOCUMENTED field (missing from the official data types)
titleNoNew title
item_idYesTask ID
due_dateNoDeadline YYYY-MM-DD, or '' to remove
end_dateNoSoft deadline YYYY-MM-DD (Start & End Dates strategy), '' removes
label_idsNoNew labels (IDs from get_labels; replaces existing ones, [] removes all)
parent_idNoMove to category/project ID (not validated by the server — a wrong ID yields an orphan, live-tested 2026-08-29; repaired by running FIX_CYCLES() in the app's console)
remindersNoOwn reminders: 'HH:MM' on the task's day, or 'before:N' = N minutes before the clock time. Stored as the reminders list + one server entry of type M per reminder; before values are saved as an absolute time, as in the app. Without a day, today applies. Replaces the list; [] removes all own reminders
backburnerNoTrue = put in the backburner, False = take out. NOTE: only effective on an UNSCHEDULED task — set day='unassigned' at the same time; scheduling trumps the flag in the UI (verified in the app 2026-08-29)
start_dateNoStart date YYYY-MM-DD, '' removes. Mechanics (verified in the app 2026-08-29): the Start Dates strategy hides BACKBURNER items until their start date — combine with backburner=true and day='unassigned'; a scheduled task is not affected
review_dateNoReview date YYYY-MM-DD, '' removes. Verified in the app 2026-08-29: shows in the Review view on the date; the day-view banner additionally requires the Review Alert workflow snippet
planned_weekNoPlan into a week: the week's Monday YYYY-MM-DD (Planning Ahead strategy; verified in the app 2026-08-29 — also shows in the month view), '' removes. The app's view: clearing propagates server-side, but with Planning Ahead on (2026-08-29) the task stayed in the month view even after switching views — ask the user to reload the client (F5 in the web app/PWA, restart of the desktop app) before a missing render is taken for an error
subtasks_addNoNew subtasks (titles), added last
bonus_sectionNo'Essential' or 'Bonus' (bonusStructure strategy), '' removes
daily_sectionNoDay section 'Morning'/'Afternoon'/'Evening' (dailyStructure strategy), '' removes
no_auto_orbitNoOrbit strategy: True = exempt the task from automatic orbiting (auto-orbit otherwise pulls in scheduled tasks). UNDOCUMENTED field (bool type verified in live data 2026-08-29)
planned_monthNoPlan into a month: YYYY-MM (Planning Ahead strategy, verified in the app 2026-08-29), '' removes
reward_pointsNoReward points the task AWARDS on completion (coin + points in the list row when the Rewards strategy is on, verified in the app 2026-08-29), 0 removes. Do not set together with isReward
subtasks_doneNoSubtask ids to check off (ids from the task's subtasks)
custom_sectionNoID of a custom section from strategySettings.customStructure, '' removes
subtasks_renameNoSubtask id → new title
perma_snooze_timeNoHide the task every day until HH:mm (permaSnoozeTime), '' removes. Verified in the app 2026-08-29
time_block_sectionNoTime block ID (from get_today_time_blocks, or time_block_id from create_time_block), '' removes. Shows under the block's section in Today when Time Block Sections is on, the day view is grouped by time block (per device, not synced) and the task is scheduled on the block's day — see create_task
snooze_until_unix_msNoSnooze the task until unix time in milliseconds (itemSnoozeTime), 0 removes. Verified in the app 2026-08-29: hides from Today AND the category view (the wiki's 'everywhere except the master list' does not hold for the category view)
time_estimate_minutesNoTime estimate in minutes, 0 removes it

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.7.3
    • addedInput schema / properties / reminders
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Own reminders: 'HH:MM' on the task's day, or 'before:N' = N minutes before the clock time. Stored as the reminders list + one server entry of type M per reminder; before values are saved as an absolute time, as in the app. Without a day, today applies. Replaces the list; [] removes all own reminders"
      +}
    • addedInput schema / properties / size
      Added value: +{
      +  "anyOf": [
      +    {
      +      "enum": [
      +        "XS",
      +        "S",
      +        "M",
      +        "L",
      +        "XL",
      +        ""
      +      ],
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Size XS/S/M/L/XL (taskSize 1-5), '' removes (false)"
      +}
    • addedInput schema / properties / subtasks_add
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "New subtasks (titles), added last"
      +}
    • addedInput schema / properties / subtasks_done
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Subtask ids to check off (ids from the task's subtasks)"
      +}
    • addedInput schema / properties / subtasks_rename
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": {
      +        "type": "string"
      +      },
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Subtask id → new title"
      +}
    • addedInput schema / properties / time
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Clock time HH:MM (requires a day). Writes the app's form: taskTime, title prefix 'HH:MM ', reminderTime and a server entry of type T — the app reminds at that time. '' removes the time (update_task)"
      +}
  2. Changed1 schema field changedv1.7.1
    • changedInput schema / properties / time_block_section / description
      Previous value: -"Time block ID (from get_today_time_blocks, or time_block_id from create_time_block), '' removes. NOTE: stored, but gives no visible link in Today (verified in the app 2026-08-29 and 2026-09-13); in the app the link is carried by the block's own label/category/smart-list mapping — see create_task"New value: +"Time block ID (from get_today_time_blocks, or time_block_id from create_time_block), '' removes. Shows under the block's section in Today when Time Block Sections is on, the day view is grouped by time block (per device, not synced) and the task is scheduled on the block's day — see create_task"
  3. Changed1 schema field changedv1.7.0
    • changedInput schema / properties / time_block_section / description
      Previous value: -"Time block ID (from get_today_time_blocks), '' removes. NOTE: stored, but no visible section link renders in Today even with the strategy active (verified in the app 2026-08-29)"New value: +"Time block ID (from get_today_time_blocks, or time_block_id from create_time_block), '' removes. NOTE: stored, but gives no visible link in Today (verified in the app 2026-08-29 and 2026-09-13); in the app the link is carried by the block's own label/category/smart-list mapping — see create_task"
  4. Changed1 schema field changedv1.6.0
    • changedInput schema / properties / planned_week / description
      Previous value: -"Plan into a week: the week's Monday YYYY-MM-DD (Planning Ahead strategy; verified in the app 2026-08-29 — also shows in the month view), '' removes (client cache may linger until a view switch)"New value: +"Plan into a week: the week's Monday YYYY-MM-DD (Planning Ahead strategy; verified in the app 2026-08-29 — also shows in the month view), '' removes. The app's view: clearing propagates server-side, but with Planning Ahead on (2026-08-29) the task stayed in the month view even after switching views — ask the user to reload the client (F5 in the web app/PWA, restart of the desktop app) before a missing render is taken for an error"
  5. Changed1 schema field changedv1.4.2
    • changedInput schema / properties / parent_id / description
      Previous value: -"Move to category/project ID (not validated by the server — a wrong ID yields an orphan, live-tested 2026-08-29)"New value: +"Move to category/project ID (not validated by the server — a wrong ID yields an orphan, live-tested 2026-08-29; repaired by running FIX_CYCLES() in the app's console)"
  6. Changed1 schema field changedv1.4.0
    • changedInput schema / properties / parent_id / description
      Previous value: -"Move to category/project ID"New value: +"Move to category/project ID (not validated by the server — a wrong ID yields an orphan, live-tested 2026-08-29)"
  7. First observedv1.3.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say non-read-only, idempotent, non-destructive; the description adds the endpoint and auth requirement (/doc/update, Full Access Token), the day/time coupling (T entry moves, own M reminders stay), the outcome of day='unassigned', and failure semantics (transient 500 retried once, permanent 500 = missing document). These are behavioral facts the annotations cannot convey.

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?

Purpose and routing are front-loaded, and nearly every sentence carries a distinct behavior. Some lines are telegraphic to the point of opacity (the M/T entry shorthand, 'strategy-dependent fields are stored even when the strategy is off'), costing a little readability for a 29-parameter tool.

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

Completeness5/5

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

For a high-complexity mutation tool it covers the essentials: auth level, destructive-free semantics, edge cases around scheduling and recurrences, and error transience. An output schema exists, so the description is not obligated to explain return values, and it correctly limits itself to noting reminders are echoed back.

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 cross-parameter meaning the per-field schema text cannot: changing the day relocates reminderTime and the T entry while own reminders remain, and subtasks are written with dotted keys. It stops short of documenting most of the 29 fields, which the schema already handles.

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

Purpose5/5

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

Opens with a specific verb+resource plus an enumeration of the updatable surface ('Update a task: title, day, time, reminders, size, subtasks'). It also routes three adjacent operations to their own tools (update_category_or_project, set_priority, mark_done), so an agent can distinguish it from siblings without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit when-not guidance: categories/projects, priority/frog, and completion belong to other tools, and changes to a recurring task belong in update_recurring_task. The warning that parent_id/subtasks on a recurring occurrence leave the recurrence untouched is exactly the kind of exclusion that prevents a wrong call.

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