amazing-marvin-complete-mcp

create_task

Instructions

Create a task with category, day, priority, size, time and reminders. The title is stored verbatim: the server's shortcut parsing is disabled (X-Auto-Complete: false), so '#Category', '~15', '*m' and '*p2' are NOT parsed — '#' in titles is safe. Use the parameters instead. startDate/endDate are set with update_task afterwards (/addTask ignores them). Size, subtasks, clock time and reminders are written in a second step with /doc/update and /reminder/set in the app's form; if a step fails the response says which ones were done (the task then already exists). A clock time requires day. Strategy-dependent fields (planned_week/month, review_date, backburner, reward_points, the sections) are stored even when the strategy is off in the app.

Input Schema

TableJSON Schema

Name	Required	Description
`day`	No	Schedule on date YYYY-MM-DD, 'today', or 'unassigned' (= unscheduled, same as omitting). Same rules as update_task.
`frog`	No	Dread/frog 1-4 (read in the app, 2026-10): 1=I dread this a little (A little), 2=I dread this (Dread), 3=I dread this a lot (A lot), 4=This might kill me (Toxic — requires 'Enable toxic frog level' in the account; Simple mode shows only one level)
`note`	No	Note (markdown; '- ' at line start is written as '* ', see list_capabilities.note_format)
`size`	No	Size XS/S/M/L/XL (taskSize 1-5). XS and XL can be disabled in the account. Written with /doc/update after creation (/addTask drops the field)
`time`	No	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)
`title`	Yes	Task title
`due_date`	No	Deadline YYYY-MM-DD (use sparingly)
`priority`	No	Priority (isStarred): 3=Most important/red, 2=Very important/orange, 1=Important/yellow, -1=Low priority (down arrow; shown in the app only with 'Enable low priority' on in the Priorities strategy — the value is stored regardless). 0 is not valid here; omit for no priority
`subtasks`	No	Subtasks (titles), written after creation
`is_reward`	No	Documented Task field with no observed function — normally do NOT use. The app's purchasable rewards are separate Rewards documents that the public API cannot reach at all (live-tested 2026-08-29: no endpoint exists, and app rewards are not Tasks); the flag on a Task produced no UI effect. Never combine with reward_points
`label_ids`	No	Label IDs (from get_labels)
`parent_id`	No	ID of the category/project the task belongs in (from get_categories). Omit for the Inbox. NOTE: the server does not validate the ID — a wrong parentId yields an orphan reachable only via date reads (live-tested 2026-08-29); repaired by running FIX_CYCLES() in the app's console
`reminders`	No	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
`backburner`	No	True = put in the backburner (dormant). NOTE: only effective on an UNSCHEDULED task — scheduling (day) trumps the flag in the UI (verified in the app 2026-08-29), so do not combine with day
`review_date`	No	Review date YYYY-MM-DD (Review Date strategy)
`planned_week`	No	Plan into a week: the week's Monday YYYY-MM-DD (Planning Ahead strategy)
`bonus_section`	No	'Essential' or 'Bonus' (bonusStructure strategy)
`daily_section`	No	Day section: 'Morning', 'Afternoon' or 'Evening' (dailyStructure strategy)
`planned_month`	No	Plan into a month: YYYY-MM (Planning Ahead strategy)
`reward_points`	No	Reward 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; points are claimed via claim_reward_points). Do not set together with is_reward
`custom_section`	No	ID of a custom section from strategySettings.customStructure (customStructure strategy)
`time_block_section`	No	Time block ID (from get_today_time_blocks, or time_block_id from create_time_block). Points the task at a time block; the task then appears under that block's section in Today. Three conditions (verified in the app 2026-09-17, 1.70.0.0, PWA + desktop): (1) the Time Block Sections strategy is on, (2) the day view is grouped by time block (Group by → Group by time block section — set per device, not synced; help article 1950243), (3) the task is scheduled on the block's day (day ≤ that date) — an unscheduled task with the field set is stored but does not appear in Today at all. Without (2) no sections render and the field looks inert. The field is sufficient on its own: the block needs no label/category/smart list, and blocks from create_time_block behave like blocks created in the app. The block's own Smart Time Block mapping (label/category) is a second, independent route that catches matching tasks without this field. The section shows before the block's start time (after its end: untested). The field is not exposed in the app's task settings — the app sets it when a task is added directly inside a block section
`time_estimate_minutes`	No	Time estimate in minutes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv1.7.3Oct 13, 2026

changedInput schema / properties / frog / anyOf

Previous value: -[
-  {
-    "maximum": 3,
-    "minimum": 1,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maximum": 4,
+    "minimum": 1,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / frog / description

Previous value: -"Frog marker 1=normal, 2=baby, 3=monster"New value: +"Dread/frog 1-4 (read in the app, 2026-10): 1=I dread this a little (A little), 2=I dread this (Dread), 3=I dread this a lot (A lot), 4=This might kill me (Toxic — requires 'Enable toxic frog level' in the account; Simple mode shows only one level)"

changedInput schema / properties / note / description

Previous value: -"Note (markdown)"New value: +"Note (markdown; '- ' at line start is written as '* ', see list_capabilities.note_format)"

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"
+}

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). XS and XL can be disabled in the account. Written with /doc/update after creation (/addTask drops the field)"
+}

addedInput schema / properties / subtasks

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Subtasks (titles), written after creation"
+}

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)"
+}

