Skip to main content
Glama
andreasd083

amazing-marvin-complete-mcp

update_task

Idempotent

Update an existing task's title, schedule, deadline, labels, note, estimate, or sections. Modify task fields directly to keep task details current.

Instructions

Update a task: title, day, deadline, labels, note, estimate, sections. Update fields on an existing TASK via /doc/update (Full Access Token). For categories/projects, use update_category_or_project. For priority, use set_priority. Always complete tasks via mark_done, never here. Strategy-dependent fields (start/end date, planned_week/month, review_date, backburner, orbit, the sections) can be set even when the strategy is disabled in the app — they just are not shown in the UI then. A clock time (Time/taskTime) and the task's reminder fields are set in the APP, not here — an MCP limitation (double-write sync, see set_reminder), NOT a Marvin limitation: Marvin fully supports times on tasks. Note on recurring tasks: never edit recurrence rules here — neither on a generated instance (recurring=true, id 'YYYY-MM-DD') nor on the generator document. Do that editing in the Marvin app. Simple field changes (title, note) on a single instance are fine. Note: Marvin's server can sporadically respond 500 on /doc/update (transient and atomic — no partial write); just retry. But a PERMANENT 500 (persists across retries) means the document does not exist — deleted, or a wrong/never-existing ID (the server responds 500 instead of 404 for missing IDs, verified live 2026-08-29). Fetch a fresh ID via get_categories/get_children.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dayNoSchedule on YYYY-MM-DD, 'today', or 'unassigned' to unschedule
noteNoNew note (replaces the existing one)
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)
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
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
custom_sectionNoID of a custom section from strategySettings.customStructure, '' removes
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. 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"
  2. 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"
  3. 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"
  4. 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)"
  5. 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)"
  6. First observedv1.3.0

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the annotations, disclosing the /doc/update write endpoint, Full Access Token requirement, MCP limitation around clock time/reminders, strategy-disabled fields still being settable, and the 500-vs-missing-ID server behavior. It also explains that a permanent 500 means a non-existent document. These are valuable behavioral traits not visible in the schema or annotations.

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

Conciseness5/5

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

The description is long, but it is densely informational and every sentence adds decision-relevant context. It is front-loaded with the core purpose, then covers routing, limitations, recurring-task warnings, and error semantics in a logical order. For a complex 23-parameter mutation tool with many verified edge cases, this length is justified.

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?

Given the tool's complexity, the rich schema, and the output schema, the description is complete: it covers auth, sibling routing, strategy interactions, recurring-task rules, and server error behavior. It does not need to explain return values because an output schema exists. Nothing critical for correct invocation is missing.

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 baseline is 3 and the schema already documents all 23 parameters in detail. The tool description adds a high-level field list but does not need to repeat per-parameter semantics. The schema's parameter descriptions carry the load effectively.

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?

The description opens with 'Update a task: title, day, deadline, labels, note, estimate, sections,' a specific verb plus resource. It explicitly routes category/project updates, priority changes, and completion to sibling tools, distinguishing update_task from update_category_or_project, set_priority, and mark_done.

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?

The description explicitly says when to use alternatives: 'For categories/projects, use update_category_or_project. For priority, use set_priority. Always complete tasks via mark_done, never here.' It also gives strong do-not-use guidance for recurring-task recurrence rules, telling the agent to edit those in the app.

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