Changed1 schema field changedv1.7.1Sep 18, 2026

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). NOTE: stored, but gives no visible link in Today (verified in the app 2026-08-29, and re-verified 2026-09-13 with app 1.70.0.0, PWA + desktop, Time Blocking on). In the app the link is carried by the block's own mapping to a label/category/smart list (see get_today_time_blocks), and a block shows its tasks only during its own clock time — to make a task appear in a block, give the block a category in the app and put the task there. Reported upstream"New value: +"Time block ID (from get_today_time_blocks, or time_block_id from create_time_block). Points the task at a time block; the task then appears under that block's section in Today. Three conditions (verified in the app 2026-09-17, 1.70.0.0, PWA + desktop): (1) the Time Block Sections strategy is on, (2) the day view is grouped by time block (Group by → Group by time block section — set per device, not synced; help article 1950243), (3) the task is scheduled on the block's day (day ≤ that date) — an unscheduled task with the field set is stored but does not appear in Today at all. Without (2) no sections render and the field looks inert. The field is sufficient on its own: the block needs no label/category/smart list, and blocks from create_time_block behave like blocks created in the app. The block's own Smart Time Block mapping (label/category) is a second, independent route that catches matching tasks without this field. The section shows before the block's start time (after its end: untested). The field is not exposed in the app's task settings — the app sets it when a task is added directly inside a block section"

Changed1 schema field changedv1.7.0Sep 13, 2026

changedInput schema / properties / time_block_section / description

Previous value: -"Time block ID (from get_today_time_blocks). NOTE: stored, but no visible section link renders in Today even with the Time Block Sections strategy active (verified in the app 2026-08-29) — visible section assignment is done in the app"New value: +"Time block ID (from get_today_time_blocks, or time_block_id from create_time_block). NOTE: stored, but gives no visible link in Today (verified in the app 2026-08-29, and re-verified 2026-09-13 with app 1.70.0.0, PWA + desktop, Time Blocking on). In the app the link is carried by the block's own mapping to a label/category/smart list (see get_today_time_blocks), and a block shows its tasks only during its own clock time — to make a task appear in a block, give the block a category in the app and put the task there. Reported upstream"

Changed1 schema field changedv1.6.0Sep 12, 2026

changedInput schema / properties / day / description

Previous value: -"Schedule on date YYYY-MM-DD, or 'today'. Omit for unscheduled."New value: +"Schedule on date YYYY-MM-DD, 'today', or 'unassigned' (= unscheduled, same as omitting). Same rules as update_task."

Changed1 schema field changedv1.4.2Aug 31, 2026

changedInput schema / properties / parent_id / description

Previous value: -"ID of the category/project the task belongs in (from get_categories). Omit for the Inbox. NOTE: the server does not validate the ID — a wrong parentId yields an orphan reachable only via date reads (live-tested 2026-08-29)"New value: +"ID of the category/project the task belongs in (from get_categories). Omit for the Inbox. NOTE: the server does not validate the ID — a wrong parentId yields an orphan reachable only via date reads (live-tested 2026-08-29); repaired by running FIX_CYCLES() in the app's console"

Changed3 schema fields changedv1.4.0Aug 30, 2026

changedInput schema / properties / parent_id / description

Previous value: -"ID of the category/project the task belongs in (from get_categories). Omit for the Inbox."New value: +"ID of the category/project the task belongs in (from get_categories). Omit for the Inbox. NOTE: the server does not validate the ID — a wrong parentId yields an orphan reachable only via date reads (live-tested 2026-08-29)"

changedInput schema / properties / priority / anyOf

Previous value: -[
-  {
-    "maximum": 3,
-    "minimum": 1,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maximum": 3,
+    "minimum": -1,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / priority / description

Previous value: -"Priority 1-3 (3=red/highest, 2=orange, 1=yellow)"New value: +"Priority (isStarred): 3=Most important/red, 2=Very important/orange, 1=Important/yellow, -1=Low priority (down arrow; shown in the app only with 'Enable low priority' on in the Priorities strategy — the value is stored regardless). 0 is not valid here; omit for no priority"

First observedv1.3.0Aug 29, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Annotations only say it is not read-only, not idempotent and not destructive; the description goes well beyond them by disclosing that shortcut parsing is disabled (X-Auto-Complete: false), that size/subtasks/time/reminders are written in a second step via /doc/update and /reminder/set, and that a partial failure leaves a task that already exists with the response naming which steps succeeded. That partial-success semantics is exactly the kind of behavioral trait an agent must know to avoid duplicating a task.

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 action is front-loaded in one short sentence before the caveats, which is the right ordering for a 23-parameter tool. The remaining text is dense and clause-heavy with parenthetical asides, but each statement carries operational information rather than filler.

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 not be explained, and the description still covers the important exception: partial-step failure reporting. For a creation tool with heavy strategy-dependent fields and a two-phase write, the non-obvious cross-field constraints are surfaced, though the relationship to sibling creation tools remains unaddressed.

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% and every parameter carries a detailed description, so the schema already does the heavy lifting and a 3 is the baseline. The description reinforces a few cross-cutting rules (clock time requires day, strategy-dependent fields are stored even when the strategy is off) but adds no per-parameter syntax or format detail beyond what the schema supplies.

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 opening sentence states a specific verb and resource plus the field families it accepts ('Create a task with category, day, priority, size, time and reminders'), so an agent can identify it immediately. It does not name or distinguish itself from near siblings such as create_recurring_task or create_event, which is the only gap.

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?

It routes some work elsewhere ('startDate/endDate are set with update_task afterwards', 'Use the parameters instead' of inline shortcuts), which is genuine when-to-use guidance. However, there is no explicit statement of when to prefer this over create_recurring_task/create_event, nor of prerequisites such as needing a day before a clock time presented as a usage rule.

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

Deploy Server